Summary: | Problems with packages named "java" | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | John Whaley <jwhaley> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | erich_gamma, esmith, frank.sauer, kent_johnson |
Version: | 2.1 | ||
Target Milestone: | 2.1 RC3 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
John Whaley
2003-03-17 06:11:04 EST
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. 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. |