[11u] RFR: 8243029: Rewrite javax/net/ssl/compatibility/Compatibility.java with a flexible interop test framework

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Thu Jul 23 09:04:49 UTC 2020


 Hi Matthias

> Seems jdk11 does only know the name of TLS_CHACHA20_POLY1305_SHA256 but nothing more , the real support came with jdk12.
> Some other folks were struggeling with this too :
> https://jira.mariadb.org/browse/CONJ-721
> 
> Maybe there is a chance to backport it to jdk11 in future   (of course it is a separate issue) ?
On the one side, it would be good if all VMs supported the same certificates.
On the other side, this is a functional change, e.g. as "8140466: ChaCha20 and Poly1305 
TLS Cipher Suites" requires a CSR.  As you probably noted, there are
quite some resistances against downporting functional changes ...
see the Shenandoah discussion.

After my initial RFR, a fix for the test was pushed to jdk/jdk:
https://bugs.openjdk.java.net/browse/JDK-8245005
javax/net/ssl/compatibility/BasicConnectTest.java failed with No enum constant
With this fix the issues I see are fixed.  It should be downported, too.

> Could you file a separate bug  for the readme,  I guess this needs fixing in jdk/jdk too .
The follow up fix also corrects the test name in the README I had
complained about in my first RFR.
Also, I figured that I need not specivy -m to run manual tests, it
sufficies to remove -a from the command line. 
Still mentioning this in the README would be usedufl, but I don't 
feel like opening a change only for this.

I did two adaptions to the change, though:
http://cr.openjdk.java.net/~goetz/wr20/8243029-ssl_test_framework-jdk11/02/
Find the incremental patch below.

Best regards,
  Goetz.

--- a/test/jdk/javax/net/ssl//compatibility/HrrTest.java
+++ b/test/jdk/javax/net/ssl//compatibility/HrrTest.java
@@ -88,8 +88,7 @@
         List<TestCase<ExtUseCase>> testCases = new ArrayList<>();
         for (CipherSuite cipherSuite : new CipherSuite[] {
                 CipherSuite.TLS_AES_128_GCM_SHA256,
-                CipherSuite.TLS_AES_256_GCM_SHA384,
-                CipherSuite.TLS_CHACHA20_POLY1305_SHA256}) {
+                CipherSuite.TLS_AES_256_GCM_SHA384}) {
             testCases.add(createTestCase(cipherSuite));
         }
         return testCases;
--- a/test/jdk/javax/net/ssl//compatibility/README
+++ b/test/jdk/javax/net/ssl//compatibility/README
@@ -21,9 +21,9 @@
 
 ##### Summary #####
 This test is used to check the interop compatibility on JSSE among different
-JDK releases. The oldest version supported by the test is JDK 7. Some of Java
+JDK releases. The oldest version supported by the test is JDK 8. Some of Java
 source files, like JdkInfoUtils.java, JdkProcServer.java and JdkProcClient.java,
-use only JDK 7-compliant language features and APIs, in order to allowing
+use only JDK 8-compliant language features and APIs, in order to allowing
 different JDK releases can load and run associated classes.
 
 ##### Usage #####
@@ -47,7 +47,6 @@
 
 ##### Usage Examples #####
 $ cat /path/to/jdkList
-/path/to/jdk7
 /path/to/jdk8
 /path/to/jdk9
 /path/to/jdk10
@@ -57,6 +56,6 @@
     -Dtest.jdk.list.file=/path/to/jdkList \
     $JDK_WS/jdk/test/javax/net/ssl/compatibility/Compatibility.java
 The above example uses a file "/path/to/jdkList" to contain the paths of local
-different JDK builds through 7 to 10. The execution uses each of JDK builds as
+different JDK builds through 8 to 10. The execution uses each of JDK builds as
 server and client respectively. And it enables SSL debug flag, and tests the
 full parameter value set.


More information about the jdk-updates-dev mailing list