+1 on the plan overall, but I'm not sure whether I'd forbid the JUnit asserts wholesale. I've found myself combining AssertJ for collection assertions and things like that with assertEquals() / assertTrue() for the most basic things.
--Gunnar On Fri, 3 Jul 2026 at 18:07, Eduard Tudenhöfner <[email protected]> wrote: > > That high-level plan sounds good to me and aligns with my thinking on this. > However, I don't think we can forbid JUnit asserts via *spotless*. In > Iceberg [1] we forbid those by using *checkstyle*, but *checkstyle* isn't > used in the parquet project. > > [1]: > https://github.com/apache/iceberg/blob/2f05390e0730200866f52a7e8585480bd6c4596e/.baseline/checkstyle/checkstyle.xml#L482-L491 > > > On Fri, Jul 3, 2026 at 3:36 PM Steve Loughran <[email protected]> wrote: > > > On Mon, 29 Jun 2026 at 15:37, Russell Spitzer <[email protected]> > > wrote: > > > > > +1 > > > > > > I do think these are generally worthwhile. They are also a great help > > > for consistency. As long as it doesn't require a huge rewrite of the > > > existing > > > codebase I think it's worth while gradually switching. > > > > > > > > > > > I'd propose something like > > > > 1. PR to add assertJ to POMs: no source code changes > > 2. Policy of new test suites to be assertJ only, changes to existing > > test suites to remain junit. > > 3. move individual modules to assertj; > > 4. spotless rules to forbid junit asserts > > > > > > Doing in this order means there'd be a mix of the different asserts for a > > while, and existing prs would need some work. > > > > Getting the AI tools to do a lot of the migration will help. > >
