Navigation problems in IDEApplication from External Plug-in Libraries project

[trancexpress]

If I have org.eclipse.swt.gtk.linux.x86_64 imported from the SWT repo, I see navigation problems in IDEApplication, when opened from the External Plug-in Libraries project.

If I go to IDEApplication.start() and I try to open Display, it opens a class in the JDK, not in SWT. Also I cannot Ctrl+left click checkInstanceLocation in this line, to navigate to the definition of the method:

			Object instanceLocationCheck = checkInstanceLocation(shell, appContext.getArguments());

Sometimes I see also broken syntax highlighting. This is not the only class in which I run into such problems as of late.

See screen recording:

vokoscreenNG-2026-03-23_16-06-35.mp4

I see this in e.g. a new workspace with:

Eclipse SDK
Version: 2026-06 (4.40)
Build id: I20260321-1800

To have the External Plug-in Libraries project, Ctrl+3 and use: "Add All Plug-ins to Java Workspace Scope"

Importing org.eclipse.swt.gtk.linux.x86_64 from the running platform also causes the issue.

[trancexpress]

Reproducible as far back as:

Eclipse SDK
Version: 2021-09 (4.21)
Build id: I20210906-0500

[merks]

It works for me on the latest SDK version on Windows:

Version: 2026-06 (4.40)
Build id: I20260321-1800

It seems strange it would be OS-specific. I guess it could be a JDT issue? But I can only guess...

[trancexpress]

There are other problems too, e.g. code around org.eclipse.ui.workbench has no syntax highlighting and I can't open the definition of WorkbenchPlugin:

Only if I have the org.eclipse.ui.workbench project open.

I'm not sure what the bug is, I'll try to debug. F3 at least shows "current selection cannot be opened in an editor`, which is a start.

[laeubi]

@trancexpress please show the expanded "Plug-in Dependencies" container. These are exactly the kind of problems you will face when the classpath is missing a (transitive) dependency so I suspect something must be different between yours and that from @merks ...

[merks]

What happens when you do Ctrl-Shift-T like this:

In the past I used to have to do this:

But now that seems to have already been done when I created this IDE setup with Oomph just now.

[trancexpress]

please show the expanded "Plug-in Dependencies" container

External Plug-in Libraries doesn't have a plug-in dependencies container, neither does org.eclipse.swt.gtk.linux.x86_64.

For org.eclipse.ui.workbench its:

container.txt

I notice I still have a platform I set for tests... when using the running platform as target platform, the container has:

container_running_platform.txt

Highlighting got worse, but the navigation works for WorkbenchPlugin:

For Display its still wrong and for checkInstanceLocation() it still doesn't work.

What happens when you do Ctrl-Shift-T like this:

Could it be that the Windows JDK doesn't have a Display type? I'm not familiar with JRE/JDK builds on Windows.

[merks]

Yes, I don't see such things in my JDK. I would think they shouldn't be visible....

[trancexpress]

org.apache.felix.gogo.shell.Shell is opened when I try to open the declaration of Shell. Which is likely why the navigation for checkInstanceLocation() doesn't work.

Debugging OpenAction, at:

"main" #1 [229641] prio=6 os_prio=0 cpu=26806.61ms elapsed=379.40s tid=0x00007f0ed401bb70 nid=229641 runnable  [0x00007f0ed91fa000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.jdt.ui.actions.OpenAction.run(OpenAction.java:143)
        at org.eclipse.jdt.ui.actions.SelectionDispatchAction.dispatchRun(SelectionDispatchAction.java:278)
        at org.eclipse.jdt.ui.actions.SelectionDispatchAction.run(SelectionDispatchAction.java:252)
        at org.eclipse.jface.action.Action.runWithEvent(Action.java:474)

input is:

IDEApplication.class [in org.eclipse.ui.internal.ide.application [in /data/eclipses/eclipseSDK_latest/plugins/org.eclipse.ui.ide.application_1.6.0.v20251217-1052.jar]]
  class IDEApplication

Then, when org.eclipse.swt.gtk.linux.x86_64 is open, elements is:

[class Shell {key=Lorg/apache/felix/gogo/shell/Shell;} [in Shell.class [in org.apache.felix.gogo.shell [in /data/eclipses/eclipseSDK_latest/plugins/org.apache.felix.gogo.shell_1.1.4.jar]]]]

When org.eclipse.swt.gtk.linux.x86_64 is closed, its:

[class Shell {key=Lorg/eclipse/swt/widgets/Shell;} [in Shell.class [in org.eclipse.swt.widgets [in /data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.gtk.linux.x86_64_3.134.0.v20260317-1422.jar]]]]

