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.
