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 23:46:14 GMT


Kathey Marsden wrote:

> David Van Couvering wrote:
> 
> 
>>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.
>>
> 
> 
>>DB2jServerImpl.main(new String[] { "ping", "-p", "2000"} );
>>
>>rather than
>>
>>DB2jServerImpl impl = new DB2jServerImpl()
>>impl.setCommand("ping");
>>impl.setPort("2000");
>>impl.execute();
>>
> 
> DB2jServerImpl  is not a public class. NetworkServerControl is where the
> public api lives, so if we did use the JavaBean
> or execute approach the methods would live  there.

OK, point taken.

> 
> 
>>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
>>{
> 
> 
> I feel a little funny about NetworkServer being called a tool, but maybe
> it's ok for NetworkServerControl  (a tool that controls the server?). 

Names are always a struggle.  I was thinking the same thing, actually. 
On the drive home, I thought that perhaps BaseMain was a better name for 
the base class.  It's "something that has a main routine."

> 
> 
>>  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
> 
> 
> Should this be:
>     public static void execute(String[] args) throws Exception?

Yes, sorry

> 
> 
>>  {
>>    // yada yada
>>  }
>>}
>>
>>and then applications can do
>>
>>MyTool.execute(new String{ "ping" });
>>
>>Comments?
> 
> 
> Well my comment is that I am glad I took this off the starter task list
> when I saw you picked it up.

:)

> 
> But I  have a question.  With regard to Network Server, would this just
> be an additional way to control network server if you would prefer to
> use execute instead of the existing NetworkServerControl API?  If so, 
> would one be preferred over the other?

Well, I am still learning Derby, but I did have the same question.  I 
assumed Eclipse had a reason for going this route.  To be honest, I am 
concerned that we are trying to bend over backwards for the Eclipse 
folks when we should be telling them how to use this in the right way.

I am going to push harder with the J2SE team to try and find an answer 
about the specified behavior for exit status when you return from 
main(), but in general it seems like a bad idea to call main() of a 
tool, and you shouldn't be that surprised if it does a System.exit() to 
set the exit status...

> 
> I asked Rajesh to respond regarding his original Eclipse requirements,
> but while the execute thing sounds interesting, I  wonder how it
> addresses the Eclipse calling model?  Maybe  a static method is all that
> is needed and  execute would suffice if it is a static method.

See above, I'd like to understand their requirements and why they aren't 
calling NetworkServerControl directly, which would solve their problems.

Not that we still shouldn't fix this and have a general policy about 
embedding classes with main() methods.

> 
> 
> Still also I wonder about  what Dan said:
> 
> Never make assumptions that your Java program is controlling the JVM and
> has the right to call methods like System.exit, then multiple Java
> "main" programs can hook up together without problems.

Yes, that's fair, but if we have a documented mechanism for embedding 
the programs using a different method, then we get the best of both 
worlds: we can control exit status if main() is called, and we can be 
embedded.

This of course hinges on whether or not the exit status of a VM is 
defined when you throw an exception (or not) from main().  If it's 
well-defined, then we can just have main() throw Exception and be done 
with it.

> 
> 
> I guess that is how I would like to see it in an ideal world. Maybe that is not possible,
but   I would like to hear a little bit more input before we make such a decision about the
public API's.  

I'll try to get an answer from the J2SE folks.  In meanwhile I'll put 
this task on hold and go work on something else :)

David

> 
> 
> Thanks
> 
> Kathey
> 
> 

Mime
View raw message