Skip to content

Add compiler support for Java-25 and set up a Java-25 build#3604

Merged
cdietrich merged 1 commit into
eclipse-xtext:mainfrom
HannesWell:java25
Mar 12, 2026
Merged

Add compiler support for Java-25 and set up a Java-25 build#3604
cdietrich merged 1 commit into
eclipse-xtext:mainfrom
HannesWell:java25

Conversation

@HannesWell

Copy link
Copy Markdown
Contributor

This adds only compiler support for Java-25, i.e. it becomes possible to compile projects that target Java-25.
This doesn't add UI support for it yet, but I can try to extend this PR if you want to have this one pass.
A dedicated Java-25 test project is also missing (like the one added for Java-21), but I can also look into that.
As far as I know now new relevant compiler constructs where added respectivly the Java standard library wasn't changed between Java-21 and 25 in a way that affects Xtext.

Java-17 support is maintained with this.

Part of

This also includes

I could do it without it, the latter but it would become more complex eventually.

matrix: # 'macos-14' is arm64
os: ['ubuntu-22.04', 'macos-14', 'windows-2022']
java: [ 21 ]
java: [ 25 ]

@HannesWell HannesWell Feb 16, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In case just minimal support is added for Java-25 at the moment the main build could also stay at Java-21 and just one extra branch for Java-25 could be added.

@cdietrich

Copy link
Copy Markdown
Contributor

what is still unclear to me: how does this work without changes to bom

// assertEquals(ClassFileConstants.JDK21, JavaVersion.JAVA21.toJdtClassFileConstant());
assertEquals(4259840, JavaVersion.JAVA21.toJdtClassFileConstant());
// assertEquals(ClassFileConstants.JDK25, JavaVersion.JAVA25.toJdtClassFileConstant());
assertEquals(4521984, JavaVersion.JAVA25.toJdtClassFileConstant());

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i assume we need to use the try catch approach here

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? I don't see anything referenced that's not available in the baseline Java or Eclipse version?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also in the 2024-03 target platform / the one that is also used in maven bom?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in the past we did some reflection in that test instead of
4521984

@HannesWell HannesWell Feb 18, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also in the 2024-03 target platform / the one that is also used in maven bom?

It should be yes. Eclipse 2025-12 had complete Java-25 support and since Java-21 was released two years earlier I expect the 21 constants to be available since 2023-12.
And I also ran the Jenkins build in the m2e JIPP with the lowest TP and java-17 and it succeeded.

in the past we did some reflection in that test instead of

That would work too, but I think the approach to just inline the value (implemented before by @LorenzoBettini) is simpler.
And the later expected code is already available as commented out code.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, IIRC, in the past I had inlined a constant for such a scenario. I did that because someone else had done that in the past.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can clean this up with my big bump pr in follow up

@cdietrich

Copy link
Copy Markdown
Contributor

as i have feared this will open the complete can
grafik

@github-actions

github-actions Bot commented Feb 16, 2026

Copy link
Copy Markdown

Test Results

  8 054 files  + 1 593    8 054 suites  +1 593   3h 52m 50s ⏱️ + 49m 4s
 43 124 tests  -    118   42 540 ✅  -    113    584 💤 ±  0  0 ❌ ±0 
212 391 runs  +42 336  209 470 ✅ +41 757  2 921 💤 +587  0 ❌ ±0 

Results for commit c114fa8. ± Comparison against base commit 479dbc8.

This pull request removes 124 and adds 6 tests. Note that renamed tests count towards both.
foo.FooTest ‑ assertTrue
org.eclipse.xtend.ide.tests.editor.XbaseEditorOpenClassFileTest ‑ Unknown test
org.eclipse.xtend.ide.tests.editor.XtendEditorChangingClasspathTest ‑ Unknown test
org.eclipse.xtend.maven.XtendCompilerMojoIT ‑ aggregation
org.eclipse.xtend.maven.XtendCompilerMojoIT ‑ continueOnXtendWarnings
org.eclipse.xtend.maven.XtendCompilerMojoIT ‑ emptyDirWarningDefault
org.eclipse.xtend.maven.XtendCompilerMojoIT ‑ emptyDirWarningFalse
org.eclipse.xtend.maven.XtendCompilerMojoIT ‑ emptyDirWarningTrue
org.eclipse.xtend.maven.XtendCompilerMojoIT ‑ encoding
org.eclipse.xtend.maven.XtendCompilerMojoIT ‑ fileSystemAccess
…
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[11: Maven|Plain|HIERARCHICAL|Fat Jar]
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[12: Gradle|Plain|HIERARCHICAL|Fat Jar]
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[14: Maven|Plain|HIERARCHICAL|Regular]
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[15: Gradle|Plain|HIERARCHICAL|Regular]
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[8: Maven|Plain|HIERARCHICAL|None]
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[9: Gradle|Plain|HIERARCHICAL|None]

♻️ This comment has been updated with latest results.

@HannesWell

Copy link
Copy Markdown
Contributor Author

as i have feared this will open the complete can

Indeed.
So I assume you prefer to postpone this too?
For me it wouldn't be that bad, since I found in the meantime, that I can just leave the Xtext/Xtend compiler configuration at Java-21 while moving the runtime and other parts to Java-25 seems to work well. So for me this isn't 'urgent' anymore.
I assume that lower level adaption isn't necessary anyways in Xtext.

@cdietrich

Copy link
Copy Markdown
Contributor

