Update BREE to Java21 for SWT

[jonahgraham]

To be able to do #2561 (comment) I need Java 21.

[jonahgraham]

This is expected to fail with missing version bumps, but as we are around branch point I will correct that once the master is open for 2026-03 dev.

[github-actions]

Test Results

  118 files  ±0    118 suites  ±0   17m 10s ⏱️ +5s
4 653 tests ±0  4 635 ✅ ±0  18 💤 ±0  0 ❌ ±0 
  338 runs  ±0    334 ✅ ±0   4 💤 ±0  0 ❌ ±0 

Results for commit 785e5da. ± Comparison against base commit 941ff78.

♻️ This comment has been updated with latest results.

[laeubi]

To be able to do #2561 (comment) I need Java 21.

I'm just wondering, when the test needs java 21 why do we need to bump the bundles/fragments?

[jonahgraham]

Seemed like a good time to make the update. We are only testing on Java 21 anyways on CI, so let's make it official.

[laeubi]

Seemed like a good time to make the update. We are only testing on Java 21 anyways on CI, so let's make it official.

One should consider that SWT can be used "standalone" as well so bumping the java version for no good reason can have a negative impact on a lot of unknown consumers and does not bring any benefits.

Esepcially if you say we are already testing on Java 21 all whats needed is to use the higher version in the test bundle to make your use-case work what has a much smaller footprint, easier to review and so on.

[merks]

I think maybe the point is that nothing tests that it actually runs on the older JVMs.

[laeubi]

I think maybe the point is that nothing tests that it actually runs on the older JVMs.

We don't do that on other places as well ... I also don't see why we should assume it is not the case, and if we do we need to recompile each and every library we use in eclipse because also there we never check it actually runs with the EE declared there.... not talking about that no one ever test we can run with any older version we currently allow in version ranges.

[merks]

We don't do that on other places as well ...

Indeed with significant parts of equinox being an example.

[akurtakov]

As for the June release the plan is to make use Java FFM (final in Java 22) thus SWT will bump to Java 25 it seems correct to have one release that moves to Java 21 (even if not strictly depending on things in it) to allow gradual progress for consumers.

[HeikoKlare]

Fully agree that we should move to Java 21 sooner than later so that we have at least one further relase until we move to Java 25.

Regarding moving to Java 25 in Eclipse/SWT, I would like to mention that it might be that consumers suffer from https://bugs.openjdk.org/browse/JDK-8336862. At least we do and we are still investigating solutions but have not found any to apply with reasonable effort yet. That behavior change was reverted for the more revent Java 21 release but is present in Java 22 onwards.

[laeubi]

As for the June release the plan is to make use Java FFM (final in Java 22) thus SWT will bump to Java 25 it seems correct to have one release that moves to Java 21 (even if not strictly depending on things in it) to allow gradual progress for consumers.

If we're planning to raise the requirement to Java 25 in the June release (as mentioned in the discussion), I don't see a strong benefit in raising it to Java 21 now. This intermediate step would:

1. Cut off Java 17 users - We'd be dropping support for users still on Java 17 for only a ~6 month period before another major jump
2. Create unnecessary churn - Two BREE updates in quick succession (17→21 now, then 21→25 in June) versus one larger update (17→25 in June)
3. Limited benefit window - The advantages of Java 21 features would only be available for a short period before we move to Java 25

Alternative proposal: Stay at Java 17 for now and make a single, larger jump directly to Java 25 in the June release, skipping Java 21 altogether. This would:

• Give Java 17 users more time to prepare for the transition
• Reduce the migration burden to a single update
• Align better with the planned Java 25 adoption timeline

What are the compelling reasons for the intermediate Java 21 step that would outweigh these concerns? Are there specific Java 21 features that SWT urgently needs before June?

[akurtakov]

We seem to have a totally opposite view of what is a benefit and what a concern. Everything you describe as churn and etc. is what I see as benefit - send a message that no one can pretend to have missed that things are moving up and make people prepare for even bigger changes.
If someone disagrees with 2 of the PLs saying SWT goes to Java 21 this release - the only step forward is https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#committer-disagreement-resolution

[laeubi]

Don't know this was a official "vote" from PL and assumed it was more an open discussion. As it seems not the case and my concerns are actually overruled I will simply abstain from this then as a consequence then, no need for any addition disagreement process here as I raised my concerns.

[HeikoKlare]

I appreciate seeing arguments to consider being raised. No matter if they change any decision or not, it's valuable to have them on the table to consider.

