btw, the idea of using a marker interface for the joint compilation
compatibility (or incompatibility) was to potentially be able to fail
joint compilation in case these classes are used. Of course that would
make only sense if the Groovy class is actually used by Java in such a
manner that it matters.. which is difficult.
I do like using multiple transforms like you did.
bye Jochen
On 4/30/26 22:43, Paul King wrote:
We don't stop anyone going 100% Groovy! :-) But for those who don't, I
think the current spike represents a solid move forward for Groovy/Java
interop. In almost all places where we know the shape of the final
class, that shape is now reflected accurately in the stubs.
Obviously, things we don't know about at CONVERSION phase, we can't
reflect. Then, there are a small number of more complicated cases, that
aren't currently covered but we could possibly cover later. Importantly,
these are now covered in the documentation for each impacted transform,
rather than a general caveat that has been in place before.
The approach used by our transforms can be followed by framework
developers too and there are many examples in the codebase and learnings
in the GEP-21 doco which they can lean on.
The other thing which is now covered is native records - except for a
few edge cases which we could aim to improve upon if needed.
Cheers, Paul.
On Thu, Apr 30, 2026 at 4:46 AM MG <[email protected]
<mailto:[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]
<mailto:[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://github.com/apache/groovy-
website/blob/asf-site/site/src/site/wiki/GEP-21.adoc>
https://groovy.apache.org/wiki/GEP-21.html <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] <mailto:[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
