Please see the following JVM spec documents: [1] A minor update to the previously-shared document—changes detailed below. [2] An adjustment to the Value Classes spec introducing CONSTANT_ClassType to represent direct value class types. [3] An adjustment to the Value Classes spec to allow value classes to be declared explicitly, rather than derived.
Changes to [1]: - Allowed vbox to trigger initialization of the VCC. - Reordered runtime exceptions of vunbox (NPE, not ICCE, if the input is null). - Added some minor changes to account for the broader domain of CONSTANT_Class strings in 4.7.3, 4.7.5, 4.10.1.3, and 'new'. On my TODO list: - Investigate exactly which steps should be taken when loading a $Value class triggers loading of a VCC - Clean up verification rules to enforce the 4.9.1 static constraints (and maybe move some format checking/static constraints to resolution time?) [2] and [3] are not necessarily part of MVT, but are natural next steps that we have discussed recently. [2] sets us up for introducing as many type structures as we want and moving away from using CONSTANT_Class to represent types (while continuing to provide legacy support). [3] seems the best path towards dropping the "$Value" convention and, ultimately, having a Q/L pair of types pointing to a single class name. Not sure whether [3] is a viable stopping point for tools and APIs, though, without taking another step to add support for boxed L types. —Dan [1] http://cr.openjdk.java.net/~dlsmith/values.html [2] http://cr.openjdk.java.net/~dlsmith/values-classtype.html [3] http://cr.openjdk.java.net/~dlsmith/values-declaration.html
