There are a couple of different terms that have been used to describe early access features - incubator (jep 11), experiment, or optional. At least for me, these different terms result in different mental models for how this should work for the VM. Hopefully, we're all thinking about the same behaviour semantics and are just using different terms but I think it's worth clarifying.
1) JEP 11 does a good job of describing incubator and makes it clear that it refers to non-standard modules / java-level code. Not VM features.
2) An optional feature is something you can chose to implement (or not) but must exist as part of the current JVM spec. All of its JVM spec changes would need to be in the spec and their enablement / enforcement would depend on whether the VM chose to implement that optional feature. Removal of the optional feature from the JVM spec would basically be impossible - it may fall into disuse through VMs not implementing it, but it would be hard to remove.
3) An experimental feature on the other hand, is something that would be allowed to have an appendix or set of experimental JVM spec changes that are only enabled by command line option + present in classes with new minor classfile versions. These features would start life deprecated and expectation is that classfiles with this particular minor version would no longer be recognized by future VMs when the experimental features graduate to the real JVM features, providing freedom to experiment without requiring the VM to carry the support burden long term.
My understanding has been that with the MVT prototype work, we've been aiming for the 3rd case. Does this match everyone's expectations? Anyone think we're aiming for some other point on the spectrum?
One of my fears is that we're going to end up with the VM required to support multiple ways of recognizing ValueCapableClasses / ValueTypes, especially if there are spec changes between the different ways (think the mess that is invokespecial and the ACC_Super flag) based on attribute vs annotation or classfile version, etc.
>> On Jul 5, 2017, at 8:12 AM, Karen Kinnear <karen.kinn...@oracle.com> wrote:
>>
>>> > Dan S: class loading in the proposed JVMS: if you see $Value
>>> > 1) first derive the VCC name and see if already resolved
>>> > 2) if not - load the VCC, check properties and derive
>>> > (ed. note - if see VCC - lazily derive derived value class on touch)
>>>
>>> It's not a requirement that the value class derivation is lazy, correct?
>> Let’s double-check with Dan Smith at today’s meeting.
>>
>> The way I read 5.3 Creation and Loading in
>> http://cr.openjdk.java.net/~dlsmith/values.html
>> it appears to allow lazy derivation as well as eager derivation, which I think is what we both want
>> since it allows implementations to optimize.
>> Our current derivation is also eager.
>
> Summary of today's discussion, supplemented with some reflection on what I see as the requirements:
>
> - The specification shouldn't care when the class is derived (though it must occur, naturally, no later than resolution of "Foo$Value"); the specification *might* care when error checking occurs, because that's observable.
>
> - Current specification draft says error checking occurs when Foo$Value is loaded (5.3), and that "Class or interface creation is triggered by another class or interface D, which references C through its run-time constant pool." So, as a test case: if my program has no references to Foo$Value (direct or reflective), no VCC-related errors would occur.
>
> - We could redesign this so that the VCC properties are checked during loading/verification of Foo. I am concerned that, where Foo is version 54.0 and has attribute ValueCapableClass, this sort of error checking will violate the Java SE 10 spec.
>>
>>> > Dan S: class loading in the proposed JVMS: if you see $Value
>>> > 1) first derive the VCC name and see if already resolved
>>> > 2) if not - load the VCC, check properties and derive
>>> > (ed. note - if see VCC - lazily derive derived value class on touch)
>>>
>>> It's not a requirement that the value class derivation is lazy, correct?
>> Let’s double-check with Dan Smith at today’s meeting.
>>
>> The way I read 5.3 Creation and Loading in
>> http://cr.openjdk.java.net/~dlsmith/values.html
>> it appears to allow lazy derivation as well as eager derivation, which I think is what we both want
>> since it allows implementations to optimize.
>> Our current derivation is also eager.
>
> Summary of today's discussion, supplemented with some reflection on what I see as the requirements:
>
> - The specification shouldn't care when the class is derived (though it must occur, naturally, no later than resolution of "Foo$Value"); the specification *might* care when error checking occurs, because that's observable.
>
> - Current specification draft says error checking occurs when Foo$Value is loaded (5.3), and that "Class or interface creation is triggered by another class or interface D, which references C through its run-time constant pool." So, as a test case: if my program has no references to Foo$Value (direct or reflective), no VCC-related errors would occur.
>
> - We could redesign this so that the VCC properties are checked during loading/verification of Foo. I am concerned that, where Foo is version 54.0 and has attribute ValueCapableClass, this sort of error checking will violate the Java SE 10 spec.
Doesn't the use of experimental features allow the new classfile versions to define new behaviour? I would expect the ValueCapableClass attribute to be ignored in a v.54 classfile and only take affect in a v.54.1 classfile so that the semantics can be changed in the future.
>
> Elaborating: we're presenting values as an optional feature of Java SE 10. For a JVM that does not implement the optional feature, JVMS 10 says that a ValueCapableClass attribute on a version 54.0 class file will be ignored. JVMS 4.7.1: "any attribute not defined as part of the class file specification must not affect the semantics of the class file. Java Virtual Machine implementations are required to silently ignore attributes they do not recognize." My interpretation of our mission, in adding an optional feature, is to provide new capabilities while having no impact on existing behavior. We can do new things where JVMS 10 specifies an error; we can't generate new errors where JVMS 10 specifies none.
New classfile version == new behaviour, right?
>
> - We could limit usage/interpretation of "ValueCapableClass" to 54.1 class files. Then eager error checks when loading Foo would be fine. But the ability to work with 54.0 ValueCapableClass class files is an important use case.
The model here is that using a JVM 10 javac, a classfile with the annotation is v54 and on a VM with some -XX:EnableExperimentalFeatures flag, this derives a v.54.1 class for the DVT? This basically gives new behavior to v.54 classfiles which makes it very hard to change when Java 11 comes along and fully specifies ValueTypes. Customers will still have these annotated v.54 classes and expect them to keep working as values, meaning the JVMs will need to support both the annotation and the new way.
Limiting the new behaviour to v.54.1 classfiles and then making them illegal in Java 11 makes it obvious to the user that the experimental classfiles won't work the same way and likely need to be refactored to the new "real" ValueTypes way.
Would the annotation be in an incubator module so that it can be deprecated / removed easily in a future release?
>
> - Actually, examining that use case more closely, we discussed how attributes are not the right tool at all. We want clients of MVT to be able to generate interesting programs using a vanilla Java SE 10 compiler. The best mechanism to communicate "I'm a value-capable class" using a vanilla Java compiler is annotations, not attributes.
Because we're dealing with experimental features, can we require a similar -XX:EnableExperimentalFeatures flag (or -D option) for javac to convert the annotation into a v.54.1 classfile with the attribute? This makes it easy to write the code but keeps it sandboxed to the experimental classfile version.
>
> Tentatively, the spec should be revised so that:
> - The "ValueCapableClass" attribute no longer exists. Delete changes to 4.7 and delete new section 4.7.25.
> - A "value capable class" is a class whose RuntimeVisibleAnnotations includes a ValueCapableClass annotation (package TBD; whether the referenced class must be loaded TBD)
> - As usual, this annotation doesn't impact behavior of class Foo
> - When loading Foo$Value, as specified in 5.3, we'll check that Foo is a value capable class and that it has the right properties
>
> —Dan
Annotations are typically more expensive to read in the VM than attributes. If not for the vanilla-java concerns, a feature like this would have an attribute in the JVMS. Shouldn't we try to start with the attribute to keep us close to the path we'd pick for a future java release?
--Dan
