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] > > > > >
