POC: JDK ClassModel -> ASM ClassReader

[Rafael Winterhalter]

It's not really my decision what ASM is doing, but I think they agree with
my attempt to integrate ASM and the API:
https://gitlab.ow2.org/asm/asm/-/issues/317978

My favoured solution would be to merge this into core-ASM (via a
multi-release jar for example) and to pick up the reader/writer if
possible. This way ASM would automatically become forwards-compatible given
no byte code changes. (And the possibility to run unknown attributes
through ASM what is still an open issue in my bridge.) If ASM would not
want to do that, I would still want to adopt it for Byte Buddy.

I did a test with my bridge in Byte Buddy for a simple Java agent with a
downgraded ASM version and it worked really well.

Paul Sandoz <paul.sandoz at oracle.com> schrieb am Mo., 18. Juli 2022, 22:31:

> Fair point. How might you envisage the future of ASM? some stripped down
> version with integration hooks into the classfile API?
>
> Paul.
>
> > On Jul 10, 2022, at 11:54 AM, Rafael Winterhalter <rafael.wth at gmail.com>
> wrote:
> >
> > You are right that using AutoCloseable might be misleading, I had the
> same thought. I still chose the interface as IDEs know the type and warn if
> an AutoClosable is neither passed on nor closed, so I felt it would be a
> better choice compared to a custom method. I do however disagree with the
> ASM integration being an academic exercise. ASM is well-established and a
> de-facto standard for code generation. There's tons of code written in ASM
> and sometimes (like in Byte Buddy), ASM is publicly exposed and cannot be
> replaced without creating years of migration work. My hope is that a bridge
> like this would allow for ASM to adapt to the OpenJDK APIs for its readers
> and writers (on VMs where those are available). By achieving this, the "ASM
> problem" could be solved with the JVM version the API is released, which is
> likely many years before the OpenJDK API could make ASM obsolete.
> >
> > I agree that the focus should be on a convenient API and not to reinvent
> ASM in new cloths, but the new API should aim to make itself integratable,
> I think, as this would create huge value and speed-up adoption.
> >
> > Am Fr., 8. Juli 2022 um 22:53 Uhr schrieb Paul Sandoz <
> paul.sandoz at oracle.com>:
> > The inversion of control in the current API is indeed awkward when
> something else wants to take overall control, and in those circumstances
> one would have to give up certain features (like reapply as you noted) and
> there is more room for error (e.g. paring closes, use after close).
> >
> > Arguably making those open builders AutoCloseable is misleading, since
> since if the building can be lexically scoped one should use the existing
> API (ignoring details on exceptions and capturing, which I don’t think are
> sufficient to justify a new mode of writing).
> >
> > It feels like the ASM integration is more of an academic exercise. A
> useful one to play with the API and provide feedback, but in practice how
> useful is it? (Since one can always interoperate between classifies.)
> >
> > I am concerned the choice will be a distraction, but I don’t have any
> better concrete ideas right now. It would be helpful to understand more
> about the integration experiments with the Java compiler to
> compare/contrast.
> >
> > Paul.
> >
> > > On Jul 6, 2022, at 2:05 PM, Rafael Winterhalter <rafael.wth at gmail.com>
> wrote:
> > >
> > > With the writer, I have made some progress after adding a monadic view
> to ClassBuilder where one can apply a consumer multiple times before
> "closing" the writer for extracting a class file. I pushed this experiment
> on a commit of my clone (
> https://github.com/raphw/jdk-sandbox/commit/2be58f400b9ebf96b851eda658e0b8d2560421c5)
> to showcase the way I thought this might work. In theory, it should allow
> for any optimization of the current API. At the same time, it is awkward
> enough that people would only use it if they really needed it and therefore
> avoid it by default. And once they use it, any IDE would ask for closing
> each intermediate object when detecting the AutoCloseable interface. The
> only thing that I had to compromise on compared to "non-open" API was the
> use of CodeBuilderImpl which is currently reapplying the consumer in case
> of a LabelOverflowException. At the same time, I hoped that this might be a
> temporary state anyways as the possible reapplication is unlikely to be
> expected by any user.
> > >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220719/399ac179/attachment.htm>