RFR: 8334714: Class-File API leaves preview [v2]
Chen Liang
liach at openjdk.org
Sat Aug 24 03:49:07 UTC 2024
On Sat, 24 Aug 2024 03:05:14 GMT, xxDark <duke at openjdk.org> wrote:
> Classfiles with oak format seem to be unparsable. They also cannot be written. (maxStack/maxLocals in Code attribute depend on classfile version). Constants such as `JAVA_1_VERSION` exist in `java.lang.classfile.ClassFile`.
Unfortunately, ClassFile API's scope is only to interpret correctly the Class Files that are accepted by the current VM and support writing such class files; for example, for release N, we will not support correct parsing or writing of preview class files from N-1, N-2, etc.
While your account of oak format seems interesting (from a search, it seems to use u1 for max stacks/locals, u2 for Code size), it is neither recognized by hotspot (the reference implementation for JVM):
https://github.com/openjdk/jdk/blob/5671f836039ef1683e3e9ce5b7cf0fa2f1860e2d/src/hotspot/share/classfile/classFileParser.cpp#L2332-L2334
Nor by the JVMS: https://docs.oracle.com/javase/specs/jvms/se22/html/jvms-4.html#jvms-4.7.3
And as such, it falls out of the [goals](https://openjdk.org/jeps/466#Goals) of the API, and is likely not going to be added. You most likely will resort to a third party library to handle such frozen format, as the main issue ClassFile API is solving is that a library built against JDK 21 may not run on JDK 23 unless it bumps its ASM dependency to support reading JDK 23 Class File format, which doesn't exist for the said oak format.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2308036118
More information about the core-libs-dev
mailing list