Java25Parser compiled with Java 25 breaks Java 24 runtime compatibility

[kdvolder]

Java25Parser compiled with Java 25 breaks Java 24 runtime compatibility

What version of OpenRewrite are you using?

• OpenRewrite core: 8.71.0 (also reproduced with 8.73.0-SNAPSHOT)
• Maven plugin: 6.27.1
• Gradle plugin: 7.19.0
• Bug NOT present in OpenRewrite 8.65.0
• Bug introduced sometime between 8.65.0 and 8.71.0 (intermediate versions not tested)

How are you running OpenRewrite?

I am using both the Maven and Gradle plugins. The issue affects both single-module and multi-module projects.

Maven configuration:

<plugin>
  <groupId>org.openrewrite.maven</groupId>
  <artifactId>rewrite-maven-plugin</artifactId>
  <version>6.27.1</version>
  <configuration>
    <activeRecipes>
      <recipe>com.vmware.tanzu.spring.recipes.boot40.UpgradeSpringBoot_4_0</recipe>
    </activeRecipes>
  </configuration>
  <dependencies>
    <dependency>
      <groupId>com.vmware.tanzu.spring.recipes</groupId>
      <artifactId>spring-boot-4-upgrade-recipes</artifactId>
      <version>1.5.5-SNAPSHOT</version>
    </dependency>
  </dependencies>
</plugin>

Gradle configuration:

plugins {
    id("org.openrewrite.rewrite") version "7.19.0"
}

rewrite {
    activeRecipe("com.vmware.tanzu.spring.recipes.boot40.UpgradeSpringBoot_4_0")
}

dependencies {
    rewrite("com.vmware.tanzu.spring.recipes:spring-boot-4-upgrade-recipes:1.5.5-SNAPSHOT")
}

Reproduction project: https://github.com/vmware-tanzu/spring-upgrade-recipes/tree/main/bug-reports/java25parser-gradle

What is the smallest, simplest way to reproduce the problem?

The issue occurs when running any OpenRewrite recipe on Java 24 runtime. Even a minimal project triggers the error:

build.gradle:

plugins {
    id 'java'
    id 'org.openrewrite.rewrite' version '7.19.0'
}

rewrite {
    activeRecipe("org.openrewrite.java.format.AutoFormat")
}

Any Java file:

public class Example {
    public void hello() {
        System.out.println("Hello");
    }
}

Run with Java 24:

$ java -version
openjdk version "24" 2025-03-18
OpenJDK Runtime Environment (build 24+36)

$ ./gradlew rewriteRun

What did you expect to see?

The recipe should execute successfully on Java 24 runtime, just as it does on Java 21 and Java 25.

What did you see instead?

The build fails immediately with a classversion error:

java.lang.UnsupportedClassVersionError: org/openrewrite/java/Java25Parser has been compiled by a more recent version of the Java Runtime (class file version 69.0), this version of the Java Runtime only recognizes class file versions up to 68.0

What is the full stack trace of any errors you encountered?

java.lang.UnsupportedClassVersionError: org/openrewrite/java/Java25Parser has been compiled by a more recent version of the Java Runtime (class file version 69.0), this version of the Java Runtime only recognizes class file versions up to 68.0
	at java.base/java.lang.ClassLoader.defineClass1(Native Method)
	at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1027)
	at java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:862)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:760)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
	at org.openrewrite.java.JavaParser.fromJavaVersion(JavaParser.java:XXX)

Root Cause Analysis

A version of OpenRewrite between 8.65.0 and 8.71.0 introduced two changes that together create this issue:

1. Java25Parser recompiled with Java 25

The rewrite-java-25 module was recompiled from Java 21 (class version 65) to Java 25 (class version 69).

Verified via bytecode inspection:

# OpenRewrite 8.65.0
$ javap -v Java25Parser.class | grep "major version"
  major version: 65  # Java 21

# OpenRewrite 8.71.0  
$ javap -v Java25Parser.class | grep "major version"
  major version: 69  # Java 25

2. Parser selection logic changed

In rewrite-java/src/main/java/org/openrewrite/java/JavaParser.java (commit 07a72d60a):

Before (8.65.0):

if (version > 21) {
    return new Java25Parser(...);
}

After (8.71.0):

if (version > 22) {
    return new Java25Parser(...);
}

The version variable comes from System.getProperty("java.version") - it's the JVM runtime version, not the source level.

Impact by Java version:

• Java 21 (LTS): ✅ Works - condition is false, never loads Java25Parser
• Java 24: ❌ BREAKS - condition is true, attempts to load Java25Parser compiled with Java 25
• Java 25: ✅ Works - can load Java25Parser compiled with Java 25

Suggested Fixes

Option 1: Compile Java25Parser with Java 21 (Recommended)

Revert to compiling the rewrite-java-25 module with Java 21 (as in 8.65.0). This maintains backward compatibility while still supporting Java 25 source code parsing.

Option 2: Adjust parser selection logic

Change the condition to only load Java25Parser on Java 25+:

if (version > 24) {
    return new Java25Parser(...);
}

Business Impact

While Java 24 is a non-LTS interim release, some organizations require Java 24 support for:

• Proactive compatibility testing before Java 25 LTS
• Early adoption of new language features
• Enterprise CI/CD pipelines testing against multiple Java versions

This issue forced us to downgrade from 8.71.0 to 8.65.0 to maintain Java 24 compatibility for our customers ahead of an upcoming release.

Are you interested in contributing a fix to OpenRewrite?

We're happy to contribute a fix if guidance is provided on the preferred approach (Option 1 vs Option 2 above). Please let us know which direction you'd like to take.

Attachement

I am attaching a zip file containing scripts and test code that can be used to reproduce the bug.

java25parser-gradle.zip

Note: name is confusing it says 'gradle' but it actually uses maven, originally we did also reproduce with gradle but 'parameters' such as OR version are easier to control with maven, and the bug doesn't appear to be specific to a particular plugin (maven/gradle) or version of the plugin.

Note: created attached reproducer and analysis with help of AI, but should contain ample material and easy to follow instructions to figure out how to run it. It has a script which you are meant to run, give it parameter which is a Java version (21, 24, 25) and it will run the maven plugin on a toy project.

It uses sdkman and assumes you have required JDK installed to run the test script.

Also includes detailed analysis on which this bug report is based.

[timtebeek]

Hi! Thanks for the detailed report; It's not the first time this has come up, but it was a deliberate choice. Let me share some earlier thoughts I'd written up elsewhere:

We provide parsers for various Java versions, focusing on LTS releases 8, 11, 17, 21 & 25. Our Java parsers are strongly tied to non-public APIs such as com.sun.tools.javac and com.sun.source, which often change in incompatible ways between any version of Java (both LTS and intermediate). As some examples between Java 11 and 17 we saw the addition of records, switch expressions, pattern matching, and keywords like yield and permits, as well as at times incompatible internal API method signature changes for JavaDocs and others. Historically this has made it a challenge to support latest LST + n versions.

In the past we've resorted to reflection and other complex patterns to support non-LST features early, but this meant there were a lot of complications in maintaining now five parsers in parallel; soon six with the Java 26 RC next month.

WIth Java 25 we restructured which parsers support which features, and update the runtime requirements for continued non-LTS versions. We landed on only supporting features beyond a particular LTS version (say Java records from 14+), as of the next LTS version that includes that feature (for records: 17).

• You can see the parser version selection play out in JavaParser.
• Which was slightly amended with Use the Java25Parser for Java 23 and above #6280

For a brief while we had also attempted to allow folks to continue to run from say Java 15, by setting the parsers to target the previous LTS version when compiling, but this lead to repeated troublesome issues with the project setup, finally reverted in:

• Target matching Java versions after seeing IDE failures #6204

In short it's been a long road to end up with the current situation, balancing various trade offs and having learned from earlier iterations.

Now as you've found at this point it's not possible to run on Java 24, as the selected parser would be bumped up to next LTS Java 25 to support the likely features you're using if you'd previously gone to 24. We're likely not able to compile that Java 25 parser to a target runtime of 21 or lower, because of compilation being strongly tied to the com.sun packages which differ between Java versions.

[kdvolder]

Ok, but this means that openrewrite simply can not run at all on Java 24. I don't see how that makes sense, when you could have just as easily fallen back on Java21 parser and still have something that mostly works.

