Hey Paul,
Thanks for the great reply! Totally understand on being busy with all of
the releases.
First, regarding the notes on the GEP:
Thank you for the details, it really helped. As well, I appreciate the
clarifications and corrections (and mental model section). The updated
GEP looks much better and reads clearer and is easier to understand
(even though I am now biased since I've read it multiple times and no
longer have first-time reader objectivity).
Pedantic editing note, in the for "The two distinct benefits" section,
some of the code fences with backticks seem to be incorrect or something
is not escaped somewhere, leading to wonky rendering.
—
I do have some _curiosities_ regarding the "Method/constructor call
argument" part of the "Context types" section, as it relates to the "all
modes" category. I am assuming, given everything up until now in the
GEP, that this is _not_ quite what I think it is/what it is saying at
face value (i.e. "Dot shorthand doesn't work with method/constructor
calls"). There's a bit of nuance in there that I _think_ I understand …
maybe.
My operating assumption is that, taking our `logPrint` example as
context: it's not saying that `logPrint("Hello World", .INFO)` does NOT
implicitly work/is NOT supported per se. Rather, it's more about the
method's signature at compile time. The nuance being the question of:
"For any given method X, does the method's signature specify the types,
at compile-time, or is it dynamic (i.e. using `def` for types)?”?
Furthermore, I would take this to mean that even a single dynamic type
in a method's signature would "break" this from being possible, not just
the type of the parameter of the enum target (e.g. `public void
logPrint(def message, LogLevel level)` breaks this GEP's contract even
if/when used as `logPrint("Hello World", .RED)` since at compile-time
the types are not definitively known/dynamic dispatch is involved)? I
feel like my understanding here is very fuzzy and wrong.
I think that my understanding is leading me to believe that this is
overall alluding to the fact that `logPrint(String message, def
level)`/`public Logger(def level)` doesn't work/would not be compatible.
However, `logPrint(String message, LogLevel level)`/`public
Logger(LogLevel level)` _would_ work/be compatible because the types
(all of them) are/would be known at compile time, even without
`@CompileStatic` or `@TypeChecked`. Correct?
Apologies if I am being overly pedantic here.
—
>> > Similarly the feature only works in contexts where the type is
obvious
>> > and clear to the compiler (e.g. explicit declaration in/on LHS
>> > expressions): `Color my_color = .RED`. The benefit here being less
about
>> > imports and more about avoiding/reducing redundant code
duplication/over
>> > specification. Coupled with compile time type-safe literals over
the
>> > string coercion evaluation at runtime.
>> >
>> > Assuming this understanding is correct, this makes sense and I can
see
>> > the value in each case. Albeit I am less inclined to see a _lot_
of
>> > value in the second, but meh neither here or there around being
more
>> > expressive/less verbose being an a bad thing in and of itself
(i.e. I
>> > would rather have the option to be less verbose than always forced
to be
>> > verbose).
>
> Sure, but Groovy coerces String values to enum values too, so it isn’t
> just about
> a better score in code golf, but actual errors that would occur at
runtime like:
> Color myColor = ‘READ’
> could be caught at compile time.
Yeah, I should have clarified that more in my original remark around
"compile time type-safe literals". As you note, the dot-shorthand would
enhance type safety and make code safer/clearer in intent as well as
enable the compiler to find mistypes early on. Always a win in my book.
I completely agree with the value it brings in cases such as `Color
color = .RED` over `Color color = 'RED'` (fun fact: I didn't even know
that Groovy allows this/could do the string coercion into enum's ...
nice, dangerous ... but nice).
I could see someone making the case that this capability alone is a
strong enough reason to recommend/consider this feature further since it
significantly improves enum/enum-like types making them pleasant enough
and actually ergonomic to use.
Heck, time-permitting, I am probably going to tinker with things to get
some grammar for it working, slap-dashed of course.
—
Since my earlier reply, I have been deeply looking into this GEP/idea to
really understand it, poke some holes in it, etc. Some of the gotchas,
edge cases, and/or questions that I have come across include:
1. How would multiple possible ambiguous overloads/handling work? For
example, `public void classifyReport(Color color)` and `public void
classifyReport(ProjectStatus status)` where `enum ProjectStatus { RED,
YELLOW, GREEN }`. I'd throw a compiler error and force the user to
disambiguate though perhaps there is a more elegant solution.
2. Would `.valueOf` be supported? It would be somewhat redundant since
doing `Color color = str` would be the same, more or less, as `Color
color = .valueOf(str)`, right?
3. Could we do `.new(...)`? Would this just always be implicitly
supported?
4. Is there interplay with null-safe access?
I really do think this is a great feature and idea to add to the
language. Hopefully that is clear. It would absolutely be tremendously
useful, especially in actually getting to me use enums/enum-like types
at all, at the very least. As it stands today where using enum/enum-like
types is concerned, for me at least, they are elusive and archaic to the
code I see and write, so much so, that I had written enums off as
obsolete and irrelevant to/for practical use. Consequently, leading me
to completely forget the concept even exists and thus haven't used them
in years in many codebases/languages. I am sure I am not alone in that
sentiment, unfortunately.
Overall, it seems very possible, practical, and pragmatic, at least from
a surface review. Of course, the devil's in the details as they say.
—
Second, regarding the AI meta note (responses inline):
> On the generative tooling discussion. Yes there has been some AI
> assistance on the GEP. We "more or less" follow the ASF guidelines[1].
Thanks for the clarification and details. Totally get where you are
coming from. That policy is a good starting point, but I do wonder if
it's not a bit dated by now, at this point (it has a timeline reference
of June 2023 ... ancient in AI-tech term timelines).
Any who, my question was at high level, just very broadly knowing if the
content and AI overlapped in anyway. I saw tell-tale signs and
incongruity in the content that was indicative of AI but then again, I
know that I'm not an expert so I thought perhaps that I should just have
taken it at face value at first.
> "More or less" because there is a lot of debate at the moment:
> * Does it apply to docs and code?
> * Should we use "Generated-by" or "Assisted-by" to properly reflect
> the guideline which indicates the committer takes responsibility for
> the content.
Good questions, I don't really have strong thoughts or opinions on these
beyond: do we expect someone to be reading the material in question
ever? If so, proper source and/or attribution credits are probably going
to be helpful then.
> * If the intended purpose is to potentially produce a “machine
> parsable Tooling-Provenance file", why is AI that different to which
> compiler I used, what editor did I code in, what checkstyle rules did
> I use, and so forth.
Not to belabor the point, it's a good callout. I think that your
examples of compilers, editors, linters, etc. are not quite an
apples-to-apples comparison. Those tools are all deterministic in nature
and reproducible (in-spirit), while AI is not and cannot ever really be
(at least not what we call AI now and for all intents and purposes). Not
that it determinism makes a tool inherently better or worse, just that
there is more of an incentive to need to know about that tradeoff.
—
For clarity's sake, don't get me wrong, I am not anti-AI or such. My
perspective is that if one wants to use AI, go for it. More power to the
person. I use AI constantly. It's a great tool, like any other tool.
As far as I see it, it's just respectful and good etiquette to denote,
disclose, and attribute AI usage (in whatever form and however is
applicable/appropriate) in a properly, clearly, and explicitly denoted
fashion so that readers clearly know. Just seeing a tag of "AI" such
that I could then know "Yar, there be AI afoot here”.
For clarity, the reasons being that if I know something was involved
with AI, then I should both scrutinize a lot more and dismiss it
point-blank when there are signs of skipped steps/missing logic or
hallucinations.
Essentially, rather than try to operate along the lines of "Ok, XYZ
human wrote this, there's the implicit assumption that they are a sane,
rational, and logical person. They clearly they know better than me and
things that I don't. Let me try extra hard to reason through the topic
more thoroughly and with an intent to really try to understand it"; the
reader can operate with the knowledge that "Non-determinism is
non-determinism. Don't try to figure out if/how randomness begets logic.
Be on guard.”.
However, that's all just my opinion and take on it.
P.S.
I am not personally calling anyone out either. I just figured there
might be a blanket policy or something along those lines. I figured the
GEP was AI influenced in one way or another but wasn't sure and thought
it could just as well be "reader error" on my part (usually the case).
> TBH, knowing which tools/models were used has some benefit, but some
> folks see all the commit messages as being little more than free
> advertising to the LLM companies.
Yep. Good point. Just seeing "AI" as a tag or something like that is a
footnote/disclosure is all I ever usually look for. I totally get the
perspective of not doing product-placement/endorsement and dealing with
all of that. I am in agreement.
> These comments aren't to indicate that we should take guidelines
> lightly, just that we have some time while things settle down. Most
> people seem quite good at telling when content was
> AI-generated/assisted.
>
> I think the most important thing for us is knowing that heavy AI
> assistance should lead to heavy human review. And we should apply a
> risk-based approach. AI assist on docs/tests is less risky than prod
> code, and prod code itself has different risk profiles, e.g. a simple
> DGM method addition vs multithreading, some of our metaprogramming
> code, some of our type checking and bytecode gen code.
Fair enough. I tend to lean on the "heavy review" by default side for
any AI generated content. I guess it's more about the day coming when we
_can't_ easily tell when content had AI involvement.
—
Thanks again for the reply and warm welcoming to mailing list/community.
I hope to actively contribute and be helpful in some way.
Thanks,
Matt
------ Original Message ------
>From "Paul King" <[email protected]>
To [email protected]
Date 8/3/2026 11:40:16 PM
Subject Re: Some draft GEPs: GEP-28 and GEP-29
>
>
>Hi Matt,
>
>
>
>Thanks for your thoughtful reply. Sorry for the delay - I've been busy
>
>working on releases.
>
>
>
>On the generative tooling discussion. Yes there has been some AI
>
>assistance on the GEP. We "more or less" follow the ASF guidelines[1].
>
>"More or less" because there is a lot of debate at the moment:
>
>* Does it apply to docs and code?
>
>* Should we use "Generated-by" or "Assisted-by" to properly reflect
>
>the guideline which indicates the committer takes responsibility for
>
>the content.
>
>* If the intended purpose is to potentially produce a "machine
>
>parsable Tooling-Provenance file", why is AI that different to which
>
>compiler I used, what editor did I code in, what checkstyle rules did
>
>I use, and so forth.
>
>TBH, knowing which tools/models were used has some benefit, but some
>
>folks see all the commit messages as being little more than free
>
>advertising to the LLM companies.
>
>
>
>These comments aren't to indicate that we should take guidelines
>
>lightly, just that we have some time while things settle down. Most
>
>people seem quite good at telling when content was
>
>AI-generated/assisted.
>
>
>
>I think the most important thing for us is knowing that heavy AI
>
>assistance should lead to heavy human review. And we should apply a
>
>risk-based approach. AI assist on docs/tests is less risky than prod
>
>code, and prod code itself has different risk profiles, e.g. a simple
>
>DGM method addition vs multithreading, some of our metaprogramming
>
>code, some of our type checking and bytecode gen code.
>
>
>
>On to your comments on the GEP itself, you have a pretty good
>
>understanding. You pointed out some unclear bits, so I created a new
>
>version which improves some of those points and added some inline
>
>clarifications below.
>
>
>
>You have the general idea. Java programmers have the mental model that
>
>"I already told the compiler the type of my enum in the switch clause,
>
>so why should I have to tell it again in the case label".
>
>
>
>The PR extends that mental model to other places where we have already
>
>told the compiler about the type (or where it could infer it), so we
>
>avoid repeating that information. The leading dot also caters to
>
>dynamic Groovy, which would otherwise interpret some of these cases as
>
>properties.
>
>
>
>Cheers, Paul.
>
>
>
>[1] https://www.apache.org/legal/generative-tooling.html
>
>
>
>On Thu, Jul 30, 2026 at 3:17 AM Matt M <[email protected]> wrote:
>>
>>
>>
>> Hello,
>>
>>
>>
>> I am not sure of the GEP process, however, I figured I could chime-in
>>
>> with some, hopefully, helpful feedback.
>>
>>
>>
>> I agree with the sentiment thus far: adding the dot shorthand is a
>>
>> relatively easy improvement to the language ergonomics in some very
>>
>> specific narrow cases. However, the syntax can/does seem a bit eccentric
>>
>> or uncomfortable. Though, I can imagine myself getting used to it over
>>
>> time as I am exposed to it more and more. There's a certain beauty in
>>
>> the symmetry of it versus using a separate designator or signifier
>>
>> instead (e.g. `:RED`).
>>
>>
>>
>> That said, I thought I had read through the document fairly well and
>>
>> understood what it was getting at. However, that said, I am not
>>
>> intimately familiar with the other languages mentioned in the GEP (i.e.
>>
>> Dart and Swift primarily) such that I have a firm grasp of/on the
>>
>> semantics being proposed. Therefore, I wanted to perhaps re-state the
>>
>> GEP with my understanding of the GEP as a way to clarify and perhaps
>>
>> provide some feedback.
>>
>>
>>
>> —
>>
>>
>>
>> One of the fundamental benefits of this feature would be avoiding the
>>
>> need to import enum/enum-like types (static or otherwise) if/when they
>>
>> can be inferred from their localized usage. For example:
>>
>>
>>
>> ```
>>
>> LogLevel.groovy
>>
>> public enum LogLevel { … }
>>
>>
>>
>> Loggers.groovy
>>
>> public void log_print(String message, LogLevel level) { … }
>>
>>
>>
>> App.groovy
>>
>> log_print("Hello world", .INFO);
>>
>> ```
>>
>>
>>
>> Such usage of the feature, in the context of the method call, is only
>>
>> possible because of the method signature allowing the compiler to know
>>
>> about and clearly infer the type being used and thus allows the user to
>>
>> avoid importing the type explicitly and qualifying the usage of the
>>
>> value with the aforementioned type.
>
>
>
>Spot on. I added a clarification in the GEP on this.
>
>
>>
>> Similarly the feature only works in contexts where the type is obvious
>>
>> and clear to the compiler (e.g. explicit declaration in/on LHS
>>
>> expressions): `Color my_color = .RED`. The benefit here being less about
>>
>> imports and more about avoiding/reducing redundant code duplication/over
>>
>> specification. Coupled with compile time type-safe literals over the
>>
>> string coercion evaluation at runtime.
>>
>>
>>
>> Assuming this understanding is correct, this makes sense and I can see
>>
>> the value in each case. Albeit I am less inclined to see a _lot_ of
>>
>> value in the second, but meh neither here or there around being more
>>
>> expressive/less verbose being an a bad thing in and of itself (i.e. I
>>
>> would rather have the option to be less verbose than always forced to be
>>
>> verbose).
>
>
>
>Sure, but Groovy coerces String values to enum values too, so it isn't
>
>just about
>
>a better score in code golf, but actual errors that would occur at runtime
>like:
>
>Color myColor = 'READ'
>
>could be caught at compile time.
>
>
>>
>> —
>>
>>
>>
>> Any who, I wasn't _super_ clear on all of this in the examples/cases of
>>
>> the GEP, so it might be worth elaborating and expanding a bit more.
>>
>> Since in my first readings, I wasn't convinced and questioned how this
>>
>> avoids the required import anyways to even use the enum/enum-like type.
>>
>>
>>
>> I do see a lot of value/"nice'ness" with/for being able to use this
>>
>> feature with the static factory methods (e.g. `.of(...)`, etc.). That
>>
>> would be really nice and just add that extra bit of nice syntax sugar.
>>
>>
>>
>> I am still a bit hazy on how/where this shorthand would apply exactly in
>>
>> all cases, based on reading the GEP. I am uncertain if it would work
>>
>> in/with the `==` operator. For example, would it work for `if
>>
>> (this.my_color == .RED) { ... }` cases or not? Would it depend if
>>
>> `my_color` was defined as something like `public Color my_color` or
>>
>> `public def my_color`? Again, I am not _super_ clear on this.
>>
>>
>>
>> The GEP seems to have a bit of contradictory notes around this. The `==`
>>
>> example/case is mentioned a few times as being partially supported early
>>
>> on and then it is mentioned as maybe being supported in the deliverables
>>
>> section but then says its an excluded feature? So that's why I am
>>
>> unsure.
>
>
>
>Yeah, that wasn't clear and I have improved it. Let me know if it
>
>still seems too complex.
>
>
>>
>> Finally, more of a meta note/question, was this GEP written by AI or
>>
>> assisted with AI? There seem to quite a few places that read as if it
>>
>> were written by AI. I am not sure what the official policy or line is on
>>
>> the whole usage of AI is in Groovy / GEP's, but if AI is involved in
>>
>> anyway: it would be good etiquette to explicitly, clearly, and boldly
>>
>> mention that the GEP was AI written and/or its contents' creation was
>>
>> assisted with AI tools. This way more appropriate and applicable
>>
>> scrutiny may be applied, especially for contradictions, inaccuracies,
>>
>> and/or hallucinations.
>>
>>
>>
>> Any who, I hope this has been helpful. Looks really cool.
>>
>>
>>
>> Thanks,
>>
>> Matt
>>
>>
>>
>>
>>
>> ------ Original Message ------
>>
>> From "Paul King" <[email protected]>
>>
>> To "Groovy_Developers" <[email protected]>
>>
>> Date 7/29/2026 12:06:10 AM
>>
>> Subject Re: Some draft GEPs: GEP-28 and GEP-29
>>
>>
>>
>> >
>>
>> >
>>
>> >Yeah, it will be one of those subjective things.
>>
>> >
>>
>> >
>>
>> >
>>
>> >Some folks think it is ugly to have to type "Color.RED" when Java lets
>>
>> >
>>
>> >you just type "RED". We have that down to just one case now (or you
>>
>> >
>>
>> >can use an import) but for dynamic Groovy we probably can't do better.
>>
>> >
>>
>> >The GEP proposal would give another option. And for some folks all the
>>
>> >
>>
>> >extra places they can shorten using a consistent pattern might seem
>>
>> >
>>
>> >like a beautiful thing to them, but yes I still fall into the camp of
>>
>> >
>>
>> >"it looks a little awkward", but I am still keen to explore the
>>
>> >
>>
>> >possibilities.
>>
>> >
>>
>> >
>>
>> >
>>
>> >Cheers, Paul.
>>
>> >
>>
>> >
>>
>> >
>>
>> >On Wed, Jul 29, 2026 at 6:25 AM MG <[email protected]> wrote:
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Just a quick feedback for GEP-28: I saw that "Sigil variants" (@RED,
>>
>> >>
>>
>> >> :RED, etc) are already stated as rejected in the GEP, but what about
>>
>> >>
>>
>> >> something similar to Groovy's "it" in closures (maybe as an option, to
>>
>> >>
>>
>> >> also be able to break ambiguities without having to fall back to the
>>
>> >>
>>
>> >> current fully qualified notation) ?
>>
>> >>
>>
>> >> To me the floating-in-free-air-dot-prefix notation ( .RED ) looks like
>>
>> >>
>>
>> >> an error / ugly...
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Cheers,
>>
>> >>
>>
>> >> mg
>>
>> >>
>>
>> >>
>>
>> >>
>>
>> >> Am 28.07.2026 um 08:30 schrieb Paul King:
>>
>> >>
>>
>> >> > Hi folks,
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > I created two more draft GEPs tentatively targeting Groovy 7:
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > * GEP-28 is about supporting DOT-notation that is supported by Dart
>> and Swift.
>>
>> >>
>>
>> >> > [I like the brevity it gives but it also takes some getting used to
>>
>> >>
>>
>> >> > and it complicates things if Java ever develops a different compact
>>
>> >>
>>
>> >> > syntax.]
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > * GEP-29 is about supporting deeper null checking.
>>
>> >>
>>
>> >> > [This is really about whether we want to fully support JSpecify which
>>
>> >>
>>
>> >> > seems to be gaining momentum. NullChecker in Groovy 6 already offers
>>
>> >>
>>
>> >> > partial support.]
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > I don't really have the cycles to do major reviews of the GEPs yet,
>>
>> >>
>>
>> >> > and I expect both will go through several iterations when we do. For
>>
>> >>
>>
>> >> > both we should ask ourselves whether we need the feature and weigh up
>>
>> >>
>>
>> >> > each's value against the increased complexity. But I wanted to capture
>>
>> >>
>>
>> >> > the ideas anyway, since I think they are worth thinking about in due
>>
>> >>
>>
>> >> > course. We should be comfortable with rejecting GEPs if the ideas
>>
>> >>
>>
>> >> > don't belong or belong somewhere else.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > To be honest, we already have a backlog of potential Groovy 7 features
>>
>> >>
>>
>> >> > that will keep us busy for a while.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > But if other folks want to jump ahead and think about them, feel free.
>>
>> >>
>>
>> >> >
>>
>> >>
>>
>> >> > Cheers, Paul.
>>
>> >>
>>
>> >>
>>
>>
