[Biojava-l] Running apps with Java
Francois Pepin
fpepin at cs.mcgill.ca
Mon Aug 11 11:03:55 EDT 2003
I have code that did that, but it wasn't reliable enough to use like
that. For unknown reasons, there are programs that I couldn't call at
all.
The only reliable method that I found was to write a one-liner shell
script to be executed by sh, but this is an ugly, ugly hack.
The grabbing of stdin and stdout wasn't working as advertised either.
This is with Linux. I don't know about Windows, but I'm sure I'm not the
only one who needs to call Linux apps.
Maybe like Mark said it got more reliable with 1.4.
Personally I'd much rather use a system like that than to have to depend
on Perl or Python to do it.
Francois
On Mon, 2003-08-11 at 04:11, Thomas Down wrote:
> On Mon, Aug 11, 2003 at 11:59:46AM +1200, Schreiber, Mark wrote:
> >
> > What is the best way to invoke a native bioinformatics program in
Java.
> > People have reported that controlling processes directly has been
patchy
> > in Java, is this still the case or have JVMs evolved? If not then what
> > is the alternative? Wrapping the program in a perl or python
webservice?
> > If this was the prefered method then we could borrow quite a bit from
> > the Bio::Pipeline::Runnable package.
>
> I think it *is* possible to write good-quality wrappers to
> external tools in Java: it's just that the Runtime.exec
> APIs are substantially more complicated than the equivalents
> in $PREFERRED_SCRIPTING_LANGUAGE. If you're using stdin/stdout/stderr
> on the external program, you need to make heavy use of Threads
> in Java. I think that's the main barrier to entry.
>
> A lot of these issues could probably be addressed by something
> like:
>
> public class ExecTools {
> /**
> * Execute an external program and wait for it to complete.
> *
> * @param args the command line to run.
> * @param input some data to feed to the program's standard input,
> * or null if no data.
> * @param stdout a StringBuffer to receive the program's output,
> * or null to ignore them.
> * @param stderr a StringBuffer to receive the program's error
> * stream, or null to ignore this.
> * @returns the program's return code.
> */
>
> public static int exec(
> String[] args,
> String input,
> StringBuffer stdout,
> StringBuffer stderr
> );
> }
>
> All the necessary thread code for most practical uses of exec could
> be hidden in there. I might code this up this afternoon if nobody
> objects -- it's code I write reasonably regularly, and the API above
> would certainly save me time. Anyone else?
>
>
> As for the web service approach, AppLap might be relevant:
>
> http://industry.ebi.ac.uk/applab/
>
> Thomas.
> _______________________________________________
> Biojava-l mailing list - Biojava-l at biojava.org
> http://biojava.org/mailman/listinfo/biojava-l
More information about the Biojava-l
mailing list