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
