Some quick background on the putative benefits of this feature (and why
we're investing in it):
- Lazy constant loading. Currently, constructing a Class, MethodType,
or MethodHandle in a <clinit> forces eager class loading, which (a)
contributes to startup and (b) potentially leads to bootstrap loops.
Being able to express an LDC from nominal inputs in Java means constant
resolution can be delayed with no loss of performance.
- Indy. Right now, there's no nonreflective way to encode an indy in
Java source code. As we use indy more and more, this becomes an
increasingly bigger problem, especially for testing.
- Nominal carriers for bytecode and compiler plugin APIs. Bytecode
APIs and compiler plugins need a way to describe classfile constants,
both on the generation and parsing side. The "live types" (Class,
MethodType, MethodHandle) are unsuitable because the classes being
described may not be loadable. This forces API designers into ad-hoc
encodings, either abusing strings, or defining one-off classes.
- Static opt-out of indy-driven language features. As we have more
language features that use indy (lambda, string concat, maybe soon
switch classifiers), we need a way to opt out of using indy in targeted
ways (globally for AOT, locally for bootstrap avoidance). However, we
don't want to force the compiler to understand the semantics of each
bootstrap; ideally, bootstraps can be expressed in both nominal and
"live" forms, and the compiler can choose which it wants. If the types
representable in in the constant pool have both live and nominal
representations that can be freely converted to each other, this reduces
the code duplication we might otherwise encounter in static-izing indy
sites. There's a long road to get here, but this is almost certainly
part of the solution.
