Conversation
|
I'd be conservative and would not yet force users to require Java 17 as runtime, esp. given that is not yet 100% supported by Hadoop. A backward-compatible approach, similar to that described in HADOOP-18887 might be better. What about?
This option seems to work (I tried it, but without exhaustive testing). |
|
Yes I agree with you @sebastian-nagel I'm not keen to force a JDK upgrade to 17 via this PR either. I'll augment the PR accordingly. Thanks for the review. |
|
I augmented the CI to accommodate the backward-compatible Java version strategy for Apache Nutch, similar to the approach described in HADOOP-18887.
|
|
Resolved conflicts. I'm wondering whether we should perform a separaste upgrade to JDK17 BEFORE we consider this branch further. It would certainly simpligy the CI as we wouldn't need to worry about the additional complexity it adds to the GitHub CI. I'm open to suggestions and would also like to respect the opinuons shared on dev@. |
Great!
I think it is exhaustively enough discussed the upgrade to JDK 17 on dev@ (thread) with the consensus to upgrade after the release of 1.22. If we are lucky Hadoop 3.5.0 will be released soon and it should support JDK 17.
I've verified that both GitHub and Apache Jenkins CI builds use JDK 17, already before merging #825 / NUTCH-3064. GeoIP2 5.0.2 also requires JDK 17 - both build and runtime, the latter only if the plugin is used. From my perspective: +1 to merge. |
This is a PR for NUTCH-3145. It is quite an interesting issue as JUnit 6 requires Java 17. I am not convinced/sure that we want to orchestrate an upgrade from Java 11 --> 17 through a JUnit upgrade. I opened this ticket as a bit of an experiment. It also encouraged me to check in on NUTCH-2987 and perhaps more importantly the behemoth that is HADOOP-17177.
Any feedback or thoughts welcome. Thank you