Type Hierarchy has duplicated entries (classes) and one of them is incomplete

[fedejeanne]

Sometimes when I get the Type Hierarchy of a given class, I get duplicated entries.

In the following screenshot you can see duplicated entries of AbstractCustomDispatch.

I copied the fully qualified name of both classes and noticed that the entry on the top is inside a fictional package that has an additional src. right at the beginning. The real package starts with aq.

Additional info

1. AbstractCustomDispatch and all of its subclasses are ours i.e. they are present in the workspace as source code.
2. The subclasses are in different plugins

---

---

---

3. The methods of the AbstractCustomDispatch that is found under src.aq... (and the methods of its subclasses) are missing 👎

4. The methods of the AbstractCustomDispatch that is found under aq... (and the methods of its subclasses) are there 👍

I am not able to consistently reproduce the error but I just happen to run into it today and I started debugging.

Current findings

My assumption is that the type AbstractCustomDispatch is still not completely discovered by the time its first 3 subclasses are being populated and it is completely known (and it's known to be in the workspace) by the time the rest of its subclasses are being computed.

I set a breakpoint in here

eclipse.jdt.core/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/hierarchy/HierarchyResolver.java

Line 605 in 1ec8da7

superclass = findSuperClass(suppliedType, typeBinding);

And noticed that the return values of findSuperClass(suppliedType, typeBinding) are different for some subclasses.

For example here are the parameters and the result of the call when analyzing CloseKeyEventDispatch (which is one of the 3 subclasses that is missing the methods in a previous screenshot👎 )

And here's how it looks when analyzing CutAndCopyDispatchReplacement (which is one of the subclasses that has all its methods in the hierarchy view 👍): members are there and AbstractCustomDispatch does not show (not open) anymore.

[fedejeanne]

Any hints about how to proceed are highly appreciated. I'm out of my depth here.

[fedejeanne]

I was able to trace the problem all the way back to the existence of 2 very similar instances of PackageFragmentRoot inside the JavaProject with name aq.openoffice.api

This is the current stack trace:

Thread [Worker-1288: Computing type hierarchy of 'AbstractCustomDispatch - {vi}.openoffice.api.dispatch'...] (Suspended (breakpoint at line 393 in HandleFactory))	
	owns: TypeHierarchy  (id=23766)	
	HandleFactory.getPkgFragmentRoot(String) line: 393	
	HandleFactory.createOpenable(String, IJavaSearchScope) line: 134	
	IndexBasedHierarchyBuilder.buildFromPotentialSubtypes(String[], HashSet, IProgressMonitor) line: 324	
	IndexBasedHierarchyBuilder.build(boolean) line: 152	
	TypeHierarchy.compute() line: 305	
	TypeHierarchy.refresh(IProgressMonitor) line: 1263	
	TypeHierarchyLifeCycle.doHierarchyRefresh(IJavaElement[], IProgressMonitor) line: 331	
	TypeHierarchyLifeCycle.doHierarchyRefreshBackground(IJavaElement[], IProgressMonitor) line: 272	
	TypeHierarchyLifeCycle$1.run(IProgressMonitor) line: 225	
	Worker.run() line: 63	

An easy fix is to consistently favor one of those entries over the other e.g. doing it like this in order to favor source entries (the Nr. 2, marked in green in the screenshot above).

diff --git a/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/util/HandleFactory.java b/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/util/HandleFactory.java
index 7f78e67..d2bdb3a 100644
--- a/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/util/HandleFactory.java
+++ b/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/util/HandleFactory.java
@@ -381,6 +381,7 @@
 
 		IPath path= new Path(pathString);
 		IProject[] projects= ResourcesPlugin.getWorkspace().getRoot().getProjects();
+		PackageFragmentRoot secondBest = null;
 		for (IProject project : projects) {
 			try {
 				if (!project.isAccessible()
@@ -390,7 +391,12 @@
 				for (IPackageFragmentRoot r : roots) {
 					PackageFragmentRoot root= (PackageFragmentRoot)r;
 					if (root.internalPath().isPrefixOf(path) && !Util.isExcluded(path, root.fullInclusionPatternChars(), root.fullExclusionPatternChars(), false)) {
-						return root;
+						// Favor source folders
+						if (root.getKind() == IPackageFragmentRoot.K_SOURCE) {
+							return root;
+						}
+						// otherwise remember it as second best choice
+						secondBest = root;
 					}
 				}
 			} catch (CoreException e) {
@@ -398,7 +404,7 @@
 				// JavaModelException from getPackageFragmentRoots - a problem occured while accessing project: nothing we can do, ignore
 			}
 		}
-		return null;
+		return secondBest;
 	}
 
 }

