java.bytecode (or similar) module?

[Remi Forax]

Hi Volker,
the easy anwser if the JDK do not include all packages of ASM and is patched version of ASM.

In details, let me try to explain, how it works currently, the JDK version used internally:
- is a parts of ASM, some packages are not present (asm.tree, asm.tree.analysis, asm.xml) because the JDK mostly uses ASM to read/write bytecodes, not to perform analysis on it.
- is an older version than the current version of ASM, the process to include a version of the ASM in the JDK requires a released version of ASM and takes some times so an internal version do not contains all bug fixes already in the master of ASM. Bug fixes from ASM may not be needed because the JDK only uses some parts of ASM. We release a major version of ASM the weekend (all developers of ASM have a real job) just after the GA of the JDK. So a release of the JDK never contains a released version of ASM, usually it takes one or two updates.  
- a newer version compared to ASM, because the internal version is patched to introduce bytecode changes that will be speced in the future. Branch of ASM that contains upcoming changes are always based on drafts of the spec, so changes in branches appears later and are we hope cleaner because it's easier to implement a feature when you have a spec (even if it's a draft).

regards,
Rémi

----- Mail original -----
> De: "Volker Simonis" <volker.simonis at gmail.com>
> À: "Brian Goetz" <brian.goetz at oracle.com>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Mardi 14 Novembre 2017 10:11:44
> Objet: Re: java.bytecode (or similar) module?

> Brian Goetz <brian.goetz at oracle.com> schrieb am Di. 14. Nov. 2017 um 09:55:
> 
>> The ASM folks are deeply involved in all projects that entail bytecode
>> changes.
> 
> 
> So then what's the rational to not export the ASM which is included in the
> JDK anyway? I mean exporting from a jdk.xxx module, not from a standard
> module. Wouldn't that be useful if it is there anyway?
> 
> 
>  Ensuring that ASM and other such tools are prepared for classfile changes
>> with enough time to update is an Importanz 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
>>