i also assume it wont work at runtime due to bom
even if we would hide it from the wizard

@HannesWell

Copy link
Copy Markdown
Contributor Author

What bom are you referring to exactly?
The targeted eclipse version must of course support Java-25. But just running with Java-25 could work with quite old releases. Of course if one compiles code at runtime targeting Java-25 one must use Eclipse 2025-12, which is the first version of JDT fully supporting Java-25.

@cdietrich

Copy link
Copy Markdown
Contributor

stuff like the xtext maven plugin uses the bom i have linked above / in the other discussionhttps://github.com/eclipse-xtext/xtext/blob/425a9bee287588415dacc1042ce9e31f4ac7a3fa/org.eclipse.xtext.dev-bom/pom.xml#L273

@HannesWell HannesWell force-pushed the java25 branch 2 times, most recently from 4419731 to 8d1b756 Compare February 17, 2026 22:38
@HannesWell

Copy link
Copy Markdown
Contributor Author

what is still unclear to me: how does this work without changes to bom

In the meantime I added a java-25 profile to the BOM. But I'm not sure if it is actually necessary, because the jdt.core version supporting Java-25 still runs on Java-17. So we could just bump that. But I don't know your policy with respect to the versions in the BOM and the minimally supported target SimRel.

Furthermore I added a dedicated compiler and wizard tests for Java-25 and adapted failing tests.
The most difficult one is probably ImportOrganizerTest.xtend, which had to be adapted because java.util.Collections class became final in (or before) Java-25.

In the current state all Github and Jenkins builds (executed in the m2e JIPP) succeeded in my testing.

Please let me know if something is missing.

// see https://bugs.eclipse.org/bugs/show_bug.cgi?id=399519
@Test def testExtensionFeatureCallToStaticLocalFieldFromSuper() {
'''
import java.util.Collections

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you change this test?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Collections is final in Java-25 and wasn't in Java-21 and before:

So I searched for another class that's not final and has (directly or inherited) static methods that could be used for this test.
And ArrayList seemed a simple replacement where the static methods from the List interface could be used (and it was similar).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the past, when supporting Java 21, I had similar problems due to changes in the JDK. I solved them by NOT using JDK types for tests: I crafted a few Java types (stub classes) with the requirements for our tests.

If you need a "class that's not final and has (directly or inherited) static methods" I'd create a stub class in that tests project and use that one in the test.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good idea.
But since it's working now, I would be fine to leave it as it is for now. However, if you'd prefer to have it changed, I can implement your suggestion.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It depends on how much work it requires.
If it's not that much, I'd do it now so we can continue removing our dependencies on JDK, which will likely break in future JDK versions.
If it takes too much time, now that it works we can leave it like that; in the future it might break again ;)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have this problem on a regular base so i am fine with adjusting stuff while keeping the intent of the test

@cdietrich

Copy link
Copy Markdown
Contributor

@HannesWell can you check what of this is missing on #3638

@cdietrich

Copy link
Copy Markdown
Contributor

So your proposal is to close eyes on eg wizard not working properly on main

@HannesWell

Copy link
Copy Markdown
Contributor Author

So your proposal is to close eyes on eg wizard not working properly on main

Sorry for the simple question, but what wizard changes are you referring to exactly?
I went through your big PR #3638 and didn't find a change related to the wizard that seems relevant for me for just the addition of Java-25 support. Bumping the minimum to 21, of course requires changes again, but IMO that's better done separately.
Or do you also have not yet applied the required wizard changes for adding Java-25?
Because in #3604 (comment), we see that the wizard already reads the available constants.
And I've already added the wizard tests for Java-25 and they all passed the last time I checked it.

But I'm happy to add the required wizard changes if you point me to them.

@HannesWell HannesWell force-pushed the java25 branch 3 times, most recently from 8dc1f30 to 21bc1ae Compare March 11, 2026 09:27
Comment thread org.eclipse.xtext.util/src/org/eclipse/xtext/util/JavaRuntimeVersion.java Outdated
Comment thread pom.xml
@HannesWell

Copy link
Copy Markdown
Contributor Author

The Jenkins changes are again tested with
https://ci.eclipse.org/m2e/job/try-outs-xtext-Hannes/

@cdietrich

Copy link
Copy Markdown
Contributor

can you check the failing CliWizardIntegrationTest

@HannesWell

Copy link
Copy Markdown
Contributor Author

can you check the failing CliWizardIntegrationTest

It was referencing a milestone MWE repository that was probably set during the release rampdown and that I copied at the time when I created this PR. That should be fixed now.

But this is now blocked by

@cdietrich

Copy link
Copy Markdown
Contributor

Done

Comment thread org.eclipse.xtext.util/src/org/eclipse/xtext/util/JavaVersion.java Outdated
- Add constants for Java-25
- Add compiler and wizard tests for Java-25.
- Add Java-25 profile to xtext-dev BOM
- Fix tests failing on Java-25:
  - java.util.Collections class is final in Java-25
@HannesWell

Copy link
Copy Markdown
Contributor Author

Now all tests pass again and the Jenkins build looks also good:
https://ci.eclipse.org/m2e/job/try-outs-xtext-Hannes/

Do you have more more remarks or need more changes or is this ready?

@cdietrich cdietrich merged commit cee4445 into eclipse-xtext:main Mar 12, 2026
9 of 10 checks passed
@HannesWell HannesWell deleted the java25 branch March 12, 2026 08:38
@HannesWell HannesWell mentioned this pull request Apr 2, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants