Byron Nevins wrote:
>
>
> 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...
>
> Is there something besides the placement of opening curly braces? I
> can't code with them placed raggedly as per the convention. But I *can*
> check it in that way when I'm done.
Keep lines under 80 columns, put spaces around keywords, things like that.
You just have to bite the bullet and learn to code that way to begin with.
Converting at checkin time is a losing proposition.
>> There seems to be no synchronization of the objects shared between the
>> worker threads and the calling thread.
>
> There are no shared objects, or at least there is no shared /changing
> /of objects. I don't see any potential problems. Do you see a problem???
Oh ya, many.
The lists of streams can be modified while the worker threads are running.
The StringBuilders are read and written by different threads. If you
used StringBuffers they'd at least be thread safe.
You might want to point FindBugs at this code and see what it says.
>> If I ask for stdout and stderr, I think I want them interleaved in time,
>> not accumulated separately and concatenated.
>
> It's too difficult/messy to do that. The caller can instead create the
> process with ProcessBuilder, use ProcessBuilder.redirectErrorStream()
> and then grab the stdout String (getOut()) for interleaved output.
Then it probably doesn't make sense to have a method that returns both
of them together.