db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java
Date Thu, 28 Apr 2005 22:17:12 GMT
Hi, all.  I have done further investigation, and conversations I have 
had convince me that (a) System.exit() is the proper way to set an exit 
code and (b) embedding apps in general should not be calling main(), and 
(c) since we have a policy of always expecting to be embedded, tools 
should have a policy of providing a callable execute() method that 
doesn't do System.exit() but instead throws exceptions.

Regarding Jeremy's suggestions:

I wasn't sure, and I checked: Callable is new to JDK 1.5.  Unless I am 
mistaken, we can't take advantage of new JDK 1.5 features at this time, 
am I right?

In terms of Runnable, that would work, but I am a bit concerned because 
the real semantics of Runnable are that you can run it as a separate 
thread, and it could be confusing to overload it this meaning with our 
implied meaning that it can be embedded and executed.  We could define 
our own interface that all our tools follow that has the very specific 
semantics of "this is a tool that you can embed, you need to call the 
execute() method to avoid the VM exiting".

Also, the JavaBean approach assumes you create an instance of the beast, 
and I have noticed that many command-line classes have most of their 
code in static methods and use static variables (not that they should, 
but that's what they do).  Also, it might actually be easier to set up 
an array of Strings rather than call a bunch of set methods, especially 
if you can create the array in-place, e.g.

DB2jServerImpl.main(new String[] { "ping", "-p", "2000"} );

rather than

DB2jServerImpl impl = new DB2jServerImpl()
impl.setCommand("ping");
impl.setPort("2000");
impl.execute();

So, I would like to propose the following:

- Define a new abstract class, e.g. org.apache.derby.tools.BaseTool, 
that looks something like this:

public abstract class BaseTool
{
   public abstract void execute(String[] args) throws Exception;

   /**
   * Basic main routine, can be overridden if needed
   */
   public static void main(String[] args)
   {
     try
     {
       execute(args);
     }
     catch ( Exception e )
     {
       e.printStackTrace();
       System.exit(1);
     }
     System.exit(0);
   }
}

and then have our tools implement this, e.g.

public class MyTool extends BaseTool
{
   public void execute(String[] args) throws Exception
   {
     // yada yada
   }
}

and then applications can do

MyTool.execute(new String{ "ping" });

Comments?

David

Jeremy Boynes wrote:

> David Van Couvering wrote:
> 
>> I like Jeremy's idea of a JavaBean interface, although I don't 
>> understand why it needs to implement Runnable or Callable, is that 
>> just so it uses a standard mechanism for a no-arg execute method?
>>
> 
> Yes.
> -- 
> Jeremy

Mime
View raw message