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