POC: JDK ClassModel -> ASM ClassReader

[Paul Sandoz]

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