[JEP Proposal] Constant-Time Enum Size Access (https://gist.github.com/TuranDev/9a20c773d8c698de918da54b2964bf65)

[Turan Suleyman]

Thanks both for the feedback.

So to the problem. In low-latency (nanosecond sensitivity) or gc sensitive systems, it’s common for frameworks, dispatch loops, and state machines to query enum metadata on the critical path.
Even small, repeated array allocations (from values()) show up as avoidable GC pressure and measurable CPU cost under load.

Examples I’ve seen in practice where this occurs include:
- HFT / real-time systems using enums for event codes, message categories, FIX tags
- protocol engines where enums represent message types
- parsers/tokenizers using enums for token types
- table-driven state machines that query enum sizes on each transition

Regarding the backwards compatibility comment, I understand a static SIZE field could conflict with existing code, which is why I also suggested a compiler-generated size() method.
Enums already reserve compiler-generated methods like values() and valueOf(String).
If a size() method were considered useful, javac would also reserve that name in the same way and emit a clear diagnostic on conflict. This would follow existing precedent.

On the suggested solution of:

enum MyEnum {
  public static final List<MyEnum> VALUES = List.of(MyEnum.values());
}

Yes, it’s possible to write (and myself and others already leverage such patterns or utils as workarounds) but they have to be manually added to every enum and cannot be relied on by frameworks or libraries.
They’re workarounds for something the compiler knows statically.

I guess to summarise the overall point of raising this is that many performance critical systems end up reinventing their own cached size patterns, suggesting (atleast in my eyes) that there is a missing language-level mechanism.

Thanks again for taking the time to review this and offer guidance.

Turan

On Tuesday, 18 November 2025 at 23:22, Ron Pressler <ron.pressler at oracle.com> wrote:

> Before proposing anything, I would start with focusing on the problem.
> 
> You mention allocation and performance, but not every `new X[3]` necessarily allocates anything, and even when it does, there isn’t necessarily a performance issue. Even if there is a problem, a size method or field is not necessarily the right solution.
> 
> So it’s best to first identify a problem and then let the JDK maintainers come up with an appropriate solution. Do you have an example of a real program where obtaining the number of enum values makes up a significant portion of the profile and/or causes some memory-related issues?
> 
> — Ron
> 
> P.S.
> 
> Your document mentions “zero-GC”, and I just want to point out that with the JDK’s more modern GCs, zero runtime allocations does not mean zero GC. In fact, allocating a new object can result in less GC work than mutating and sometimes even reading an old object. An allocation rate that’s too high can cause a lot of GC work, but so can an allocation rate that’s too low (not with the old GCs, but with the new ones). Avoiding allocations is no longer a good approach to minimising latencies in recent versions of the JDK.
> 
> > On 18 Nov 2025, at 23:04, Turan Suleyman turansuleyman at proton.me wrote:
> > 
> > Hi all,
> > I’d like to start a discussion/gather feedback about a "small" quality of life enhancement to java.lang.Enum to add a constant-time, allocation-free way to obtain the number of constants in an enum type.
> > Today, the usual approach is: int n = MyEnum.values().length;
> > This creates a new array on every call, which is both non-constant time and allocates memory unnecessarily.
> > Since the number of enum constants is fixed and known at compile time, this information could be exposed more efficiently.
> > I’ve written a draft JEP describing two possible designs:
> > • A compiler-generated static constant, e.g.
> > public static final int SIZE = <number of constants>;
> > • A built-in API method such as
> > MyEnum.size();
> > Draft JEP: https://gist.github.com/TuranDev/9a20c773d8c698de918da54b2964bf65
> > I’d appreciate feedback on:
> > • Whether this seems like a worthwhile enhancement
> > • Preference between the two design options
> > • Whether anyone would be interested in sponsoring the JEP ( or rolling the change into an open piece of work) if there’s agreement to pursue it.
> > Thank you for your time and thoughts.
> > Best regards,
> > Turan