Bug 576970 - Spurious JDT Type Hierarchy duplicate entries
Summary: Spurious JDT Type Hierarchy duplicate entries
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 4.22   Edit
Hardware: PC Windows 10
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard: stalebug
Keywords:
Depends on:
Blocks:
 
Reported: 2021-10-30 04:15 EDT by Ed Willink CLA
Modified: 2023-10-26 01:46 EDT (History)
1 user (show)

See Also:


Attachments
screenshot (25.47 KB, image/png)
2021-10-30 04:15 EDT, Ed Willink CLA
no flags Details
Pruned Zipped Workspace .metadata (34.32 MB, application/octet-stream)
2021-11-03 07:37 EDT, Ed Willink CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ed Willink CLA 2021-10-30 04:15:58 EDT
Created attachment 287405 [details]
screenshot

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

The attached type hierarchy of IResource shows multiple IFile and IContainer and ...

Surely there can only be one IContainer?

Why doesn't hovertext expain where they come from and why thet are different?

(The Target platform is the Running Platform so a multiple from a different target cannot explain one extra.)

Using Show In Package Explorer reveals that each duplicate comes from the same plugin. Since this plugin is a Plugin-in Dependency, surely the Type Hierarchy should eother show many tens of duplicates if each plugin is separate, or just one, if usefully duplicate references are filtered.

(Possibly a duplicate of Bug 566289 for C++.)
Comment 1 Andrey Loskutov CLA 2021-11-02 17:57:17 EDT
Could you reproduce in a new workspace / fresh Eclipse install (no updates)? If yes, please add steps to reproduce. I assume the types are from different plugins, may be running platform is in broken state.
Comment 2 Ed Willink CLA 2021-11-03 07:37:03 EDT
Created attachment 287435 [details]
Pruned Zipped Workspace .metadata

(In reply to Andrey Loskutov from comment #1)
> Could you reproduce

Reproduces in the, probably same, still live workspace that did not have IResource in its Type Hierarchy history. Reproduces when Restarting and auto-restoring the Type Hierarchy.

Strangely the Type Hierarchy View has no Close icon so I cannot Close and force a New Type Hierarchy. Package Explorer has also lost its close icon. Detach, close, new Type Hierarchy restores still bad. Detach, Close, Restart Eclipse, New Type Hierarchy sill restores the bad duplicates.

> may be running platform is in broken state.

Almost certainly. Probably a side effect of the 'mapping' of a plugin reference from each open project to a 'single' plugin. After building with my normal open projects, I opened org.eclipse.emf.ecore as a project (rather than plugin) and this perhaps gave the 'mapping' an opportunity to consider the references from org.eclipse.emf.ecore to be 'new' rather than shared.

However examining the inverse 'mapping' using Show in Package Explorer to identify the preferred plugin hosts, the three plugin projects are pretty unremarkable.

--

So yes there may be a broken platform analysis that persists over a Restart Eclipse; so presumably in the Workspace - attached. May be move to platform bug.

But there type hierarchy could certainly survive the duplicate.
Comment 3 Eclipse Genie CLA 2023-10-25 16:06:27 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 4 Ed Willink CLA 2023-10-26 01:46:53 EDT
I suspect that this is another symptom of the problem with a stale / broken Java index for which a manual rebuild of the index 'solves' the problem.

Perhaps Bug 576555 or https://github.com/eclipse-jdt/eclipse.jdt.core/issues/1179