Hi Artem,
Please find the new webrev [1].
This test has been refactored significantly. It supports more cipher
suites, and case combinations among the TLS communication parameters.
For more details, please look through README [2].
[1] http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/
[2]
http://cr.openjdk.java.net/~jjiang/8186057/webrev.04/test/jdk/javax/net/ssl/compatibility/README.html
Best regards,
John Jiang
On 07/09/2017 18:47, sha.ji...@oracle.com wrote:
Hi Artem,
On 07/09/2017 16:28, Artem Smotrakov wrote:
In case of SNI, SSLParemeters.setServerNames() method (and others
related to SNI) was introduced in 8. I don't think the code which use
this method can be compiled with 6 and 7.
All of Java source are compiled by a JDK 10 build, which is specified
by jtreg option "-jdk". Other testing JDKs, including 6 and 7, just
use the .class files on runtime.
That's why the below line exists in Compatibility.java,
32 * @compile -source 1.6 -target 1.6 Server.java Client.java
JdkUtils.java
But if you want to test SNI with 8+, you need to call them.
https://docs.oracle.com/javase/8/docs/api/javax/net/ssl/SSLParameters.html#setServerNames-java.util.List-
If a feature, like ALPN and SNI, is not supported, such method would
not be called on runtime.
Best regards,
John Jiang
Artem
On 09/07/2017 11:24 AM, sha.ji...@oracle.com wrote:
Hi Artem,
On 07/09/2017 16:07, Artem Smotrakov wrote:
- Please use try-with-resources if possible (files, sockets, etc)
The test uses only JDK 6-supported language features, but
try-with-resources is introduced by JDK 7.
Here we come to another issue. I believe that it would be good to
use write clients for all JDK versions. If you use the same code
for all Java versions, that means that you use only JDK 6 API.
Let's consider the following:
- we want to test 8 vs 9
- 8 and 9 may have some API (or just functionality) which is not
supported by 6 (for example, ALPN, SNI)
If you write code which is compatible with 6, then you can use API
from newer versions, but we still may want to test it.
In fact, the current test has already covered ALPN, though only JDK
9 and 10 support the associated methods, like
SSLParameters.getApplicationProtocols().
ALPN-associated case combinations are ignored if a JDK doesn't
support this feature. Exactly, JdkUtils checks if a specific JDK
build contains method SSLParameters.getApplicationProtocols().
I think the same approach could be applied for SNI in the future.
Best regards,
John Jiang
Artem
Best regards,
John Jiang
Artem
On 09/07/2017 08:52 AM, sha.ji...@oracle.com wrote:
Hi,
Please review this test for checking the interop compatibility
on JSSE among different JDK releases (from 6 to 10).
It covers the cases, like handshake, data exchange, client
authentication and APLN, on all TLS versions (if possible).
And the selected TLS cipher suites are:
TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA
and TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA.
For more details, please look though the README.
Webrev: http://cr.openjdk.java.net/~jjiang/8186057/webrev.00
Issue: https://bugs.openjdk.java.net/browse/JDK-8186057
Best regards,
John Jiang
