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

[Brian Burkhalter]

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 <vita...@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 <vita...@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.