java.bytecode (or similar) module?

[Brian Goetz]

The ASM folks are deeply involved in all projects that entail bytecode changes.  Ensuring that ASM and other such tools are prepared for classfile changes with enough time to update is an important aspect of running such a project and determining if it is ready to propose to target.  

Sent from my MacBook Wheel

> On Nov 14, 2017, at 8:43 AM, Volker Simonis <volker.simonis at gmail.com> wrote:
> 
> 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