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.

Reply via email to