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
application.
Background:
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 Classloader.java 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
classloaders.
Conclusion:
- 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
classloader).
WDYT?
Cheers, Steve.
--------------------------
Stephen McConnell
mailto:[EMAIL PROTECTED]
http://www.dpml.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
