Java 8 is basically Python 2.7. There's a large population of stragglers who are going to take a long time to drop their dependency on it, but once that's done, future upgrades will be much easier. The biggest issues with upgrading from Java 8 are a result of JDK-internal classes being encapsulated by default, which in turn forces a lot of commonly used libraries (especially mocking libraries) to be upgraded. Subsequent upgrades (e.g. 17 -> 21 -> 25) are easier.
I think the longer-term liability is the Android ecosystem. We're eventually going to have to decide to either drop Android support or specifically target the subset of Java 17/21/25/... that is Android-compatible. On Wed, Mar 25, 2026 at 10:23 AM Oleg Kalnichevski <[email protected]> wrote: > On Wed, 2026-03-25 at 11:38 -0400, Gary Gregory wrote: > > For me the compromise, if you want to call it that, is Java 17. > > > > Gary > > > By the time HC 6.0 is ready to go GA, Java 25 will be what Java 17 is > today. We should be targeting Java 29 or even Java 29+. > > And we can keep 5.x maintained and Java 8 compatible all this time. > > Oleg > > > > > On Wed, Mar 25, 2026, 10:58 Arturo Bernal <[email protected]> wrote: > > > > > I was not arguing for dropping support abruptly. My point was about > > > using a > > > new major line to modernize without forcing existing users off 5.x. > > > If Java > > > 25 is too aggressive, then we can discuss a lower baseline, but the > > > split > > > itself still seems reasonable. > > > > > > Arturo > > > > > > > > > On Wed, Mar 25, 2026 at 3:49 PM Gary Gregory > > > <[email protected]> > > > wrote: > > > > > > > On Wed, Mar 25, 2026, 10:30 Arturo Bernal <[email protected]> > > > > wrote: > > > > > > > > > I am not suggesting dropping support for existing users > > > > > abruptly. I am > > > > > suggesting a new major line where we can modernize without > > > > > carrying all > > > > > historical baggage forever, while keeping 5.x as the stable > > > compatibility > > > > > line during a transition period. > > > > > > > > > > > > > If you require Java 25 for a new major version, very few people > > > > and > > > > companies will use it IMO. At least according to Java surveys, > > > > however > > > > reliable these are > > > > > > > > Gary > > > > > > > > Arturo > > > > > > > > > > > > > > > On Wed, Mar 25, 2026 at 2:09 PM Gary D. Gregory > > > > > <[email protected]> > > > > > wrote: > > > > > > > > > > > Going all the way to Java 25 would be a mistake IMO. It would > > > exclude a > > > > > > large portion of corporate users. For example, at work, we > > > > > > have > > > > finalized > > > > > > standardizing on Java 17, not 21, not 25. Why? Because some > > > > > > of our > > > > > > customers cannot just upgrade their OS version to match what > > > > > > Java 21 > > > > > > requires. This is an issue with IBM i for example (a.k.a > > > > > > AS/400, > > > > iSeries, > > > > > > and i5/OS). > > > > > > > > > > > > HTH, > > > > > > Gary > > > > > > > > > > > > On 2026/03/24 06:35:12 Arturo Bernal wrote: > > > > > > > Hi all, > > > > > > > > > > > > > > Maybe I am missing something, but why not consider a 6.x > > > > > > > line on > > > Java > > > > > 25 > > > > > > > and keep 5.x as the current stable line for a transition > > > > > > > period? > > > > > > > > > > > > > > That would give us room to drop historical baggage in a new > > > > > > > major > > > > > without > > > > > > > forcing an abrupt transition on existing users. > > > > > > > > > > > > > > Arturo > > > > > > > > > > > > > > > > > > > > > Arturo > > > > > > > > > > > > > > > > > > > > > On Mon, Mar 23, 2026 at 7:57 PM Gary Gregory < > > > [email protected] > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > I'm OK to upgrade Core and Client to Java 17. > > > > > > > > > > > > > > > > Gary > > > > > > > > > > > > > > > > On Mon, Mar 23, 2026 at 11:21 AM Oleg Kalnichevski < > > > > [email protected] > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sun, 2026-03-22 at 12:15 -0700, Ryan Schmitt wrote: > > > > > > > > > > Insofar as that perception exists, I don't think it > > > > > > > > > > can be > > > > blamed > > > > > > on > > > > > > > > > > the > > > > > > > > > > Java 8 compatibility baseline. Netty still used a > > > compatibility > > > > > > > > > > baseline of > > > > > > > > > > Java 6 (!) until Netty 4.2 came out last year and > > > > > > > > > > raised it > > > to > > > > 8. > > > > > > The > > > > > > > > > > correct way of viewing the bytecode upgrade is as a > > > > > > > > > > means to > > > an > > > > > > end, > > > > > > > > > > not an > > > > > > > > > > end to itself: what does it gain us? What goals would > > > > > > > > > > it > > > allow > > > > us > > > > > > to > > > > > > > > > > pursue? I'm not asking rhetorically; I can't think of > > > > > > > > > > a > > > > > compelling > > > > > > > > > > answer, > > > > > > > > > > but maybe someone else can. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > * 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. > > > > > > > > > > > > > > > > > > * 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. > > > > > > > > > > > > > > > > > > * 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. > > > > > > > > > > > > > > > > > > We have not attracted a single casual contributor for > > > > > > > > > God knows > > > > how > > > > > > > > > many years, let alone someone worthy being a committer > > > > > > > > > or a > > > PMC. > > > > We > > > > > > are > > > > > > > > > failing as a project, at least by the ASF standards. > > > > > > > > > > > > > > > > > > Anyways, I am willing to wait a few more years if the > > > > > > > > > plan is > > > to > > > > > > > > > upgrade straight to Java 24 or 24+ or 24++. If all we > > > > > > > > > do is > > > wait > > > > > > > > > several more years to upgrade to Java 17, we are > > > > > > > > > basically > > > > working > > > > > > > > > ourselves into a hole. > > > > > > > > > > > > > > > > > > Oleg > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------- > > > > > ------ > > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ----------------------------------------------------------------- > > > > ---- > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------- > > > > > > -------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
