ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran" <>
Subject Re: FW: Problem with ANT classloader?
Date Mon, 20 May 2002 02:39:35 GMT

----- Original Message -----
From: "Conor MacNeill" <>
To: "Ant Developers List" <>
Sent: Sunday, May 19, 2002 6:18 PM
Subject: Re: FW: Problem with ANT classloader?

> Dominique Devienne wrote:
> > Don't any of the ANT experts out there have any clue what's going on
> > --DD
> Sure, but sometimes I find other things to do on my weekend :-)
> Let me start by saying that it is not possible to safely execute any
> arbitrary piece of Java code in Ant's VM. This is one reason why the
> option to fork is provided. When java code is run within Ant's VM it is
> going to be affected by Ant's environment, particularly the classpath,
> as well as the requirements not to mess with that environment. A class
> that sets System.out, for example, would cause trouble executing within
> Ant's VM.
> This is why the option to fork is provided. You can run your Java class
> in a clean VM. It is slower, as you say, but in general it is also safer.

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.
> Of course, even when trying to isolate you, some VM classes must still
> be loaded by the parent loader. The classloader treats all classes from
> the java and javax package spaces as such. This approach worked
> reasonably well up until JDK 1.4 when the JDK started to include many
> classes from outside these packages - notably the XML related classes.
> There are a few things that can be done
> 1. Add the XML related classes into the "special" classes so they are
> delegated
> 2. Allow you to specify that you want the classloader to delegate via a
> new attribute i.e. <java delegate="true">
> I'm not that happy with the first approach as the problem will just keep
> growing. The second approach is OK but then the <java> task will not
> behave like you were running in your own VM.

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,.

The better solution is on the HDD of my now-defunct laptop; I can post/apply
it once I have a replacement laptop, which means that once I have dealt with
a crushing internal purchasing beaurocracy that
-refuses to ship me the laptop to a different country (the US) than my
nominal place of employ (the UK)
-wont let me get one of those home user laptops with firewire, s-video out,
camera memory stick reader and cd playback of 8+hours while the CPU is off,
and costing so much less than the dull corporate systems that I could afford
to stack it with 1GB ram and still have spare cash
-wont ship it to me without windows pre-installed. That just niggles me.

anyhows, that means that I wont get the files back for a few weeks; I may
jsut dredge up my patch from the archive, apply them to a different box and
then redo the refactoring. This time I will even write the tests, with our
old friend <available>



To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message