Wait for deferred PDE classpath initializer before initial reconcile

[merks]

• This avoids the display the transient error annotations that are the result of PDE's deferring classpath initialization to a background job.

See eclipse-pde/eclipse.pde#1888 for related details.

---

I acknowledge that there may well exist better solutions and I am willing to help review such alternative solutions in the future.

My hope is that we can make this low-risk comprise change for m2 so that I can fully test tomorrows SDK build in real-life scenarios tomorrow, before the final m2 build, where I currently always see error annotation in open editors on startup; ones that do not go away, although I do believe that the "do not go away problem" has been solved. So the remaining problem (transient annotation that this PR addresses is definitely far less nasty.

In any case, of course I respect the decisions of the project committers whatever those decisions may be. We're one big team and have the same goals in mind, i.e., high quality software.

[laeubi]

@merks I think InitializeAfterLoadJob should also belong to the group ClasspathContainerInitializer.class now (as well as its RealJob) even though these are started as part of loading the editor, there is no guarantee the complete before the editor start to reconcile and might be running still.

[merks]

@merks I think InitializeAfterLoadJob should also belong to the group ClasspathContainerInitializer.class now (as well as its RealJob) even though these are started as part of loading the editor, there is no guarantee the complete before the editor start to reconcile and might be running still.

I did experiment with waiting for that job too but it had no impact on the visual outcome/behavior. This job has always just run separately in the background, and adding it to the family will tend to contribute to @iloveeclipse’s concerns about delays for all Java editors including for scenarios where things have apparently worked fine without a delay and do not involve PDE.

So while logically what you suggest seems appropriate and sensible, conservatively it’s probably better not to fix/change something where we have not demonstrated an actual problem that the change solves.

[merks]

@iloveeclipse

FYI, I tested setting up my normal Oomph IDE based on the Eclipse SDK from last night. That version (the top one) consistently restarts in a clean state while the M1 version (the bottom one) always comes up with errors:

So these changes do look properly functional now. (And of course the editor shows errors when one introduces them.)

Thank you and @laeubi both for the your contributions to this improved result.