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]
