Re: Feedback requested for Groovy 6

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.