ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <>
Subject Re: We need to stop the lies
Date Fri, 22 Feb 2002 10:43:59 GMT
 --- Stefan Bodewig <> wrote: > On
Thu, 21 Feb 2002, <> wrote:
> > On 21 Feb 2002, Stefan Bodewig wrote:
> >> >> What do people think of breaking optional.jar
> into several
> >> >> pieces cut along the dependencies,
> optional-junit.jar,
> >> >> optional-trax.jar and so on.
> >
> > +1, great idea.
> > 
> > What I don't like is the fact that we load
> optional.jar and what's
> > inside in the 'parent' class loader.
> This is what I've called "the problem that cannot be
> fixed in a
> backwards compatible way" - I'd be happy if you
> could prove me wrong.

If we keep all those classes in one big lump there is
little chance of keeping backward compatibility.
Now, once you chop it in pieces new posibilities

This and the addition of an autoload mechanism on
separate loaders, can help solve the problem. After
all if in a particular project people are using a task
that requires certain classes living in the CLASSPATH
you can always put them back in there and nothing is

> The main classloader problem of Ant 1.x is, that
> there is far too much
> stuff on the system classloader IMHO, but I'm really
> afraid that there
> are lots of people who rely on Ant having its own
> classes just there.
> > I liked very much the idea of using named loaders,
> and a model
> > similar with what tomcat is using ( either
> version, but 3.3 in
> > particular :-).
> Your description sounds a lot like Conor's of
> Mutant's class loader
> hierarchy (see proposal/mutant/docs/desc.html) and
> Myrmidon does
> something similar IIRC.  So you we all basically
> agree that having a
> class loader hierarchy like that is the way we
> should go -
> unfortunately this is not backwards compatible for
> the things that
> have been shipping with Ant before.

For what I remembered of his description of
classloader hierarchy, I think it is too limiting.
If libA needs things from libB, his approach will
declare that "libA extends libB" which is fine unless
libA also needs things from libC. Now you cannot do it
because we have single inheritance (i.e., a
classloader onl has one parent classloader).

This is why I use named loaders. Each name loader
defines a group of libraries(jars) that need to work
together. if libA requires libB and libC you just put
all of them on the same loader, 'loaderABC'.

I use parent classloaders to solve a different problem
that we have, and which I think it is a BUG not a
feature: we do not unload the classloaders once 
we live the subproject that created them. What antlib
does is that the named loaders hierarchy reflect the
hierarchy of subprojects. 

So if subproject X adds a libD to 'loaderABC' what you
get is a new classloader whose parent is 'loaderABC'
from the parent project and which contains libD. When
you get out of X you release its instance of
'loaderABC' but still have its parent instance.

It is simple, and covers more. This is exactly what
the Class-Path manifest entry tries to acheive but
without hardcoding in the libraries the names of other

The thing that puts everything together and gives the
backward compatibility, is the autoload feature into
named classloaders. That will give users the
impression that all tasks are there where they need to
be. And after all if for some reason you really need
to have one of them in the CLASSPATH, you can always
do that by moving it to ant/lib.

> If we start shipping new tasks in extension
> libraries that get loaded
> from named class loaders, that is fine, but for the
> things that used
> to be on the system classloader, we must still
> ensure they stay there.

Well, we now tell people to take them out of there so
things will work, so I think the autoloading is a much
better solution. As for the core tasks, those should
stay in ant/lib since after all they are core.

Jose Alberto

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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

View raw message