Join GitHub today
Possible JDK 11 fixes #4138
I see the changed exception as a possible unintentional regression by the JDK team. My preference is to report that upstream & see if they agree.
If they're gonna fix it then we don't need to change OkHttp and widen more things to be retried. If they aren't going to fix it then we might as well land this.
Jul 13, 2018
1 check passed
added a commit
this pull request
Jul 20, 2018
@wangweij with JDK 11
java version "11-ea" 2018-09-25
@wangweij with JDK 10
@wangweij If observed behaviour has to change so be it. But as a client library that someone hides and simplifies this for users, as much as possible it would be great to have either
a) some stability to the same observed behaviour persists across versions. e.g. keep it the same.
Thanks for looking into this.
As a preparation of TLS 1.3, we rewrote JSSE a lot and you can see many new class names in the stack trace. While the exact type of SSLException is implementation detail, we do believe it's better to make it consistent. I cannot make any guarantee but will try. Thanks for the report.
I've proposed a fix at http://mail.openjdk.java.net/pipermail/security-dev/2018-July/017670.html. If approved hopefully it will be included in EA build 24 of JDK 11, which should be available next Thursday.