On Wed, 2026-03-25 at 12:59 -0700, Ryan Schmitt wrote: > > > > * 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.
It did. We went up from Java 5 to Java 7 but we should have gone straight to Java 8. > > 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. I want to see three things * custom functional interfaces replaced with standard ones * custom concurrency primitives replaced / complemented with standard ones * virtual threads The first two are not possible without a major release, so we might as well upgrade all the way to Java 21, Java 25 or even Java 29 the same time. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