Probably no one of us would be in favor of increasing requirements / BREEs without any relevant need. In this case, I particularly see the need in the upcoming bump to Java 25. Skipping a complete Java LTS release could raise even more concerns.
Consumers who want to use latest Eclipse/SWT should be on up-to-date Java anyway as otherwise they will loose compatibility soon. Waiting for the last possible point in time to update is probably not a good idea. That's why cutting of users does not count as an argument for me, unless there are specific concerns with moving from Java 17 to 21 (which I am not aware of, in contrast to Java 25 as mentioned above).
In addition, the argument only applies to pure SWT consumers. Everyone using the Eclipse Platform needs to use Java 21 already.

[iloveeclipse]

• Give Java 17 users more time to prepare for the transition
• Reduce the migration burden to a single update

From my experience, "affected" users never read any announcements and never prepare upfront to anything.

So announcing now we would switch to java 25 in two releases would not force anyone to try and fix problems locally, and because of that there would be no reduction of the burden, the opposite will happen: they will get all changes in one "big bang" event with Java 25, so they will have to deal with Java 21 and 25 changes at same time.

Also from my experience as platform owner for our application, switching via one "big bang" event always caused lot of troubles and took much more time for me in the past. After we've switched to "build & test every week on master", almost all problems were "easy" to identify & fix (compared to "build once next target release is out & pray it works").

Switching to Java 21 now is fine IMO, earlier is better, also better to sort out problems specific to Java 21 and to 25.

[iloveeclipse]

 [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:5.0.1:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.swt.svg: Only qualifier changed for (org.eclipse.swt.svg/3.131.0.v20251201-0912). Expected to have bigger x.y.z than what is available in baseline (3.131.0.v20251009-2047) -> [Help 1]

[HeikoKlare]

 [ERROR] Failed to execute goal org.eclipse.tycho.extras:tycho-p2-extras-plugin:5.0.1:compare-version-with-baselines (compare-attached-artifacts-with-release) on project org.eclipse.swt.svg: Only qualifier changed for (org.eclipse.swt.svg/3.131.0.v20251201-0912). Expected to have bigger x.y.z than what is available in baseline (3.131.0.v20251009-2047) -> [Help 1]

Actually I would expect a minor version bump in all bundles when increasing the BREE even though API tooling would be fine with the micro version bump already performed for most of the bundles/fragments.

[merks]

I agree with the minor version bump. It's better for setting bounds for those folks who might want to set bounds.

[akurtakov]

Minor version bump is actually a requirement as per the guidelines https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/wiki/Version-Numbering#when-to-change-the-minor-segment

[jonahgraham]

This is expected to fail with missing version bumps, but as we are around branch point I [Jonah] will correct that once the master is open for 2026-03 dev.

and:

Minor version bump is actually a requirement

I'll update minor versions and push new version in a bit.

[merks]

master is open for 2025-03 dev

I know you actually mean 2026-03. 😁

[jonahgraham]

master is open for 2025-03 dev

I know you actually mean 2026-03. 😁

Yup 🤣

(I corrected previous comments now)

[Mailaender]

Skipping a complete Java LTS release could raise even more concerns.

I agree. Smaller steps are usually the way to go for transitioning larger projects. Even if you do them in fast succession. It adds a safety net to fallback to.

[jonahgraham]

Doh! Unqualified OSGi version 3.133.0.qualifier must match unqualified Maven version 3.132.100-SNAPSHOT for SNAPSHOT builds

I assume there was an easier way to do this than how I did it (manually - but forgetting about pom.xmls).

[jonahgraham]

This will be ready for review when https://ci.eclipse.org/releng/job/eclipse.platform.swt/view/change-requests/job/PR-2824/8/ is complete. Note that this was a rebuild so that the forceNativeBuilds is on to make sure that part of the Jenkinsfile change is exercised before merge as much as possible (see parameters).

There are a number of deprecation warnings that need to be fixed with the update to Java 21 - I will be providing them as follow-on PRs to make it easier to review.

[jonahgraham]

Because of eclipse-platform/eclipse.platform.releng.aggregator#3315 Jenkins timed out to rebuild the macos aarch natives. All the other platforms the natives built fine.

I restarted the Jenkins build, but only building the natives for linux and win32 as run 11

So run 8 shows all the natives (except macos aarch) building fine and run 11 completed successfully, testing the GTK port against the Jenkins rebuild natives. Both those runs were against the same commit: 785e5da

IIUC run 11 is marked as a failing check, but I will fix those warnings in subsequent commits/PRs.

Any objections to merging? I would like to get it in before I end up with a bunch of conflicts as others submit their PRs.