<div dir="ltr"><div>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.</div><div><br></div><div>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></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Fr., 8. Juli 2022 um 22:53 Uhr schrieb Paul Sandoz <<a href="mailto:paul.sandoz@oracle.com">paul.sandoz@oracle.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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">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" 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>
</blockquote></div>