CSR for Class-File API (Preview)

[-]

I think the Classfile API has a few approaches to mitigate your issue, with
the latest API on latest JDK model:



On Wed, May 24, 2023, 11:30 AM <ebruneton at free.fr> wrote:

> 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),
>
AccessFlag takes care of it, and can potentially ignore/fail on invalid
flags.

>   b) remove elements which were previously valid (e.g. JSR/RET),
>
A specification of major version can be used to reject invalid entries

>   c) add new elements (e.g. bootstrap methods, new descriptor syntax,
> etc),
>
These are parsed by classfile API properly; if users encounter them, they
fail like enum switch encountering new enums.

> 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,
>
Only if you don't configure your major version

>   b) crash or produce code which is invalid for the new version,
>
Same as above.

>   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),
>
It may, but the Classfile API can drastically decrease the failure chance
if, say, it's just adding an annotation.

> 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."
>
The classfile API still can address most of these problems, such as
handling new CP entries (otherwise unknown size) when everything else
doesn't change. It parses Classfile into something more understandable to
users and more resistant to format updates. And it allows older code to
fail fast on incompatibilities of new class files, which is a significant
improvement from the existing situation in terms of compatibility and
correctness.

>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230524/a13e13fb/attachment-0001.htm>