ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Glick <Jesse.Gl...@netbeans.com>
Subject Re: Fork implementation of <antlr> task [was Re: Problem with <antlr> task]
Date Fri, 02 Feb 2001 11:11:05 GMT
"Nikhil R. Deshpande" wrote:
> [snip]
> One more suggestion:
> To avoid the situation like this (i.e. when classes running
> through ant tasks call System.exit()), why not have ant's own
> security manager with the permission for exitVM disabled?
> and catch the resulting SecurityException?
> (What impact will this have on other tools and IDEs which
> rely on or use ant?)

Can speak for NetBeans as an example: it would likely cause problems.
But if a container is permitted to substitute its own implementation,
that would be fine. E.g.:

public interface ExitTrapper {
    int FALL_THROUGH_CODE = Integer.MIN_VALUE;
    /** Run r.
      * If it calls System.exit(), trap & return code;
      * else return FALL_THROUGH_CODE */
    int run(Runnable r);
}
// ....
/** register a systemwide System.exit() trapper.
  * @throws SecurityException if double-registered */
public static registerExitTrapper(ExitTrapper t)
    throws SecurityException;
/** @see ExitTrapper.run() */
public static int runTrappingExit(Runnable r);

where Ant provides a default ExitTrapper with a custom SecurityManager
etc., and some container such as an IDE can supply a different one (e.g.
based on its own existing SecurityManager). Could also be extended to
handle redirecting System.* I/O streams while running a thunk, which is
somewhat related.

-Jesse

-- 
Jesse Glick   <mailto:Jesse.Glick@netbeans.com>
NetBeans, Open APIs  <http://www.netbeans.org/>
tel (+4202) 3300-9161 Sun Micro x49161 Praha CR

Mime
View raw message