CSR for Class-File API (Preview)

[Brian Goetz]

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