Skip to content

Comments

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

Open
HannesWell wants to merge 2 commits intoeclipse-xtext:mainfrom
HannesWell:java25
Open

Add compiler support for Java-25 and set up a Java-25 build#3604
HannesWell wants to merge 2 commits intoeclipse-xtext:mainfrom
HannesWell:java25

Conversation

@HannesWell
Copy link
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 ]
Copy link
Contributor Author

@HannesWell HannesWell Feb 16, 2026

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
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
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
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
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
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

Copy link
Contributor Author

@HannesWell HannesWell Feb 18, 2026

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.

@cdietrich
Copy link
Contributor

as i have feared this will open the complete can
grafik

@github-actions
Copy link

github-actions bot commented Feb 16, 2026

Test Results

  8 071 files  + 3 219    8 071 suites  +3 219   3h 45m 13s ⏱️ + 1h 28m 47s
 43 238 tests +     2   42 648 ✅  -      4    584 💤 ±    0  6 ❌ +6 
212 493 runs  +84 974  209 566 ✅ +83 800  2 921 💤 +1 168  6 ❌ +6 

For more details on these failures, see this check.

Results for commit 8d1b756. ± Comparison against base commit 99a5c22.

This pull request removes 5 and adds 7 tests. Note that renamed tests count towards both.
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[11: Gradle|Plain|HIERARCHICAL|Fat Jar]
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[12: Maven|Plain|HIERARCHICAL|Regular]
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[14: Gradle|Plain|HIERARCHICAL|Regular]
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[8: Gradle|Plain|HIERARCHICAL|None]
org.eclipse.xtext.xtext.wizard.cli.CliWizardIntegrationTest ‑ testProjectCreation[9: Maven|Plain|HIERARCHICAL|Fat Jar]
org.eclipse.xtend.maven.XtendCompilerMojoIT ‑ simpleJava25Project
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
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
Contributor

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

@HannesWell
Copy link
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
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

- 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
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.

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.

2 participants