ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell \(DPML\)" <>
Subject RE: classloader for 1.7
Date Thu, 24 Aug 2006 16:11:33 GMT

Peter Reilly wrote: 
> Subject: classloader for 1.7
> If it is not a little too late, I would like to get a vote on 
> including classloader into ant 1.7.
> (

I've been reading through the documentation on the proposed classloader
datatype.  My initial reaction was positive and content demonstrates an
understanding of the issues involved - however - the initially good feeling
moved to a bad feeling as I dug deeper into the proposal.

If I have understood things correctly - the classloader datatype provides
support for (a) the creation of classloader based on the supply of parent
classloader identifies and data resolvable to resources urls, and (b)
modification of the state of new and existing classloaders including the
system classloader, the classloader established for Ant (the project
loader), the context classloader and a couple of other variations on the

In my experience the only time I need to modify a classloader is the special
case of the system classloader - for example a task that requires a class to
be mounted at system level (e.g. URL handler, or XML resolvers, etc.).  For
*all* other cases the creation of a new classloader at the level of a
taskdef is sufficient (although I do recognize that the current taskdef
model does not allow this at a script level).

My primary concern is the introduction of potential modification of the Ant
project classloader state and the impact this can have on classloaders
created as children of the project classloader. For example, if an antlib
developer publishes a task with the intention that the task be loaded in a
classloader created as a child of the Project classloader and another task
developer assumes Project classloader extension for a different tool - then
the classloader structure created by the first developer can be completely
corrupted (e.g. a class added to the Project classloader will be used
instead of a class in a child classloader - thereby destroying the runtime

The more I think about this the more I think that we are not dealing with
the potential to "shoot oneself in the foot" - but more probably is the
scenario where we are creating the potential for "stepping on a landmine".

I think that the subjects of system classloader expansion and antlib loading
are valid concerns and need to be addressed - but they need to be address as
integral elements of the antlib task semantics and implementation.

My conclusion is that <classpath> proposal should not be included in 1.7.  

Cheers, Steve.

Stephen McConnell

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

View raw message