Three Oracle engineers have submitted a formal thesis of proposed enhancements to the Java Virtual Machine and Java language to support small, immutable value types.
Oracle Java language architect Brian Goetz, architect John Rose and Oracle Labs software architect Guy Steele publicized the first draft of their “State of the Values” proposal describing their overall approach to adding value types—also called user-defined primitives, immutable records or restricted classes—to the JVM instruction set.
“The goal of this effort is to explore how small immutable user-defined aggregate types without identity can be surfaced in the language and the JVM instruction set to support memory- and locality-efficient programming idioms without sacrificing encapsulation,” the proposal stated. “We believe that the design of the Java VM and language can be gently extended with a new kind of type, a value type, which usefully combines the properties of Java’s current classes and primitive types.”
(Related: A new programming language that uses the JVM for its runtime)
Goetz, Rose and Steele view value types as a way to build new value-based data structures, regarding the value type definitions as specially marked and restricted classes, but with developer freedom to treat the values as a new kind of primitive type. Value type integration in the JVM could enable Java support for features such as numerics, algebraic and native data types, tuples, cursors and flattening, according to the proposal.
A few of main characteristics of these value types, as laid out by the engineers, are:
• Scalarization: Routine breakdowns of value types into components, stored in stack registers rather than the heap.
• Wrapping: Boxed and unboxed value type representations required for interoperability with APIs that require reference types, automatically generated from the value type description.
• Names: Value types identified by names, not just their element numbers.
• Interoperability: The compiler and VM are free to implement value counterparts without a value class author.
• Encapsulation: Private components for values using the same principle as private fields for objects.
• Variables: Existing variable types should all be able to hold values. Methods should be able to return values.
• Identity comparison: The == operator on objects performs an identity comparison; on primitives it performs a bitwise comparison
• Identity hash code: The default identity-based hash codes for objects do not apply to value types. Internal operations like serialization would either not apply to values or they would use value-based distinction supplied by the value type’s hashCode method.
Many questions about this early value type proposal still remain. Goetz, Rose and Steele talked about lingering decisions over issues such as subtyping, reflection, fieldwise side effects, array values and others, but are confident value types are a worthwhile addition to the JVM and Java.
“Along with the questions, we believe we have enough answers and insights to begin prototyping value types, and verifying our thesis,” the statement read. “That is, we think it quite likely that a restricted class-like type can be made to look enough like a primitive to be worth adding to the language and VM.”
For more detail about the proposal’s background, thesis, use cases, requirements, code details and examples, the full “State of the Values” report is available here.
