java.bytecode (or similar) module?

[Volker Simonis]

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
>
>