Diff between the classpath container of External Plug-in Libraries when org.eclipse.swt.gtk.linux.x86_64 is close (left) and open (right):

@@ -689,7 +689,6 @@
 /data/eclipses/eclipseSDK_latest/plugins/org.eclipse.search.core.source_3.16.600.v20250920-0652.jar[CPE_LIBRARY][K_BINARY][sourcePath:/data/eclipses/eclipseSDK_latest/plugins/org.eclipse.search.core.source_3.16.600.v20250920-0652.jar][isExported:false]
 /data/eclipses/eclipseSDK_latest/plugins/org.eclipse.search.source_3.19.0.v20260318-1629.jar[CPE_LIBRARY][K_BINARY][sourcePath:/data/eclipses/eclipseSDK_latest/plugins/org.eclipse.search.source_3.19.0.v20260318-1629.jar][isExported:false]
 /data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.gtk.linux.x86_64.source_3.134.0.v20260317-1422.jar[CPE_LIBRARY][K_BINARY][sourcePath:/data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.gtk.linux.x86_64.source_3.134.0.v20260317-1422.jar][isExported:false]
-/data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.gtk.linux.x86_64_3.134.0.v20260317-1422.jar[CPE_LIBRARY][K_BINARY][sourcePath:/data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.gtk.linux.x86_64.source_3.134.0.v20260317-1422.jar][isExported:false]
 /data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.svg.source_3.132.100.v20260312-0625.jar[CPE_LIBRARY][K_BINARY][sourcePath:/data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.svg.source_3.132.100.v20260312-0625.jar][isExported:false]
 /data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.svg_3.132.100.v20260312-0625.jar[CPE_LIBRARY][K_BINARY][sourcePath:/data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.svg.source_3.132.100.v20260312-0625.jar][isExported:false]
 /data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.tools.source_3.112.0.v20260305-0656.jar[CPE_LIBRARY][K_BINARY][sourcePath:/data/eclipses/eclipseSDK_latest/plugins/org.eclipse.swt.tools.source_3.112.0.v20260305-0656.jar][isExported:false]

The container entry is:

	<classpathentry kind="con" path="org.eclipse.pde.core.externalJavaSearch"/>

Odd that JDT does anything at all in that case... The byte code should have fully qualified references to org.eclipse.ui.internal.ide.application.Shell... I'll open an issue also at JDT when I find time to create a minimal reproducer. There should be no type opened given the classpath that PDE is providing. Maybe the open action has some relaxed search rules for whatever reason...

As for the PDE classpath itself, I'm not sure why its different when org.eclipse.swt.gtk.linux.x86_64 is open. Next thing to find out here. Maybe there is some sort of mismatch going on, considering how having org.eclipse.ui.workbench as source in my workspace and a target platform with a different version of it also caused an issue.

[trancexpress]

The container is skipping entries found in the workspace: org.eclipse.pde.internal.core.SearchablePluginsManager.computeContainerClasspathEntries()

boolean addModel = Arrays.stream(entry.getWorkspaceModels())
		.map(IPluginModelBase::getUnderlyingResource).map(IResource::getProject)
		.noneMatch(PluginProject::isJavaProject);
if (!addModel) {
	continue;
}

For WorkbenchPlugin the container org.eclipse.pde.core.externalJavaSearch is also missing org.eclipse.ui.workbench.

But, JDT seems to do a 2nd attempt for WorkbenchPlugin, due to not finding anything the first time.

This is the first scope, it contains only what the PDE container has:

