The implementation uses invokedynamic (which has been available for ages) and dispatches to java.lang.runtime.SwitchBootstraps#typeSwitch(…): https://docs.orac

The implementation uses invokedynamic (which has been available for ages) and dispatches to java.lang.runtime.SwitchBootstraps#typeSwitch(…): https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/lang/runtime/SwitchBootstraps.html#typeSwitch(java.lang.invoke.MethodHandles.Lookup,java.lang.String,java.lang.invoke.MethodType,java.lang.Object https://docs.oracle.com/en/java/javase/20/docs/api/java.base......) The concrete implementation in doTypeSwitch currently says “Dumbest possible strategy”: https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java https://github.com/openjdk/jdk/blob/master/src/java.base/sha... There is no @IntrinsicCandidate, so I don't expect Hotspot to special-case any of this yet. The machinery described so far merely computes an array index, and there is a subsequent lookupswitch opcode that selects the appropriate case body to run. I'd be somewhat surprised if Hotspot could unroll the checking loop and eliminate the subsequent switch. So the Java implementation looks rather bad from a performance point of view (but it's obviously designed for compact bytecode and future optimization). Scala could certainly do the same (the magic of invokedynamic is that it's not magic), and probably much better in many cases, even on current Hotspot.