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

Reply via email to