Community
Participate
Working Groups
If I have the hierarchy: java.lang.Object package1.Super (from a.jar) package2.Subclass (from b.jar) package3.SubSubclass (from b.jar) In a prior build (I20071030-0010), if a.jar was missing from the build path I would still get package2.Subclass package3.SubSubclass However, in I20071212-0010, I only get: package3.SubSubclass. To reproduce: In the attached project take the type hierarchy (F4) for GrandChildClass. Note that it will give the full type hierarchy up to java.lang.Object. Now remove super.jar from the build path and refresh the type hierarchy (you may need to switch between the different type hierarchy modes to ensure the hierarchy gets recalculated). You will lose all super-class information for GrandChildClass even though it's immediate parent is available.
Created attachment 85434 [details] Used to demonstrate type hierarchy regression.
The attached project doesn't contain any jar and its .classpath contains references to jars on your C: drive. <?xml version="1.0" encoding="UTF-8"?> <classpath> <classpathentry kind="src" path="src"/> <classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/> <classpathentry kind="lib" path="C:/class.jar"/> <classpathentry kind="lib" path="C:/subclass.jar"/> <classpathentry kind="lib" path="C:/super.jar"/> <classpathentry kind="output" path="bin"/> </classpath>
Created attachment 85446 [details] The missing jar files
Created attachment 85575 [details] Proposed fix and regression test
Fix and test released for 3.4M5
This doesn't seem to completely fix the problem. In I20080115-1740 build (which appears to have had the patch applied), when I import jdt.core as source, set TypeHierarchy.DEBUG=true and add an e.printStackTrace to the suppressed catch statement at HierarchyResolver:569, I get the output attached at the bottom of this post. The resulting ITypeHierarchy doesn't list any superclasses or interfaces, even though in the logic at HierarchyResolver:553, it appears that supertype information is found when I step through in the debugger. When I set a breakpoint near the source of the issue, the problem reads in the debugger: Pb(324) The type javax.servlet.jsp.tagext.Tag cannot be resolved. It is indirectly referenced from required .class files The Tag type in question is an unresolved interface implemented by a super-class. Output from debug statements: CREATING SUPER TYPE HIERARCHY [Thread[main,6,main]] org.eclipse.jdt.internal.compiler.problem.AbortCompilation at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:121) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:179) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1806) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:3647) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.cacheMissingBinaryType(LookupEnvironment.java:180) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:52) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:101) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.superInterfaces(BinaryTypeBinding.java:951) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.findSuperInterfaces(HierarchyResolver.java:259) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.reportHierarchy(HierarchyResolver.java:514) at org.eclipse.jdt.internal.core.hierarchy.HierarchyResolver.resolve(HierarchyResolver.java:561) at org.eclipse.jdt.internal.core.hierarchy.HierarchyBuilder.buildSupertypes(HierarchyBuilder.java:115) at org.eclipse.jdt.internal.core.hierarchy.IndexBasedHierarchyBuilder.build(IndexBasedHierarchyBuilder.java:135) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.compute(TypeHierarchy.java:300) at org.eclipse.jdt.internal.core.hierarchy.TypeHierarchy.refresh(TypeHierarchy.java:1241) at org.eclipse.jdt.internal.core.CreateTypeHierarchyOperation.executeOperation(CreateTypeHierarchyOperation.java:90) at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:720) at org.eclipse.jdt.internal.core.JavaModelOperation.runOperation(JavaModelOperation.java:780) at org.eclipse.jdt.internal.core.BinaryType.newSupertypeHierarchy(BinaryType.java:802) at org.eclipse.jdt.internal.core.BinaryType.newSupertypeHierarchy(BinaryType.java:754) at org.eclipse.jst.jsf.common.internal.types.TypeInfoCache.getOrCreateTypeInfo(TypeInfoCache.java:296) at org.eclipse.jst.jsf.common.internal.types.TypeInfoCache.cacheSupertypesFor(TypeInfoCache.java:256) at org.eclipse.jst.jsf.designtime.internal.view.DTComponentIntrospector.isTypeNameInstanceOfClass(DTComponentIntrospector.java:261) at org.eclipse.jst.jsf.designtime.internal.view.model.jsp.analyzer.TagAnalyzer.getJSFComponentTagType(TagAnalyzer.java:719) at org.eclipse.jst.jsf.designtime.tests.views.model.jsp.TestTagAnalyzer.testGetJSFComponentTagType(TestTagAnalyzer.java:194) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62) at org.eclipse.pde.internal.junit.runtime.UITestApplication$1.run(UITestApplication.java:118) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:130) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3735) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3372) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2392) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2356) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2222) at org.eclipse.ui.internal.Workbench$4.run(Workbench.java:474) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:469) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:106) at org.eclipse.pde.internal.junit.runtime.UITestApplication.start(UITestApplication.java:52) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:106) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:76) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:362) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:175) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:564) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1251) at org.eclipse.equinox.launcher.Main.main(Main.java:1227) on type InputTextTag [in InputTextTag.class [in com.sun.faces.taglib.html_basic [in C:\cam\tomcat\apache-tomcat-5.5.15\server\lib\jsf-impl.jar]]] CREATED SUPER TYPE HIERARCHY in 141ms Focus: InputTextTag [in InputTextTag.class [in com.sun.faces.taglib.html_basic [in C:\cam\tomcat\apache-tomcat-5.5.15\server\lib\jsf-impl.jar]]] Super types: Sub types:
Are you saying that the test case from comment 1 is still failing using a pure I20080115-1740 build? If not, could you please provide a new test case that shows the problem?
Created attachment 87452 [details] JUnit test case
To use the example2.zip, import into your workspace. Take the subclass.zip file bundled in the plugin and put into your JUnit workspace on the classpath of a Java project called "TestProject". Now run TestTypeHierarchy test case against the JUnit workspace. Note a few things: 1) The missing interface implemented by SuperClass seems to cause the problem. 2) If you add a trace statement to HierarchyResolver:569, you can trap the AbortCompilation exception that seems to be causing the problem.
Created attachment 87519 [details] Proposed fix and regression test Thanks for the test case. Indeed I see that in my previous patch I fixed the newTypeHierarchy() operation but not the newSupertypeHierarchy() operation. This patch also fixes the newSupertypeHierarchy() operation.
Verified for 3.4M5 using build I20080204-0010
