On Thu, 13 Apr 2023 12:07:00 GMT, Jan Lahoda <jlah...@openjdk.org> wrote:
>> Note that currently, a `switch` over an enum will already trigger >> initialisation of the enum class because of the need to compute the relevant >> mapping array by the synthetic helper class, see [JDK‑7176515] for details. >> - https://github.com/openjdk/jdk/pull/10797 >> >> [JDK‑7176515]: https://bugs.openjdk.org/browse/JDK-7176515 "[JDK‑7176515] >> ExceptionInInitializerError for an enum with multiple switch statements" > > FWIW, a sketch on how avoiding the enum initialization might look like is > here: > https://github.com/lahodaj/jdk/compare/JDK-8300543...lahodaj:jdk:JDK-8300543-lazy-enum?expand=1 > > more work needed to make that work for `typeSwitch`, and to combine that with > #9779. FWIW... an observation from working on [JDK-7176515](https://bugs.openjdk.org/browse/JDK-7176515). This is probably redundant but here goes anyway. In the compiler there are currently three different ways of handling enums in switch statements: 1. The old way, where a separate lookup class is generated for traditional switch-on-enum statements 2. The `ordinal()` way, which is an optimization available when the `enum` type is defined in the same file as the `switch` statement (what JDK-7176515 adds) 3. The new way using bootstrap methods, which is used by the pattern matching stuff My observation is simply that the old way <span>#</span>1 should be completely eliminated and folded into <span>#</span>3. <span>#</span>1 is just a hold-over from before INVOKEDYNAMIC. Using a bootstrap method is "the right way" to handle enums. Instead, traditional switch-on-enum should be handled as a degenerate case of pattern switch with enums. This will simplify the code and eliminate the ugly extra lookup class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1167032116
