Community
Participate
Working Groups
I have found what I consider to be a bug in how Eclipse 3.2.1 handles libraries with missing classes. What I've been able to determine is that when a library class references a missing class the intellisense and other code aware editor features stop functioning (Add unimplemented methods as an example). Ideally the editor features would just continue despite the broken library so the other, valid, classes can be found but I know that might be difficult. I think at a minimum an Error should be posted to the error log so that the user has some idea of whats going wrong and what classes he needs to find or fake to fix it. The reason this problem came up is that RIM's library is missing at least one class referenced in an interface that is implemented in the "MainScreen" class. This means that while we are developing we have no smart editor functions inside any Screen based Class (which is quite a few of them). I have no intention of ever trying to implement the interface with the issue (which I couldn't anyways because I am missing a class) but since the classes I have to use are dependent on it it still breaks my dev environment. I have produced a minimal test case with comments detailing some of these problems but I don't see any place to attach a file, ill commit this bug and then add the project (only 5 files).
Created attachment 60122 [details] TestCase Comments in Test.java should show the issues
Looks like a duplicate of bug 164266.
Kent - shouldn't this be supported using our missing binary type support ?
Just an update, there is an error log if the missing classes are directly related to the current class. I was seeing some "Java model errors" for a class I was extended over. The situation in this case the missing classes were inner classes of Screen. When I tried to do the intellisense I would get two error messages for these two missing classes. It was what I was hoping could be done in the other situation as it made patching the library much easier. Thanks. class A extends Screen{} lib: class Screen{ class innerClass1{} class innerClass2{} class missingClass1{} class missingClass2{} }
Philippe - our missing binary type support doesn't kick in, because the referenced types are found as source types & not binary types. We would need to change the o.e.jdt.internal.core.SearchableEnvironment & NameLookup to find binary types instead of source types for any referenced types that are not currently being modified in working copies. I do find it odd that the PackageFragment for a package in a prereq project is picked up a source package & not a binary package.
Jerome - Can o.e.jdt.internal.core.SearchableEnvironment & NameLookup find binary types instead of source types in cases like this one ?
(In reply to comment #6) > Jerome - Can o.e.jdt.internal.core.SearchableEnvironment & NameLookup find > binary types instead of source types in cases like this one ? > Note this comment applies to bug 164266. Moving this comment there.
For this sepcific bug, I'm getting which might explain the silent failure. (Kent back to you.) !ENTRY org.eclipse.jdt.core 4 4 2007-03-20 19:09:48.806 !MESSAGE Could not retrieve declared methods !STACK 0 org.eclipse.jdt.internal.compiler.problem.AbortCompilation at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:97) at org.eclipse.jdt.internal.compiler.problem.ProblemHandler.handle(ProblemHandler.java:153) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.handle(ProblemReporter.java:1727) at org.eclipse.jdt.internal.compiler.problem.ProblemReporter.isClassPathCorrect(ProblemReporter.java:3520) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.cacheMissingBinaryType(LookupEnvironment.java:178) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:46) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:131) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypesFor(BinaryTypeBinding.java:893) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.methods(BinaryTypeBinding.java:874) at org.eclipse.jdt.core.dom.TypeBinding.getDeclaredMethods(TypeBinding.java:266) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInType(Bindings.java:423) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethodInHierarchy(Bindings.java:440) at org.eclipse.jdt.internal.corext.dom.Bindings.findOverriddenMethod(Bindings.java:483) at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager$1.visit(OverrideIndicatorManager.java:179) at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:486) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2476) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2546) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:483) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2476) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2546) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:213) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2476) at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager.updateAnnotations(OverrideIndicatorManager.java:172) at org.eclipse.jdt.internal.ui.javaeditor.OverrideIndicatorManager.reconciled(OverrideIndicatorManager.java:251) at org.eclipse.jdt.internal.ui.javaeditor.CompilationUnitEditor.reconciled(CompilationUnitEditor.java:1572) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.reconcile(JavaReconcilingStrategy.java:137) at org.eclipse.jdt.internal.ui.text.java.JavaReconcilingStrategy.initialReconcile(JavaReconcilingStrategy.java:176) at org.eclipse.jdt.internal.ui.text.CompositeReconcilingStrategy.initialReconcile(CompositeReconcilingStrategy.java:114) at org.eclipse.jdt.internal.ui.text.JavaCompositeReconcilingStrategy.initialReconcile(JavaCompositeReconcilingStrategy.java:122) at org.eclipse.jface.text.reconciler.MonoReconciler.initialProcess(MonoReconciler.java:103) at org.eclipse.jdt.internal.ui.text.JavaReconciler.initialProcess(JavaReconciler.java:332) at org.eclipse.jface.text.reconciler.AbstractReconciler$BackgroundThread.run(AbstractReconciler.java:170)
Sam, to clarify: the code assist (what you call intellisense) failing silently is fixed in the 3.3 stream. However the "Add uninplemented methods" silent failure is still present in the 3.3 stream and is due to the stack trace I just reported.
The exception is thrown because there is no referenceContext for the ProblemHandler.
The ProblemHandler's referenceContext comes from the LookupEnvironment's unitBeingCompleted. We null out the LookupEnvironment's unitBeingCompleted at the end of Compiler.resolve(), which is called during the reconcile loop. We need to leave it set to the last unit since the binary types can be accessed thru the dom afterwards.
Created attachment 61447 [details] Proposed patch Do we want to release this change for M6 or wait for M7?
Created attachment 61459 [details] Patch for tests Need to fixup expected results for bug 173338 ASTConverter15Test test0239() & test0240()
I think the fix is good. If we recontribute for M6, and tests are fine, then I would put it in.
Released to HEAD
Adding missing comment to have this bug in our verification list: Released for 3.3 M6
Kent could you please backport this fix in R3_2_maintenance ?
Backported to R3_2_maintenance
*** Bug 183508 has been marked as a duplicate of this bug. ***
