Restore the type from class file input in the background

[laeubi]

This is just a draft to show the code.

[iloveeclipse]

I had finally time to look at that. This should solve the original problem to 90% (shows the code if type is on classpath, shows disassembled code if not and shows some error otherwise).

There is a bug in case the type is on classpath but in another jar file, because editor tries to re-set the input from the wrong thread. That must be fixed, see below where.

Remaining 10% could be done later on, these would be mostly side-effects after re-init & editor input change:

• the Java editor breadcrumb is disconnected (shows empty space)
• link with ediktor doesn't work and activating restored class file editor does not expand/navigate to the right packages in the jar file in the Package explorer
• same as above: opening type from restored editor opens new class file editor

These issues could be fixed later on, I assume.

[iloveeclipse]

Thanks for looking into this, if you are confident it goes in the right direction I would ask to merge

• ClassFileEditor is not restored leading to ClassFileEditorInputFactory returned null error #2371

This is a ticket, not a PR. Do you mean first commit of this PR?

[laeubi]

Sorry that should be this one:

• Move the relocation code from the factory to the ClassFileEditor #2379

[iloveeclipse]

Sorry that should be this one:

I've fixed & merged that PR and rebased this PR unchanged (just squashed) on top of master. I will try to review this PR soon.

[iloveeclipse]

Unfortunately I've not tested good enough #2379, the case where the class is missing because jar is deleted, not just updated (like IBuild update to next one but without keeping the old one on the disk) is not handled properly and results again in an ugly error shown in the editor.

I will push some changes now, where I'm unhappy because it reports too many errors to the log while JDT UI is trying to access missing class file before the input is updated and right class file is found.

[laeubi]

@iloveeclipse if you want I can try to split up some parts already to make the PR smaller, for example the change in

org.eclipse.jdt.ui/ui/org/eclipse/jdt/internal/ui/javaeditor/ClassFileDocumentProvider.java

seems isolated enough to be merged independently together with:

https://github.com/eclipse-jdt/eclipse.jdt.ui/pull/2380/files#diff-acebf6e389acb8ba7fcd6a44dc1d9ae09dc08102d84bcdfb0c304334be26ea0fR869

[iloveeclipse]

With latest patch set I've adressed the problems:

• we again rely on async PDE jobs and have no chance if they run in parallel, so I've added model listener again.
• breadcrumb init need to happen again on class editor input change if it was not properly initialized before.
• don't log errors about missing jar files in various UI places (decorator, breadcrumb etc), editor already shows the message that class is not found. This requires Provide proper ELEMENT_DOES_NOT_EXIST code on missing jar files eclipse.jdt.core#4270.

[laeubi]

@iloveeclipse good to see you are making good progress here, I initially opened it as a POC because it really only showed a very rough idea and I'm not familiar with all the JDT details it looks much better now already.

we again rely on async PDE jobs and have no chance if they run in parallel, so I've added model listener again.

I think this is actually the right approach anyways, as classpath changes can happen anytime, e.g. target platform gets reloaded, Manifests change (either by user or due to switching branches), so if this can be detected (and handled) that's really great. I can't tell ho often I have to manually fixup things (closed projects, broken editor states also sometimes failed target resolutions) when switching / syncing branches.

[laeubi]

By the way with latest ibuild is see zero "async" changes when restarting the Eclipse SDK workbench, but is see different component access the java model what leads to loading the container from different threads (before the Initializing Java Tooling kicks in), I have created

• BuildpathIndicatorLabelDecorator access the Java model before initialization #2393

for one observed case, I also have seen this for Override indicator installation job but was not yet able to capture a stack trace.

[iloveeclipse]

By the way with latest ibuild is see zero "async" changes when restarting the Eclipse SDK workbench

This still happens if the target platform is modified, so jar on PDE classpath changes the version for example.
In that case the update happens asynchronously.

[laeubi]

This still happens if the target platform is modified, so jar on PDE classpath changes the version for example.
In that case the update happens asynchronously.

Yes this is expected. PDE always restore the last state from where it shut down and then check if anything has changed in the background.

[iloveeclipse]

LGTM for me.

@laeubi : please review my changes.

I will wait for your review before merging.

[laeubi]

It all looks good to me.