POC: JDK ClassModel -> ASM ClassReader

[Rafael Winterhalter]

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/20220710/bdacd93f/attachment-0001.htm>