> > * We have accumulated an ungodly amount of outdated APIs in core > ironically largely due to sticking to Java 7 compatibility for too long > instead of upgrading to Java 8 at the beginning of 5.x cycle. In > retrospect it was a mistake and it hurts us now. >
I agree, which is why I think a language/bytecode version upgrade should happen in concert with a new major version. The biggest issue for us seems to be the core-client split, which means we have a ton of de facto implementation details and private APIs that are subject to the same compatibility constraints as public APIs. * We will no longer be able to use the latest Assert4j, Junit, Mockito > versions as they upgrade to Java 17 and we stick to Java 8. It will be > hurting us, too. > Fair point, but it's also easier for test dependencies to drop support for newer Java versions, since that doesn't prevent their consumers from cross-compiling to Java 8. It does prevent them from _testing_ on Java 8, but that's usually not a problem. It wouldn't be ideal for us, but even we only occasionally run into version-specific issues (typically with TLS). > * But the BIGGEST PROBLEM is not about byte code compatibility or any > code at all. The biggest issue is that we are no longer attracting > contributors to project because it is being seen as too dated, too > legacy focused, useful but completely uninteresting and irrelevant. > I think we should make a list of all the things we'd like to do and organize them into a 2x2 matrix along these lines: - Breaking API changes required? Y/N - Java language/bytecode upgrade required? Y/N If there's a lot we can do with Java 17+ without breaking API changes, that would be a pretty good argument for upgrading _within_ the 5.x line. My guess is that most ideas would fall into the other quadrants, which would mean that upgrading to Java 17+ would be worth doing as part of a comprehensive reworking of the codebase, but not on its own.
