ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Conor MacNeill <>
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/taskdefs
Date Tue, 21 Jan 2003 10:13:36 GMT
Costin Manolache wrote:
> I know that pretty well ( reverse loader is required by 2.3+ servlet spec -
> one of the biggest mistakes IMHO ). 

Yes, that is pretty weird.

> There are some cases where a reverse loader will help, and is actually 
> needed. 

I think it mainly helps when the classloader hierarchy is not clean and you 
need to workaround that (true in Ant to some extent).

In Ant a long time ago, I let the classloaders all be reversed and it was 
not a good thing. I corrected that with a potentially backward compatability 
breaking change to make most Ant uses of classloaders respect the loader 

As a slight concession I introduced, but did not document, the reverseLoader 
attribute. It was intended to allow the old behaviour to be accessed if it 
turned out to be required. For the most part it has not. Only 
Velocity/Anakia had problems due to the use of singletons that needs to be 

There are two locations in Ant where the classloaders do not strictly 
respect the hierarchy - the <java> task and the <junit> task. In both cases 
this is an attempt to make running a class behave the same as it would if it 
were to be run within its own VM. You'll also note that this is where people 
encounter LinkageErrors a lot (see Ant user list). Fortunately both these 
tasks allow the operation to be forked into a separate VM bypassing the 
classloader issues altogether.

The new task, however, makes it easy to expose this problem. In this case 
the problem would manifest itself in not just the <java> and <junit> tasks 
but anywhere within Ant's core. It would not be easy to solve these problems 
by saying "set fork=yes" as we do now.

It would also not be easy to diagnose these problems since the manifestation 
of Linkage Errors is far from the source of the problem and can depend on 
many factors including garbage collection. For example I have seen 
behaviours such
* working on the first run (one classloader),
* failing on the second (two classloaders with overlapping paths),
* working on second run if delayed (garbage collection cleaning up)

That sort of problem drives people nuts.

I'd rather people bump into the problems of the loader hierarchy limitations 
(normally ClassNotFound) since these errors represent a "fail-fast" 
situation and the workarounds can be driven from there (rejig classpaths, etc)

> Is your -1 on "global  non-delegate behavior", or also on support for 
> parentFirst for individual packages ?

My -1 applies to any user ability to avoid the classloader heirarchy.



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

View raw message