OpenJDK11u: Backward incompatible behavior

Alexey Bakhtin alexey at
Wed Feb 26 12:22:47 UTC 2020

Hello Xuelei,

Thank you for review.

getSession() method is implemented identically to JDK8, so it's behaviour is backward compatible to JDK8

I have updated review with some modifications:
1) Enabled sun/security/ssl/SSLSocketImpl/ jtreg test. This test emulates socket timeout during handshake and app data transfer.
2) I have added cache for incoming data received from socket ( class). Socket timeout could happen while reading single handshake message by small chunks. It is implemented similarly to JDK8 and allows to pass sun/security/ssl/SSLSocketImpl/ClientTimeout test
3) I have added SocketTimeoutException handling into sun/security/ssl/SSLSocketImpl/ jtreg test. This test also verifies SocketExceptions during handshake.

Webrev for JDK11 :

Webrev for JDK15 :

Tested with sun/security/ssl and javax/net/ssl jtreg tests

Thank you

> On 25 Feb 2020, at 19:42, Xuelei Fan < at> wrote:
> > JDK11 webrev:
> Maybe, the getSession() could throw InterruptedIOException as well.
> I may try to catch the InterruptedIOException, rather than handle it in the IOException catching block.
> Thanks,
> Xuelei
> On 2/24/2020 11:04 AM, Alexey Bakhtin wrote:
>> Hi Xuelei,
>> Thank you. It would be glad if you can review this fix.
>> The patch almost cleanly applied to JDK15.
>> Also, As Kumar mentioned, the patch does not include regression test.
>> I’m going to add regression test and patch for JDK15 tomorrow.
>> Thank you.
>> Alexey
>>> On 24 Feb 2020, at 21:41, Xuelei Fan < at> wrote:
>>> Hi Alexey,
>>> Thanks for working on this issue.  Do you plan to fix it for JDK 15, the current JDK reposiroty?
>>> I need more time for evaluate the fix.  For example, I'm not sure if we could always throw InterruptedIOException to applications, even for getSession().
>>> Regards,
>>> Xuelei
>>> On 2/24/2020 7:58 AM, Alexey Bakhtin wrote:
>>>> Hello,
>>>> 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,
>>>> Alexey
>>>>> 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.
>>>>> Thanks,
>>>>> Xuelei
>>>>> 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 <>.
>>>>>> Overview:
>>>>>> 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.
>>>>>> Thank
>>>>>> Kumar Srinivasan
>>>>>> VMware

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <>

More information about the security-dev mailing list