Re: My verdict on AST level joint compilation

Hi Paul,

even if this topic is not directly relevant to us (we went 100% Groovy 
in our project some time ago), going for an 80% - 90% approach (by 
basically introducing something like an "AST-transform-interface" 
concept), instead of forever waiting for the "perfect" solution (that 
most likely never comes), seems like a good & workable idea here to me.

Cheers,
mg

Am 29.04.2026 um 05:54 schrieb Paul King:
> I updated the GEP and created a spike. In the spike I tried 4 
> transforms: @Sortable, @ToString, @TupleConstructor, @Lazy.
> The "shape" of what they later fully inject is added during CONVERSION 
> and appear in the stubs. Basically, any AST transform, on an opt-in 
> basis, can inject a stub at CONVERSION and fill it out properly during 
> the normal AST transform call.
>
> If folks like the idea, I can see what additional transforms this 
> might work for. It isn't as fancy as Jochen's original proposal, and 
> it isn't a solution that covers every case, but so far it seems to 
> cover quite a few cases.
>
> It won't cover situations where the shape of members added in later 
> injections can't be known in advance. So, there will still be some 
> caveats but far fewer. And it does mean we (and our users) have to 
> write the stub injection code for each affected transform if we (they) 
> want to gain the extra visibility in their stubs.
>
> Cheers, Paul.
>
>
> On Tue, Apr 28, 2026 at 7:17 AM Paul King <[email protected]> wrote:
>
>     I created a very early alpha GEP capturing a version of Eric's idea:
>
>     https://github.com/apache/groovy-website/blob/asf-site/site/src/site/wiki/GEP-21.adoc
>
>     https://groovy.apache.org/wiki/GEP-21.html
>
>     It was mostly Claude and I haven't vetted it properly yet, so it
>     might have some holes/hallucinations, but it should serve as a
>     suitable starting point for an on-going conversation.
>
>     I would also be keen to help progress this, but more than happy if
>     someone else wants to take the lead.
>
>     Cheers, Paul.
>
>
>     On Tue, Apr 28, 2026 at 1:53 AM Jochen Theodorou
>     <[email protected]> wrote:
>
>         On 4/27/26 16:35, Milles, Eric (TR Technology) via dev wrote:
>         [...]
>         > In general, I think the expectation is that we offer a
>         single source
>         > folder that can have bi-directional dependencies between
>         groovy and java
>         > sources.
>
>         it would actually be interesting to know more about the
>         expectations of
>         our users here
>
>         > In practice, this has probably reached a good-enough state.
>         > The cost of supporting the last 20% -- features like @Delegate,
>         > @Builder, and so on -- may or may not be worth the
>         complexity or risk.
>
>         agreed
>
>         > I have considered the idea of split-phase AST transforms. 
>         For example,
>         > if a transform can run in CONVERSION or SEMANTIC_ANALYSIS to
>         add some
>         > tags (annotations, interfaces, metadata, ...) or stub
>         elements (fields,
>         > methods, inner classes, ...).  Then a second pass of the
>         transform runs
>         > in CANONICALIZATION or INSTRUCTION_SELECTION to finish off
>         the code
>         > generation.  This sort of thing could help with java stubs.
>
>         yes, plus the transform could carry a marker interface that
>         shows it is
>         joint compilation friendly.
>
>           bye Jochen
>