Community
Participate
Working Groups
build I20021127 - using the core spy tools, I restarted a workbench containing just the resource perspective (and spy tools perspective) with no editors open, although I had previously opened some Java files - the tools showed org.eclipse.jdt.ui and related plugins getting activated Here is the stack at the point of activation: Activating plugin: org.eclipse.jdt.ui Plugin activation stack: org.eclipse.jdt.ui Class loading stack: Stack trace: java.lang.Throwable at org.eclipse.core.internal.runtime.PluginStats.traceActivate (PluginStats.java:89) at org.eclipse.core.internal.runtime.PluginStats.startActivation (PluginStats.java:71) at org.eclipse.core.internal.plugins.PluginDescriptor.doPluginActivation (PluginDescriptor.java:187) at org.eclipse.core.internal.plugins.PluginClassLoader.activatePlugin (PluginClassLoader.java:59) at org.eclipse.core.internal.plugins.PluginClassLoader.internalFindClassParentsSel f(PluginClassLoader.java:137) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.findClassParentsSelf (DelegatingURLClassLoader.java(Compiled Code)) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass (DelegatingURLClassLoader.java:880) at org.eclipse.core.internal.boot.DelegatingURLClassLoader.loadClass (DelegatingURLClassLoader.java:860) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension (PluginDescriptor.java:130) at org.eclipse.core.internal.plugins.PluginDescriptor.createExecutableExtension (PluginDescriptor.java:167) at org.eclipse.core.internal.plugins.ConfigurationElement.createExecutableExtensio n(ConfigurationElement.java:103) at org.eclipse.ui.internal.WorkbenchPlugin$1.run (WorkbenchPlugin.java:116) at org.eclipse.swt.custom.BusyIndicator.showWhile (BusyIndicator.java:65) at org.eclipse.ui.internal.WorkbenchPlugin.createExtension (WorkbenchPlugin.java:113) at org.eclipse.ui.internal.WorkbenchPlugin.getElementFactory (WorkbenchPlugin.java:229) at org.eclipse.ui.internal.EditorHistoryItem.restoreState (EditorHistoryItem.java:61) at org.eclipse.ui.internal.EditorHistory.restoreState (EditorHistory.java:122) at org.eclipse.ui.internal.Workbench.restoreState(Workbench.java:1214) at org.eclipse.ui.internal.Workbench.access$7(Workbench.java:1200) at org.eclipse.ui.internal.Workbench$8.run(Workbench.java:838) at org.eclipse.core.internal.runtime.InternalPlatform.run (InternalPlatform.java:843) at org.eclipse.core.runtime.Platform.run(Platform.java:413) at org.eclipse.ui.internal.Workbench.openPreviousWorkbenchState (Workbench.java:790) at org.eclipse.ui.internal.Workbench.init(Workbench.java:603) at org.eclipse.ui.internal.Workbench.run(Workbench.java:1346) at org.eclipse.core.internal.boot.InternalBootLoader.run (InternalBootLoader.java:841) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462) at java.lang.reflect.Method.invoke(Native Method) at org.eclipse.core.launcher.Main.basicRun(Main.java:247) at org.eclipse.core.launcher.Main.run(Main.java:703) at org.eclipse.core.launcher.Main.main(Main.java:539) We need to avoid activating plugins simply to present the editor history. The plugin should only be activated if an editor history item is chosen. We should persist the name of the item separately if needed.
This can be worked around, allowing one to look at other plugin activation problems, by setting the history length to 0 in the Editors preference page.
A test for whether or not the IEditorInput exists is used to determine whether or not an item is stale - if it is stale it is removed from the MRU list. Similarly, when an item is added to the history, any other instance of the item is removed from the list. Whether or not there is another item instance is determined by comparing the editor inputs to see if they are equal. For these two cases, since editor input may not be restored, need to compare IEditorInput name, tooltiptext, and factoryId and these items should be stored separately so that the comparison can take place without restoring the whole editor input. Need to use IResourceChangedListener to track when to remove stale items. Need to change refreshItems to only look at restored editor inputs.
I think we should use the same idea we used for NavigationHistorEntry. We save enough information to restore the item. If the resource is deleted if fails to open when/if the user selects that item and at that moment we can remove the item from the menu. Remember that it is a list of editors not resources. And editors do not map to resources.
*** Bug 27308 has been marked as a duplicate of this bug. ***
Made the changes to avoid creating the editor input eagerly (only when item is selected). It compares (name, toolTipText, factoryId) when trying to match items. I did not add a workspace listener to eagerly prune items. It still prunes when shown, but only checks those items that have been restored. Also made a couple of tweaks to the name display (don't consider toolTipText as a path if it matches the name -- a common case, e.g. for repository files). Tested with workspace files, repository files, external class files, and combinations thereof, both when restored and not restored (except for repository files, which aren't persisted).
I can't even reproduce this in 20021127 much less verify that it's fixed. I have three .java files in the editor history but the jdt.ui plug-in is not activated on startup.
.java files use FileEditorInput. To reproduce the original problem, you need to open a .class file in an external jar.
Verified fixed in build 20021216
