JDK 10 RFR of 8185092: Data race in FilterOutputStream.close

[Brian Burkhalter]

On Jul 26, 2017, at 11:25 AM, Martin Buchholz <martinrb at google.com> wrote:

> Making close exactly-once as you have done is probably the right strategy.
> 
> Probably most of java.io was designed to be "mostly thread-safe" as was common culture back in the last millennium.  There were no "synchronized" in FilterOutputStream probably because previously there was no need!
> 
> For jdk10 VarHandles are probably generally preferred to j.u.c.atomic classes.

A blanket change from atomics could be a separate issue.

> The lack of thread safety specs (and general java.io love) remains a long term big problem.

I noticed your issue comment; this should be filed as another issue, I suppose.

> It's weird to add @bug to a test without changing the test itself.  Is the test really testing this fix?

Yes, it’s weird. It’s not really testing the fix. I was thinking of this change as correcting the patch which fixed the issue linked to this issue which uses the same test. I would actually prefer not to modify the test and instead add the label “noreg-cleanup” as this change seems to be pretty clear.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20170726/9f80c992/attachment.html>