CSR for Class-File API (Preview)

[ebruneton at free.fr]

liangchenblue at gmail.com and brian.goetz at oracle.com wrote:
- "I think the Classfile API has a few approaches to mitigate your 
issue, with the latest API on latest JDK model:"
- "A specification of major version can be used to reject invalid 
entries"
- "if users encounter them, they fail like enum switch encountering new 
enums."
- "Only if you don't configure your major version"
- "The classfile API still can address most of these problems,"
- "I agree that without a characterization of all possible future JVMS 
Ch4 changes, we can't claim the problem is solved."

As I said "I think [the ClassFile API] will help mitigate this problem 
["Version skew between frameworks and the running JDK"], but that it 
won't fully solve it.". So its seems we agree on this.

To reflect this, can the end of this CSR section be rewritten to 
something like "... that nothing too serious has changed. Providing a 
class-file library as part of the JDK, always up-to-date with the new 
JDK features, can mitigate most of these version skew problems."?

Eric

PS: failing fast by checking the major version is what ASM currently 
does. If frameworks do this on top of the ClassFile API, they don't gain 
much with respect to this "version skew" problem (i.e. a possibly long 
delay between a JDK release and the point where frameworks and 
applications work with the new class file format).

>> The current formulation of the CSR seems to imply that the API will 
>> fully solve the "Version skew between frameworks and the running JDK" 
>> problem. I think it will help mitigate this problem, but that it won't 
>> fully solve it. A new JDK might
>>  a) change the semantics of existing elements (e.g. ACC_SUPER),
>>  b) remove elements which were previously valid (e.g. JSR/RET),
>>  c) add new elements (e.g. bootstrap methods, new descriptor syntax, 
>> etc),
>> Hence a framework written for a previous JDK version, using the 
>> ClassFile API, might
>>  a) produce code which has an unexpected semantics in the new version,
>>  b) crash or produce code which is invalid for the new version,
>>  c) fail or crash due to unexpected inputs (either right away if the 
>> user code is "clean" and checks for every possible unexpected input 
>> case, or later and in possibly hard to debug ways otherwise),
>> when run without any change on a newer JDK with its "up-to-date 
>> classfile library".
> 
> While I can't characterize all future changes to the classfile 
> specification, and clearly all bets would be off if the `aaload` 
> bytecode went the way of jsr/ret, there is an approach that frameworks 
> can use to mitigate the problem you outline.  The key choice a 
> framework here is whether to preserve the classfile version when 
> transforming, or whether to use a version the framework knows about.  
> There are cases when the sensible thing to do is preserve the version, 
> such as if you're only dropping the LineNumberTable. (And yes, if at a 
> later version of the spec made LNT required, this would be a problem.)  
> There are also cases where the sensible thing to do is stick to a known 
> version of the classfile format.  What this does is let the framework 
> author trade off between "fail at instrumentation time" and "fail at 
> class load time".
> 
>> 
>> See also the issues raised by Brian in 
>> https://mail.openjdk.org/pipermail/classfile-api-dev/2022-July/000053.html. 
>> E.g. "you should not be parsing (let alone instrumenting) Java 19 
>> classfiles if you don’t understand the semantics of the attributes 
>> defined for Java 19 classfiles.": I think this applies to a framework 
>> using the ClassFile API as well, if this API existed in Java 18.
> 
> I agree that without a characterization of all possible future JVMS Ch4 
> changes, we can't claim the problem is solved.  What we can add to the 
> story, over and above the previous scenario, is that there is now an 
> intermediary (the JDK) that understands the newer classfile format, and 
> can translate it into an object model that is at least partially 
> understood by the framework.