Peter Donald wrote: > [snip] > Yep the shell works the way you have set it. The problems is that there > could be assumptions made in other bits of code. A lot of tools cache > things in static variables (including the jdk tools) which means that you > can get erratic behaviour. While most things would work ... others may end > up working inconsistently over time - or worse ... being platform dependent > (ie *nix traditionally doesn't file lock but win32 does). [snip]
For purposes of comparison, NetBeans runs Ant in-process. The only such problem I am aware of, as Peter said: if you use the (internal) Javac as your compiler, and also build JAR files which are in your <javac> classpath, on Windows sometimes you will get errors from the compiler. AFAIK this is due to static caches deep in Javac code which are not cleared, and locks being held etc. Anyway, if you use Jikes or Unix or both I believe this does not happen. Perhaps <javac> should support an external Javac mode, as well as internal. Then you would avoid startup time on Ant in general, while still paying it for Javac classes. Acceptable for a project which is doing a lot of work other than compiling. Of course, you could just use Jikes, but for some purposes the "official" Javac is desired. Of interest: NetBeans itself wraps the Javac compiler in-VM, with small modifications to go through the filesystems abstraction. For this purpose, last I checked, the bad static parts were simply patched. I would love to be able to point you to the implementation that does this, as it would be useful for Ant, but unfortunately this code is (I believe) part of the small closed-source chunk of NetBeans (closed because it is based on original Javac code which is under an incompatible license). On the other hand, NetBeans also is able to invoke Javadoc in-VM and clean up its mess after it; this code *is* open-source (nothing copied from Sun code, just wrappers): http://www.netbeans.org/source/browse/~checkout~/javadoc/src/org/netbeans/modules/javadoc/ EnvWrapper.java is probably of most interest. An idea for Ant: some special classloader (variant of AntClassLoader?) which would keep track of any classes it loaded, and also initial values of all static fields in those classes. When you call reset(), it uses reflection to reset all static fields. So even unknown, non-static-safe code could be run repeatedly, so long as it was loaded via this loader (which you could enforce via e.g. package wildcards). The following JSR would do a more comprehensive job of it though: http://java.sun.com/aboutJava/communityprocess/jsr/jsr_121_isolation.html Cheers, -Jesse -- Jesse Glick <mailto:[EMAIL PROTECTED]> NetBeans, Open APIs <http://www.netbeans.org/> tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
