MMS • RSS
Oracle have been working to bring value types to Java. This effort has been ongoing in Project Valhalla, the mission statement of which is to be “a venue to explore and incubate advanced Java VM and Language feature candidates”. InfoQ has previously covered this project and the in-progress work to introduce value types in Java.
Value types are intended to be a third form of data type available in some future version of Java, to complement the currently-existing two: primitive types, and object references. The phrase most often used is that Java value types should “code like a class, work like an
int“. This means that they should be a composite data type (code like a class) but lack identity and not pay the object header cost if at all possible (work like an
As the platform currently stands, the environment deliberately does not provide this form of low-level control over memory layout – it would be similar to a C struct, which the JVM does not support. Instead, in current versions all composite data types must be accessed by reference.
If the Java platform is to be extended to include value types, then the question naturally arises as to whether value types can be used as type parameter values. If not, then this would seem to greatly limit their usefulness. Therefore, the design of values types has always included the assumption that they will be valid as values of type parameters in an enhanced form of generics.
This is related to the fact that the Java type system lacks a top type – there is no type that is the supertype of both
int. Another way of saying this is that the Java type system is not single-rooted. Due to this, type parameters for Java’s generic types have only ranged over reference types and there is no obvious way to create a self-consistent meaning for
List<int>. The arrival of value types must address this issue (and also type erasure of generics) if at all possible.
As another design constraint, since Java 8 it has been a design goal to advance the possibility that certain reference types in the JDK (and possibly beyond) might be allowed to evolve in later releases to become value types. Two obvious examples of candidates for this are
LocalDateTime – both have the properties that would be expected of value types. For example, they are both immutable and would be expected to exhibit value semantics – two objects are equal if and only if the values of all their fields are equal.
If it is possible for JDK types to evolve into value types, then this begs the question of what the representations for the types would look like in the class files. In the current version of the JVM, reference types are written as
L<qualified type>;, so that
Optional is represented by the type descriptor
Ljava/util/Optional;. Over the last several years, different proposals and design approaches have been investigated in search of a representation of value types.
John Rose, Oracle’s JVM Architect, recently described the history briefly, the various approaches that have been tried, and the problems encountered.
The current direction is that value types will continue to be described using the same descriptor syntax as reference types (rather than, e.g.
Qjava/util/Optional; as was discussed at one point). This approach has the nice feature of helping to maintain backwards compatibility, which has been a first-class Java design principle since the earliest days of the platform.
However, the design does have a problem in that the type descriptor is now an incomplete description, as it does not encode the fact that certain types are really value types. To resolve this, the current proposal is that the JVM class file format will be extended with a new section (
ValueTypes) that details which types within the file are actually value types. The details have been written up by John Rose although some lively discussion about some of the details is continuing on the valhalla-dev mailing list. Recent contributions from Stephen Colebourne and others have discussed topics such as the nullability (or otherwise) of Java value types.
In parallel, the implementation work is proceeding well, and it is expected that a prototype suitable for JVM hackers, framework authors and those comfortable with bytecode will be available soon. As is usual for major features in active development, Oracle do not commit to delivery of the prospective features with any particular Java version or by any specific date in the future.