Bug 3158

This sort of behaviour can usually be explained or investigated but we will 
need more information. We need to know your system classpath, the classpath you 
are using with your Java task and even the ant-debug output which will show the 
activity of the Ant classloader.

Created attachment 434 [details]
demonstration of the (maybe) bug

I have improved the error reporting in the classloader for this but ultimately 
this bug comes from the interaction of the classloader and the fact that the VM 
now includes many classes from outside the java/javax namespaces. The error now 
reported is this

java.lang.NoClassDefFoundError: org/xml/sax/helpers/DefaultHandler
        at java.lang.ClassLoader.defineClass0(Native Method)

Ant's classloader for <java> tasks tries to minimize the chance of Linkage 
errors by only allowing java.* classes to be loaded from the parent 
classloader. Thus when your class tries to load 
org.xml.sax.helpers.DefaultHandler, Ant's loader says no and tries to resolve 
the class in the classpath it has been given. 

That hueristic is OK under JDK 1.3 for most cases (CORBA maybe an exception), 
but is going to breakdown under JDK 1.4 for a larger number of situations (XML 
parsing).

This will require more thought since it affects the whole classloading strategy 
which needs to be redesigned to more cleanly separate the classes available to 
the Ant core, the tasks, and tasks like <java>, while avoiding linkage errors. 

Didn't mean to close this one

Created attachment 629 [details]
The targer "run_fail" demonstrates failure to load a resource. The target "run_ok" forks a new VM and successfully finds the resource.

-Changed the title to emphasise java1.4 nature. I'd have made it a keyword but 
I cant. Now that 1.4 is out we should address this somehow. 

Conor, Steve -- do you know if this is still a problem? (I don't have Java1.4)

The problem conor refers to (things like org.w3c) in the base classloader 
still exist and need fixing. 

But, I had a look at the attachment from Jason; his problem is that
ClassLoader.getSystemClassLoader().getResource( "Test2.class" ) fails

...probably because he is using the wrong classloader, right? The system 
classloader when fork=false cant see the test2.class; he should be using 
this.getClass().getClassloader() or something similar.

*** Bug 10682 has been marked as a duplicate of this bug. ***

I got an NoClassDefFoundError when using reflecation in combination with the
java task. I get a NoClassDefFoundError when I instanciate the same class more
than 5 times via reflection-api.

I've attached a small reproduction.

Created attachment 2751 [details]
Bug report

Created attachment 3924 [details]
Java test that fails when not forked

Created attachment 3925 [details]
build.xml file for myTest.java

I have provided two attachments for this bug in the hopes that they 
will help to find and fix it.  myTest.java and myBuild.xml.  If you 
comment out any one of the six tests in myTest.java, it will run 
either forked or non-forked.  If you leave all six in place, it will 
fail with a NoClassDefFound error when not forked but will run when 
forked.

On at least some VMs, may work to use ClassLoader.systemClassLoader.parent; on
my Sun 1.4.1 VM, this is the extension loader (with parent null == bootstrap
loader). That will load from rt.jar (incl. org.xml.sax.** etc.) as well as
registered extensions (jre/lib/ext/). But I'm not at all sure this is guaranteed
to work, especially on JDK 1.1.

Summary
========
Andreas - your example works on Ant 1.6 alpha

Jason - your example fails and will always fail. By asking for the System
classloader, you are getting Ant's system loader. The <java> task with fork="no"
provides an imperfect approximation of running your class in its own VM. Things
like fiddling with System.out and using System resources such as the System
Loader will generally cause problems. You need to either change your loading
approach to something like

URL url = Test2.class.getClassLoader().getResource( "Test2.class" );

which will work when not forked or accept the fact that some things need to be
forked.

Christopher - your bug is fascinating - the first four iterations work - the 5th
fails. Anyway, under Ant 1.6Alpha, this works correctly.

Steve - your example also displays the weird behaviour of Christoper's example
and it too works under Ant 1.6alpha

or, in other works we have FIXED, WONTFIX, FIXED, FIXED. 

I'm going to close as FIXED.