[Performance] [UI Freeze] Changing a constructor triggered a import fix and a search

[fedejeanne]

Hello everyone,
I am looking into a performance issue reported by a colleague and I could use some help.

Details

• Full sample: UI-Freeze-2025-03.zip
• Eclipse Version: 4.35.0.I20250228-0140

The issue

The colleague reported that he merely changed the type of a parameter in a constructor (he went 2 levels up in the type hierarchy) and then he performed the same changes in 2 subclasses. When he changed the constructor in the 2nd subclass, the UI froze.

Example: from java.nio.channels.Channel to java.lang.AutoCloseable

Go from this:

import java.nio.channels.Channel;

public class A {
	public A(Channel s) {}
}

class B extends A {
	B(Channel s) {
		super(s);
	}
}

... to this:

public class A {
	public A(AutoCloseable s) {}
}

class B extends A {
	B(AutoCloseable s) {
		super(s);
	}
}

In our specific case, both interfaces belong to an automatically generated Metamodel which is very big, so the the super-interface (AutoCloseable in this example) has lots of sub-interfaces and implementations.

This is what I see in the sample (main thread):

Which tells me:

1. Changing the parameter type triggered an ImportsFix which in turn triggered a search
2. The main thread went to wait, which would explain the UI freeze

I wasn't (yet) able to deduce which is the other thread that is taking so much time.

Questions

• Why was the fix triggered? Was it so that the compiler can go through the callers of the constructor and then recompile the code? AFAIK this shouldn't be necessary since the changes should produce no new compile errors.

• Could it be that there is some other task (compilation, indexing, etc) meddling here and causing the freeze?

Thank you in advance for the help!

[fedejeanne]

Here's the chain of events as I understand them:

1. Changes occurred and the user saves the file (Ctrl + s)
2. The save actions trigger an Organize Imports (org.eclipse.jdt.internal.corext.fix.ImportsFix)
3. The Organize Imports needs to perform a pattern search, for which it needs to wait until all other jobs are finished (notice the usage of IJavaSearchConstants.WAIT_UNTIL_READY_TO_SEARCH here)
4. In the end, this reaches performConcurrentJob and ends up blocking here

My question is: wouldn't it be better (and possible) to have such expensive operations like fixing the imports working in a background thread and apply the changes to the current editor when they are ready?

I'm not familiar with the internals of this mechanism...

... but I assume that it means that changes made by the user while the organize imports was running in the background will be overwritten. If that's the case, one could simply block the editor (and just the editor) until the organize imports is ready.

WDYT?