<div dir="auto"><div>I think the Classfile API has a few approaches to mitigate your issue, with the latest API on latest JDK model:<div dir="auto"><br></div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 24, 2023, 11:30 AM  <<a href="mailto:ebruneton@free.fr" target="_blank" rel="noreferrer">ebruneton@free.fr</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The current formulation of the CSR seems to imply that the API will <br>
fully solve the "Version skew between frameworks and the running JDK" <br>
problem. I think it will help mitigate this problem, but that it won't <br>
fully solve it. A new JDK might<br>
  a) change the semantics of existing elements (e.g. ACC_SUPER),<br></blockquote></div></div><div dir="auto">AccessFlag takes care of it, and can potentially ignore/fail on invalid flags.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  b) remove elements which were previously valid (e.g. JSR/RET),<br></blockquote></div></div><div dir="auto">A specification of major version can be used to reject invalid entries</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  c) add new elements (e.g. bootstrap methods, new descriptor syntax, <br>
etc),<br></blockquote></div></div><div dir="auto">These are parsed by classfile API properly; if users encounter them, they fail like enum switch encountering new enums.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hence a framework written for a previous JDK version, using the <br>
ClassFile API, might<br>
  a) produce code which has an unexpected semantics in the new version,<br></blockquote></div></div><div dir="auto">Only if you don't configure your major version</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  b) crash or produce code which is invalid for the new version,<br></blockquote></div></div><div dir="auto">Same as above.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  c) fail or crash due to unexpected inputs (either right away if the <br>
user code is "clean" and checks for every possible unexpected input <br>
case, or later and in possibly hard to debug ways otherwise),<br></blockquote></div></div><div dir="auto">It may, but the Classfile API can drastically decrease the failure chance if, say, it's just adding an annotation.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
when run without any change on a newer JDK with its "up-to-date <br>
classfile library".<br>
<br>
See also the issues raised by Brian in <br>
<a href="https://mail.openjdk.org/pipermail/classfile-api-dev/2022-July/000053.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://mail.openjdk.org/pipermail/classfile-api-dev/2022-July/000053.html</a>. <br>
E.g. "you should not be parsing (let alone instrumenting) Java 19 <br>
classfiles if you don’t understand the semantics of the attributes <br>
defined for Java 19 classfiles.": I think this applies to a framework <br>
using the ClassFile API as well, if this API existed in Java 18.<br>
<br>
In other words, I think that even with the ClassFile API, frameworks <br>
which are not explicitly updated to work with a new JDK version (which <br>
can take some time) will result "in runtime errors or, worse, frameworks <br>
trying to [transform] class files from the future and engaging in leaps <br>
of faith that nothing too serious has changed."<br></blockquote></div></div><div dir="auto">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.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If this analysis is correct, is there a way to reformulate this "Version <br>
skew between frameworks and the running JDK" section to make it clear <br>
that the proposed API will not fully solve this problem?<br>
<br>
Eric<br>
<br>
> Hi,<br>
> <br>
> I've just kicked off CSR JDK-8308754 Class-File API (Preview) to have <br>
> enough time for discussions and improvements.<br>
> <br>
> Javadoc at <br>
> <a href="https://cr.openjdk.org/~asotona/8308754/classfile-api/javadoc/java.base/java/lang/classfile/package-summary.html" rel="noreferrer noreferrer noreferrer" target="_blank">https://cr.openjdk.org/~asotona/8308754/classfile-api/javadoc/java.base/java/lang/classfile/package-summary.html</a> <br>
> is altered to show target java.lang.classfile package and will be <br>
> updated according to our current main codebase.<br>
> <br>
> No branch nor fork is created for the transition and all API or javadoc <br>
> changes are expected to go to the current codebase in the jdk main <br>
> under jdk.internal.classfile package.<br>
> <br>
> Please let me know your comments.<br>
> <br>
> Thanks,<br>
> <br>
> Adam<br>
</blockquote></div>
</div></div>