ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <co...@cortexebusiness.com.au>
Subject Re: Classloader Problems
Date Mon, 08 Apr 2002 14:44:04 GMT
Daniel Barclay wrote:

> 
> 
>>From: Adam Murdoch [mailto:adammurdoch@apache.org]
>>...
>>The <java> task uses a specialised classloader, which 
>>basically ignores 
>>everything from the system classloader that is not in the 
>>java.* or javax.* 
>>packages.  That, of course, includes sun.jdbc.odbc.JdbcOdbcDriver.
>>
> 
> Why does it do that?


The <java> task tries to give the same behaviour whether the class you are 
running is run within Ant's VM or in a separate VM. To do this it tries to 
isolate the classes used by the class being executed and those of the Ant VM. 
Some classes, of course, should not be loaded separately. You would not want two 
separate versions of java.lang.Object, for example since Ant still needs to 
manipulate the instance of the class it creates.

So, to handle the majority of cases, Ant uses the system copy of the java.* and 
javax.* classes. Typically a user class will not define classes in these 
packages. Unfortunately the VM runtime includes some classes outside of these 
packages such as the one above and these will not be available unless it is 
provided explicitly to the <java> task via its classpath. Of course, the user's 
classpath may include javax.* classes and these can also cause problems.

In the end, running any arbitrary class with an arbitrary classpath within Ant's 
VM is quite difficult to do with 100% confidence. If you want to be safe use the 
fork attribute.

Conor



--
To unsubscribe, e-mail:   <mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message