Ensure forceReconciling is called after initialProcess if it was ignored

[merks]

What it does

Fixes #2074

How to test

See the issue and this PR:

eclipse-pde/eclipse.pde#1711

Basically in a self-hosted launch, create some plugin projects, leave an editor on one source file open, and restart.

Author checklist

• I have thoroughly tested my changes
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[merks]

@iloveeclipse

Is there any chance of getting this (with whatever changes you request) in for M1? Every IDE I open starts with errors and it would be great after M1 to see that problem go away...

[iloveeclipse]

Thanks.

[iloveeclipse]

If the JavaLeaktest fails on jenkins too (it might still work if generic editor is not there), please rebase on master, once #2130 is merged (will happen ASAP).

[merks]

@iloveeclipse

It looks like all the tests pass and #2130 is still running. Do you still want a rebase when that's done?

[iloveeclipse]

@iloveeclipse

It looks like all the tests pass and #2130 is still running. Do you still want a rebase when that's done?

No. It seem that tests on jenkins don't include generic editor bundle.

[iloveeclipse]

Thanks Ed, really appreciate that you've debugged all that mess with startup init.

[merks]

And I really appreciate your constructive suggestions, the review from @jjohnstn, and that this is merged for M1. Yeah!!! Thanks thanks!!

[Phillipus]

Doe this mean no more red errors at startup? Will test if so... :-)

[merks]

I'm not 100% sure if eclipse-pde/eclipse.pde#1711 is also needed to fix the problem but I think so... Maybe not... I tried a bunch of times without it and see the error appear and disappear...

[Phillipus]

I tested build I20250404-1800. I still see red error markers in Java editors on startup. They go away after a few seconds, but Eclipse never used to be like this. Is this intended behaviour?

[merks]

I’m not sure the value in repeating the months long history. Maybe best you dredge through it.

Quick summary. JDT asks for the classpath on the UI thread really early even when the job manager is not yet enabled to schedule jobs. PDE now guards against this deferring the computation to a background job. The computation typically takes several seconds if everything is cached. It could take minutes. There were issues filed complaining about extremely long freezes during startup. So now the startup does freeze but the editor reports errors during the former freeze period.

Is it intended that a long running task be done on the UI thread early during startup? Apparently so because no steps are being taken to avoid that. Of course I think it’s a hard problem so I’m not pointing fingers. I can only say that I’ve invested days of effort making it less horrible. Someone else will need to nip this problem at the source. No classpath initialization on the UI thread. That needs to stop and of course avoiding expensive IO and network traffic on the UI thread is always to be avoided at all cost. But I think the folks with the skills and insights are busy on other things.

[Phillipus]

@merks Thanks for the explanation, I appreciate it. 😄

I guess I'm still trying to further my understanding of why it all seemed to be working before this.

I can only say that I’ve invested days of effort making it less horrible.

I can see that and I appreciate your hard work (and all the the work that you've put into Eclipse over the years 💯 )

[merks]

The code wasn’t just changed for no good reason. There were issues opened about minute(s) long startup freezes with fingers pointing at PDE. But PDE cannot make the world spin faster.

As I said, it’s best to focus on fixing the problem at the origin rather than suggesting that PDE should start yet again resolving a target platform on the the UI thread because that mostly seemed OK except when it wasn’t. We should move forward.

It reminds me a bit of the horror of URI encoding where properly encoding a URI that was not being properly encoded previously breaks downstream code which assumed the URL was not encoded. The temptation is to revert the “breaking” change but it’s a death spiral where the problems just cannot and will not ever be fixed. This also has cost me more than a day of effort but was well invested nevertheless.

One really significant thing to note here is that this behavior literally on kicks in if and only if the job manager is suspended. That only is the case during the very earliest stages of bootstrapping the workbench. It’s even been suggested that we stop suspending the job manager to fix the problem. It seems any solution that doesn’t involve JDT avoiding to do arbitrarily expensive work at what is arguably an obscenely early point during startup is preferable. We really need to move toward a proper solution. I wish I were made of time. 😩

[Phillipus]

@merks Thank-you for taking the time to explain things further, I appreciate it. :-)

[merks]

I know who the people are who make Eclipse the great community that I love. 💕 You are high on that list! 🏅

[Phillipus]

I know who the people are who make Eclipse the great community that I love. 💕 You are high on that list! 🏅

Ah, man, that's high praise coming from you! (I've been developing on Eclipse since 2003. BTW - the greatest Eclipse framework ever is EMF).