java.bytecode (or similar) module?

[Volker Simonis]

Hi Michael,

I think what you propose is a good idea. I actually already thought
about proposing something similar :)

Providing a java.bytecode module (i.e. in the "java"
package/namespace) is probably not that easy because it would require
specification through the JCP. So it may even require its own JSR?

I think as an interim solution it could already help if the version of
ASM, which as you correctly noticed, is already included in the JDK
anyway, would be publicly exported. In the medium term it could be
made an incubator module and then finally standardized.

Let's see what other (Alan, Remi ?) think about this.

Regards,
Volker


On Tue, Nov 14, 2017 at 1:01 AM, Michael Rasmussen
<michael.rasmussen at zeroturnaround.com> wrote:
> Hi,
>
> 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