java.bytecode (or similar) module? (original) (raw)

Fridrich Strba fridrich.strba at suse.com
Tue Nov 14 07:36:22 UTC 2017

This was actually something puzzling me in the whole versioning discussion: why on the earth increasing every 6 months a language source and target levels unless some new features require it. Especially if the version has 4 digits and one could intelligently use them. But did not want to add my grain of salt into the cacophony.

Cheers

F.

On 14/11/17 01:01, Michael Rasmussen wrote:

The new release cadence means a new class file version every 6 months [1]. 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 tedious. 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. Kind regards Michael Rasmussen [1] https://twitter.com/mreinhold/status/926135074780692480

More information about the jdk-dev mailing list