Java 21 with Graal support by crogoz · Pull Request #1211 · palantir/palantir-java-format (original) (raw)
Conversation
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=true or - by default - using the java-based implementation.
Adds the following support:
- JEP-441 Pattern Matching switch (with guard)
- JEP-443 Unnamed Patterns and Variables
- Fixes the comments indentation inside switch statements
==COMMIT_MSG==
Java 21 Support with Graal & Java-based Implementations
==COMMIT_MSG==
FLUPs:
- support reflowing strings in intellij see: Java 21 with Graal support #1211 (comment)
Possible downsides?
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
| + " 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( |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| testImplementation 'com.fasterxml.jackson.core:jackson-databind' |
|---|
| } |
| tasks.withType(JavaCompile).named('compileJava') { |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, I mean target = 21 in the subprojects.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| @@ -1,56 +0,0 @@ |
|---|
| [ |
| { |
| "name":"[Lcom.fasterxml.jackson.databind.deser.Deserializers;" |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| jdks { |
| daemonTarget = 17 |
| daemonTarget = 21 |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need daemonTarget 21?
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
libraryTarget implies runtime, I think we can just leave this out to keep it like our other Gradle plugins.
This was referenced
Mar 13, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})