[8u] RFR 8209333: Socket reset issue for TLS 1.3 socket close

Volker Simonis volker.simonis at gmail.com
Wed Jan 13 14:02:38 UTC 2021

Andrew Haley <aph at redhat.com> schrieb am Mi., 13. Jan. 2021, 11:30:

> On 1/12/21 5:46 PM, Volker Simonis wrote:
> > Notice that it is perfectly fine to put an autoclosable resources in
> > the try clause, even if that resource is not used within the try block
> > itself. After all, that's the reason why Java 9 simplified this
> > pattern by extending "try-with resources" to also accept already
> > existing resources as final or "effectively final" variables in the
> > try statement [1]. Nothing obscure at all.
> One person's obscure is another's apogee of clarity, I suppose.
> The problem here, IMO, is that the TWR construct doesn't do
> anything useful: it's only hiding a catch-then-close.
> > In 8 however, we have to declare a new variable for the resource in
> > the try clause, because the Java 9 simplification isn't available. If
> > we were to write new code for jdk8 I could agree with you to use the
> > older, more traditional pattern. But we're reviewing a downport here
> > and for downports we have other priorities:
> >  - keep modifications of a change to a minimum
> >  - try to not impact future downports
> OK, so for you deviations from upstream patches are more important
> than idiomatic JDK8 code. I get that, but in this case the resulting
> code is such that it provokes a warning, which I expect you'll admit
> is something of a red flag. Any backports to a "stable" release that
> generate new warnings are a big deal, IMO, although I grant you that
> this warning is not about anything terribly important.

But this warning is suppress by an annotation as it is already done in
several other places in the 8u code base.

If that's still not acceptable for you I won't argue any further and
recommend David to rewrite his downport as proposed by you. In the end we
only want to fix the underlaying issue.

> > As David mentioned, more backports in this area will follow that's why
> > I think that the code version he presented is the best compromise.
> In this exact area, as in these lines of code or the ones next to
> them? If not, that doesn't matter.
> --
> Andrew Haley  (he/him)
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

More information about the jdk8u-dev mailing list