Prepare 4.38 development

[eclipse-releng-bot]

Prepare development of Eclipse 4.38.
This complements:

• Prepare 4.38 development eclipse.platform.releng.aggregator#3271

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

binaries/org.eclipse.swt.cocoa.macosx.aarch64/META-INF/MANIFEST.MF
binaries/org.eclipse.swt.cocoa.macosx.x86_64/META-INF/MANIFEST.MF
binaries/org.eclipse.swt.gtk.linux.aarch64/META-INF/MANIFEST.MF
binaries/org.eclipse.swt.gtk.linux.ppc64le/META-INF/MANIFEST.MF
binaries/org.eclipse.swt.gtk.linux.riscv64/META-INF/MANIFEST.MF
binaries/org.eclipse.swt.gtk.linux.x86_64/META-INF/MANIFEST.MF
binaries/org.eclipse.swt.win32.win32.aarch64/META-INF/MANIFEST.MF
binaries/org.eclipse.swt.win32.win32.x86_64/META-INF/MANIFEST.MF
bundles/org.eclipse.swt/META-INF/MANIFEST.MF
bundles/org.eclipse.swt/pom.xml

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From de8266d24c9a29fd12e2f1ee1b0a9c744d6498d7 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <[email protected]>
Date: Fri, 29 Aug 2025 19:33:52 +0000
Subject: [PATCH] Version bump(s) for 4.38 stream


diff --git a/binaries/org.eclipse.swt.cocoa.macosx.aarch64/META-INF/MANIFEST.MF b/binaries/org.eclipse.swt.cocoa.macosx.aarch64/META-INF/MANIFEST.MF
index 26c863aecd..ac3a606dae 100644
--- a/binaries/org.eclipse.swt.cocoa.macosx.aarch64/META-INF/MANIFEST.MF
+++ b/binaries/org.eclipse.swt.cocoa.macosx.aarch64/META-INF/MANIFEST.MF
@@ -3,7 +3,7 @@ Fragment-Host: org.eclipse.swt;bundle-version="[3.128.0,4.0.0)"
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
 Bundle-SymbolicName: org.eclipse.swt.cocoa.macosx.aarch64; singleton:=true
-Bundle-Version: 3.131.0.qualifier
+Bundle-Version: 3.131.100.qualifier
 Bundle-ManifestVersion: 2
 Bundle-Localization: fragment
 Export-Package: 
diff --git a/binaries/org.eclipse.swt.cocoa.macosx.x86_64/META-INF/MANIFEST.MF b/binaries/org.eclipse.swt.cocoa.macosx.x86_64/META-INF/MANIFEST.MF
index 37c4c27a31..cd516b318e 100644
--- a/binaries/org.eclipse.swt.cocoa.macosx.x86_64/META-INF/MANIFEST.MF
+++ b/binaries/org.eclipse.swt.cocoa.macosx.x86_64/META-INF/MANIFEST.MF
@@ -3,7 +3,7 @@ Fragment-Host: org.eclipse.swt;bundle-version="[3.128.0,4.0.0)"
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
 Bundle-SymbolicName: org.eclipse.swt.cocoa.macosx.x86_64; singleton:=true
-Bundle-Version: 3.131.0.qualifier
+Bundle-Version: 3.131.100.qualifier
 Bundle-ManifestVersion: 2
 Bundle-Localization: fragment
 Export-Package: 
diff --git a/binaries/org.eclipse.swt.gtk.linux.aarch64/META-INF/MANIFEST.MF b/binaries/org.eclipse.swt.gtk.linux.aarch64/META-INF/MANIFEST.MF
index ab66886914..77b5072882 100644
--- a/binaries/org.eclipse.swt.gtk.linux.aarch64/META-INF/MANIFEST.MF
+++ b/binaries/org.eclipse.swt.gtk.linux.aarch64/META-INF/MANIFEST.MF
@@ -3,7 +3,7 @@ Fragment-Host: org.eclipse.swt;bundle-version="[3.128.0,4.0.0)"
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
 Bundle-SymbolicName: org.eclipse.swt.gtk.linux.aarch64; singleton:=true
