If we can speed up the 3.x release, since it has already moved up the JDK17+, it will be easier to land these changes in 3.x only.
Istvan Toth <st...@cloudera.com.invalid> 于2025年3月7日周五 03:42写道： > > I'd split that into two tickets. > > First move to Jetty 12 while keeping the old javax package names, and once > that's done and tested, we can look into moving to jakarta. > > Istvan > > On Thu, Mar 6, 2025 at 8:33 PM Andrew Purtell <apurt...@apache.org> wrote: > > > > Therefore, I plan to use the EE8 environment on Jetty 12. > > > > Ah, thanks for mentioning EE. > > > > Do you have a requirement to stay with EE 8 ? > > > > If we could target EE 9 instead of EE 8 that would align with some internal > > requirements at $dayjob. For what it's worth. Mostly the point of EE 9 is a > > move of the EE stuff into a new namespace, allowing for further development > > under the Eclipse Foundation without trademark conflicts with Oracle's > > "Java" branding. The trademark issue and follow on Java licensing concerns > > are going to be relevant for anyone who might be visited by an Oracle > > lawyer-shark. > > > > On Tue, Mar 4, 2025 at 6:42 AM Nihal Jain <nihalj...@apache.org> wrote: > > > > > > 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. > > > > > > +1, I would like to volunteer for this work. > > > > > > Maintaining Jetty 9.4.x could be quite challenging from a CVE perspective > > > since it has been EOCS (End of Community Support) since June 2022, and > > new > > > releases may not be forthcoming for a long time. I faced similar issues > > > during our last hbase-thirdparty release. See this issue comment: > > > > > https://github.com/jetty/jetty.project/issues/12630#issuecomment-2604701092 > > > > > > Regarding the version and CVEs, I agree with @Andrew and suggest that we > > > jump directly to Jetty 12, bypassing Jetty 11, to support javax.servlet > > for > > > JSP 2.3.1. Therefore, I plan to use the EE8 environment on Jetty 12. See > > > Jetty version history: https://jetty.org/download.html#version-history > > > > > > @Istvan, is there any particular reason you recommend moving to Jetty 11, > > > which is also EOCS? > > > > > > If others are fine with me taking this up, I can create the necessary > > > JIRAs for the Jetty migration project and start the work soon. > > > > > > Regards, > > > Nihal > > > > > > On 2025/03/03 18:08:53 Wei-Chiu Chuang wrote: > > > > FYI I think Hadoop will need to make similar moves too. > > > > Sounds like Hadoop should start the work to drop JDK8 as well. I know > > > Steve > > > > has a patch that requires JDK17+ due to Iceberg > > > > https://github.com/apache/hadoop/pull/7316 > > > > > > > > ---------- Forwarded message --------- > > > > From: Istvan Toth <st...@apache.org> > > > > Date: Sun, Mar 2, 2025 at 9:41 PM > > > > Subject: [DISCUSS] Plans for JDK22 / SecurityManager removal > > > > To: HBase Dev List <dev@hbase.apache.org> > > > > > > > > > > > > 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. > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: common-dev-unsubscr...@hadoop.apache.org > > > For additional commands, e-mail: common-dev-h...@hadoop.apache.org > > > > > > > > > > -- > > 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 > > > > > -- > *István Tóth* | Sr. Staff Software Engineer > *Email*: st...@cloudera.com > cloudera.com <https://www.cloudera.com> > [image: Cloudera] <https://www.cloudera.com/> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera > on LinkedIn] <https://www.linkedin.com/company/cloudera> > ------------------------------ > ------------------------------
