Thanks for your reply, Andrew. If no-one else picks it up, I will try to start working on moving to Jetty 12 in a few weeks.
On the importance of recent Java support: (which doesn't change the fact that we're at the mercy of Hadoop releases) I also used to think that it's not important to support the latest Java versions, but recent discussions with the Trino team have changed my mind. My new understanding is that there are an increasing number of users and projects who are aggressively moving to the latest Java versions, both applications and libraries (for example Trino), and if we don't keep up, then HBase/Phoenix becomes a non-starter by simply not running in their JVMs. Yes, probably 80% of the current users and 90+% percent of nodes are enterprises and other very risk-averse entities that wouldn't even consider a non-LTS java version, but by lagging with Java support, we are driving off new adapters that are vital for the long-term health of the project. By keeping up with non-LTS versions, we also get a head-start, and are much more likely to support new LTS releases on day one. Istvan On Mon, Mar 3, 2025 at 6:07 PM Andrew Purtell <apurt...@apache.org> wrote: > I don't think compatibility with the very most recent Java version is a > primary requirement for this project. Identifying the issues and proposing > a plan as has been done here is great. Beyond that, if someone has the > burning need to move to Java 22 or later we should here about it then by > user filed JIRAs or PRs or mailing list posts asking about breaks caused by > SecurityManager removal. Should Hadoop take steps we could also leverage > that, after the change lands in a released version we can consume. > > The dependency on the old version of Jetty that seems about to fall out of > maintenance seems like a more immediate issue, given that Jetty is a > frequent flyer for security issues and has a number of (solved) CVEs posted > over the past few years. > > > I think that the best course of action would be adding a separate Jetty > 12 > > module to hbase-thirdparty, this way 9.4.x and 11.0.x can be both > > used/updated by the 2.x / 3.x branches. > > +1 > Presumably JIRAs/PRs to move up to Jetty 12 would follow. I think we can > find helpers for a Jetty 12 uplift at the $dayjob here also. > > > On Mon, Mar 3, 2025 at 5:50 AM Istvan Toth <st...@apache.org> wrote: > >> Correction: I meant Jetty 12 >> >> On Mon, Mar 3, 2025 at 6:41 AM Istvan Toth <st...@apache.org> wrote: >> >> > Hi! >> > >> > The last big incompatible JDK change is the JEP411/JEP486 >> SecurityManager >> > removal process, which has gotten serious with JDK22, which disables >> > Subject.doAs*() Subject.getSubject() by default (while providing the >> kind >> > of equivalent callAs() and current() methods), and kills automatic >> Subject >> > propagation to new threads. >> > >> > To add insult to injury the new methods are only available from JDK18, >> so >> > it is not possible to just move to the new API without breaking JDK17. >> > >> > Some of this can only be solved in Hadoop (hopefully 3.5) , but HBase >> can >> > also take steps to move towards JDK22 compatibility in the meantime. >> > >> > Here's the plan I have in mind: >> > >> > - Review and the dependencies WRT SecurityManage usage (just search for >> > API calls) >> > - Update the dependencies as needed >> > >> > - Add a reflection-based compatibility Utility class based on Jetty's >> > SecurityUtils, (or one of its derivatives) >> > - Replace the deprecated method calls with the compatibility versions >> > - Wrap Runnables/Callables with Subject current()/callAs() methods. >> > >> > One large dependency I have identified is Jetty. >> > While technically we MAY be able to keep using 9.4 by overriding its >> > default ThreadFactory, I think that considering that even semi-formal >> Jetty >> > 9.4 support is on its very last legs (the latest update was never even >> > announced and is not listed in the downloads page), the advantages of >> > updating to Jetty 11 on branch-3+ now far outweighs the added >> maintenance >> > burden of the branch divergence. >> > >> > I think that the best course of action would be adding a separate >> Jetty11 >> > module to hbase-thirdparty, this way 9.4.x and 11.0.x can be both >> > used/updated by the 2.x / 3.x branches. >> > >> > What do you think ? >> > >> > - Do you agree that JEP411/486 should be treated as a priority ? >> > - Would you volunteer for the dependency audit ? >> > - Do you agree with the Jetty update, and the plan outlined above ? >> > >> > Istvan >> > >> > ps: Sorry, no links because GMail seems to react very bady to any. >> Please >> > use search. >> > >> > >> > > > -- > Best regards, > Andrew > > Unrest, ignorance distilled, nihilistic imbeciles - > It's what we’ve earned > Welcome, apocalypse, what’s taken you so long? > Bring us the fitting end that we’ve been counting on > - A23, Welcome, Apocalypse >