-Bundle-Version: 3.131.0.qualifier
+Bundle-Version: 3.131.100.qualifier
 Bundle-ManifestVersion: 2
 Bundle-Localization: fragment
 Export-Package: 
diff --git a/binaries/org.eclipse.swt.gtk.linux.ppc64le/META-INF/MANIFEST.MF b/binaries/org.eclipse.swt.gtk.linux.ppc64le/META-INF/MANIFEST.MF
index 043a0153a2..6d14bd5867 100644
--- a/binaries/org.eclipse.swt.gtk.linux.ppc64le/META-INF/MANIFEST.MF
+++ b/binaries/org.eclipse.swt.gtk.linux.ppc64le/META-INF/MANIFEST.MF
@@ -3,7 +3,7 @@ Fragment-Host: org.eclipse.swt;bundle-version="[3.128.0,4.0.0)"
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
 Bundle-SymbolicName: org.eclipse.swt.gtk.linux.ppc64le;singleton:=true
-Bundle-Version: 3.131.0.qualifier
+Bundle-Version: 3.131.100.qualifier
 Bundle-ManifestVersion: 2
 Bundle-Localization: fragment
 Export-Package: 
diff --git a/binaries/org.eclipse.swt.gtk.linux.riscv64/META-INF/MANIFEST.MF b/binaries/org.eclipse.swt.gtk.linux.riscv64/META-INF/MANIFEST.MF
index 5c8fa217e5..7fd71e115d 100644
--- a/binaries/org.eclipse.swt.gtk.linux.riscv64/META-INF/MANIFEST.MF
+++ b/binaries/org.eclipse.swt.gtk.linux.riscv64/META-INF/MANIFEST.MF
@@ -3,7 +3,7 @@ Fragment-Host: org.eclipse.swt;bundle-version="[3.128.0,4.0.0)"
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
 Bundle-SymbolicName: org.eclipse.swt.gtk.linux.riscv64; singleton:=true
-Bundle-Version: 3.131.0.qualifier
+Bundle-Version: 3.131.100.qualifier
 Bundle-ManifestVersion: 2
 Bundle-Localization: fragment
 Export-Package: 
diff --git a/binaries/org.eclipse.swt.gtk.linux.x86_64/META-INF/MANIFEST.MF b/binaries/org.eclipse.swt.gtk.linux.x86_64/META-INF/MANIFEST.MF
index 688a94b7de..afe6592fba 100644
--- a/binaries/org.eclipse.swt.gtk.linux.x86_64/META-INF/MANIFEST.MF
+++ b/binaries/org.eclipse.swt.gtk.linux.x86_64/META-INF/MANIFEST.MF
@@ -3,7 +3,7 @@ Fragment-Host: org.eclipse.swt;bundle-version="[3.128.0,4.0.0)"
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
 Bundle-SymbolicName: org.eclipse.swt.gtk.linux.x86_64; singleton:=true
-Bundle-Version: 3.131.0.qualifier
+Bundle-Version: 3.131.100.qualifier
 Bundle-ManifestVersion: 2
 Bundle-Localization: fragment
 Export-Package: 
diff --git a/binaries/org.eclipse.swt.win32.win32.aarch64/META-INF/MANIFEST.MF b/binaries/org.eclipse.swt.win32.win32.aarch64/META-INF/MANIFEST.MF
index 4804132b9d..b6dc89e711 100644
--- a/binaries/org.eclipse.swt.win32.win32.aarch64/META-INF/MANIFEST.MF
+++ b/binaries/org.eclipse.swt.win32.win32.aarch64/META-INF/MANIFEST.MF
@@ -3,7 +3,7 @@ Fragment-Host: org.eclipse.swt;bundle-version="[3.128.0,4.0.0)"
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
 Bundle-SymbolicName: org.eclipse.swt.win32.win32.aarch64; singleton:=true
-Bundle-Version: 3.131.0.qualifier
+Bundle-Version: 3.131.100.qualifier
 Bundle-ManifestVersion: 2
 Bundle-Localization: fragment
 Export-Package: 
