On Thu, Mar 26, 2026, 15:42 Oleg Kalnichevski <[email protected]> wrote:
> 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 > Virtual threads would be the driver for Java 21 instead of 17 then. The question is when to do the switch. Gary > 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] > >
