On Sat, 24 Aug 2024 05:03:33 GMT, xxDark <d...@openjdk.org> wrote:

> If Hotspot now parses these files incorrectly, it might be worth to just 
> throw `UnsupportedClassVersionError` for oak class files?

This would be an important decision; I would wait till Monday when more 
engineers are back to discuss about the histroy of dropping support for such 
files, why this format never made its way to the JVMS, and the correct way to 
handle so as to avoid inconsistency between different versions.

> Edit: I missed the word `preview` in the quote. Does this only apply to 
> *preview* class file features?

Yes, Class-File API is supposed to handle whatever the VM handles. It's 
actually considered a "JVM API" in Oracle's documentations: 
https://docs.oracle.com/en/java/javase/22/vm/class-file-api.html

OpenJDK's preview version policy allows shipping the preview features for 
testing to a wider audience without any implied burden of long-term 
maintenance. So for example, if the Nullable Types JEP preview adds `~` as a 
null marker in `Signature` attribute but changes it to `?` in a subsequent 
preview, the JVM and core libraries will act as if a previous iteration with 
`~` marker never existed; the policy is similar to that for preview libraries.

Unfortunately, there seems to be some misunderstanding around the role of 
preview, so some are asking if preview features that is largely unchanged and 
finalized in a future release can become finalized in an LTS as well. Short 
answer, no: it's an experiment format enabled by the new 6-month release 
schedule.

And note that javap uses ClassFile API, and as a result, javap for release N 
cannot correctly decompile Class Files with version N-1.65535, etc. We are 
planning to decompile on a best-effort basis, that we try to interpret such as 
class as if it's N.65535 (maybe emit a warning), trying to salvage the most out 
of the Class File and printing errors (but continue to output) if we encounter 
anything we don't expect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308402818

Reply via email to