java.bytecode (or similar) module?

[Fridrich Strba]

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
>