If I do that then the other entry (the <project root>, marked in red in the screenshot above) is not used and the error doesn't happen since there is no duplicated AbstractCustomDispatch class, only the one whose FQN does not contain src..

[fedejeanne]

Question: why is there a PackageFragmentRoot of type <project root> in there in the first place? I am trying to reproduce the error in a fresh workspace but I can't manage to insert the <project root> in the JavaProject instance.

Does anyone know how to achieve that?

[fedejeanne]

I just happened to run into another exception that seems to originate from the same wrong misconception

Here's where the problem is found:

eclipse.jdt.core/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/CompilationUnit.java

Lines 1214 to 1215 in 1ec8da7

	if (root.getKind() != IPackageFragmentRoot.K_SOURCE)
	return new JavaModelStatus(IJavaModelStatusConstants.INVALID_ELEMENT_TYPES, root);

Here's the current stack-trace:

Stack-trace

Thread [org.eclipse.jdt.internal.ui.text.JavaReconciler] (Suspended)	
	CompilationUnit.validateCompilationUnit(IResource) line: 1215	
	CompilationUnit.validateExistence(IResource) line: 1525	
	CompilationUnit(Openable).generateInfos(IElementInfo, Map<IJavaElement,IElementInfo>, IProgressMonitor) line: 236	
	ResolvedSourceType(SourceRefElement).generateInfos(IElementInfo, Map<IJavaElement,IElementInfo>, IProgressMonitor) line: 127	
	ResolvedSourceType(JavaElement).openWhenClosed(IElementInfo, boolean, IProgressMonitor) line: 571	
	ResolvedSourceType(JavaElement).getElementInfo(IProgressMonitor) line: 294	
	ResolvedSourceType(JavaElement).getElementInfo() line: 280	
	ResolvedSourceType(SourceType).getAnnotations() line: 222	
	4 collapsed frames	
	QualifiedName.accept0(ASTVisitor) line: 159	
	QualifiedName(ASTNode).accept(ASTVisitor) line: 3312	
	ImportDeclaration(ASTNode).acceptChild(ASTVisitor, ASTNode) line: 3360	
	ImportDeclaration.accept0(ASTVisitor) line: 305	
	ImportDeclaration(ASTNode).accept(ASTVisitor) line: 3312	
	CompilationUnit(ASTNode).acceptChildren(ASTVisitor, ASTNode$NodeList) line: 3383	
	CompilationUnit.accept0(ASTVisitor) line: 256	
	CompilationUnit(ASTNode).accept(ASTVisitor) line: 3312	
	2 collapsed frames	
	ReconcileWorkingCopyOperation$1.run() line: 315	
	SafeRunner.run(ISafeRunnable) line: 47	
	ReconcileWorkingCopyOperation.notifyParticipants(CompilationUnit) line: 300	
	ReconcileWorkingCopyOperation.executeOperation() line: 113	
	ReconcileWorkingCopyOperation(JavaModelOperation).run(IProgressMonitor) line: 751	
	ReconcileWorkingCopyOperation(JavaModelOperation).runOperation(IProgressMonitor) line: 816	
	CompilationUnit.reconcile(int, int, WorkingCopyOwner, IProgressMonitor) line: 1431	
	JavaReconcilingStrategy.reconcile(ICompilationUnit, boolean) line: 132	
	JavaReconcilingStrategy$1.run() line: 94	
	SafeRunner.run(ISafeRunnable) line: 47	
	JavaReconcilingStrategy.reconcile(boolean) line: 91	
	JavaReconcilingStrategy.reconcile(IRegion) line: 158	
	JavaCompositeReconcilingStrategy(CompositeReconcilingStrategy).reconcile(IRegion) line: 94	
	JavaCompositeReconcilingStrategy.reconcile(IRegion) line: 107	
	JavaReconciler(MonoReconciler).process(DirtyRegion) line: 77	
	AbstractReconciler$BackgroundWorker.run() line: 201	
	2 collapsed frames	

