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]
