Hi Elliotte, Think several points are, even if unrelated to this thread, wrong:
* Support: it is not more supporter so you can get surprises with recent java versions or warnings at least * JUnit3 is mainly about inheritance which is very limited and legacy since Junit4 with rules and JUnit 5 goes the step further enabling more "context" composition (where Junit4 was often stucked to some required rule params or runner+rule compositions) So there cn be reasons to migrate for still maintained and in dev project - like maven and this is why we did for some projects, for others, as Sandra said, stick to the old java+maven+plugins, no point to migrate. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le ven. 3 oct. 2025, 14:11, Elliotte Rusty Harold <[email protected]> a écrit : > On Thu, Oct 2, 2025 at 9:21 AM Sandra Parsick <[email protected]> wrote: > > > My 2ct to the JUnit 3 discussion: > > > > The last release of JUnit 3 was 2007. 18 years ago! I think that is > > enough time for a migration :o). I know manual migration sucks. But > > fortunately, nowadays we have tools like OpenRewrite [2] that can > > automate the happy part and help automate the custom part [3]. Of > > course, it depends on your customization how big the manual part will > > stay. But hey, that is the known consequence of customizing. > > To be honest, if you have no problem staying on JUnit 3 then you should > > be okay to stay on an older Surefire plugin version that supports JUnit > 3. > > You say that like it’s a bad thing. JUnit 3 is a mature, battle > tested, and bug free product that fully serves its purpose. It works > in essentially all versions of Java in use today (I think minimum is > Java 1.1?)) and is thoroughly documented, supported, and understood. > There haven’t been releases since 2007 because it hasn’t needed a > release since 2007. > > If you want reliable, bug free software, you need to know when to > stop. Chasing the new shiny is not sufficient reason to release. If > there’s nothing that needs to be done, (and for JUnit 3 there isn’t), > then nothing is precisely what you should do. I’ve talked more > extensively about this here: > > https://www.youtube.com/watch?v=XdoUNQTDE_U&t=3745s > > JUnit 4 and 5 do not improve on JUnit 3, or each other. They are > simply two more ways to do the same thing. The improvements I see that > help developers test code are in supplementary libraries like assert4j > or Guava Testlib, not the core frameworks. So if a project wants to > keep using JUnit 3, it should. Burning developer time upgrading is > irrational. > > -- > Elliotte Rusty Harold > [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
