ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <>
Subject [PATCH] classloader jumbo patch
Date Thu, 25 Jan 2001 12:25:17 GMT
OK best for last...

This fixes one bug and one lacking capability. Both relate to use of
classloaders and show up when you try to embed Ant in another tool. The
patch permits Ant to function well inside the NetBeans IDE (for
example); without it, there are some workarounds (reimplement <taskdef>
and so on) but they are not complete and it is a mess. Hopefully other
GUIs could benefit as well, I don't know.

1. AntClassLoader. [This patch can actually stand on its own, if the one
reference to project.getDefaultClassLoader() is changed to e.g.
AntClassLoader.class.getClassLoader().] AntClassLoader currently when
trying to resolve "system" classes, uses the primordial classloader. If
Ant itself was *not* loaded with the primordial classloader, this is
unworkable: e.g. a user task may be loadable but Task itself is not
(from within that AntClassLoader) -> NoClassDefFoundError when
resolving. The patch simply makes the loading work logically, wherever
Ant itself was loaded from.

Furthermore, previously AntClassLoader under Java 2 would provide no
permissions for loaded classes. This means that in a VM with an
installed security manager, any task performing a controlled action
(pretty much any task at all: e.g. open a file, ...) would throw
AccessControlException and be useless. The patch (under Java 2) supplies
loaded classes with the same permissions as Ant itself (matching the
commandline behavior), under the assumption that tasks and build scripts
are trusted and there is no sandboxing needed or wanted. Under JDK 1.1,
it should compile (note the reflection calls) but do nothing different;
someone with a 1.1 installation, please double-check!

2. Project.defaultClassLoader and related code. I added a bean property,
defaultClassLoader, set on a per-project basis (should be inherited in
<ant> calls) and defaulting to Ant's own classloader. This classloader
should be used as the default one for any task/chunk of code needing to
load something (probably provided by a user) that has not been
explicitly handed a classpath. In commandline Ant, this should cause no
difference in behavior. When embedded in a GUI that has its own
classloaders, the GUI can ask the project to use its own standard one
instead. For example, in the NetBeans IDE there is a magic classloader
that can load stuff from the user's own project (i.e. Java
classes/resources developed inside the IDE, not the startup classpath).
NetBeans can then pass that classloader to Ant, so that e.g. <taskdef>
with no explicit classpath attribute will ask NetBeans for a
user-created class of that name. Same applies to many other tasks:
<available>, ...

I have tested this patch some under Linux 1.3; at least the standard
testsuite says it is OK. A version of ant.jar with this patch, when
installed into NetBeans via the existing integration minus the existing
hacky workarounds, seems to behave as desired.

Any philosophical/practical objections? BTW #1 is more important than


Jesse Glick   <>
NetBeans, Open APIs  <>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR
View raw message