Java 12's JVM Constants API explained in 5 minutes

This month we are focusing on Java 12 new features you should know about. In other articles, we looked at improvements to Garbage Collection, Java 12 made microbenchmarking easier and Java 12 Switch Expressions explained in 5 minutes

In this article, we are looking at the JVM Constants API.

The purpose of this new API (JEP 344) is to make it easier for programs that manipulate class files to model bytecode instructions, which have to handle loadable constants. This is a very technical change, so it is more about helping the developers of Java to make it better than giving general developers a specific new feature.

So firstly, what are loadable constants?

Every Java class has something called a constant pool table. Each entry in the table is a loadable constant and has the following format:

cp_info {
    u1 tag;
    u1 info[];
}

The tag specifies what type the constant is, 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 (this differs depending on the type).

JVM instructions, e.g. ldc and invokedynamic 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 therefore deal with loadable constants). If the constant type is something like a String or an Integer, this works without issue. But it can become complicated if the constant type is a Class.

Loading classes is not always straightforward, and there are several ways it can fail, for example if the Class does not exist or cannot be accessed.

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.

An example of a class that will benefit from this new feature is LambdaMetaFactory, which provides bootstrap methods for invokedynamic call sites. The new API will mean that how this class works can be hugely simplified.

Jlink plugins will also benefit, as they have to deal with classes which are not yet available when they are described.

What are your thoughts on the changes?