Does the Ant launcher really want the whole VM to itself?

[David Byrden <co...@byrden.com>]

Am I correct in saying that ANT 1.7 has this limitation;
it requires full ownership of the VM?

I say this because of 2 things:
[1] It calls System.exit() which kills the entire VM. This is
    not desirable if another Java program calls Ant.
[2] It assumes that it was loaded by the bootstrap ClassLoader
   and won't work otherwise.

You're probably aware of [1]. There are calls to System.exit()
in both the Launcher class and the older Main class. We can
easily extend Main and change this behaviour by overriding a
method; somebody evidently thought this through. But the Launcher
class (org.apache.tools.ant.launch.Launcher) doesn't give us an
easy way to do this.

The documentation advises us to skip these two classes
and enter Ant in a different way from Java programs, but there is
so much code in them that it's easier to simulate a call from the
command line. And I need to do that for a special reason; my
command line is XMLSH, a Java program that loads Ant into its own VM.

Problem [2] is more subtle. On loading Ant, I see something like this:

"org.apache.tools.ant.Main cannot be cast to 
org.apache.tools.ant.launch.AntMain"

The problem is in the Launcher class. It creates a ClassLoader to
load Ant, and it assumes this to be a child of Launcher's own loader.
That will be true if Launcher came in via the bootstrap loader, but it's not
always true.

But a simple change to one line of code will link these class loaders
correctly in all situations.

So I'm asking if I really need to replace the Launcher class to
make these changes, or has somebody found a better way?

David Byrden



---------------------------------
BYRDEN.COM
David Byrden - IT-Dienstleister
Wien 1030
---------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org