I havent found it to be that much slower. A fair amount of the java exe and runtime libraries are already in memory and disk cache when you spawn the new JVM, so although there is startup hit, you dont pay the penalty of loading all the stuff in from HDD again. I havent done enough rigorous experiments to say this is a consistent truth, so in ACM terminology this is "an observation", not "a finding". Its enough of an observation for me to always set fork=true and not worry about things. Also when you fork you get System.exit() handling, proper-like, and better leakage handling.
Agreed, although the startup hit may be significant for a short lived <java> task.
I have that patch to do (1) posted a few weeks ago, and a better solution, derived from Dominique's suggestions (move it all to JavaEnvUtils, return a String array of intrinsic classes). The problem doesnt grow very fast, only at the rate of new java versions, so is tractable. Indeed, we should add some of the org.omg classes and even sun.misc for various bits of code to work in-JVM,.
Let me just add that the javax package itself represents something of a problem. As time goes on parts of this package move from something found outside the VM (it may be provided by an app server, for example) to classes within the VM.
Conor
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
