Whoa, I was just trying to fix the System.exit() problem :)
I agree with you that there is a bit too many responsibilities for one object, and that parsing of arguments should be separated from execution of logic. However, I don't think that I should attack the separation of establishing a remote connection and driving the wire protocol as part of this bug. I think we should log a separate bug for that issue, I think it's a great thought for a more flexible design.
I tend to agree. KISS for now and let's tackle the bigger issue when it has had a bit more thought.
<snip/>
However, other Derby tools, however, like ij and dblook, don't have this command-based interface. They do need some kind of "execute" method that matches the way it is invoked from the command-line. As discussed, if the behavior of exit status when returning from main() is well defined by the Java spec, then we can just use main with no call to System.exit(). Otherwise, we should provide a separate execute() method for embedding applications.
ij seems wierd to me as I would expect an app just to use raw JDBC - perhaps commands to execute a script would be useful.
If we decide upon a separate execute() method, my question still is, what is the easier way to invoke this execute method, using an arg array, or by instantiating an instance and setting bean properties? I think this is an indepedent question from any separation of concern issues within the tool itself. I personally think an arg array is easier, but perhaps I'm missing an important architectural issue.
What I don't like with the arg array is the lack of context and type safety.
For example, I find
cmd.execute(new String[]{"-p", "1567", "-h", "localhost" })less meaningful than
cmd.setPort(1567);
cmd.setHost("localhost");
cmd.execute();and probably harder to implement when you add in error checking.
-- Jeremy
