ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: FW: Problem with ANT classloader?
Date Mon, 20 May 2002 01:18:48 GMT
Dominique Devienne wrote:
> Don't any of the ANT experts out there have any clue what's going on here?
> --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.

Let me explain what the AntClassLoader does and why and how that causes 
you problems. The <java> task runs the AntClassLoader in "isolated" mode 
where it will not delegate to its parent classloader. Why does it do 
that? Well, one of the reasons is that it is trying to make the <java> 
task behave like you were running within your own VM. In particular it 
is trying to hide the classes from Ant's classpath from you. Some 
background may be found here

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

A workaround with the current version of Ant is to put everything in the 
system classpath and run <java> without a classpath at all.


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

View raw message