ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen McConnell" <>
Subject RE: classloader for 1.7
Date Fri, 25 Aug 2006 18:17:24 GMT
I'm currently digging into the classloader expansion issue with the
objective of establish how system classloader state modification can be
achieved without breaking in applications that establish Ant as an embedded


JDK 1.4 introduced the java.system.class.loader property through which the
implementation class of the system classloader could be specified.  Prior to
that there was no 'elegant' solution.  Ant (maintaining compatibility with
JDK 1.2) handles bootstrap establishment of a system classloader via a
URLClassLoader.  In addition the Loader class assigns the classpath resolved
from the system, Ant' library and user libraries to the system property
'java.class.path' which is presumably how the initial modification of the
system classloader state is established.

In the class (the Classloader task in Ant's SVN trunk) the
task attempts to modify the state of a named classloader - the default being
the system classloader.  If the name if not null the classloader is selected
on the basis that the classloader is a named resource.  If the classloader
returned from the name is null or is not an instance of AntClassLoader the
task execute method simply returns.  As such this task isn't going to do
anything for the system or Ant project classloader - although it would be
fully functional for a classloader established via a taskdef statement
(which creates a new AntClassLoader using the system classloader as parent).

The <classloader> task written by Rainer Noack and proposed by Peter uses a
number of adapter classes to apply reflective operations to a supplied
classloaders.  As such it can bypass the restrictions on protected methods
on URLClassLoader to modify the classloader state.  In effect this
implementation is more complete in that it supports both the Ant-based
classloader and classloaders derived from URLClassLoader (which should in
principal cover the case of applications the embed Ant and declare custom
classloaders via the "java.system.class.loader" (although I haven't tested
this yet). On the other hand the potential for unforseen errors is much
higher due to the potential mutation of the 'project' and 'current' thread


  - the version in SVN does not appear to me to be satisfactory 
    due to the limitation of operation on AntClassLoader as opposed to 
    the combination of AntClassLoader and URLClassLoader
  - the proposed replacement IMO goes too far in that it introduced 
    a much higher potential danger related to mutation of project and 
    context classloaders at any point in a build sequence simply by 
    following different and potentially incompatible usage instructions 

Given that a solution that limits mutation to the system classloader
provides the potential solution for all requirements - I think it is the
safer next step (i.e. update the class in SCN to handle a URLClassLoader,
with formal documented extension semantics, with scope limited to the system


Cheers, Steve.

Stephen McConnell

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

View raw message