ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: Dealing with ClassLoaders
Date Tue, 26 Feb 2002 01:05:37 GMT
From: "Conor MacNeill" <>

> Jose Alberto,
> I have the following problems with your proposal:
> 1. It assumes that jars used by Ant should be placed into sub-directories of
> the Ant install directory. I know Ant is the centre of the Universe but I
> don't think we should be encouraging everything to end up in there. I know
> this happens today with the lib directory. I'm not happy about that but I
> think this proposal will just magnify the problem.

I agree that in the future we should encourage the usage of the <antlib>
task as the way to load new libraries. However given the classloader
problems and the backward compatibility issues to take care for,
the autoloading features proposed here are there to deal with those things.

Mutant's proposal for example is even more extrema in that regard, since
it requires the usage of global names for libraries and for those libraries
to live inside ANT's configuration. 

So, anyway the reason for the autoload is mostly for the things that
we ship, for third party libraries I would argue that <antlib> is the way to go.

> 2. It ties the operation of a build file to the configuration of the user's
> Ant subdirectories. If the link is implicit, it will not be obvious. This
> could be become a maintenance nightmare. Consider this scenario
> User: I downloaded your build file and it didn't work
> Build Writer: Oh, you need to set up your directory structure this way (...)
> User: OK I did that and it broke half my other build files. They game me a
> different setup.
> If the link is explicit it will be worse.
> User: The Tomcat build uses classlaoder "A" for foo.jar but Xerces uses "A"
> for jaxp.jar. If I put JAXP in "A" it breaks Tomcat build. What shold I do?
> BuildWriter: Ahhh ...

I presume this are two separate build files that are run as part of a larger project.
"A" will contain the classes for tomcat only during the execution of the tomcat buildfile
when it comes out those classes go away and it is now available for Xerces buildfile
to put its classes there. 

This would have been a problem if one buildfile called the other, but then the writer
of the top one would had have to take that into consideration since it would have
been part of its build.

> 3. The proposal isn't hierarchical. If b1.jar depends on a1.jar (since it
> uses a type defined in a1.jar, for example) it must live in the same
> directory. If b2.jar also depends on a1.jar but is incompatible with b1, you
> have a problem. For example, we have problems today where some tasks
> conflict with Ant'2 JAXP classes.

I would aregue that there is no full proof solution to this issue. Unless you put every
single class in a different jar file and then you may try to control every possible combination.
BTW, there is nothing requiring things to live in the same directory since that is only
for the autoload. You can always load the classes in your own classloader "X" and 
load the parts that you want. And this is possible because the autoloaded jars
do not reside in the system classpath and there for you can reconfigure them as needed.

> 4. Adding classes to a classloader after it is running may be dangerous if
> these classes have already been loaded by a child classloader.

Child classloaders are only used by subprojects. When the subproject ends the child
is dismissed and released. Hence there should be very little problems in that regard.

Hope this clarifies things for you,

Jose Alberto
> > -----Original Message-----
> > From: Jose Alberto Fernandez []
> > Sent: Wednesday, 20 February 2002 1:01 PM
> > To: Ant Project List
> > Subject: Dealing with ClassLoaders
> >
> >
> > Hi,
> >
> > One of the things I think is broken in ANT1 is the way we deal
> > with ClassLoaders. Our current
> > approach of having some of the code in the CLASSPATH and any
> > other code being loaded
> > on independent ClassLoaders just causes all kinds of problems
> > that only can be solved by
> > putting everything in the CLASSPATH of the JVM.
> >
> > In the <antlib> proposal I am trying a different approach. Still
> > certain things, like core, will go in
> > the CLASSPATH, to obtain backward compatibility. Additional
> > Classloaders will not be defined
> > by the jar files being added but by name. Every time a library is
> > loaded, one specifies (implicitly or
> > explicitly) the ClassLoader to use for loading its content.
> >
> > In other words instead of creating more and more classloaders,
> > one just add more and more
> > classes to an (maybe) existent classloader. By being able to
> > identify which one we one to use
> > we can accpomplish selective segregation of the classes when
> > there are dependency clashes.
> >
> > The third aspect, which I am considering right now, is to have
> > three predetermine locations for
> > libraries:
> >
> > 1) $ANT_HOME/lib: this jars are added in the JVM's classpath.
> >
> > 2) $ANT_HOME/autolib/* : Any jars in subdirectories will be
> > loaded at start-up on ClassLoaders
> > identified by the name of the subdirectory.
> >
> >     $ANT_HOME/autolib/A/{a1.jar, a2.jar} :
> >         a1.jar and a2.jar will use ClassLoader "A".
> >
> >     $ANT_HOME/autolib/B/{b1.jar, b2.jar} :
> >         b1.jar and b2.jar will use ClassLoader "B".
> >
> > this will allow related libraries to se the same classloader and
> > eliminate many of the current issues.
> >
> > 3) $ANT_HOME/antlib: this is the location for libraries to be
> > loaded on demand by using <antlib library='x.jar'>
> > and one can specify which classloader to use.
> >
> > To me this mechanism is much more simple to administrate, since
> > in general people can first try loading
> > everything in the default Classloader, and in case of a conflict
> > they just need to change where they want
> > to see what.
> >
> > Comments, thoughts,
> >
> > Jose Alberto
> >
> >
> >
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

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

View raw message