The check you built into the Java25 parser guarantees that on Java 24 openrewrite will attempt to classload and fail with a hard crash, because it was compiled on Java 25.

I suggest simply changing that check to forego loading this parser on Java 24, since you know it will fail anyway, why would it make sense to even try to load something that is not compatible with the current runtime?

I guess what you are saying is, if I undertsand it, there may be some consequences of falling back to the Java 21 parser as it may not support all the newest features introduced post Java 21. Okay, but that is nowhere near as bad as crashing OR outright, and making it completely unable to do anything at all.

Look at this way... assuming you are running on Java 24, for whatever reason, your current implementation gives a hard crash... meaning you get 0% of functionality. Falling back on Java 21 parser you get something that mostly works but may fail on some newer syntax.

Java 25 to support the likely features you're using if you'd previously gone to 24

Actually I think reality is that no or very few new fancy Java 24 features are being used, but this simply a requirement coming from the gradle version in use on a project, which has dictated that a specific Java runtime must be used. (At least this is what I have been told is the reason our customer wants to run on Java 24 specifically).

[kdvolder]

FYI: this is basically the reason why I have been told that some customers explicitly require to be able to run OR on Java 24:

https://docs.gradle.org/current/userguide/compatibility.html

This table seems to say that for Gradle version >=8.14 and < 9.x you need to be running on Java 24. If that is the case, the choices that OR made around Java25Parser means you cannot use latest version of open-rewrite with the latest version of Gradle 8.x.

[timtebeek]

Hmm, I could see it make sense to attempt to fall back to the Java 21 parser on Java 24. What have is trouble was compiling the 25 parser with a target runtime of 21. But skipping selection as you've said might make sense still. Want to propose that in a PR and tag me for review?

[kdvolder]

I tested out the Java21Fallback yesterday, and while that seemed to work before with my toy application in the original report...

Looks like this really doesn't work in general. Our CI runs a smoke test migrating an old version of spring-petclinic. And even though I am pretty sure it isn't using fancy new post Java21 syntax, the Java21 parser isn't working properly when running on Java24 and many recipes fail to do what they are supposed to because of this.

I'll paste full stacktrace/error below, of the kind of errors that I'm seeing. But I think this is the TLDR:

Caused by: java.lang.NoSuchMethodError: 'com.sun.tools.javac.tree.DCTree$DCDocComment com.sun.tools.javac.tree.DocCommentTable.getCommentTree(com.sun.tools.javac.tree.JCTree)'

So looks like Java21Parser isn't quite working '95%' as I was hoping/assuming and my 'suggestion' on how to handle this was therefore not really a sound approach afterall.

@timtebeek Any suggestions on what we could do about this? TBH, I think its terrible that latest Gradle 8.x is forcing people onto a non LTS Java 24 runtime. But it is the sad reality, so I think we need to find some way to allow people on Gradle 8.x to run recent versions of open-rewrite.

Full details below:

Warning:  There were problems parsing src/main/java/org/springframework/samples/petclinic/PetClinicApplication.java
Warning:  There were problems parsing src/main/java/org/springframework/samples/petclinic/PetClinicRuntimeHints.java
...many more...

