On Sat, 24 Aug 2024 03:05:14 GMT, xxDark <d...@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
