> On 26 Jul 2019, at 19:36, Alan Bateman <alan.bate...@oracle.com> wrote:
>
> The bug summary might be a big misleading as SequenceInputStream isn't thread
> safe and close isn't atomic. The changes are really to attempt to close all
> the remaining streams rather than bailing out when closing one of them fails.
I'm not a native English speaker and I used this word as a synonym to
"indivisible". In this particular case "all or nothing". Am I using it wrong?
Or are you saying that the word "atomic" is owned exclusively by the concurrency
domain? What word (or phrase) would you use in this case?
The aim of the subject line is to convey the crux of the issue succinctly. I
hope no one goes and fixes the issue after reading just the subject line without
looking any further into "details" and "description".
> In any case, the change looks okay but it might be simpler to restructure to
> use:
>
> while (in != null) {
> try { in.close() } catch (IOException e) { ... }
> peekNextStream();
> }
>
> to simplify the error handling and avoid mixing nextStream and peekNextStream.
Possibly.
> There is also some curious code in peekNextStream where it handles
> nextElement returning null - I don't know the history on that but it looks
> like it's trying to handling a broken Enumeration.
I wouldn't touch that code. In the case of `peekNextStream` we could only remove
the needless cast (generics) without compromising compatibility.
