Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News The Current State of Java Value Types

The Current State of Java Value Types

This item in japanese


Oracle has 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 int).

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 Object and 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. 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 Optional and 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 does not commit to delivery of the prospective features with any particular Java version or by any specific date in the future.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Oracle J#

    by Timothy Liu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Back to 1998, there was a (killed) J# of M$. Twenty years later, Oracle just re-cook it.

  • Re: Oracle J#

    by Ben Evans,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Not really comparable. In the articles by John Rose that are linked from the above, he walks through several design approaches that have been prototyped and rejected. It's pretty clear that avoiding the problems of the .NET implementation of structs and value types (whilst staying backwards compatible) is a major goal.

  • Re: Oracle J#

    by Ciprian Khlud,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Eh, feeling bitter?

    Of course that Java didn't copy J#. For that matter, if you talk about "high level ideas" that platforms take, yes, of course, every company "steals" from the other ideas.

    But to be frank, many things are just too differently implemented in Java and .Net to say that they just "re-cooks" the other ones.

    For example just few things that Java copied from .Net but they didn't:
    - Generics
    - Lambdas (in many cases there is C# syntax, but they work really different)
    - parallel() call on top of lambdas
    - Jigsaw with internal module visibility which somewhat resemble the .Net's Assembly internal visibility

    But if you are so pedantic, I can say just in the few years things that .Net definitely stole from Java world:
    - .Net Core just added a tiered JIT, a feature that Java had it at least in production (as of Azul) for 10 years
    - .Net just added static imports, a feature from Java 1
    - and they just added methods to interfaces
    - DLR: a "rip-off" of "invoke-dynamic"

    But if we go into these talks, we go nowhere, because going into implementation, you will see many things are too different compared with what is described.

  • Re: Oracle J#

    by David Pickett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Types, well:

    - the first thing that occurs to me is to support all of IEEE 754, like the modern hardware does.

    - extended range types, some now supported in classes, would make nice types.

    - primitive type references/pointers seems like a good candidate for recapturing the speed and versatility of C/Assembly.

    - rational types for capturing fractions without rounding error would be neat!

    - primitive date-time types would be good.

    - primitive money types would be nice (implicitly scaled integer).

    - scaled integers in general would be handy, like in handling fractional stock shares.

    - Hints in Class declaration that this is a user defined type might be sufficient to restrict but create default methods/interfaces.

    - Arrays of all the above, of course.

    - Do we need parallel Classes like Integer to get utility methods/interfaces like StringToX, access to containers, etc.?

  • Re: Oracle J#

    by Ben Evans,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I would recommend reading the linked articles and reviewing the design. Some of what you mention is already included, some is never going to happen (e.g. user-visible raw pointer types) and some just doesn't make sense in the context of the current design.

  • Value type signature

    by Cergey Chaulin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I've always though it felt natural to encode value types using Q signature. Why do they always put great store in compatibility ?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p