HIVE-29027: Move to JDK-21
Tasks
- [X] Hive Dev Box to support JDK-21 --> Built custom image with jdk-21 support & pushed to DockerHub
- [X] DockerFiles to use JDK-21 -> Bump JDK version in docker images
- [X] System.setSecurityManager removal in JDK-21 --> Replaced System.exit() & setSecurityManager with ExitUtil (Hadoop Solution)
- [X] Removal of Thread.stop() -> Thread.stop is removed in JDK-21 --> Replaced with interrupt & will thread handle (Replaced in a deprecated test only method otherwise interrupt ain't a direct replacement of stop)
- [X] Removal of Reflections hack -> JDK-21 is more strict it doesn't let hack the Final fields -> test class had field Final removed that final from test class & dropped the hack
- [X] JWT tests modifying System env --> Not supported in JDK-21, tried some hacks to prevent not dropping those tests, may not be exact copy but better than dropping
- [X] Decimal/Float precession change in JDK-21 --> JDK-21 had changes around the precession, leads to query output regen, haven't found any hack to use the old behaviour, as of now can't help it but adapt. https://inside.java/2022/09/23/quality-heads-up/ https://bugs.openjdk.org/browse/JDK-4511638
- [X] Kudu tests failing -> Tests failing since Kudu uses internal java classes removed in JDK-21 raised KUDU-3670. --> Replaced the util which runs the Kudu Cluster with directly running the Kudu cluster
Instant approve :)
Down to some 24 Failures, of which 2 flaky (they passed in previous build). 22 are all from Kudu Handler. Have created a ticket KUDU-3670.
Trino is already on JDK-24, doesn't even compile with lower versions
Green Build with JDK-21 :-)
134 files changed 🥇
Awesome, will this be in hive v5.0 ? :)
@ayushtkn, did you grep for
<maven.compiler.source>8</maven.compiler.source>
<maven.compiler.target>8</maven.compiler.target>
see https://issues.apache.org/jira/browse/HIVE-29018
I didn't knew something was on 8 :-) I just pushed upgrading it to 21, ran tests locally in that module, they were passing, rest will see
[INFO] Results:
[INFO]
[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0
@ayushtkn, what are the plans here? should we wait with the merge until 4.1.0 cut-off ?
That is what I am thinking, hold it till branch 4.1.0 is cut & then chase this for master branch
I believe changes of *.java are also applicable to Java 17, can those changes go branch-4.1 too? then 4.1.x should be compatible with both Java 17 & 21
@ayushtkn is there any blocker (beside +1's) to merge this change?
@aturoczy nothing from my side as such
https://tenor.com/hu/view/yes-gif-22712908
Nice work, @ayushtkn!
Does ExitUtil work without the JDK 21 upgrade? If so, how about creating a separate ticket for it and marking it as a blocking dependency for this one? It already has standalone value, and splitting it out would make this PR much clearer.
This applies to all the changes here that are compatible with earlier JDK versions, but since the ExitUtil changes are quite substantial, I’d prefer to extract them into a separate patch.
If so, how about creating a separate ticket for it and marking it as a blocking dependency for this one? It already has standalone value, and splitting it out would make this PR much clearer.
Thanx @abstractdog for the review. The ExitUtils change is now separated
PR looks good to me—I'm open to giving a +1.
The only potentially debatable part is the precision change, which results in many q.out diffs. However, looking at the underlying Java change: 🔗 https://github.com/openjdk/jdk/pull/3402/files which was eventually committed here: 🔗 https://github.com/openjdk/jdk/commit/72bcf2aa03d53b0f68eb07a902575b4e8628d859
The fact that even Java’s golden files changed is pretty telling—so it is what it is. For the Hive release, we can note that this is due to JDK-4511638.
assuming that @ayushtkn will consider my comment regarding systemlambda vs. system stubs, LGTM
Quality Gate passed
Issues
2 New issues
0 Accepted issues
Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code