On 11/28/2011 11:27 AM, Xuelei Fan wrote:
webrev: http://cr.openjdk.java.net/~xuelei/7115524/webrev.02/
I think the class is special in that in the class the client is not
really want to establish a HTTPS/TLS connection with the server. The
purpose of the class is to get the server certificate. It does not
matter whether the TLS connection is negotiated or not. So the class
only need a parser that can read the server certificate during the TLS
handshaking. The "security" functions (for example, encryption
decryption digest, etc.) do not make sense. In such situation, we really
don't mind what's the underlying providers.
Does it make sense?
Yes.
But I really don't think you need to change this behavior. If this class
is not used by anyone else except KeyTool, there is no difference
between a static field and a local variable. I really don't like static
fields.
I make a update, so that even the TLS handshaking failed or other IO
exceptions, once we are able to get the server certificate, we will use it.
This is good, and you can add a comment on this.
Thanks
Max
Thanks,
Xuelei
On 11/27/2011 10:31 PM, Xuelei Fan wrote:
On 11/27/2011 7:07 PM, Weijun Wang wrote:
On 11/27/2011 05:48 PM, Xuelei Fan wrote:
Sent from my iPad
On Nov 27, 2011, at 5:01 PM, Weijun Wang<weijun.w...@oracle.com> wrote:
Anyway, I find this a little unsafe. One can add a new SSL security
provider at run time, and then run this method, and the new provider
can be loaded.
I did not follow your ideas. The new provider is loaded, and what's
the worries then?
Typo, I meant "cannot".
1. Run this method, the default SSL provider loaded
2. Add a new SSL security provider
3. Run this method again, still the old provider.
Got it. But this class is very special in that the security provider may
be useless.
It is a little complicated. I will call you tomorrow to explain more. I
think we still have space to improve the stability and performance based
on the latest update.
Thanks,
Xuelei
