A couple of months ago, Oracle JVM architect John Rose, and Oracle Java language architect Brian Goetz, published the first minimal value type proposal. Value types will provide developers with the capability to define new types that share some of the semantics of primitives. The objective of this initial proposal is simply to allow prototyping, experimentation, and the production of the first micro-benchmarks; since the final version is not expected until Java 10, the proposal adds only one new bytecode instruction to support value types, and defers any Java language changes for a future version.
Since the Java language itself is not being modified as part of this proposal, the only way to make use of the new features will be directly through the relevant bytecode constructs. This means that only developers who work on bytecode generation tools, such as JVM language developers, will have access to value types. On top of this, the value types capabilities will only be available for classes denoted and constructed to that effect, which are loaded into specific value-capable modules, and which are present in class files of a specific major and minor version. This heavily sandboxed approach ensures that advanced users can access the new capabilities, while ordinary users can still use the new versions of the JVM without stumbling upon issues.
The full set of changes to support this first version of value types can be found on the proposal but can be summarised in the following four items:
- A new annotation called @DeriveValueType to tell the JVM about value-capable types. It's important to distinguish here between value-types and value-capable types. Value-capable types are ordinary Java classes that the JVM can use to generate a value type. If value types are not enabled, then the value-capable type is just an ordinary class.
- Extension of the class file format to add the definition of a new Q-Type descriptor. The current class file format defines type signatures with a letter, including both primitives (I for integer, C for character, etc) and what is called an L-Type for objects (L followed by the fully qualified name of the class, like "Ljava/lang/String;"). The Q-Type will work in a similar way to an L-Type, but it will be specific to value-types (and its descriptor will start with the letter Q).
- One new bytecode instruction, called "typed", to move Q-Types to and from the stack. The new instruction will work as a kind of macro-instruction, meaning it can be combined with other existing instructions to create the effect of multiple new bytecodes being available. This approach will provide "typed" with two parameters: an index pointing to the definition of the Q-Type, so the JVM knows what it needs to load or store, and another bytecode, indicating the operation to be executed. This is similar to the current "wide" operator.
- A new class called ValueType<T> with methods to execute reflection operations on Q-Types; this will be analogous to the existing Class<T> for ordinary types. This is particularly important because, in order to reduce the number of new bytecode instructions to a bare minimum, there will be no instructions, at least for now, to create or manipulate Q-Types. Providing reflection capabilities means these operations can still be done through the relevant method handle, but without committing to a new bytecode instruction.
This proposal is far from a full implementation, and its experimental nature suggests that it will differ from the final version; as the authors themselves highlighted, there is always the chance that none of these items will be part of the final release. However, this early version will allow prototyping with Project Panama or GPU experiments, which will provide feedback regarding performance, development effort for a full solution, and usability. As an example, one of the things that are expected to be discovered with this activity, is the final set of bytecode instructions that should be added to the JVM to fully support value types.
