java.bytecode (or similar) module?
michael.rasmussen at zeroturnaround.com
Tue Nov 14 00:01:56 UTC 2017
The new release cadence means a new class file version every 6 months
. This means framework parsing/generating bytecode (or relying on
libraries like ASM), will always be playing catch-up, or waiting for
ASM etc to be updated. Or alternatively, for frameworks slow to
update, users of those frameworks will have to explicitly override the
versions of its dependencies in their build scrips, hoping that ASM
n+1 is binary compatible with ASM n.
Previously, with the old release model, a new class file version every
few years wasn't that big a hassle, but having to do this every 6
months, in order to ensure that your version of ASM doesn't throws
exception because the class file version is now n+1, is going to be
So have there been any talks about (or any concrete plans to) create a
java.bytecode module, that is able to parse/generate bytecode for the
release's class file version? Meaning a library/framework could simply
depend on this module, and thus have an API available that was able to
parse the bytecode, and would also work and be able to parse class
files running on the next java release.
Yes, I know usage of such an API would have to be written somewhat
defensively, what should I do if I get the bytes for a value-type?
Personally I would prefer that the developer can decide this; if I'm
just scanning class files for annotations on methods, it doest't
matter much to me if a method uses a feature introduced in Java 12 or
only use Java 6 stuff.
Of course, there would be a constant overhead of keeping it up-to-date
for every single JDK release; but some of that cost is there already.
There are currently multiple such private APIs in the JDK, ranging
from a shaded ASM used in lambdas, to the API used in Proxy,
reflection, javac, javap, etc. Adding a java.bytecode module (or
package in java.base), the code could then be reused, and thus help
clean up the existing private APIs.
More information about the jdk-dev