Those look interesting Per.

We typically just use a normal assert for the assertEquals case:

assert 5.0 == 5.00

but there are folks that like the JUnit assertEquals variants.

The classloader stuff also looks useful.

Maybe create a Jira or discussion in the mailing list.

Cheers, Paul.

On Sat, Apr 4, 2026 at 1:54 AM Per Nyfelt <[email protected]> wrote:

> 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.
>

Reply via email to