OpenJDK11u: Backward incompatible behavior

Kumar Srinivasan kusrinivasan at
Mon Feb 24 16:32:03 UTC 2020

Hi Alexey,

Thanks for the update. I glossed over the changes.

Observation: I don’t see a regression test in your webrev, is this still a work in progress ?

I am very surprised, how a simple socket feature such as this, escape the JSN-test dragnet in the first place ?


On Feb 24, 2020, at 7:58 AM, Alexey Bakhtin <alexey at<mailto:alexey at>> wrote:


I have been working on this issue for some time already.
The patch below adds handling during TLS handshake negotiation. This functionality seems to have been missed during the TLSv1.3 implementation ( JDK-8196584 )
Tested with JDK11 and higher.

JDK11 webrev:

jbs: and

Thank you,

On 22 Feb 2020, at 15:00, security-dev-request at<mailto:security-dev-request at> wrote:

I will look into the issue.

BTW, I closed JDK-8239788 as duplicate of JDK-8239798.


On 2/21/2020 9:24 AM, Kumar Srinivasan wrote:
Hi security-folk,

At VMware while upgrading our application to OpenJDK11u, we have
encountered what seems to be a serious behavior issue.
The issue AFAICT seems to have stemmed from the work for TLS1.3 and
JDK-8196584 <>.

With OpenJDK11 the end-points are closed immediately with TLS alerts
raised when an exception is received.
This is not the case with JDK8 the socket is not closed allowing retries.

I have filed: JDK-8239798 (with a reproducer), this issue was also
reported ?to Azul and they have filed: JDK-8239788.

Can you please evaluate this at the earliest, this is a serious show
stopper for VMware.

Kumar Srinivasan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the security-dev mailing list