Daniel Barclay wrote: > > >>From: Adam Murdoch [mailto:[EMAIL PROTECTED]] >>... >>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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
