Java 21: Pattern Matching + StringTemplate JEP-430 + Unnamed JEP-445
Before this PR
May error on parsing Java 21 file.
After this PR
Support of different JEP of Java 21 and preview
- JEP-430 StringTemplates
- JEP-440 Record Patterns
- JEP-441 Pattern Matching switch (with guard)
- JEP-443 Unamed Pattern
Possible downsides?
Build
- I added a independent gradle module to build all Java 21 code but the gradle do not support to build groovy code with java 21: it should be first compile with java 17 and you can compile the project with java 21 π
- I added a hack on palantir-java-format gradle script to copy all the java 21 class file on the jar. π
- Need to add --enable-preview with Java 21.
Code
- "StringTemplates" was really hard to support: I did some change on
JavaInput.javaandvisitStringTemplate. The complexity of this part is really to high. - I copy and past "visitCase" from Java14 file and the guard param.
Thanks for your interest in palantir/palantir-java-format, @npeters! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.
Generate changelog in changelog/@unreleased
changelog/@unreleasedWhat do the change types mean?
feature: A new feature of the service.improvement: An incremental improvement in the functionality or operation of the service.fix: Remedies the incorrect behaviour of a component of the service in a backwards-compatible way.break: Has the potential to break consumers of this service's API, inclusive of both Palantir services and external consumers of the service's API (e.g. customer-written software or integrations).deprecation: Advertises the intention to remove service functionality without any change to the operation of the service itself.manualTask: Requires the possibility of manual intervention (running a script, eyeballing configuration, performing database surgery, ...) at the time of upgrade for it to succeed.migration: A fully automatic upgrade migration task with no engineer input required.
Note: only one type should be chosen.
How are new versions calculated?
- βThe
breakandmanual taskchangelog types will result in a major release! - π The
fixchangelog type will result in a minor release in most cases, and a patch release version for patch branches. This behaviour is configurable in autorelease. - β¨ All others will result in a minor version release.
Type
- [ ] Feature
- [ ] Improvement
- [ ] Fix
- [ ] Break
- [ ] Deprecation
- [ ] Manual task
- [ ] Migration
Description
Check the box to generate changelog(s)
- [ ] Generate changelog entry
The build is so painful... I push all the jar / idea-plugin https://github.com/npeters/palantir-java-format/releases/tag/java21-draft.
link to #934 #933 #931
great job, now gotta wait for approval
Has there been any progress on this PR? Would love to see a new release supporting Java 21.
Thanks for submitting this PR - although we're unlikely to be able review it/actually support Java 21 in palantir-java-format by the end of the year. There's a significant amount of other work we need to do on our internal repos (currently ongoing) before we can start using Java 21 source features and these take priority. Unfortunately, we are quite resource constrained at the moment.
Until then, you may be able to use something like jitpack (https://jitpack.io/) if it is allowed by your organisation to use this commit hash until we are in a place to review/merging/supporting it.
The build is so painful... I push all the jar / idea-plugin npeters/palantir-java-format@
java21-draft(release).
Is there also a chance for the gradle plugin? I also hit some issues and would like to test if the modification works with https://github.com/JabRef/jabref/blob/39569344d4051ac958e4fc5edda89866d0706498/src/main/java/org/jabref/gui/fieldeditors/identifier/IdentifierEditor.java#L63. (which is issue https://github.com/palantir/palantir-java-format/issues/952)
yes, the PR should manage the #952. It is part of 'JEP-441 Pattern Matching switch (with guard)' .
There are already a test on the guard: sample is I961.
@CRogers Is there any news regarding when the team will have the capacity to review this PR?
Thanks for submitting this PR - although we're unlikely to be able review it/actually support Java 21 in palantir-java-format by the end of the year.
End of WHICH year? π Jokes aside β can you nominate more maintainers? A few ASF projects like maven use palantir and we would like to have property formatted source code. Maybe one of them could get access to palantir PRs and releases?
In relation to this - StringTemplates as we currently no them are 100% dead and will not be in JDK 23, even under --enable-preview: https://mail.openjdk.org/pipermail/amber-spec-experts/2024-April/004106.html
Maybe a smaller scope would be easier to review? What about limiting the support to the new pattern matching features like case null, defaut ->?
As far as I understand the whole setting, the whole endeavor is blocked by the release of version 2.0 of the IntelliJ Gradle Plugin, because of the fix https://github.com/JetBrains/intellij-platform-gradle-plugin/issues/1494 is needed.
(Source: https://github.com/palantir/palantir-java-format/pull/997)
@koppor How can I assist you? This PR seems too complex to merge and I understand. Perhaps a better approach would be as follows:
- Create one pull request with a Gradle configuration build that includes multi-compilation tasks and multi-test task, each targeting a specific JDK version.
- Submit another pull request containing the Java code and associated tests
@koppor If you agree with this plan. I can try to do it.
@talios thank you for the point. We need to create a InputAstVisitor class for each java version.
How it's looking?
Yo, any updates in regard to the following changes.