RFR[12] JDK-8211978: move testlibrary/jdk/testlibrary/SimpleSSLContext.java and testkeys to network testlibrary

[Weijun Wang]

> On Oct 15, 2018, at 6:01 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> 
> On 15/10/18 10:53, Weijun Wang wrote:
>> This is bad.
> 
> In the absence of better test library, module-patching,
> and jtreg support, this is what we end up with. It's
> not too bad.

I meant this is unfortunate, or this is a bad situation. No complaint to the tests themselves.

> 
>> Maybe we can duplicate the ASCII-fied data. I don't have a strong opinion now.
> 
> Duplicating the testkeys, regardless of ASCII-ification
> seems worse than the duplication of this small trivial
> implementation class.

I understand the duplication of the class is inevitable anyway now. Just thought if the data should be duplicated too. On one hand it's about ASCII-ification, also, it's about test maintaining. Every time I see "../../.." I feel scared.

Thanks
Max

> 
> -Chris.
> 
>> --Max
>>> On Oct 15, 2018, at 5:21 PM, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
>>> 
>>> Hi Max,
>>> 
>>> These tests are whitebox tests - the tests classes are patched
>>> into the java.net.http module, and as a consequence they can't
>>> compile against library classes which are on the classpath.
>>> This is the unfortunate reason for the presence of a
>>> SimpleSSLContext clone in there.
>>> 
>>> best regards,
>>> 
>>> -- daniel
>>> 
>>> On 15/10/2018 03:53, Weijun Wang wrote:
>>>> Hi John
>>>> I see testkeys is directly referenced in AbstractSSLTubeTest.java and FlowTest.java by an inner class also named SimpleSSLContext. Is it very different from the one in SimpleSSLContext.java? Can they be combined?
>>>> If so, then we have a chance to ASCII-fy the testkeys file and directly include it inside SimpleSSLContext.java. This way we can delete one more binary file and do not need to care about file permissions. What a marvelous gain would that be!
>>>> Thanks
>>>> Max
>>>