ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <>
Subject RE: Dealing with ClassLoaders
Date Mon, 25 Feb 2002 05:07:52 GMT
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.

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 ...

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.

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

> -----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: <>

View raw message