[FEATURE] JDK 23 compatibility #3722
Comments
|
I can reproduce this error in some other context (also involving calling compilation task programatically): https://ci.eclipse.org/ls/job/jdt-ls-javac/lastCompletedBuild/testReport/org.eclipse.jdt.ls.core.internal.handlers/RenameHandlerTest/testLombokSingular/ lombok/src/utils/lombok/javac/Javac.java Line 364 in 1ac3950 |
|
GraalVM compatibility: |
|
OpenJDK 23 also throws the above error. The ASM shadow can't handle version 23 bytecode. |
|
Aside from the Javadoc error, lombok-patcher needs to be released first: projectlombok/lombok.patcher#15 and then lombok should be updated to use the new patcher. |
|
It looks like SneakyThrowsRemover also needs some fiddling: |
|
This should be fixed by my PR, can you try the artifact build by our pipeline? |
|
@Rawi01 works quite well, thank you. |
|
@mmoayyed how exactly does one reproduce this? I just migrated an existing project from Java 22 to 23 and it was built successfully. Stack:
I would like to know exactly which conditions trigger the incompatibility with lombok. |
|
With Liquibase 4.29.2, and with DataChangeExecListener |
|
Is this |
|
I've been running edge release for a while. Can we get a release going please? |
It seems that the use of Lombok's |
The title hints that all issues regarding Java 23 would be included. Please change it otherwise, thanks. |
|
is there any estimated time when lombok will support Java23? |
Yes, the title does, but the content of the first post doesn't, focusing on a single issue. I don't have any editing or mod priviledge here. I think that each issue should be submitted in a different bug report, this one either has a title too broad or should be written as an umbrella-issue right from the start. Further, the title contains "[FEATURE]" when it is in fact a "[BUG]" report. This is important, since bugfixes normally have higher priority (not that it really makes a difference in this project though). |
|
I think all the bugs already have separate issues. This issue (IMHO) is mostly about the release of the artifact |
|
@mmoayyed We have been using that jar, from #3750, for some weeks now, but not in production. Any ETA on when that PR will be merged, this issue closed, and there will be another release? It's the main thing holding us back from moving to JDK23 in production. Thanks. |
|
@rspilker @rzwitserloot lombok team: any idea when a JDK 23-compatible version of lombok will be released? |
|
There wasn't much to do to enable JDK23 compatibility; pretty sure we got there. The edge release has it: https://projectlombok.org/download-edge Feedback welcome! One thing that doesn't seem to work quite yet is lombok's understanding of markdown-based javadoc comments. As in, our @aholland JDK23 isn't something you should be running in production at all. |
|
@rzwitserloot why ? Any specific problems with this release ? |
|
@rzwitserloot This is a very common misconception. |
This suggestion makes me really nervous. If anything, everyone should be running the latest JDK (Java 23 as of today) as that's the only one OpenJDK supports and maintains. Please check the video shared by @lprimak as well as JEP 14: The Tip & Tail Model of Library Development. I am hoping Lombok will align its release model in a way that is compatible with the latest JDKs. |
|
That's not accurate. Please watch: https://youtu.be/3bfR22iv8Pc?t=168 The presence of the update repository in no way guarantees any maintenance/support from the OpenJDK project itself. Depending on these versions for bug fixes or security patches is like relying on charity i.e. some altruistic (instead of contractual) contributions from the community. That might work from time to time, but that's hardly something to base an IT strategy on top of.
And this is why I am not asking for lombok to be upgraded to the latest JDK, but to merely be made compatible with the latest.
I believe that because I have also worked on projects using Java 5. But that's nothing to be proud of. |
Right, and I would elaborate a bit further on what it means to be "maintained". The current JDK (23 at this time) is the only JDK version where the entire JDK is fully maintained in OpenJDK in the sense that any issue anywhere in the JDK would be looked into. When it comes to older releases, maintenance takes the form of backports, i.e. a fix is made in mainline and then potentially backported to an update release of the old version. Components that have been removed from the mainline (as, for example, SecurityManager is about to be) are not maintained in old versions in the sense that an issue against them is often likely to be ignored as there is no original work in old repo, just backports. Such original work could still happen if a paying support customer of a JDK vendor files an issue against such a component that no longer appears in mainline, and the vendor does that original work for the customer and chooses to contribute it to OpenJDK. |
|
In fact, I would suggest that Lombok is released when a new version of Java is in "rampdown phase" about 2-3 months before the actual release. Lombok is such a great tool, my only "complaint" is the late releases vs. JDK release. Thanks for such a great tool guys, makes Java much more of a pleasure to use than it already is! |
|
Maybe Oracle could standardize the APIs Lombok uses so this could be easier? |
|
Lombok doesn't use APIs but internal classes and members. Standardising arbitrary AST transformations would be one of the most radical changes to the Java language. It would essentially mean that any library can change the meaning of Java code as it sees fit; it's more radical than adding macros. It would effectively turn Java into Racket. The "compiler plugin API" (i.e. annotation processing) has been designed so that with any "plugin" the language that's accepted still conforms to the Java language specification (Lombok code obviously doesn't). There's no doubt some people would love to see Java work like Racket, but there's also little doubt that it would change the nature of the language. |
|
But there is JEP 484: Class-File API https://openjdk.org/jeps/484 (in Java 24)
I am not sure if there is everything what Lombok uses or needs but it is a good starting point. This should resolve Java version incompatibility and waiting for a new release of ASM or other byte code manipulation library. |
|
Imagine a language where it is possible to have "a common misconception" about its releases. I bet Dennis Ritchie is having a chuckle right now:
|
I was afraid it was something like that.
Perhaps I am a bit naive, but doesn't Groovy standardize AST transformation in the language, and it's still Groovy? |
No, the JDK doesn't standardize any of such. Lombok works by hacking the inner guts of Javac and Eclipsec, it's very dirt and tricky internally. |
|
@rzwitserloot When you get the chance, would you please publish the next lombok release? The current snapshot does indeed solve the original issue reported above, and that should be good enough for most cases. (I understand there may be some lingering issues with markdown support, but I suspect they can be handled and supported in a future release) Thank you! (Somewhat related, I have also filed #3772 and done some initial work to update the patcher) |
|
Hi team, any updates here ? |
|
We expect to be able to release within twelve hours |
|
just released. If you're working with mavencentral, give it an hour or so to update mirrors. |
and others
Describe the feature
Allow lombok to support building against JDK 23.
Describe the target audience
While JDK 23 is still in RC mode as of this writing, there are RC builds available nonetheless that one can use for experimentation and preparation against the next JDK release.
Additional context
Lombok today, 1.8.34, seems unable to build against JDK 23. To start with, there is the following error:
Originally reported here: google/error-prone#4532
Judging by the trace, this line seems to suggest that this is more of a Lombok issue, rather than Gradle or Error Prone:
JDK:
Gradle:
Related: projectlombok/lombok.patcher#15
The text was updated successfully, but these errors were encountered: