<div dir="auto">It's not really my decision what ASM is doing, but I think they agree with my attempt to integrate ASM and the API: <a href="https://gitlab.ow2.org/asm/asm/-/issues/317978">https://gitlab.ow2.org/asm/asm/-/issues/317978</a><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Paul Sandoz <<a href="mailto:paul.sandoz@oracle.com">paul.sandoz@oracle.com</a>> schrieb am Mo., 18. Juli 2022, 22:31:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fair point. How might you envisage the future of ASM? some stripped down version with integration hooks into the classfile API?<br>
<br>
Paul.<br>
<br>
> On Jul 10, 2022, at 11:54 AM, Rafael Winterhalter <<a href="mailto:rafael.wth@gmail.com" target="_blank" rel="noreferrer">rafael.wth@gmail.com</a>> wrote:<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Am Fr., 8. Juli 2022 um 22:53 Uhr schrieb Paul Sandoz <<a href="mailto:paul.sandoz@oracle.com" target="_blank" rel="noreferrer">paul.sandoz@oracle.com</a>>:<br>
> 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).<br>
> <br>
> 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).<br>
> <br>
> 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.)<br>
> <br>
> 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.<br>
> <br>
> Paul.<br>
> <br>
> > On Jul 6, 2022, at 2:05 PM, Rafael Winterhalter <<a href="mailto:rafael.wth@gmail.com" target="_blank" rel="noreferrer">rafael.wth@gmail.com</a>> wrote:<br>
> > <br>
> > 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 (<a href="https://github.com/raphw/jdk-sandbox/commit/2be58f400b9ebf96b851eda658e0b8d2560421c5" rel="noreferrer noreferrer" target="_blank">https://github.com/raphw/jdk-sandbox/commit/2be58f400b9ebf96b851eda658e0b8d2560421c5</a>) 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.<br>
> > <br>
> <br>
> <br>
<br>
</blockquote></div>