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.burkhal...@oracle.com> wrote: > > On Jun 24, 2015, at 1:54 PM, Chris Hegarty <chris.hega...@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 <e...@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
