Re: RFR 8048621: Implement basic keystore tests

Hi Xuelei, Can you help to push this code for me? Full comments: 8048621: Implement basic keystore tests Reviewed-by: Xuelei Fan Contributed-by: Zaiyao Liu Thanks Kevin 于 2014/9/3 12:36, Xuelei Fan 写道: Looks fine to me. Thanks, Xuelei On 9/3/2014 10:57 AM, zaiyao liu wrote: Hi Xuelei,

Re: RFR 8048621: Implement basic keystore tests

Looks fine to me. Thanks, Xuelei On 9/3/2014 10:57 AM, zaiyao liu wrote: > Hi Xuelei, > > Thanks for review, please review the update: > http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev02/ > > Thanks > > Kevin > 于 2014/9/1 17:42, Xuelei Fan 写道: >> Providers.java >> --- >>

Re: RFR 8048621: Implement basic keystore tests

Hi Xuelei, Thanks for review, please review the update: http://cr.openjdk.java.net/~tyan/kevin/JDK-8048621/webrev02/ Thanks Kevin 于 2014/9/1 17:42, Xuelei Fan 写道: Providers.java --- May be not necessary to define Providers.SUN_JCE, Providers.SUNPKCS11_SOLARIS. As add unnecessary

Re: JEP Review Request: OCSP Stapling for TLS

hello, this is good news! jut a quick question before I prepare a full response. There is a "tunables" section mentioned in the JIRA which is not very concrete, is there a draft somewhere for it? Because, I would add as a sample/recommended tunable the option to deny for ServerSockets to respon

Wildcard in subjectAltName/dNSName

The following command would fail, rejecting the wildcard in dNSName keytool -genkeypair -ext SAN=DNS:*.example.com . keytool error: java.lang.RuntimeException: java.io.IOException: DNSName components must begin with a letter RFC5280 $4.2.1.6. contains a paragraph vaguely talking abou

JEP Review Request: OCSP Stapling for TLS

Hello all, The draft JEP "OCSP Stapling for TLS" has been opened up for community review. This is an update to the original call for comments back in mid-March this year[*]. Like some of the other early JEPs this year, this has been brought under the JEP 2.0 process. https://bugs.openjdk.j

Re: Review request for CR 8049039 Need new tests for sun.securiy.x509 classes

On 8/27/14 8:34 AM, raghu k.nair wrote: Hi Vincent / Jason, Please review the updated webrev based on Jason's comments. webrev: http://cr.openjdk.java.net/~tyan/raghu/8049039/webrev02/ Thanks, Raghu Nair On 8/27/2014 9:43 AM, ra

Re: RFR (XS) : 8057076 : Correct exception message in CertAndKeyGen.java

Looks good. --Sean On 09/02/2014 02:47 PM, Seán Coffey wrote: https://bugs.openjdk.java.net/browse/JDK-8057076 As per earlier discussion today, a simple update to the exception message used in JDK 9. diff --git a/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java b/src/

Re: Replace concat String to append in StringBuilder parameters

I believe yes. Using the -XX:+OptimizeStringConcat: java -jar -XX:+OptimizeStringConcat target/microbenchmarks.jar ".*StringBuilderConcatBenchMark.*" -wi 10 -i 10 -f 1 The same thing happened: Benchmark Mode Samples Mean Mean errorU

RFR (XS) : 8057076 : Correct exception message in CertAndKeyGen.java

https://bugs.openjdk.java.net/browse/JDK-8057076 As per earlier discussion today, a simple update to the exception message used in JDK 9. diff --git a/src/java.base/share/classes/sun/security/tools/keytool/CertAndKeyGen.java b/src/java.base/share/classes/sun/security/tools/keytool/CertAndKey

Re: RFR : 8054019 Keytool Error publicKey's is not X.509, but X509

On 02/09/2014 17:17, Sean Mullan wrote: That seems fine to me. While you are in there, it would also be nice to fix the grammar of the exception message, ex: "public key format is " + publicKey.getFormat() + ", must be X.509/X509"); Will do. Thought about adding X.509 to message that but th

Re: RFR : 8054019 Keytool Error publicKey's is not X.509, but X509

That seems fine to me. While you are in there, it would also be nice to fix the grammar of the exception message, ex: "public key format is " + publicKey.getFormat() + ", must be X.509/X509"); and open another bug to correct that in JDK 9. Thanks, Sean On 09/02/2014 11:52 AM, Seán Coffey wrot

RFR : 8054019 Keytool Error publicKey's is not X.509, but X509

I'd like to bring this change into 7u only. The 7u40 7109096 fix introduced tighter conditions around Key.getFormat(). Some interoperability issues have been seen for key generators that mightn't strictly honour the ASN.1 data format of X509 keys. As a result, I don't think the restriction was su

Re: Request for review : 8054817: File ccache only recognizes Linux and Solaris defaults

Looks fine to me. --Sean On 09/02/2014 05:55 AM, mala bankal wrote: HI Max, All, Request to review the changes for the backport of 8054817 to jdk7u-dev. webrev : http://cr.openjdk.java.net/~mbankal/8054817/webrev.00/ JDK9 changeset : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ec98f141c757 J

Request for review : 8054817: File ccache only recognizes Linux and Solaris defaults

HI Max, All, Request to review the changes for the backport of 8054817 to jdk7u-dev. webrev : http://cr.openjdk.java.net/~mbankal/8054817/webrev.00/ JDK9 changeset : http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ec98f141c757 JDK8 changeset : http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/ec98f141c7

Re: TLS extensions API, ALPN and HTTP 2.0

Your OCA is still being processed. When that has completed your name will be listed at: http://www.oracle.com/technetwork/community/oca-486395.html#b Until then, we can discuss these TLS/HTTP issues but we cannot include your APIs or source code. Thanks. On 2 Sep 2014, at 09:15, Simone Bor

Re: TLS extensions API, ALPN and HTTP 2.0

Hi, On Wed, Aug 20, 2014 at 1:03 PM, Simone Bordet wrote: > On Tue, Aug 19, 2014 at 4:11 PM, Vincent Ryan > wrote: >> Finally, please confirm that you have already signed the OCA [1] > > I have not yet, it's running through legals ATM. > I'll notify when this is done. I emailed the signed OCA.