> On Oct 15, 2018, at 6:01 PM, Chris Hegarty <chris.hega...@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.fu...@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
>>>
