Community
Participate
Working Groups
I20030211 - load project "platform launcher" from dev.eclipse.org repository - open file "Main.java" Observe: lots of squigglies I would expect not to get these kind of errors for files that are not on the class path.
*** Bug 33005 has been marked as a duplicate of this bug. ***
Follow the described scenario. When looking into what happens the following truns out: A compilation unit for Main.java is created using JavaCore.create(<file>); Although the file is in a simple and not in a Java project, a package and a Java project are created for this compilation unit. Creating a working copy of this compilation unit is also successful. The reconciler works on this working copy and reports the found problems to the registered problem requestor. The problem requestor uses the following check to decide whether the reported problems should be considered at all: ICompilationUnit unit= getWorkingCopy(...); if (unit != null && unit.getJavaProject().isOnClasspath(unit)) .. consider reported problems .... In the given scenario this check is successful although it should not. Increasing severity and moving to JDT Core.
Dirk, do you expect the working copy creation to be successfull in this scenario ? I am wondering if we should deny its creation alltogether. We do support some minimal editor behavior, but this is clearly going too far in this case.
Ok, talking with Erich, I understand that you need working copies to be openable on any .java files anywhere in the workspace (no matter if inside/outside Java projects). Definitely #isOnClasspath should behave correctly.
Problem is actually more subtle. The first call on #isOnClasspath does answer false, however other questions (getPreferences, getLastBuiltState) will cause a per project info to be cached into the manager. Thus, from thereon subsequent calls of isOnClasspath will misbehave (since it thinks it is a legite Java project, missing its .classpath file, thus defaulting to project src folder). Note that performing a check on the fly in the problem requestor is likely a little expensive, why not caching this information upfront and never activating the problem requestor at all in this case ?
Fixed in latest
Verified.
