As someone who's written some transforms that need to run in multiple phases (JPA manipulations, and I use some chaining hacks), what seems really spiffy to me would be a Template Method transform style where every phase gets a method that's called in its turn, with preserved object identity for private state. This seems like it would make stub coexistence at least easier. I expect that the instance reuse would be more invasive than the current system, though.
On Wed, Apr 29, 2026 at 1:47 PM MG <[email protected]> wrote: > 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 >>> >> >
