Java language architect Brian Goetz today posted a lengthy blog post detailing some of the proposed plans for the future of Java. He wrote that OpenJDK 9 is looking at making generic classes easier to turn into specialized classes. The idea is that these generics that can be extended over primitives, and eventually, over value types.

The changes being batted around now are variations of what other languages do with generic specialization. But the first proposal is to use *T at the end of a typename or bytecode to signify that the type is derived from the erasure of T, and thus needs to adjusted during specialization.

(Related: How Java helps modernize data in legacy apps)

Goetz also addressed sub-types and how developers could still write fully generic code with generic methods:

“Specializing generic methods is harder than specializing classes, because VM implementations are often organized around the assumption that the set of methods in a class is fixed. There are several approaches we might take for implementing and invoking specialized generic methods. One approach would be to sidestep the problem using invokedynamic; another would be via a ‘method missing’ approach.”

InvokeDynamic was one of the earlier changes to OpenJDK and is typically used by languages running on top of the JVM. Further from the blog:

“Alternately, the VM could provide a ‘method missing’ handler, one which would allow the method to be invoked with invokevirtual but introduce an additional stage that allowed for programmatic linkage after the ordinary nominal linkage failed.”

Goetz wrote that turning generic classes into specialized ones is fairly straightforward, but worries that users might want to have more control over the process have led the Java team to consider two options for user control of the process. The first idea is to allow users to simply write the code by hand and have it override the auto-specialization.

The second idea is to offer a mechanism for users to specifically override aspects of the specialization, rather than simply overriding the entire specialization top to bottom.

These specialization changes could result in some broken legacy compatibility, as in order to specialize a class type, there is metadata required in the bytecode. Thus, specialization is not likely to be in the next Java as a default option. Rather, it’d be opt-in.