Bill,
I've changed quite a few things based on your review:
* removed methods that take a File object and then create a stream
(so I don't have to worry about closing the streams, also it makes
the API too "thick"
* Removed the appended stdout/stderr strings (because it was pretty
useless)
* Fixed the Javadoc
There is one point you made that I disagree with or just don't understand:
/There seems to be no synchronization of the objects shared between the
worker threads and the calling thread.
/I still don't see a problem. we have this situation:
thread1 is writing into an unsynchronized StringBuilder object (there is
one and only one thread writing)
thread2 is reading from the SB whenever it wants.
My position is that there is nothing that either thread can do to either
corrupt the SB object or cause any problems to the other thread. Thus
it is perfectly safe code.
If I'm wrong -- can you explain -- because this stuff comes up pretty
regularly and I would change my practices...
Bill Shannon wrote:
> Byron Nevins wrote:
>> This is a new utility class. It is designed for taking the drudgery
>> out of attaching threads to stdout and stderr of processes created in
>> java.
>
> Sure would be nice if it followed our coding conventions...
>
> There seems to be no synchronization of the objects shared between the
> worker threads and the calling thread.
>
> None of the output streams opened are ever closed.
>
> If I ask for stdout and stderr, I think I want them interleaved in time,
> not accumulated separately and concatenated.
>
> The example in the javadocs uses different method names.
>
> Rather than creating threads directly, should it be using an Executor?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>