Community
Participate
Working Groups
Build ID: I20080617-2000 Steps To Reproduce: As discussed in eclipse.tools.jdt newsgroup... I have a strange (and serious) problem with Eclipse 3.4. A project of mine seems to have problems compiling some classes. Eclipse says it can't resolve a package that: - it does exist - it is in the same source folder of the classes that try to import a class in it Precisely, the structure is this: - src - my.package.MyClass - my.package.exceptions.AnotherClass MyClass imports my.package.exceptions.AnotherClass, but the compiler says it can't resolve my.package.execeptions. However, AnotherClass exists and is in that package. If I edit MyClass, delete "import my.package.exceptions.AnotherClass" then use Organize Imports and save, the error goes away, although sometimes the red markers in the overview rulers remain. It's a very weird problem, one of those problems I had in the past when I had buildpath problems. But there are no buildpath problems this time. I double checked everything, I even built up all the project from scratch in order to make sure there are no subtle causes to this. But the problem persists. I cleaned and built the project many times, without success. The classes that exhibit this problem are always the same. With Eclipse 3.3.2 there are no problems. I have prepared a small workspace that exhibits the problem. I'm taking agreements with Philippe Mulet to understand the way to submit this example code, because it's about proprietary code. Mauro.
If truly a regression, then we should address it for 3.4.1
Created attachment 106408 [details] Project that exhibits the problem I was able to prepare a tiny testcase that shows the problem and I was able to identify the problem. Please see my next comment.
First of all, prepare a new empty workspace. Set it up so that you have a 1.6 JRE bounded to JSE 1.6 Execution environment. Then, unzip the folder "Test bug 239229" in the attached ZIP into your new workspace and import the project in that folder. Now, have a look at the code: - com.ost.util.report.FilterConstraintSpecification does not compile because it can't resolve the package com.ost.util.report.exceptions... but that package is there! - the same for com.ost.util.report.InspectedMatrix - com.ost.util.report.Matrix<T> and com.ost.util.report.MatrixInspector, instead, don't have problem to resolve that package. Now, take com.ost.util.report.FilterConstraintSpecification, remove the offending import line, press Ctrl+Shift+O, then save: you'll see that the error vanishes. Then, invoke Project | Clean... and clean the project: the error will appear again! This is weird and this is what I observed in my real problem. But now the funny part... Open com.ost.util.report.Matrix<T> and see the "@see" line in its Javadoc. First of all, notice that no warning nor error is given for that malformed @see clause (I obviously activated all the Javadoc validation options), although it is clearly wrong. But now, remove the line containing the "@see" tag and save. Then do a Project | Clean... TADAA! The error "The import com.ost.util.report.exceptions cannot be resolved" on both com.ost.util.report.FilterConstraintSpecification and com.ost.util.report.InspectedMatrix is vanished! Mauro.
(In reply to comment #3) > This is weird and this is what I observed in my real problem. I meant: "in my real project"! Sorry for the typo. Mauro.
Reproduced. Problem only occurs when enabling javadoc diagnoses, and after 3.4M6.
The error indeed comes from the unbound reference in javadoc: /** * @see exceptions.InvalidRowSizeException */ I believe it is related to change for bug 196200.
Added ProblemTypeAndMethodTest#test081
Simpler testcase: //p/X.java package p; public class X extends zork.Z { } //p/Y.java package p; import p.zork.Z; public class Y { } //p/zork/Z.java package p.zork; public class Z { }
Created attachment 106735 [details] Patch in progress (3.4) The problem may occur outside javadoc. Only need a prior reference to missing type which is colliding with subpackage to cause some later confusion. In particular, I am not yet satisfied with behavior of patch for ProblemTypeAndMethodTest#test081 producing unexpected error: "3. ERROR in com\\ost\\util\\report\\Matrix.java (at line 9)\n" + " throw new InvalidRowSizeException();\n" + " ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n" + "No exception of type InvalidRowSizeException can be thrown; an exception type must be a subclass of Throwable\n"
Philippe - so this is a case of a MissingType taking precedence over a package that we have yet to find/request ? We've had similar issues with types that conflict with packages. Possibly we could handle this by searching for a conflicting package before adding a MissingType to a package's cache... then you wouldn't need to check everytime someone requests a package/type.
Created attachment 106736 [details] Simple check
My suggested patch is causing lots of regressions. I had thought of checking for conflicting package before adding missing type, but I was under impression this was weaker, as we may not know all packages at that stage (thinking of requested types to come in later).
Created attachment 106796 [details] Better patch for 3.4.x Addresses the issues raised by previous patch.
Created attachment 106802 [details] Better patch for 3.4.x take 3
Created attachment 106810 [details] Proposed patch for HEAD
Also added ProblemTypeAndMethodTest#test082-088
Released for 3.4.1
Released for 3.5M1. Fixed
Verified for 3.5M1 using I20080805-1307
*** Bug 245304 has been marked as a duplicate of this bug. ***
Verified for 3.4.1 using M20080827-2000