Does anyone know how could I create this "bad PackageFragmentRoot" (or the "bad CompilationUnit") that contains the src. as the name of the package and/or has a Kind == 2 (K_BINARY)?

I can only see this which might be related to the Kind == K_BINARY (that library is the only one without a source attachment):

The rest of the configuration does not look suspicious to me:

More configurations (Screenshots)

---

---

---

[fedejeanne]

The problem are these 2 libraries

• java_uno.jar
• libreoffice.jar

They include ../ in their classpaths:

... which ends up adding the folder aq.openoffice.api/lib/../ to the classpath of the whole WS (org.eclipse.jdt.internal.core.JavaModelManager.PerProjectInfo.resolvedClasspath) and ends up creating the infamous PackageFragmentRoot whose sources are in the / folder (and therefore, whose packages start with src.).

More precisely, calling org.eclipse.jdt.internal.core.ClasspathEntry.resolvedChainedLibraries() in here:

eclipse.jdt.core/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/JavaProject.java

Line 3210 in 2875481

ClasspathEntry[] extraEntries = cEntry.resolvedChainedLibraries();

... yields this problematic ClasspathEntry (even twice because there are 2 "bad" JARs):

/aq.openoffice.api/[CPE_LIBRARY][K_BINARY][isExported:true]

... which means in plain English "The folder aq.openoffice.api (root folder of that plugin) is a binary library and it belongs to the classpath".

[fedejeanne]

My quick workaround was to simply bury the libraries deeper so that the root folder is not added to the classpath, namely from aq.openoffice.api/lib/ --> aq.openoffice.api/lib/uno/. This ends up adding aq.openoffice.api/lib/ to the classpath which (is wrong but) doesn't break anything.

I proposed a PR to at least let the user know that a library is adding dubious entries to the class-path.

[iloveeclipse]

The problem are these 2 libraries

They include ../ in their classpaths:

Yeah. Constant PITA for anyone with such messy manifests. "Works on my machine". Ideally this should be fixed at the root cause (projects producing such libraries).

See my comment of related ticket.

If you are interested in a fix, probably one could add some jdt IDE option to ignore any "open end" classpath entries during compilation in the IDE. ECJ compiler seem to ignore them anyway since ever.

[fedejeanne]

If you are interested in a fix, probably one could add some jdt IDE option to ignore any "open end" classpath entries during compilation in the IDE. ECJ compiler seem to ignore them anyway since ever.

I would go as far as saying we should ignore the Class-Path entry in the manifest altogether during compile time. I don't really want my code being able to compile just because some 3rd-party library just happened to add some extra dependency to the classpath, I want my code to not compile until I explicitly add all the libraries that I need. Run time is a different story though: I want my application to run without having to explicitly add all necessary dependencies of all my 3rd-party libraries (which is why we have tools like maven to assemble products and ship every single needed JAR in the first place).

Sadly I wasn't able to find the cut between classpath for compilation time vs classpath for run time in the code. The names of the packages and the methods didn't help.

Any hints?

[iloveeclipse]

Any hints?

Following my comment you would see two bugs, and one of them has a link to the original bug that implemented IDE support for that feature.

[iloveeclipse]

Quoting myself how crazy it could be:

We had a case where root file system was entirely on classpath because of manifest pointing to ../../ directory

[fedejeanne]

Thank you for the hints @iloveeclipse ! I see this has been a topic for quite a few years now. I also noticed that you also discussed the behavior for the JVM (java) and the compiler (javac / ecj), which is what I meant by run time (JVM) and compile time (compiler).

I'll try to return to this topic once time allows it and I will simply continue in this issue to avoid scattering:

• compiler.batch.FileSystem.getClasspath() may return ClasspathJar for non existing classpath entry #258

[iloveeclipse]

See #4843. Let see how many JDT tests will fail now :-)