Thanks for the reply Paul (especially during trying to get V6's second
beta shipped).
Response inline:
> We could look at expanding defer further but given Groovy has
try/finally, try-with-resources, and withCloseable, numerous cases where
you'd use it in Go aren't needed here. That's not to say it wouldn't
still be useful in some additional places.
True. I misunderstood it then to an extent. I read it as an attempt to
incorporate the syntax from other languages such as Go, Zig, Odin,
Swift, and Jai to help lessen some of the boilerplate resulting from
`try/finally` and `try-with-resources` causing awkward clean-up
code/obligation(s) to appear farther away from where the obligation(s)
occurred.
As I thought about it even more I only reinforced my own logic, as it
even made since it helped prevent nesting for cases where there might
multiple `try/finally`/etc. blocks created inside of each other.
Especially when the API/code involved is not compatible with
`try-with-resources`/`withClosable` and folks would need to create
custom ad-hoc DSL's if they wanted to avoid such cases (ask me how I
know). All kludges for sure.
Thinking about it more now, I have a feeling it would dove-tail quite
nicely with other features such as the post-conditions part of
design-by-contract (maybe) and parts of the API's theorized in GEP-24
(in theory at least: `attempt { defer ...; ... }`). That's what I could
imagine it leading up to and supporting in the long-run.
> Would a defer inside a closure attach to the closure, the enclosing
method, or the block?
You raised a good question here. When I was suggesting this, I naturally
intuited the symmetry with the existing semantics of "defer works
with/on the scope an async closure" to be "defer would also work with/on
the scope of a regular closure the same way" (seamless). The parallel
symmetry just seemed to naturally fit for me, in my mind at least.
It would be interesting to see what would surprise people about the
semantics if such an implementation were picked. The other interesting
thing was that I would gauge most people naturally intuit a Groovy
closure as analogous to a method/function (I mean closures already blur
_really_ well with Java lambdas too) and thus expect essentially pretty
similar semantics.
I am curious, what did you naturally first assume or intuit how such a
feature might work with a regular closure?
> ...it's probably a Groovy 7 feature.
Yeah, fair enough.
> I just tried using defer outside an async scope and it yields a
pretty ugly MissingPropertyException.
He he, I ran into that nasty little error too and was confused such that
I thought `defer println("Hello World")` just wasn't supported at all. I
appreciate the error message PR to fix that. It's definitely cleaner and
doesn't leak a deep underlying implementation detail to folks.
In fairness, before I brought this up, I did get `defer` to work with
statement/expression and extend the existing support it had in V6. It
wasn't too bad, pretty straightforward. It's been nice to have it
available and certainly being able to quickly just do `defer XYZ` rather
than either do `try { ... } finally { ... }` or give up because I am too
lazy to write my own DSL at that point :)
Certainly food for thought for V7 at the very least.
Thanks,
Matt
------ Original Message ------
>From "Paul King" <[email protected]>
To [email protected]
Date 8/12/2026 9:32:23 PM
Subject Re: [ANNOUNCE] Apache Groovy 6.0.0-beta-1 Released
>
>
>I created: https://github.com/apache/groovy/pull/2783
>
>
>
>This at least locks things down for the time being and improves some
>
>of the error messaging. We can remove such checks if we expand to
>
>cover those cases down the track.
>
>
>
>On Thu, Aug 13, 2026 at 10:11 AM Paul King <[email protected]> wrote:
>>
>>
>>
>> Hi Matt,
>>
>>
>>
>> We could look at expanding defer further but given Groovy has
>>
>> try/finally, try-with-resources, and withCloseable, numerous cases
>>
>> where you'd use it in Go aren't needed here. That's not to say it
>>
>> wouldn't still be useful in some additional places.
>>
>>
>>
>> The tricky thing outside an async scope in Groovy is picking the
>>
>> desired semantics. Would a defer inside a closure attach to the
>>
>> closure, the enclosing method, or the block? Closures blur "function
>>
>> scope" in a way Go doesn't have to deal with, and whichever answer we
>>
>> picked would surprise someone. Inside an async closure there's a
>>
>> crisp, defensible answer: the async task. We could look at this
>>
>> further, but honestly, it's probably a Groovy 7 feature.
>>
>>
>>
>> I just tried using defer outside an async scope and it yields a pretty
>>
>> ugly MissingPropertyException. This is accurate but possibly puzzling
>>
>> for new users. It is quite possible that others also share your
>>
>> expectations, we could certainly look at adding a dedicated error
>>
>> message for that case during the Groovy 6 timeframe.
>>
>>
>>
>> Cheers, Paul.
>>
>>
>>
>> On Tue, Aug 11, 2026 at 9:17 AM Matt M <[email protected]> wrote:
>>
>> >
>>
>> > Thanks Paul!
>>
>> >
>>
>> > It might be too late, however, I wondered if there is still time to
>>
>> > provide some feedback on Groovy 6? Since beta1 came out the other day, I
>>
>> > have been finally using it and playing around with it and had a few
>>
>> > thoughts.
>>
>> >
>>
>> > The primary surprise was around the `defer` keyword. This is something I
>>
>> > was eagerly looking forward to. One of the expectations I had going into
>>
>> > it, given my reading of the Groovy 6 blog on Async/Await and the notes,
>>
>> > is that it would work like Go’s defer keyword. However, that doesn’t
>>
>> > appear to be the case. It appears to be exclusive to async/await code.
>>
>> >
>>
>> > Is there a semantic reason or design goal for not having it work for
>>
>> > both use cases (async/await code and like Go’s defer)?
>>
>> >
>>
>> > I already tinkered with adding support for it to work in any context and
>>
>> > act like Go’s defer instead.
>>
>> >
>>
>> > However, I figured I would ask if there was perhaps a larger design goal
>>
>> > or vision that perhaps explains why it doesn’t already do that.
>>
>> >
>>
>> > Thanks,
>>
>> > Matt
>>
>> >
>>
>> > ------ Original Message ------
>>
>> > From "Paul King" <[email protected]>
>>
>> > To [email protected]
>>
>> > Date 8/10/2026 6:37:41 AM
>>
>> > Subject Re: [ANNOUNCE] Apache Groovy 6.0.0-beta-1 Released
>>
>> >
>>
>> > >
>>
>> > >
>>
>> > >I'll try to do 6.0.0-beta-2 (and 5.1.0) later in the week - still a
>>
>> > >
>>
>> > >few PRs to finish reviews for.
>>
>> > >
>>
>> > >
>>
>> > >
>>
>> > >Cheers, Paul.
>>
>> > >
>>
>> > >
>>
>> > >
>>
>> > >On Wed, Aug 5, 2026 at 7:27 AM Paul King <[email protected]> wrote:
>>
>> > >>
>>
>> > >>
>>
>> > >>
>>
>> > >> Thanks everyone for the great team effort in getting the Groovy 6
>>
>> > >>
>>
>> > >> beta-1 release ready. The release is out and I have created beta-2 in
>>
>> > >>
>>
>> > >> Jira. I think we are feature complete with Groovy 6 and we won't get
>>
>> > >>
>>
>> > >> further feedback from some parts of our ecosystem until we get 6 to
>>
>> > >>
>>
>> > >> GA. So my plan is to rename beta-2 to RC-1 before the next release IF
>>
>> > >>
>>
>> > >> we only have bug fixes and minor or opt-in improvements. I'd also like
>>
>> > >>
>>
>> > >> to release sooner rather than later - maybe kicking off in a week or
>>
>> > >>
>>
>> > >> two. But we'll do a beta-2 if we need it - there are some pending PRs
>>
>> > >>
>>
>> > >> that might warrant a beta-2.
>>
>> > >>
>>
>> > >>
>>
>> > >>
>>
>> > >> Cheers, Paul.
>>
>> > >>
>>
>> > >>
>>
>> > >>
>>
>> > >> On Tue, Aug 4, 2026 at 4:40 PM Paul King <[email protected]> wrote:
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > Dear community,
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > The Apache Groovy team is pleased to announce version 6.0.0-beta-1
>> of
>>
>> > >>
>>
>> > >> > Apache Groovy.
>>
>> > >>
>>
>> > >> > Apache Groovy is a multi-faceted programming language for the JVM.
>>
>> > >>
>>
>> > >> > Further details can be found at the https://groovy.apache.org
>> website.
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > This is a pre-release of a new version of Groovy.
>>
>> > >>
>>
>> > >> > We greatly appreciate any feedback you can give us when using this
>> version.
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > This release includes 88 bug fixes/improvements as outlined in the
>> changelog:
>>
>> > >>
>>
>> > >> >
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318123&version=12357232
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > Sources, convenience binaries, downloadable documentation and an SDK
>>
>> > >>
>>
>> > >> > bundle can be found at: https://groovy.apache.org/download.html
>>
>> > >>
>>
>> > >> > We recommend you verify your installation using the information on
>> that page.
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > Jars are also available within the major binary repositories.
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > We welcome your help and feedback and in particular want
>>
>> > >>
>>
>> > >> > to thank everyone who contributed to this release.
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > For more information on how to report problems, and to get involved,
>>
>> > >>
>>
>> > >> > visit the project website at https://groovy.apache.org/
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > Best regards,
>>
>> > >>
>>
>> > >> >
>>
>> > >>
>>
>> > >> > The Apache Groovy team.
>>
>> >
