This is in my view the most interesting question, since it appears difficult at this point to introduce a really new concept into the Java language. As far as I can tell, the main reason why the JVM can’t make value types of immutable classes is the object identity problem.

So, my idea was to introduce a small change that lets the JVM know that object identity is not a problem for a particular class.

For instance, there could be a new abstract class java.lang.Immutable. Its subclasses would be required to have only primitive (or Immutable) final fields and to follow some rules for the equals() and hashCode() methods (essentially being based on the field values). Object identity (the == operator) would be defined as the same as equals(), and null-valued variables of Immutable type would not be allowed. This would allow a smart JVM to make inline value objects of variables declared as such classes.

There are some problems. For instance, an Immutable object might be assigned to an Object variable and used like a reference object. That would probably require that a “real” object is created for that value, so that it can have a reference. The question is what happens with object identity in that case. It could be solved by keeping a register of referenced immutable objects, sharing them when necessary so that there are never two unique but equal instances. A bit awkward, but it would preserve language semantics while only incurring a cost for the new Immutable classes, and only when they are used in the perhaps “least interesting” way. An alternative would be to have a special handling of “==” for variables declared as Object, checking whether they are Immutable or not. But that would come at a cost. Yet another alternative would be to let object identity be undefined for subclasses of Immutable. But that would break with Java language semantics.

Thanks for your comments.

Re: Changed semantics for value types (eg equals, locking, etc)… absolutely. One cant switch Integer between a Value type and a Ref type without breaking things like equals().

Java’s Integer shouldn’t be retrofitted anyway, since we already have ‘int’. Its more complex types that are more interesting/useful, like tuples and arrays.

.NET is IMO the best guide for how to do it decently.

I wouldnt expect to support locking over value types. locking over arbitary objects is widely seen as a near useless feature anyway, a mistake in Java’s design. Use dedicated Monitors instead.

Re:

At first sight, it may appear that immutable classes (see http://creativekarma.com/ee.php/weblog/comments/value_types_in_java/) could be treated as value types by the JVM. Indeed, the “Automatic Object Inlining” mentioned above seems to do exactly this. I doubt that it could be a general solution however, because of the problem of unique but equal instances.

For instance, Integer a = new Integer(3); Integer b = new Integer(3); creates two equal but unique objects.

If immutable classes like Integer would be implemented internally as value types, what would be the desired object identity semantics? For instance, when checking the identity of two variables using the == operator, the only sensible thing seems to be to use equals(). But that would break with current practice, for instance a == b is false in the above example.

Another problem is locking, owning the lock of object a above is not the same as owning the lock of object b, although the objects are equal.

I would guess that a JVM implementation of “Automatic Object Inlining” has to be very restrictive, making sure to avoid these problems. That probably means that such “value types” can not be stored in arrays. Which would be a pity because, as indicated in the article here, that is one of the really interesting scenarios for value types.

Perhaps it is a mistake to have public constructors on immutable classes, since they open up the possibility of creating unique equal objects. An immutable class should perhaps instead only provide object creation using static methods, like Integer.valueOf(int). That way, software should never rely on object identities.

What about this: New immutable classes should be written without public constructors, providing object construction using static methods. Such classes could get special treatment from the JVM, implementing them as value types when deemed suitable. Object identity would then be defined according to either the equals() method or just identity in all fields. Perhaps such classes should be annotated in a special way, or extend a common class java.lang.Immutable.

it could be done with annotations, however changing between value and references types changes the semantics (ie meaning/function) of a program. In general, you could not switch back an forth without breaking the software. In some limited cases, it seems you can, as is described in the link Ismael posted.

Thanks for the link. “Automatic Object Inlining” seems like clever stuff.

Ive been told that GHC Haskell automatically decides it can use unboxed records (ie value types) internally in some cases.

There is software it is simply not possible to build competitively on the JVM unless value types are used. To me, saying “use another language” is to admit defeat.

Although I think value types would be useful to have in the JVM, it’s worth mentioning that there are HotSpot modifications that propose to get many of their benefits automatically. See the “Automatic Object Inlining” section of:

wikis.sun.com/display/HotSpotInternals/Publications+JKU

As usual, there are trade-offs when it comes to choosing an automatic versus manual approach.