org.openrewrite.java.JavaParsingException: Failed to convert for the following cursor stack:--- BEGIN PATH ---
JCCompilationUnit(sourceFile = /home/runner/_work/spring-upgrade-recipes/spring-upgrade-recipes/target-project/src/main/java/org/springframework/samples/petclinic/PetClinicApplication.java)
--- END PATH ---

    at org.openrewrite.java.isolated.ReloadableJava21ParserVisitor.reportJavaParsingException (ReloadableJava21ParserVisitor.java:1889)
    at org.openrewrite.java.isolated.ReloadableJava21ParserVisitor.convert (ReloadableJava21ParserVisitor.java:1856)
    at org.openrewrite.java.isolated.ReloadableJava21ParserVisitor.visitCompilationUnit (ReloadableJava21ParserVisitor.java:633)
    at org.openrewrite.java.isolated.ReloadableJava21ParserVisitor.visitCompilationUnit (ReloadableJava21ParserVisitor.java:77)
    at com.sun.tools.javac.tree.JCTree$JCCompilationUnit.accept (JCTree.java:627)
    at com.sun.source.util.TreePathScanner.scan (TreePathScanner.java:92)
    at org.openrewrite.java.isolated.ReloadableJava21Parser.lambda$parseInputs$1 (ReloadableJava21Parser.java:189)
    at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:215)
    at java.util.Iterator.forEachRemaining (Iterator.java:133)
    at java.util.Spliterators$IteratorSpliterator.forEachRemaining (Spliterators.java:1939)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:570)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
    at java.util.stream.ForEachOps$ForEachOp.evaluateSequential (ForEachOps.java:153)
    at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential (ForEachOps.java:176)
    at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:265)
    at java.util.stream.ReferencePipeline.forEach (ReferencePipeline.java:636)
    at java.util.stream.ReferencePipeline$7$1FlatMap.accept (ReferencePipeline.java:294)
    at java.util.stream.ReferencePipeline$3$1.accept (ReferencePipeline.java:215)
    at java.util.stream.Streams$StreamBuilderImpl.forEachRemaining (Streams.java:411)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:570)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
    at java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining (StreamSpliterators.java:315)
    at java.util.stream.Streams$ConcatSpliterator.forEachRemaining (Streams.java:735)
    at java.util.stream.Streams$ConcatSpliterator.forEachRemaining (Streams.java:734)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:570)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
    at java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining (StreamSpliterators.java:315)
    at java.util.stream.Streams$ConcatSpliterator.forEachRemaining (Streams.java:735)
    at java.util.stream.Streams$ConcatSpliterator.forEachRemaining (Streams.java:734)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:570)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
    at java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining (StreamSpliterators.java:315)
    at java.util.stream.Streams$ConcatSpliterator.forEachRemaining (Streams.java:734)
    at java.util.stream.Streams$ConcatSpliterator.forEachRemaining (Streams.java:734)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:570)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
    at java.util.stream.ForEachOps$ForEachOp.evaluateSequential (ForEachOps.java:153)
    at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential (ForEachOps.java:176)
    at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:265)
    at java.util.stream.ReferencePipeline.forEach (ReferencePipeline.java:636)
    at java.util.stream.ReferencePipeline$7$1FlatMap.accept (ReferencePipeline.java:294)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1716)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:570)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential (ReduceOps.java:921)
    at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:265)
    at java.util.stream.ReferencePipeline.collect (ReferencePipeline.java:727)
    at org.openrewrite.maven.AbstractRewriteBaseRunMojo.sourcesWithAutoDetectedStyles (AbstractRewriteBaseRunMojo.java:279)
    at org.openrewrite.maven.AbstractRewriteBaseRunMojo.loadSourceSet (AbstractRewriteBaseRunMojo.java:241)
    at org.openrewrite.maven.AbstractRewriteBaseRunMojo.listResults (AbstractRewriteBaseRunMojo.java:156)
    at org.openrewrite.maven.AbstractRewriteRunMojo.execute (AbstractRewriteRunMojo.java:66)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at java.util.stream.Streams$ConcatSpliterator.forEachRemaining (Streams.java:734)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:570)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
    at java.util.stream.StreamSpliterators$WrappingSpliterator.forEachRemaining (StreamSpliterators.java:315)
    at java.util.stream.Streams$ConcatSpliterator.forEachRemaining (Streams.java:734)
    at java.util.stream.Streams$ConcatSpliterator.forEachRemaining (Streams.java:734)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:570)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
    at java.util.stream.ForEachOps$ForEachOp.evaluateSequential (ForEachOps.java:153)
    at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential (ForEachOps.java:176)
    at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:265)
    at java.util.stream.ReferencePipeline.forEach (ReferencePipeline.java:636)
    at java.util.stream.ReferencePipeline$7$1FlatMap.accept (ReferencePipeline.java:294)
    at java.util.ArrayList$ArrayListSpliterator.forEachRemaining (ArrayList.java:1716)
    at java.util.stream.AbstractPipeline.copyInto (AbstractPipeline.java:570)
    at java.util.stream.AbstractPipeline.wrapAndCopyInto (AbstractPipeline.java:560)
    at java.util.stream.ReduceOps$ReduceOp.evaluateSequential (ReduceOps.java:921)
    at java.util.stream.AbstractPipeline.evaluate (AbstractPipeline.java:265)
    at java.util.stream.ReferencePipeline.collect (ReferencePipeline.java:727)
    at org.openrewrite.maven.AbstractRewriteBaseRunMojo.sourcesWithAutoDetectedStyles (AbstractRewriteBaseRunMojo.java:279)
    at org.openrewrite.maven.AbstractRewriteBaseRunMojo.loadSourceSet (AbstractRewriteBaseRunMojo.java:241)
    at org.openrewrite.maven.AbstractRewriteBaseRunMojo.listResults (AbstractRewriteBaseRunMojo.java:156)
    at org.openrewrite.maven.AbstractRewriteRunMojo.execute (AbstractRewriteRunMojo.java:66)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:126)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute2 (MojoExecutor.java:328)
    at org.apache.maven.lifecycle.internal.MojoExecutor.doExecute (MojoExecutor.java:316)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:212)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:174)
    at org.apache.maven.lifecycle.internal.MojoExecutor.access$000 (MojoExecutor.java:75)
    at org.apache.maven.lifecycle.internal.MojoExecutor$1.run (MojoExecutor.java:162)
    at org.apache.maven.plugin.DefaultMojosExecutionStrategy.execute (DefaultMojosExecutionStrategy.java:39)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:159)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:105)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:73)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:53)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:118)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:261)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:173)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:101)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:906)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:283)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:206)
    at jdk.internal.reflect.DirectMethodHandleAccessor.invoke (DirectMethodHandleAccessor.java:104)
    at java.lang.reflect.Method.invoke (Method.java:565)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:255)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:201)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:361)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:314)

