Community
Participate
Working Groups
Build 20011211 + Jdtcore HEAD When running the JavaModel tests, we get complaints that some libraries could not be removed: WARNING: deleteFile(File) could not delete: c:\temp\comptest\1008679035369 \Minimal Jar\Minimal.zip WARNING: deleteFile(File) could not delete: c:\temp\comptest\1008679035369 \Minimal Jar WARNING: deleteFile(File) could not delete: c:\temp\comptest\1008679035369 WARNING: deleteFile(File) could not delete: c:\temp\comptest By adding some tracing code inside ClasspathJar (alloc and cleanup), we can see that some ClasspathJar never get properly cleaned up: OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Compiler/lib/classes.zip CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/Compiler/lib/classes.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/CodeAssist/lib/classes.zip CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/CodeAssist/lib/classes.zip OPEN - ClasspathJar: C:/JDK/classes.zip CLOSE - ClasspathJar: C:/JDK/classes.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Compiler/lib/classes.zip CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/Compiler/lib/classes.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/JavaSearch/AbortCompilation.jar OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/JavaSearch/MyJar.jar CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/JavaSearch/AbortCompilation.jar CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/JavaSearch/MyJar.jar OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Compiler/lib/classes.zip CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/Compiler/lib/classes.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip OPEN - ClasspathJar: C:/JDK/classes.zip CLOSE - ClasspathJar: C:/JDK/classes.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Compiler/lib/classes.zip CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/Compiler/lib/classes.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip CLOSE - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip
There are 3 occurrences of JAR left open: ... OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip ... OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip OPEN - ClasspathJar: c:/temp/comptest/1008679035369/Minimal Jar/Minimal.zip
After moving the location cleanup code to the JavaBuilder#cleanup method (rather than on the build state), I get the exact same behavior (trace + warning). I think though that it should be the JavaBuilder responsibility to cleanup the locations, given it created them.
Trace for opening was mislocated (not in the actual open code, but in the allocator). By moving the #clearLastState() invocation inside catch blocks, I get it to work ok (no more complaints). I also got it to work somewhat by moving the #cleanup() call before the #clearLastState()... behavior could be explainable if #clearLastState() could thrown any exception, but the implementation does not look like it does.
Checked that by resuming the old builder, no warning is dumped.
Ok, problem is understood. It comes from the fact that builder environment is never reinitialized when used outside the Java builder (e.g. for evaluation purpose). Changed the implementation to define INameEnvironment.cleanup() (invoked from batch compiler, evaluation support and Java builder) - used to be called IEnvironment.reset(), but it was somewhat wrongly indicating that the name environment was re-usable, which isn't true.
Fixed
