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