[timtebeek]

hi @kdvolder ; that DCDocCOmment is indeed known, and precisely why we had previously nudged Java 23+ to use our Java 25 and the Java25Parser, as the Java21Parser is incompatible, and it will affect any class with JavaDoc.

rewrite/rewrite-java/src/main/java/org/openrewrite/java/JavaParser.java

Lines 444 to 447 in ae70bc3

	// Parsers are compiled only for their matching Java version, given their use of internal/unstable APIs.
	// Language features introduced in non-LTS versions are only supported from the next LTS version onwards.
	// We recommend running on LTS versions wherever possible; non-LTS versions may struggle given the above.
	// e.g.: Java 23+ changed the return type of `DocCommentTable.getCommentTree` from `DCDocComment` to `DocCommentTree`

Sorry to hear if this wasn't known or caught earlier. It's what I had tried to get across in the earlier comment above. With the changes made in response to this issue these projects now will report a lot of warnings and fail to make changes to the associated files.

It's all just quite unfortunate all around; there's no real good way forward save for perhaps restoring the reflection hacks we had in the Java21Parser again for continued use of Java 23/24, but for maintainability we'd really rather not, and instead prefer to set clear expectations: non-LTS versions are only supported until the next LTS, which mostly aligns with support on those JVMs themselves.

Not sure I see any other clear ways forward, but I'll monitor for replies if you have any suggestions.

[kdvolder]

non-LTS versions are only supported until the next LTS, which mostly aligns with support on those JVMs themselves

Yeah... and I personally think this is all very reasonable, its really too bad that Gradle 8.x explicitly dictates the use of non LTS 8.24.

And unfortunately this seems to be one of those things 'outside our sphere of influence'.

So where does it leave us? People just shouldn't be using gradle 8.x if they want to use a recent version of open-rewrite? Do you think this is acceptable?

if you have any suggestions

I really don't. But I will offer to put in some work to help resolve this. I just don't know enough about how this works internally to come up with a good suggestion on an acceptable and practical way to get a 'mostly working java parser' on recent OR with Java 24 runtime. If you have any ideas. Do let me know. Otherwise... I guess we'll just have to tell customers to what? Either update to Gradle 9.x (without help of OR :-)? Or just not use gradle at all if they can avoid it?

[timtebeek]

So then pretty much the only thing we can do is restore (only) that work around for the changed method signatures:

• Support Gradle 8.x on Java 23+ #6725

I'd not want to back port language features, but not being able to support any JavaDoc on Gradle 8.x for Java 23+ is a bad look.