back to classpath issues

[Mike McNally <m5...@works.com>]

A couple days ago I presented a problem I was having with using
<taskdef> to load up a task class with dependencies on a package
not part of the system classpath.

Further investigation (reading the source) reveals that the 
Ant class loader can be instantiated either to load classes
preferentially with the system class loader (actually, its
parent class loader) or not.  The code used by <taskdef>
uses a now-deprecated flag called "reverseloader" to determine
how the class loader is built.  By default, they're built 
such that the system class loader is tried first.

I appreciate that this is probably a wide-ranging rat's nest
of a problem, but I'm curious as to why the "reverseloader"
flag was deprecated, as it solves my issues completely.
Without it, my choices are

1) Modify my version of Ant, either the "<taskdef>" code or
the launcher script
2) Tell our developers to build without a CLASSPATH
3) Put classes I really don't want on the normal app CLASSPATH
in there anyway

None of those alternatives are as attractive as having the 
ability simply to instruct Ant how to load my task.

If there's something icky about "reverseloader", then perhaps
the "build.sysclasspath" property could imply whether the 
parent classpath is checked first; that doesn't seem so good
since I'm sure there are cases where the behavior is strongly
undesirable.


--
[ you are my main foo ] Mike McNally -- m5@works.com

Re: back to classpath issues

[Stefan Bodewig <bo...@apache.org>]

On Wed, 5 Mar 2003, Mike McNally <m5...@works.com> wrote:

> I appreciate that this is probably a wide-ranging rat's nest
> of a problem, but I'm curious as to why the "reverseloader"
> flag was deprecated, as it solves my issues completely.

With the reverseloader attribute set to true, Ant's classloader
doesn't behave the way Sun wants it to work (delegate first) as
described in the Javadocs for the ClassLoader class.

The "bad thing" that can happen with the reverseloader attribute set
to true is that you may end up loading the same class from two
different classloaders leading to extremely difficult to track down
(and understand) ClassCastExceptions.

The attribute is "deprecated" so it doesn't get overused - and at best
only gets used by people who understand the implications and don't
field support calls to us when strange things happen 8-).

We are working on a task library concept where we may use a different
classloader layering system or similar for future extensions.  Here -
as well as in some other areas - backwards compatibility of Ant,
important as it is, gets in the way of changes that may make live
easier for advanced users.

Stefan