On Sat, Mar 28, 2026 at 11:35 AM Michael Osipov <[email protected]> wrote:
> Just wanted to share a few toughts because the debate is heated and I > don't want to jump on it: We need to mentally separate between build > requirement and compile time and runtime requirement. If some Maven plugins > unfortunately require post Java 8 they are either behind a profile and the > build requirement is raised. Maven 3.x has chosen the former, not the > latter. > I've recently taken care of this upgrade on the build tooling side, so now Java 17 is required to run our Maven build. We can use Java 17 plugins, and in principle we can upgrade to Maven 4 as soon as it's available (I've been testing release candidates for months). We still run all the tests on Java 8 and 11 as before. Compile/runtime time requirement needs to evaluated for a new major version > if there is a compile time benefit of a newer class version. Many projects > move to a new version because it looks shiny, not because there is a class > level benefit. > This is what I'm trying to suss out. Java 25 is basically Candy Land if you're an application developer, but for a library developer it's a much smaller improvement over Java 8. At the same time, I understand Oleg's concerns about the need to attract new committers in order for the project to remain healthy. My expectation is that the Valhalla features are going to be as revolutionary as the addition of generics in Java 5. When we get features like nullability marking, all the things people are doing now with SpotBugs annotations and `java.util.Optional` will feel as obsolete as raw types and downcasting in Java 4. Those features would definitely be worth a major version bump. I'm less sure that it's worth it to go to Java 17/21/25 now.
