Community
Participate
Working Groups
build I20080519-2000 1) open a new workspace 2) checkout org.eclipse.jdt.core from dev.eclipse.org 3) add an API Baseline 4) do a full build 5) open org.eclipse.jdt.core.compiler.BuildContext.java In the Problem View the type BuildContext.java has 6 problem: BuildContext extends non-API type CompilationParticipantResult BuildContext extends non-API type CompilationParticipantResult BuildContext extends non-API type CompilationParticipantResult Constructor for BuildContext with non-API parameter type SourceFile Constructor for BuildContext with non-API parameter type SourceFile Constructor for BuildContext with non-API parameter type SourceFile In fact there is only 2 problems but each problem has three occurrences. 6) add a space in the editor of BuildContext.java 7) save and build There is only 2 problems: BuildContext extends non-API type CompilationParticipantResult Constructor for BuildContext with non-API parameter type SourceFile 8) do a full build There is the same 6 problems as before
The problem seems to be with the way we handle multiple source folders with overlapping output locations. For example the package which BuildContext appears in (o.e.j.c.compiler) appears in 3 locations, but they all share the same output location (/bin). The net effect is that we end up scanning all class files that appear in the final /bin/o/e/j/c/compiler folder N times, where N is the number of times the package appears in varying source folders. It feels as though we should have some sort of 'i've been here' flag in our container visitor to prevent multiple visits to the same container.
Created attachment 101306 [details] patch This patch creates a class file container per output location than per source folder. Avoids processing class files more than once when multiple source folders point to the same output location. However, there's still a problem with SWT as it gets duplicates from its fragment... i.e. one class file from the project, and then one from the win32 fragment (since the classes are really packaged in the fragment's jar).
Created attachment 101321 [details] patch This patch fixes the SWT case by not considering SWT fragments in the workspace profile.
Created attachment 101368 [details] patch This patch adds an implementation of a class file container that is dynamic for a workspace folder. The problem with re-using "directory class file container" is that it does not update as packages are added/removed.
Olivier, Mike, please reivew. Note that *without* this patch you will get many duplicate errors in the workspace for SWT API leaks.
looks good.
+1 for 3.4RC2
Released for 3.4RC2
Verified.
