[8u] TLSv1.3 RFR: 8245477: Adjust TLS tests location

[Martin Balao]

Hi Alexey,

On Wed, Jul 22, 2020 at 11:55 AM Alexey Bakhtin <alexey at azul.com> wrote:
>
> Please find updated patch for JDK-8245477: http://cr.openjdk.java.net/~abakhtin/tls1.3/8245466/8245477/webrev.v1/
>

Thanks for submitting the series of patches related to TLS tests. I'm
trying to understand the rationale behind each step and have some
questions.

1) Those tests relocated as part of Step 9 - 8245477, are 8u tests or
did you replace them with newer JDK-11 versions in a single step?

2) Is there any other change in addition to relocation and 'references
to keystore and template files' modifications? My understanding is
that they are just JDK-8 relocated tests with some fixes only to pass,
but there is nothing new on them.

3) Should we expect all tests passing in Step 9? If not, why? I read
'no regression' in your first comment but that does not say whether
they are all passing or not.

4) I've seen tests that were relocated in Step 9 (and fixed), deleted
in Step 10 and added as new files in Step 11 (i.e.
RejectClientRenego.java). How did you decide which tests had to be
relocated, which had to be deleted in Step 10 and which had to be
added in Step 11?

5) Was any test not relocated in Step 9, not deleted in Step 10 or not
added in Step 11? Why?

6) What would be the downside if we just delete
test/sun/security/ssl/* (and any other directory whose tests are
SSL-related) and in the next step add them from JDK-11?

The problem here, from a reviewer's side, is that I need a criteria to
judge these test relocations. This criteria would be the 8u backport
of 8032473, but I'm not sure that we are aligned on that. 8032473
won't apply cleanly and it's a mega-patch. If we are doing relocations
to proceed with file replacement later (by file replacement I mean
deleting everything in one step and adding all in the next), we can
simplify things and do file replacement now agreeing on which are the
SSL-related directories. In example: why not deleting
"sun/security/ssl" and adding (from JDK-11) "sun/security/ssl",
"sun/net/www/protocol/https", "javax/net/ssl" and "com/sun/net/ssl"?
Note: there can be tests that fail because they expect a different
public API. But that is unavoidable.

NOTE: I'm just brainstorming, not convinced yet of anything.

Thanks,
Martin.-