Draft JVMS changes for Primitive Objects (JEP 401)

[Dan Smith]

Here's a long-overdue refresh of the proposed JVMS changes to support Primitive Objects:

http://cr.openjdk.java.net/~dlsmith/jep401/latest

(Sorry to dump this on the weekend, not looking for same-day feedback. :-))

I *think* I've captured all the key JVMS-related pieces that we expect to include with JEP 401, but please let me know if I missed something.

In a number of areas, there are still open design questions. I've called those out in discussion blocks. Often, I've made a somewhat arbitrary choice for how to resolve the open question, based on my mood at the time. :-) While it's useful to get something down on paper, all of these will be more carefully explored and resolved in the coming months. If you see something *not* called out that you think still needs further discussion, let me know.

New term to look out for: "inlinable reference type", which is spec-speak for "Q type". (And its companion, "standard reference type", for "L type".) Why not call it a "primitive value type", like we do in the Java language? Because, unlike the language model, in the JVM it works best to treat all class types as reference types that participate in a single substitutability/subtyping graph, even though the JVM can optimize away the references in many cases. Our generics story leans heavily on the JVM handling types in this way. Given that mismatch, it seems too confusing to try to force the same terminology into the different models.

There are supplementary "cleanup" changes included in the bundle, if you're interested in exploring them. Most of these fall under the umbrella of the "Better-defined JVM class file validation" JEP I proposed a few weeks ago, but "JVM Types Cleanup" is new.