[9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

[Vitaly Davidovich]

I must say it's a bit odd seeing an atomic field in an otherwise
non-threadsafe class.  To be pedantic, what's to prevent close (being
called on a different thread from one that allocated the filtered output
stream) from seeing inconsistent out field values (assume the stream was
published unsafely)? Readers/maintainers of this class may question why
this sole bit is covered via an atomic but rest of class isn't.

sent from my phone
On Jun 24, 2015 8:09 PM, "Brian Burkhalter" <brian.burkhalter at oracle.com>
wrote:

>
> On Jun 24, 2015, at 1:54 PM, Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
>
> > The changes themselves look ok to me. Maybe the test could exercise
> FilterOutputStream directly too?
>
> I have updated the patch to exercise FilterOutputStream as well:
>
> http://cr.openjdk.java.net/~bpb/8042377/webrev.01/
>
> Barring objections to the contrary, I will plan to push it as-is tomorrow,
> Pacific Time.
>
> On Jun 24, 2015, at 2:48 PM, Bernd Eckenfels <ecki at zusammenkunft.net>
> wrote:
>
> > I cannot speak about using AtomicBoolean in such basic classes, but I
> > generally would have done the same as I think that concurrent close()
> > is something which is not unlikely even for otherwise not thread safe
> > streams.
>
>
> Thanks for the corroboration.
>
> Brian