CSR for Class-File API (Preview)

[ebruneton at free.fr]

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

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.

In other words, I think that even with the ClassFile API, frameworks 
which are not explicitly updated to work with a new JDK version (which 
can take some time) will result "in runtime errors or, worse, frameworks 
trying to [transform] class files from the future and engaging in leaps 
of faith that nothing too serious has changed."

If this analysis is correct, is there a way to reformulate this "Version 
skew between frameworks and the running JDK" section to make it clear 
that the proposed API will not fully solve this problem?

Eric

> Hi,
> 
> I've just kicked off CSR JDK-8308754 Class-File API (Preview) to have 
> enough time for discussions and improvements.
> 
> Javadoc at 
> https://cr.openjdk.org/~asotona/8308754/classfile-api/javadoc/java.base/java/lang/classfile/package-summary.html 
> is altered to show target java.lang.classfile package and will be 
> updated according to our current main codebase.
> 
> No branch nor fork is created for the transition and all API or javadoc 
> changes are expected to go to the current codebase in the jdk main 
> under jdk.internal.classfile package.
> 
> Please let me know your comments.
> 
> Thanks,
> 
> Adam