As an example, code such as the following: ``` Function<String, String> transformer = SomeLibrary.transformer() def transformed = listOfStrings.collect(transformer) // instead of listOfStrings.collect(transformer.&apply) ```
Lots of library code, especially with "fluent interfaces", now works by handing you back a Function or similar interface that is intended to slide into a stream/functional/reactive pipeline, but while these interfaces are semantic synonyms for various arity of Closure, the Groovy built-in extensions predate them and haven't been updated to accommodate. On Thu, Apr 2, 2026 at 9:07 AM Paul King <[email protected]> wrote: > Thanks for the feedback Christopher. Can you give an example of what > you'd like to achieve? I think I know what you mean but want to be > sure. > > Paul. > > On Thu, Apr 2, 2026 at 8:37 PM Christopher Smith > <[email protected]> wrote: > > > > One thing I've been meaning to attempt but have not had the bandwidth is > to update the built-in extensive methods (mostly DefaultGroovyMethods) with > overloads that accept the JDK functional interfaces instead of Closure. > With the strong adoption of functional features by many libraries, the > impedance mismatch of not being able to feed those functions to (for > example) `collect` is both a dev and performance drag. > > > > Christopher Smith > > > > On Thu, Apr 2, 2026, 04:08 Remi Forax <[email protected]> wrote: > >> > >> ----- Original Message ----- > >> > From: "Paul King" <[email protected]> > >> > To: [email protected], "Groovy_Developers" < > [email protected]> > >> > Cc: [email protected], "dev" <[email protected]> > >> > Sent: Thursday, April 2, 2026 7:52:18 AM > >> > Subject: Feedback requested for Groovy 6 > >> > >> > Hi folks, > >> > > >> > We are nearing time to do an alpha-1 release of Groovy 6. Thanks to > >> > the Groovy dev team and all users giving feedback for working on, or > >> > helping us shape, this new version. > >> > > >> > We are seeking feedback from users and other framework writers in the > >> > Groovy ecosystem for any features you would like to see in Groovy 6, > >> > and on the ones we have been looking to include. We can't always say > >> > "yes" to all feature proposals, but we are always keen on having > >> > discussions. > >> > > >> > You can have a quick look at the very draft release notes: > >> > > >> > https://groovy-lang.org/releasenotes/groovy-6.0.html > >> > > >> > We also published a series of blog posts over the last couple of weeks > >> > seeking feedback on potential features. > >> > >> [...] > >> > >> > > >> > https://groovy.apache.org/blog/groovy-async-await > >> > > >> > Inspired by similar constructs in JavaScript, C#, Kotlin, and Swift, > >> > the proposal lets you write asynchronous code in a sequential, > >> > readable style. This allows developers to leverage virtual threads on > >> > our compute environments, which have ever increasing processing power, > >> > but without the complexity of writing ad-hoc multi-threaded code. > >> > (This is quite mature and ready for merging but hasn't seen widespread > >> > testing outside a few folks in the development team) > >> > >> Hello Paul, > >> I think you reach peak complexity (as Brian Goetz would say) with this > feature. > >> > >> There are 3 problems with CompletableFeature, > >> the code is not very readable and forgetting about exceptional case is > too easy, you have no stacktrace so when an error occurs, you are lost, you > can not profile it (because there is no stacktrace) so if your code is > slow, you are lost. > >> > >> Groovy is not only about the syntax, in my opinion, it's also about the > runtime experience, the fast feedback, you hit a runtime error, you fix it, > you continue. > >> > >> This proposal does not groove me, it's syntactic sugar on top of a > "Future Closure". > >> > >> There is a need for async being easy in Groovy, but not based on a > design similar to completable future. > >> Early erlang / early Go design, with a transparent management of the > exception / cancellation / timeout would be far better. > >> > >> Something like, an async keyword to create an asynchronous expression > and a await + all/any and timemout should be enough > >> > >> def captureTheFlag(hero, villain, flag) { > >> var heroGrab = async hero.grab(flag) // a Task object with > a volatile state typed State := NON_STARTED | Success(V value) | > Failure(Throwable t) > >> // + an owner thread, > so it can not be submitted/awaited by more than one thread > >> var villainGrab = async villain.grab(flag) > >> > >> var winner = await 1s any(heroGrab, villainGrab) else "no winner" > // run using virtual threads or not (an Executor) > >> > >> print $heroGrab() // either the value or throw the exception thrown > by hero.grab() (or a runtime exception for NON_STARTED) > >> } > >> > >> The method captureTheFlag does not need to be flagged as "async", there > is no wrappring/rewriting to a completable future code > >> > >> > >> I think you should reconsider how to make async easy in Groovy, both in > terms of syntax but also in terms of what's happen at runtime. > >> > >> [...] > >> > >> > > >> > Thanks, Paul. > >> > >> regards, > >> Rémi >
