Java 8 was only released this year, and Java 9 is scheduled for mid-2016. Despite this, some interesting details of features planned for a future version of Java (hopefully Java 10) have emerged.

Specifically, two big features have begun prototyping: Enhanced generics and value types. Enhanced generics are the feature that should allow future Java developers to write code involving, e.g. List<int> without the pain of boxing of primitive types. However, the design of the proposed new form of generics contains some subtleties that have to be approached carefully, as Brian Goetz explains in his recent design paper.

Java has always had a focus on backwards compatibility, and under Oracle's stewardship, that viewpoint has been reaffirmed. For this reason, Oracle are pursuing a tactic similar to that used for the introduction of generics in Java 5 - an approach they refer to as "gradual migration compatibility".

The basic design problem that needs to be overcome is that Java's type system does not have a unified root. There is no type in Java that is a supertype of both Object and int . This can be seen in the structure of JVM bytecode - not least in the fact that the bytecodes for returning an int versus an object from a method are different opcodes - ireturn is different from areturn .

The current prototype uses an approach called "any" type variables, to indicate that the type variable can range over both reference types and primitives (and also over the proposed new value types). This is currently written as Container<any T> but the syntax is still a work in progress, so may well change before the feature ships.

The current thinking is that while List<Integer> and List<String> will continue to be represented at runtime by List.class (so type erasure still occurs for reference types), List<int> will be represented by a different runtime type (and potentially by a different classfile). This approach is called "generic specialization" for the primitive types. It also helps with another design issue - upgrading existing collection classes to use enhanced generics. A key design goal is to allow developers to have List<int> , so there must be a migration path for an existing generic type to support any type variables in future versions.

There are also some surprises in terms of how enhanced generics fit into the type system. In particular, List<int> is not a subtype of the raw List type (if it was, then that would imply that List<int> was storing instances of Object). However, List<?> is a subtype of List , so this implies that List<int> is not a subtype of List<?> , and that wildcards do not work for enhanced generics.

The current prototype is a long way from being production ready, and there is much design and implementation work to do. In particular, the implementation of specialization is being actively worked on. Automatic generation of specialization code is desirable (as it reduces hand-written boilerplate), but this may require additional support in the bytecode and classloading subsystem. One intriguing possibility is the introduction of a metaprogramming facility at virtual machine level (but no direct Java language support). This approach is being referred to as "classdynamic" by analogy with invokedynamic and is described here.

The development of enhanced generics and value types is being conducted through Project Valhalla, and more details can be found there.