diff --git a/binaries/org.eclipse.swt.win32.win32.x86_64/META-INF/MANIFEST.MF b/binaries/org.eclipse.swt.win32.win32.x86_64/META-INF/MANIFEST.MF
index 7855c496be..873ca47cd0 100644
--- a/binaries/org.eclipse.swt.win32.win32.x86_64/META-INF/MANIFEST.MF
+++ b/binaries/org.eclipse.swt.win32.win32.x86_64/META-INF/MANIFEST.MF
@@ -3,7 +3,7 @@ Fragment-Host: org.eclipse.swt;bundle-version="[3.128.0,4.0.0)"
 Bundle-Name: %fragmentName
 Bundle-Vendor: %providerName
 Bundle-SymbolicName: org.eclipse.swt.win32.win32.x86_64; singleton:=true
-Bundle-Version: 3.131.0.qualifier
+Bundle-Version: 3.131.100.qualifier
 Bundle-ManifestVersion: 2
 Bundle-Localization: fragment
 Export-Package: 
diff --git a/bundles/org.eclipse.swt/META-INF/MANIFEST.MF b/bundles/org.eclipse.swt/META-INF/MANIFEST.MF
index cb862cd26f..476aa8b84a 100644
--- a/bundles/org.eclipse.swt/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.swt/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-Name: %pluginName
 Bundle-Vendor: %providerName
 Bundle-SymbolicName: org.eclipse.swt; singleton:=true
-Bundle-Version: 3.131.0.qualifier
+Bundle-Version: 3.131.100.qualifier
 Bundle-ManifestVersion: 2
 Bundle-Localization: plugin
 DynamicImport-Package: org.eclipse.swt.accessibility2
diff --git a/bundles/org.eclipse.swt/pom.xml b/bundles/org.eclipse.swt/pom.xml
index 623057bb9f..c6c1d4688a 100644
--- a/bundles/org.eclipse.swt/pom.xml
+++ b/bundles/org.eclipse.swt/pom.xml
@@ -20,7 +20,7 @@
         <relativePath>../../</relativePath>
     </parent>
     <artifactId>org.eclipse.swt</artifactId>
-    <version>3.131.0-SNAPSHOT</version>
+    <version>3.131.100-SNAPSHOT</version>
     <packaging>eclipse-plugin</packaging>
 
     <properties>
-- 
2.51.0

Further information are available in Common Build Issues - Missing version increments.

[github-actions]

Test Results

   546 files  ±0     546 suites  ±0   30m 8s ⏱️ -8s
 4 426 tests ±0   4 409 ✅ ±0   17 💤 ±0  0 ❌ ±0 
16 750 runs  ±0  16 623 ✅ ±0  127 💤 ±0  0 ❌ ±0 

Results for commit eca2157. ± Comparison against base commit 6b5b54a.

♻️ This comment has been updated with latest results.

[HannesWell]

This automated update looks as intended, especially the individual parts introduced with

• #2460

The only thing that's a bit bothering is the failure of all Github builds. The all fail with an API-error for the running platform:

