I think it would be nice with some additional "groovifications" to junit
(groovy-test-junit6) e.g:
1. Fix assertEquals for BigDecimal so compareTo is used instead of
equals. (so that Assertions.assertEquals(5.0, 5.00) is true)
2. Make it possible to use @Grab directly in tests by providing a
launcher interceptor for the RootLoader
The https://github.com/Alipsa/groovier-junit is doing just this and
explains the additions in more detail.
I also think it would be very useful to be able override +=, -= etc. as
has previously been discussed.
Regards,
Per
On 4/2/26 07:52, Paul King wrote:
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/loop-invariants
Loop invariants allow assertions about loop behavior to be captured as
statements. This can help humans and AI reason about loop properties,
such as termination and correctness.
(This has been merged as an optional incubating module but feedback is
still welcome)
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)
https://groovy.apache.org/blog/groovy-null-checker
For those with type safety envy of Kotlin, C# or Checker Framework
users, you can now do more complete null-safety checking using a new
type checking extension.
(This is freshly baked and more use and feedback is welcome. In the
first instance, if accepted, it would become an optional incubating
type-checking extension.)
If you have feedback on any of these proposals, or have other features
you might want to know whether we have explored, please have a chat to
us on the dev mailing list or in one of the chat forums.
Thanks, Paul.
