Hi everyone, I'd like to have people's opinions on some of the changes that I did to it: The code has been switched from Input/OutputStreams to Reader/Writer. Do people want to be able to define a particular charset when the transfer is done? Right now the default charset is being used.
The code asks for Writer for stdout and stderr instead of StringBuffer. Giving a StringWriter is much the same as giving a StringBuffer (you can recover a StringBuffer from it). Would people really want to be able to send a StringBuffer directly? Same for the Reader for the input. You can send a StringReader to do much the same, but would people want to be able to send a String directly? The advantage of the changes are 2 fold: 1- It avoids the deprecation of StringBufferInputStream. 2- It allows to define arbitrary inputs and outputs, not just String(Buffer). For example, sending a huge output to a file directly. I personally think that the class in a good shape now (I hope no one has started using the API that I just broke yet). Francois On Tue, 2003-08-12 at 07:27, Thomas Down wrote: > Hi... > > There seems to be quite a bit of interest in this subject, so > I thought I'd post an update. > > Francois Pepin has kindly merged in some functionality from > ExecRunner. You can now specify a single command line > String, instead of an arguments array, and on Windows > platforms that will be processed using the appropriate > shell. > > I've also added a timeout facility to kill long-running jobs. > This is slightly different from ExecRunner: timeouts are > specified when calling the ProcessTools.exec method, and > you get a ProcessTimeoutException if the time limit is > exceeded. This is implemented using a `time bomb' pattern, > which should be very efficient on any platform that has > a vaguely sane threading library, so I'd encourage anyone > writing pipeline-type code to consider setting sensible timeouts > on their processes. > > There are a few (Unix-centric) examples in demos/process/ > > Thomas. > _______________________________________________ > Biojava-l mailing list - [EMAIL PROTECTED] > http://biojava.org/mailman/listinfo/biojava-l _______________________________________________ Biojava-l mailing list - [EMAIL PROTECTED] http://biojava.org/mailman/listinfo/biojava-l
