BTW, Jeremy, the main use of ij as an embedded class is the test harness. It uses ij to read scripts and print results. A significant part of our testing is done that way... and right now the harness calls ij.main(args)...
The other annoying thing about ij as the tool used by the harness, while I'm on the subject, is that it depends heavily on properties for arguments -- things are specific as system properties or in a properties file. This makes it very hard to run different instances of ij with a different configuration. I was forced to generate a different properties file for each thread. ij also does connection pooling, so if you try to run say four different instances of ij and you want each instance to go against a different database, you get some very unexpected results. I learned this the hard way when I tried to use the test harness infrastructure to build a test that scales across multiple databases in the same VM. Basically not achievable with ij. I guess I should log a bug and stop whining... :)
David
[EMAIL PROTECTED] wrote:
Jeremy Boynes skrev:
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.
I totally agree with you. Also, if you write
cmd.setProt(1567); cmd.setHots("localhost"); cmd.execute();
you will get an error at compile time, whereas if you write
cmd.execute(new String[] { "-P", "1567", "-H", "localhost" });
the best you can hope for is an exception at runtime.
