Remove IPropertyChangeListener registration in dispose method of editor

[tobiasmelcher]

The two classes org.eclipse.ui.part.EditorPart and org.eclipse.ui.part.MultiPageEditorPart currently register a property change listener in their constructors but fail to unregister it in their dispose() methods.

This oversight results in a memory leak: even after an editor is closed and no longer in use, the associated memory cannot be garbage collected because the listener remains registered. Over time, this can lead to increased memory consumption and degraded performance, especially in environments where editors are frequently opened and closed.

This change ensures that the property change listeners are properly removed during disposal, allowing the editor instances to be garbage collected as expected.

Here the steps to reproduce the problem scenario:

• Download the sample plugin sample_editors.zip , extract the zip and import the project sample_editors to your workspace. The plugin contains a simple form editor registration with class sample.SampleFormEditor which allocates some amount of memory in the constructor.
• Launch the target platform, create a project and a file with name test.sampleform. Open this file and the SampleFormEditor should be opened. The editor itself is empty and does not provide any meaningful content.
• Now close the editor and run the garbage collector multiple times (after enabling "Show heap status" in the preferences) by clicking on the trash icon in the taskbar of eclipse. One would now expect that the editor instance of SampleFormEditor can be garbage collected because the editor is no longer open and used. This is not the case and can be found out by running the eclipse memory analyzer.
• Download the eclipse memory analyzer from https://eclipse.dev/mat/ , install and run it.
• Acquire a Heap Dump of your running target platform containing the SampleFormEditor
• Open the histogram of the heap dump and search for class SampleFormEditor. The histogram shows that there exists one instance of the SampleFormEditor which consumes still some memory. By running context menu action "Merge Shortest Paths to GC Roots"->"exclude all phantom/weak/soft etc. references", you can find out the reason why the object cannot be garbage collected and which object still reference the SampleFormEditor.
  Here a screenshot:

One can see in the stack that the SampleFormEditor instance is still referenced by the propertyChangeListener.

After applying the changes of this pull request, the reference is gone and the SampleFormEditor instance can be garbage collected after it is closed and no longer in use.

[iloveeclipse]

Habe you checked in git whether this is recent regression, or was it always the case?

[iloveeclipse]

Ok, the MultiPageEditorPart leak is a regression from 40edabf / #2224

[iloveeclipse]

EditorPart leak is a very old one, from 28f4ed5

[iloveeclipse]

Good catch, however small fixes needed.

Note: it will go into 4.38 and master is not opened yet for that, so we will need to wait a week or two for merging.

[iloveeclipse]

@tobiasmelcher : did you missed this: #3233 (comment) ?

[tobiasmelcher]

@tobiasmelcher : did you missed this: #3233 (comment) ?

yes, I missed it. [99f37b3] should contain the requested change.
Would be great if the Eclipse codebase would use the @null, @NotNull annotations so that the tool can already tell you where a null check is needed and where not.

[iloveeclipse]

Note: most likely API tools would complain in next release and ask for a minor segment change (dispose() is public added to EditoPart). We will see it first after master is setup for 4.38.

@tobiasmelcher : please ping me if I forget about this PR in two weeks and thanks for the bug report & fix.

[laeubi]

Note: most likely API tools would complain in next release and ask for a minor segment change (dispose() is public added to EditoPart).

Why should API tools complain here? dispose is not added, it is only overridden here, so it was always part of the public API as declared in org.eclipse.ui.IWorkbenchPart.dispose().

Still a version bump is required when fist changing a bundle in the release.

[iloveeclipse]

Why should API tools complain here?

I've just said "most likely". If it doesn't complain, we are fine.

[laeubi]

Why should API tools complain here?

I've just said "most likely". If it doesn't complain, we are fine.

If it does I would say its a bug that needs be fixed. Just in case...

[github-actions]

Test Results

 2 784 files  ±0   2 784 suites  ±0   1h 58m 25s ⏱️ + 8m 18s
 7 936 tests ±0   7 704 ✅ ±0  232 💤 ±0  0 ❌ ±0 
23 342 runs  ±0  22 599 ✅ ±0  743 💤 ±0  0 ❌ ±0 

Results for commit 99f37b3. ± Comparison against base commit 223dfe7.

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

bundles/org.eclipse.ui.workbench/META-INF/MANIFEST.MF

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 42bf49abe45362c80d09f2d7988c96df81788dff Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <[email protected]>
Date: Mon, 1 Sep 2025 11:20:56 +0000
Subject: [PATCH] Version bump(s) for 4.38 stream


diff --git a/bundles/org.eclipse.ui.workbench/META-INF/MANIFEST.MF b/bundles/org.eclipse.ui.workbench/META-INF/MANIFEST.MF
index 31364b7f1a..f865a2a1f0 100644
--- a/bundles/org.eclipse.ui.workbench/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.ui.workbench/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.ui.workbench; singleton:=true
-Bundle-Version: 3.136.0.qualifier
+Bundle-Version: 3.136.100.qualifier
 Bundle-Activator: org.eclipse.ui.internal.WorkbenchPlugin
 Bundle-ActivationPolicy: lazy
 Bundle-Vendor: %providerName
-- 
2.51.0

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

[tobiasmelcher]

thanks a lot @iloveeclipse for merging the pull request