> 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. 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. - 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. - 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. 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
