Java 21 with Graal support#1211
Conversation
javac no longer accepts these, see https://bugs.openjdk.org/browse/JDK-8027682 PiperOrigin-RevId: 525775880
This PR adds support for `switch` statements where a `case` has a guard clause. See Issue #983 Fixes #988 COPYBARA_INTEGRATE_REVIEW=google/google-java-format#988 from TheCK:master 4771486db7d8aab84eb4ecf8e68af2612d0c2b5c PiperOrigin-RevId: 588913297
Fixes google/google-java-format#937, google/google-java-format#880 PiperOrigin-RevId: 589140113
| + " incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis" | ||
| + " nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo" | ||
| + " consequat."); | ||
| System.err.println( |
There was a problem hiding this comment.
there is a bug in palantir-java-format that doesn't wrap long strings when running through the Intellij plugin - https://github.com/palantir/palantir-java-format/blob/develop/palantir-java-format/src/main/java/com/palantir/javaformat/java/FormatFileCallable.java#L51 vs https://github.com/palantir/palantir-java-format/blob/develop/palantir-java-format/src/main/java/com/palantir/javaformat/java/FormatFileCallable.java#L70. I will fix this in a separate PR
| testImplementation 'com.fasterxml.jackson.core:jackson-databind' | ||
| } | ||
|
|
||
| tasks.withType(JavaCompile).named('compileJava') { |
There was a problem hiding this comment.
moved all the *Compatibility blocks to the root build.gradle in the subprojects block. We need to set the sourceCompatibility for groovy sourceSets as well, so I think it is better to always set the source & target compatibility to 11
There was a problem hiding this comment.
Why do we need to set the sourceCompatibility for the groovy source sets too? If we can, I'd like to contain this strangeness to just the place that needs, ie the code for running the actual formatter
There was a problem hiding this comment.
I think we might avoid being able to do this by keeping libraryTarget = 17 on the root project (so the gradle plugin, idea plugin etc use 17) then putting libraryTarget = 21 on the palantir-java-format and palantir-java-format-spi projects
There was a problem hiding this comment.
Oops, I mean target = 21 in the subprojects.
| @@ -1,56 +0,0 @@ | |||
| [ | |||
| { | |||
| "name":"[Lcom.fasterxml.jackson.databind.deser.Deserializers;" | |||
There was a problem hiding this comment.
old file that was generated with graal 21 - now we are using reachability-metadata: https://github.com/palantir/palantir-java-format/pull/1211/files#diff-08891f153c2557b2f9c4131cb3f735dda8476f2f55ed91e9227b769ebe069991R87
|
|
||
| jdks { | ||
| daemonTarget = 17 | ||
| daemonTarget = 21 |
There was a problem hiding this comment.
Do we need daemonTarget 21?
There was a problem hiding this comment.
Not really, but since everything else would use java 21, I thought it is OK to move the daemon as well.
Moved it back to 17 5ca751c
| javaVersions { | ||
| libraryTarget = 17 | ||
| libraryTarget = 21 | ||
| runtime = 21 |
There was a problem hiding this comment.
libraryTarget implies runtime, I think we can just leave this out to keep it like our other Gradle plugins.
|
👍 |
|
Released 2.57.0 |
6 participants
Before this PR
No java 21 support
After this PR
Java 21 support that can run either through the native-image - by setting the gradle property
palantir.native.formatter=trueor - by default - using the java-based implementation.Adds the following support:
==COMMIT_MSG==
Java 21 Support with Graal & Java-based Implementations
==COMMIT_MSG==
FLUPs:
Possible downsides?