Community
Participate
Working Groups
Eclipse seems to have problems parsing fully-qualified package names when part of the package name matches another type. This prevents Eclipse from compiling the joeq project successfully (http://joeq.sf.net/). Here is a simple test case: /*** ClassLib/Common/Bar.java ***/ package ClassLib.Common; public class Bar { public java.lang.Object baz() { ClassLib.Common.java.lang.Object.foo(); return null; } } /*** ClassLib/Common/java/lang/Object.java ***/ package ClassLib.Common.java.lang; public class Object { public static void foo() { } } In the baz() method, Eclipse says "ClassLib.Common.java cannot be resolved". In the editor, it has a red underline under "ClassLib.Common.java.lang.Object". If you change the return value of baz() from "java.lang.Object" to just "Object", it will work. In fact, as long as the return type declaration starts with "java.lang.", it triggers the bug. This bug has been present in Eclipse since at least 2.0. It is still in RC2. Note: This looks like it may be similar to Bug #33885.
Reproduced
When using the batch compiler, it works fine. Problem would seem to be located in the builder name environment. Also, only incremental builds are fooled. Full build does work fine (same issue in SearchableEnvironment though).
Problem is actually in namelookup itself (not in name environment). The incremental scenario exposes the bug since 'java' is resolved as a supertype before ClassLib/Common/java gets created as a package. The bug is that the package lookup isn't performed if a notFound type got cached. Same problem should be reproduceable with batch compiler (if Object isn't passed on the command line).
Proposed fix on PackageBinding: public Binding getTypeOrPackage(char[] name) { PackageBinding packageBinding = getPackage0(name); if (packageBinding == null) { // find the package packageBinding = findPackage(name); } if (packageBinding != null && packageBinding != LookupEnvironment.TheNotFoundPackage) return packageBinding; ReferenceBinding typeBinding = getType0(name); if (typeBinding != null && typeBinding != LookupEnvironment.TheNotFoundType) { if (typeBinding instanceof UnresolvedReferenceBinding) typeBinding = ((UnresolvedReferenceBinding) typeBinding).resolve(environment); if (typeBinding.isNestedType()) return new ProblemReferenceBinding(name, InternalNameProvided); return typeBinding; } if (typeBinding == null) { // if no package was found, find the type named name relative to the receiver if ((typeBinding = environment.askForType(this, name)) != null) { if (typeBinding.isNestedType()) return new ProblemReferenceBinding(name, InternalNameProvided); return typeBinding; } // Since name could not be found, add problem bindings // to the collections so it will be reported as an error next time. addNotFoundPackage(name); addNotFoundType(name); } else { if (packageBinding == LookupEnvironment.TheNotFoundPackage) packageBinding = null; if (typeBinding == LookupEnvironment.TheNotFoundType) typeBinding = null; } if (packageBinding != null) return packageBinding; else return typeBinding; }
Kent - pls verify my proposed fix. If ok, will escaladate it for RC3
Indeed, was able to reproduce with batch compiler if Object is only available through the classpath.
Could this be the cause for bug 34708 as well?
It indeed feels the same, also see my comment in bug 34708.
*** Bug 34708 has been marked as a duplicate of this bug. ***
Erich - Need approval for releasing this fix into RC3
approve
Fixed in latest
Patch available at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/jdt-core- home/patches/org.eclipse.jdt.core_2.1.0.zip
*** Bug 33885 has been marked as a duplicate of this bug. ***
Kent - with last version of fix (Scope method, with getTypeOrPackage in place of findType), I am wondering if we are not missing the following 2 things which happened with #findType invocation: - reference recording - visibility check
sounds to me like you're at least missing two regression tests.... :-)
I added the reference recording. As for the type being visible - its always visible since we're looking in the same package. Frank: Are you volunteering? ;)
Man, I wish I had the time. I'd love to work on this stuff....
Thanks, your patch fixes the problem. I just went to sleep and when I woke up the bug was fixed! This has been annoying me for the past six months, but I would work around it by using Jikes as an external compiler and always doing a full build. I'm glad it fixed other people's issues; I couldn't imagine that I was the only one who uses package names that clash with system classes/packages. Thanks again.
Actually, we have added 2 regression tests for the scenario mentionned in this PR: ConformTests.test200() and test201(). But some more help would still be a good idea...
Verified.