"ModalContext" #327 [271550] prio=6 os_prio=0 cpu=15.07ms elapsed=20.83s tid=0x00007fc54b6d30e0 nid=271550 at breakpoint [0x00007fc490238000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.jdt.internal.core.search.PatternSearchJob.<init>(PatternSearchJob.java:82)
        at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:1970)
        at org.eclipse.jdt.internal.core.SearchableEnvironment.findTypes(SearchableEnvironment.java:780)
        at org.eclipse.jdt.internal.core.SearchableEnvironment.findTypes(SearchableEnvironment.java:618)
        at org.eclipse.jdt.internal.core.SearchableEnvironment.findTypes(SearchableEnvironment.java:597)
        at org.eclipse.jdt.internal.codeassist.SelectionEngine.select(SelectionEngine.java:1050)
        at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:171)
        at org.eclipse.jdt.internal.core.ClassFile.codeSelect(ClassFile.java:120)
        at org.eclipse.jdt.internal.core.AbstractClassFile.codeSelect(AbstractClassFile.java:116)
        at org.eclipse.jdt.internal.ui.actions.SelectionConverter.codeResolve(SelectionConverter.java:269)
        at org.eclipse.jdt.internal.ui.actions.SelectionConverter$1CodeResolveRunnable.lambda$0(SelectionConverter.java:253)
        at org.eclipse.jdt.internal.ui.actions.SelectionConverter$1CodeResolveRunnable$$Lambda/0x00007fc4d0dbae38.call(Unknown Source)
        at org.eclipse.jdt.internal.core.JavaModelManager.cacheZipFiles(JavaModelManager.java:5718)
        at org.eclipse.jdt.internal.core.JavaModelManager.callReadOnly(JavaModelManager.java:5707)
        at org.eclipse.jdt.core.JavaCore.callReadOnly(JavaCore.java:6211)
        at org.eclipse.jdt.internal.ui.actions.SelectionConverter$1CodeResolveRunnable.run(SelectionConverter.java:253)
        at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:123)

This is the 2nd scope, its the workspace scope:

"ModalContext" #327 [271550] prio=6 os_prio=0 cpu=18.12ms elapsed=43.22s tid=0x00007fc54b6d30e0 nid=271550 at breakpoint [0x00007fc490238000]
   java.lang.Thread.State: RUNNABLE
        at org.eclipse.jdt.internal.core.search.PatternSearchJob.<init>(PatternSearchJob.java:82)
        at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:1970)
        at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllTypeNames(BasicSearchEngine.java:1797)
        at org.eclipse.jdt.internal.codeassist.SelectionEngine.findAllTypes(SelectionEngine.java:853)
        at org.eclipse.jdt.internal.codeassist.SelectionEngine.select(SelectionEngine.java:1058)
        at org.eclipse.jdt.internal.core.Openable.codeSelect(Openable.java:171)
        at org.eclipse.jdt.internal.core.ClassFile.codeSelect(ClassFile.java:120)
        at org.eclipse.jdt.internal.core.AbstractClassFile.codeSelect(AbstractClassFile.java:116)
        at org.eclipse.jdt.internal.ui.actions.SelectionConverter.codeResolve(SelectionConverter.java:269)
        at org.eclipse.jdt.internal.ui.actions.SelectionConverter$1CodeResolveRunnable.lambda$0(SelectionConverter.java:253)
        at org.eclipse.jdt.internal.ui.actions.SelectionConverter$1CodeResolveRunnable$$Lambda/0x00007fc4d0dbae38.call(Unknown Source)
        at org.eclipse.jdt.internal.core.JavaModelManager.cacheZipFiles(JavaModelManager.java:5718)
        at org.eclipse.jdt.internal.core.JavaModelManager.callReadOnly(JavaModelManager.java:5707)
        at org.eclipse.jdt.core.JavaCore.callReadOnly(JavaCore.java:6211)
        at org.eclipse.jdt.internal.ui.actions.SelectionConverter$1CodeResolveRunnable.run(SelectionConverter.java:253)
        at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:123)

For Display and Shell the search finds a match (jdk.internal.org.jline.utils.Display resp. org.apache.felix.gogo.shell.Shell) with the first scope. So there is no attempt done with the 2nd scope.

Copying qualified names in the Java editor yields other wrong results: org.eclipse.ui.internal.ide.application.Display, org.eclipse.ui.internal.ide.application.Shell

The JDT search is so relaxed due to using this pattern:

TypeDeclarationPattern: pkg<*>, enclosing<*>, type<workbenchplugin>, prefix match, case insensitive, generic full match, fine grain: none

org.eclipse.jdt.internal.codeassist.SelectionEngine.selectedIdentifier is what the user selected, SelectionEngine doesn't try to determine what the actual type is based on imports or other information:

// only reaches here if no selection could be derived from the parsed tree
// thus use the selected source and perform a textual type search
if (!this.acceptedAnswer) {
	this.nameEnvironment.findTypes(this.selectedIdentifier, false, false, IJavaSearchConstants.TYPE, this);

Probably this is the case due to the PDE classpath container not containing the type it searched for prior to this code, but I've not debugged that part of the code.

[trancexpress]

Makes me wonder if org.eclipse.pde.core.externalJavaSearch should add projects found in the workspace via JavaCore.newProjectEntry(IPath)... If we can do this, we'll have to check if the type search finds double entries. Considering its a project dependency, probably it won't. I'll give it a shot when I find time, maybe it works without causing problems.