Community
Participate
Working Groups
(This is in 3.1 RC1.) The build path of a project in my workspace includes a 48 Mb jar with 30,000 files in it scattered among 1000-2000 packages. (The jar file is proprietary so I can't attach it.) The Java editor frequently indicates that references to classes in this jar cannot be resolved, even though the classes are there. The attached stack trace shows what seems to be the root cause of this behavior. (The JavaModelException is caught and ignored.)
Thread [Text Viewer Hover Presenter] (Suspended (breakpoint at line 468 in JavaElement)) JarPackageFragment(JavaElement).newNotPresentException() line: 468 JarPackageFragment(JavaElement).openWhenClosed(Object, IProgressMonitor) line: 499 JarPackageFragment(JavaElement).getElementInfo(IProgressMonitor) line: 232 JarPackageFragment(JavaElement).getElementInfo() line: 218 JarPackageFragment(JavaElement).getChildren() line: 173 JarPackageFragment(JavaElement).getChildrenOfType(int) line: 187 JarPackageFragment.getClassFiles() line: 120 NameLookup.seekTypesInBinaryPackage(String, IPackageFragment, boolean, int, IJavaElementRequestor) line: 792 NameLookup.seekTypes(String, IPackageFragment, boolean, int, IJavaElementRequestor) line: 769 NameLookup.findType(String, IPackageFragment, boolean, int) line: 542 NameLookup.findType(String, String, boolean, int) line: 501 SearchableEnvironment.find(String, String) line: 85 SearchableEnvironment.findType(char[], char[][]) line: 188 LookupEnvironment.askForType(PackageBinding, char[]) line: 119 PackageBinding.getTypeOrPackage(char[]) line: 178 ClassScope(Scope).getPackage(char[][]) line: 2211 QualifiedTypeReference.getTypeBinding(Scope) line: 62 QualifiedTypeReference(TypeReference).resolveType(ClassScope) line: 141 QualifiedTypeReference(TypeReference).resolveSuperType(ClassScope) line: 104 ClassScope.findSupertype(TypeReference) line: 1072 ClassScope.connectSuperclass() line: 741 ClassScope.connectTypeHierarchy() line: 878 CompilationUnitScope.connectTypeHierarchy() line: 274 LookupEnvironment.completeTypeBindings(CompilationUnitDeclaration, boolean) line: 250 SelectionEngine.select(ICompilationUnit, int, int) line: 657 CompilationUnit(Openable).codeSelect(ICompilationUnit, int, int, WorkingCopyOwner) line: 165 CompilationUnit.codeSelect(int, int, WorkingCopyOwner) line: 314 CompilationUnit.codeSelect(int, int) line: 308 JavadocHover(AbstractJavaEditorTextHover).getHoverInfo(ITextViewer, IRegion) line: 110 BestMatchHover.getHoverInfo(ITextViewer, IRegion) line: 102 JavaEditorTextHoverProxy.getHoverInfo(ITextViewer, IRegion) line: 69 TextViewerHoverManager$4.run() line: 160
FWIW, to me this looked like a bug in JavaModelCache and friends: the huge jar file gets dropped from the cache, and isn't correctly brought back in when needed.
As supporting evidence, I forgot to mention that when I reduced the size of the jar file from 48 Mb to 36 Mb by removing unneeded stuff, the problem went away.
I've been working on getting to the root of this problem, and have found something interesting: if the jar is uncompressed, the problem appears to go away. Carl, could you give this a try? Also, though we can't attach the proprietary jar directly, we can provide it directly to a JDT member working on this bug.
Yep, exploding the jar made the problem go away for me.
Created attachment 25542 [details] Ensure that JarPackageFragmentRoot make it into the cache before its contents. The problem is believed to reside in the LRU package cache. When a JarPackageFragment is flushed from the cache before its root (JarPackageFragmentRoot) is added to the cache, the cache will be left in an inconsistent state. Do not quite understand why the problem does not occur with an uncompressed jar. Could be related to the hash code though.
Patch is good. Released it in both HEAD and 3.1 maintenance branches. Thanks a lot for investigating and providing the patch Theodora. Note it is not possible to write a regression test as the bug is dependent on the implementation of HashMap.
Verified in I20050920-0010 for 3.2M2. Verified by looking code.
Verified for 3.1.1 using M20050923-1430.
*** Bug 110840 has been marked as a duplicate of this bug. ***
