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

[Vitaly Davidovich]

Right, but that's just to no-op duplicate close() calls which makes sense
to me since there's no way to query the output stream to see if it's
closed.  But that version wasn't trying to deal with (rightfully IMO given
this class isn't threadsafe) concurrent calls to close() from different
threads.

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

> To be picky about it, it is not exactly locking but a very similar pattern:
>  158     public void close() throws IOException {
>  159         if (closed)
>  160             return;
>  161         closed = true;
> On Jun 24, 2015, at 6:16 PM, Vitaly Davidovich <vitalyd at gmail.com> wrote:
> > Sorry, where was the double checked locking in FilterOutputStream? I see
> a plain "closed" boolean before.
> >
> > sent from my phone
> >
> > The intent here was to fix a specific problem of exception throwing in
> close(). Prior to this, re-closing the stream was “protected” by double
> checked locking. Extending coverage of synchronicity problems to the rest
> of the class could be addressed in the context of another issue, yet to be
> filed, should this be deemed desirable.
> >
> > On Jun 24, 2015, at 5:34 PM, Vitaly Davidovich <vitalyd at gmail.com>
> wrote:
> >
> > > 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.
>
>