Caused by: org.eclipse.tycho.core.exceptions.VersionBumpRequiredException: There are API errors:
Eclipse SWT/common/org/eclipse/swt/graphics/Point.java:133 The constructor org.eclipse.swt.graphics.Point.OfFloat.OfFloat(int, int) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Point.java:137 The constructor org.eclipse.swt.graphics.Point.OfFloat.OfFloat(float, float) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Point.java:143 The method org.eclipse.swt.graphics.Point.OfFloat.getX() is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Point.java:147 The method org.eclipse.swt.graphics.Point.OfFloat.getY() is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Point.java:151 The method org.eclipse.swt.graphics.Point.OfFloat.setX(float) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Point.java:156 The method org.eclipse.swt.graphics.Point.OfFloat.setY(float) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Point.java:184 The constructor org.eclipse.swt.graphics.Point.WithMonitor.WithMonitor(int, int, Monitor) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Point.java:192 The method org.eclipse.swt.graphics.Point.WithMonitor.getMonitor() is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:413 The constructor org.eclipse.swt.graphics.Rectangle.OfFloat.OfFloat(int, int, int, int) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:417 The constructor org.eclipse.swt.graphics.Rectangle.OfFloat.OfFloat(float, float, float, float) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:425 The method org.eclipse.swt.graphics.Rectangle.OfFloat.getX() is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:429 The method org.eclipse.swt.graphics.Rectangle.OfFloat.getY() is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:433 The method org.eclipse.swt.graphics.Rectangle.OfFloat.getWidth() is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:437 The method org.eclipse.swt.graphics.Rectangle.OfFloat.getHeight() is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:441 The method org.eclipse.swt.graphics.Rectangle.OfFloat.setX(float) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:446 The method org.eclipse.swt.graphics.Rectangle.OfFloat.setY(float) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:451 The method org.eclipse.swt.graphics.Rectangle.OfFloat.setWidth(float) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:456 The method org.eclipse.swt.graphics.Rectangle.OfFloat.setHeight(float) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:487 The constructor org.eclipse.swt.graphics.Rectangle.WithMonitor.WithMonitor(int, int, int, int, Monitor) is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:500 The method org.eclipse.swt.graphics.Rectangle.WithMonitor.getMonitor() is no longer an API
Eclipse SWT/common/org/eclipse/swt/graphics/Rectangle.java:505 The method org.eclipse.swt.graphics.Rectangle.WithMonitor.clone() is no longer an API
META-INF/MANIFEST.MF:6 The major version should be incremented in version 3.131.100, since API breakage occurred since version 3.131.0
    at org.eclipse.tycho.apitools.ApiAnalysisMojo.getApiError (ApiAnalysisMojo.java:284)
    at org.eclipse.tycho.apitools.ApiAnalysisMojo.execute (ApiAnalysisMojo.java:251)
    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 io.takari.maven.builder.smart.SmartBuilderImpl.buildProject (SmartBuilderImpl.java:206)
    at io.takari.maven.builder.smart.SmartBuilderImpl$ProjectBuildTask.run (SmartBuilderImpl.java:71)
    at java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:572)
    at java.util.concurrent.FutureTask.run (FutureTask.java:317)
    at java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1144)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:642)
    at java.lang.Thread.run (Thread.java:1583)

I think it's interesting to await results of the Jenkins build (I killed the last Y-build test for mac to speed that up).

[HannesWell]

The only thing that's a bit bothering is the failure of all Github builds. The all fail with an API-error for the running platform:

@laeubi, @HeikoKlare or @akurtakov are those familiar to you or do you want to investigate them before submitting this?

[HeikoKlare]

At a first glance, those API errors are strange: those nested classes and methods have been introduced with the current release. They are effectively part of the public API (even though they are marked as @noreference) and I do not see how that should change in any way. To me, this looks like an issue with API tooling, even though I currently cannot imagine what it does. I guess it must have something to do with the classes being nested, as we had other classes extending Rectangle and Point (also marked as @noreference and also part of a sealed hierarchy) over multiple releases before and API tooling did not complain there.

At least, I get the same errors when I set the current target platform as baseline in my IDE, so in that regard the errors appear consistently.

I will probably not find the time to deepler look into what API tooling does here before somewhen next week. But in my opinion it should not prevent us from moving on. We could simply add API filters (even though they do not make sense) to work around this for now and ensure that we do not have misleading build errors in the builds and IDE.

[HeikoKlare]

I can confirm that this is an issue with API tooling. I debugged into it and found that API tooling does not seem to be capable of properly analyzing a package with contents of multiple source folders. In this case, the ApiDescription for for the org.eclipse.swt.graphics package only contains the win32-specific classes as children, but not the common ones (including Point, Rectangle etc.). This results in the baseline comparison thinking that the reference element for, e.g., Point$OfFloat (for which is finds nothing more specific than the package org.eclipse.swt.graphics) did not contain a @noreference annotation while the current element (which is directly has at hand to analyze) is restricted in that way.
This is the point where the tooling searches for the node of the Point$OfFloat class in the baseline/reference, where the org.eclipse.swt.graphics package only has the non-common classes as children (thus especially not including Point):

If the above analysis is correct, this could indicate a major flaw in API tooling as it would mean that it's not capable properly analyzing the common parts of SWT.
This is probably the same reason for the issue we experience during in the current release cycle, also involving the Point and Rectangle classes:

