JVM Constants API: —
The purpose of implementing new constants API is to make it easier for programs that manipulate class files to model bytecode instructions, which have to handle loadable constants.
Broadly speaking every Java class has a constant pool which stores the operands for bytecode instructions in the class. and It also has a constant pool, Each entry in the table is a loadable constant and has the following format:
The tag specifies what type the constant is —
For E.g:- 7 means it’s Class, 10 is a Method Reference, 8 is a String, etc…
The info array gives more information about the constant depending on the constant type.
JVM instructions, e.g. LDC and invoke dynamic instructions, rely on the information in this table (rather than the run-time layout of classes, interfaces, etc). When these instructions are executed, the loadable constant becomes a live value, E.g. a Class, String, int, etc.
Programs that work with class files have to model these bytecode instructions and deal with the loadable constants. If the constant type is something like a String or an Integer, this works without issue because those are primitive data types. But when it comes to classes and interfaces it becomes more complicated.
Loading classes are not always straightforward, and there are several ways it can fail, for example, if the Class does not exist or cannot be accessed. then it might cause an issue, To avoid that problem —
This is where JEP 334 comes in.
In Java 12 there is now an API so that these values can be handled symbolically. For example, there is an interface called ClassDesc which can be used to symbolically represent a loadable constant of type Class, MethodHandleDesc to represent method handle constants, MethodTypeDesc to represent method type constants and so on.