• Failed to execute goal org.eclipse.tycho:tycho-apitools-plugin:5.0.0-SNAPSHOT:verify eclipse-tycho/tycho#5148

[laeubi]

@HeikoKlare Please open an issue (at best with a small reproducer project) for API tools.

Beside that

did not contain a @noreference annotation while the current element

I assume you specifically reference to the javadoc annotation, I wonder if it would make a difference if we where using the code annotation @NoReference

this could indicate a major flaw in API tooling

I think SWT is rather an exception than the norm, so even though it should be fixed I would not directly call it a major flaw given it was not detected or complained for years.

Also this more shows to me that controlling API with non standard @NoReference is always a bit fragile anyways, so if as promised in the changes in this area will vanish when we promote it to proper API.

[HeikoKlare]

Please open an issue (at best with a small reproducer project) for API tools.

I will do as soon as possible, but I don't know when I will find the time for creating that reproducer.

I assume you specifically reference to the javadoc annotation, I wonder if it would make a difference if we where using the code annotation @NoReference

Based on what I saw when debugging I don't think so. as the issue is not with the annotation itself but with the fact that the class that has the annotation does not even seem to be found in the baseline. But I just did a quick session to identify what needs to be done w.r.t. this issue and the code is not that simple, so maybe I just did not fully understand how it works yet.

I think SWT is rather an exception than the norm, so even though it should be fixed I would not directly call it a major flaw given it was not detected or complained for years.

I agree that SWT is rather an exception. What I meant with "major flaw" is that the described behavior may lead to actual API breakages not being reported if the classes to compare against are simply not found in the baseline. But as I said, it just "could indicate" it, as a deeper analysis would need to show what's actually going wrong. That's why I think we should probably not just say it's a flaw with the special structure of SWT and we should work around it but rather try to go into some analysis.

[HannesWell]

Thank you Heiko for looking into that.

Please open an issue (at best with a small reproducer project) for API tools.

I will do as soon as possible, but I don't know when I will find the time for creating that reproducer.

I assume one can simpliy reproducing this with the current state of the swt project (maybe stripped by all other classes) and a simple baseline using the [RC2 repo](the natives are getting restless here (my husband)
18:35 Uhr) with the o.e.platform feature.

We could simply add API filters (even though they do not make sense) to work around this for now and ensure that we do not have misleading build errors in the builds and IDE.

I have added a commit that does that so that we can proceed with development right now. One should be able to reproduce the problems by simply deleting/reverting those filters.

Should we submit this if the build is now fine?

[HeikoKlare]

Seems like the two preexisting API filters for MonitorAwareRectangle/MonitorAwarePoint should be removed. Then this should be ready to go.
Those classes can hopefully be removed in the current release cycle completely (was not possible because of an an API tooling issue before).

[HannesWell]

Seems like the two preexisting API filters for MonitorAwareRectangle/MonitorAwarePoint should be removed. Then this should be ready to go.

Yes, I just removed those filters.

Those classes can hopefully be removed in the current release cycle completely (was not possible because of an an API tooling issue before).

I also removed these files in the commit to remove the filters and locally in my IDE I didn't notice any problem. Lets see what the builds says.
Or is there another reason to keep them for longer?

[HeikoKlare]

Or is there another reason to keep them for longer?

No, it did just did not work before because of eclipse-tycho/tycho#5148

That's why I basically made those classes internal in the previous release cycle so that API tooling will not check them in this cycle anymore, allowing them to be removed. Seems like that works :-) Thanks for directly trying it out!

[HannesWell]

That's why I basically made those classes internal in the previous release cycle so that API tooling will not check them in this cycle anymore, allowing them to be removed. Seems like that works :-) Thanks for directly trying it out!

Understand. Actually I just removed them because a new warning pop-ed up on them and just removing them avoided adding a yet another new filter.

So then lets submit this now and look into the API-tools problems separately.

[HeikoKlare]

ftr: I have created a PDE issue with a more or less simple reproducer derived from this SWT example:

• API tools considers nested, noreference classes as public API in baseline eclipse-pde/eclipse.pde#1949

Stripping down SWT turned out that is seems to be caused by an incomplete .api_description file in the fragment that simply misses the @noreference annotations in the baseline.