> It would not to generate the certificate's ECParameterSpec and NamedGroup
> multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`.
John Jiang has updated the pull request incrementally with one additional
commit since the last revision:
add some co
On Mon, 18 Apr 2022 12:37:15 GMT, John Jiang wrote:
>> It would not to generate the certificate's ECParameterSpec and NamedGroup
>> multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`.
>
> John Jiang has updated the pull request incrementally with one ad
On Sat, 14 May 2022 13:41:38 GMT, John Jiang wrote:
> The below sun.security classes should use `@return` rather than `@returns`.
> sun/security/tools/keytool/Main.java
> sun/security/util/DerValue.java
This pull request has now been integrated.
Changeset: 63bd3b77
Author:John J
The below sun.security classes should use `@return` rather than `@returns`.
sun/security/tools/keytool/Main.java
sun/security/util/DerValue.java
-
Commit messages:
- 8286773: cleanup @returns in sun.security classes
Changes: https://git.openjdk.java.net/jdk/pull/8714/files
Webrev:
> It would not to generate the certificate's ECParameterSpec and NamedGroup
> multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`.
John Jiang has updated the pull request incrementally with one additional
commit since the last revision:
cache ParamSpec and Name
On Sat, 16 Apr 2022 14:38:09 GMT, XenoAmess wrote:
>> It would not to generate the certificate's ECParameterSpec and NamedGroup
>> multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`.
>
> src/java.base/share/classes/sun/security/ssl/SignatureScheme.java line 494:
>
>>
It would not to generate the certificate's ECParameterSpec and NamedGroup
multiple times in method `SignatureScheme::getSignerOfPreferableAlgorithm`.
-
Commit messages:
- 8284926: Share the certificate NamedGroup in
SignatureScheme::getSignerOfPreferableAlgorithm
Changes:
On Thu, 14 Apr 2022 18:08:21 GMT, Xue-Lei Andrew Fan wrote:
>> The log for Finished message looks like the below,
>>
>> "Finished": {
>> "verify data": {
>> : ... ...
>> }'} // looks weird
>>
>> because a line feed is missing in the format pattern.
>>
>> ""Finished": '{'\n" +
>>
On Wed, 13 Apr 2022 05:10:22 GMT, John Jiang wrote:
> The log for Finished message looks like the below,
>
> "Finished": {
> "verify data": {
> : ... ...
> }'} // looks weird
>
> because a line feed is missing in the format pattern.
On Wed, 13 Apr 2022 06:07:43 GMT, Xue-Lei Andrew Fan wrote:
>> The log for Finished message looks like the below,
>>
>> "Finished": {
>> "verify data": {
>> : ... ...
>> }'} // looks weird
>>
>> because a line feed is missing in the format pattern.
>>
>> ""Finished": '{'\n" +
>>
The log for Finished message looks like the below,
"Finished": {
"verify data": {
: ... ...
}'} // looks weird
because a line feed is missing in the format pattern.
""Finished": '{'\n" +
" "verify data": '{'\n" +
"{0}\n" +
" '}'" + // a line feed is needed
"'}'",
-
On Mon, 11 Apr 2022 04:02:44 GMT, John Jiang wrote:
> JDK-8228396 turned stateless resumption on by default, but the JavaDoc was
> not modified accordingly.
> And a "{" is missing for @systemProperty
> jdk.tls.server.enableSessionTicketExtension.
This pull request h
JDK-8228396 turned stateless resumption on by default, but the JavaDoc was not
modified accordingly.
And a "{" is missing for @systemProperty
jdk.tls.server.enableSessionTicketExtension.
-
Commit messages:
- 8284641: Doc errors in sun.security.ssl.SSLSessionContextImpl
Changes:
On Thu, 10 Mar 2022 06:52:14 GMT, John Jiang wrote:
> In class sun.security.ssl.ProtocolVersion, the exception message for
> unsupported protocol needs a space.
>
> ProtocolVersion pv = ProtocolVersion.nameOf(pn);
> if (pv == null) {
> throw new Illega
> In class sun.security.ssl.ProtocolVersion, the exception message for
> unsupported protocol needs a space.
>
> ProtocolVersion pv = ProtocolVersion.nameOf(pn);
> if (pv == null) {
> throw new IllegalArgumentException(
>"Unsupported protocol" + p
In class sun.security.ssl.ProtocolVersion, the exception message for
unsupported protocol needs a space.
ProtocolVersion pv = ProtocolVersion.nameOf(pn);
if (pv == null) {
throw new IllegalArgumentException(
"Unsupported protocol" + pn);
}
-
Commit messages:
-
On Tue, 22 Feb 2022 06:03:33 GMT, John Jiang wrote:
> `contentType` should be a local variable because it is only used in method
> `parse(DerInputStream derin, boolean oldStyle)`.
> This change also improves some exception catch blocks.
This pull request has now been integrated.
On Tue, 22 Feb 2022 06:36:58 GMT, Xue-Lei Andrew Fan wrote:
>> `contentType` should be a local variable because it is only used in method
>> `parse(DerInputStream derin, boolean oldStyle)`.
>> This change also improves some exception catch blocks.
>
> Looks like a trivial update, but please
`contentType` should be a local variable because it is only used in method
`parse(DerInputStream derin, boolean oldStyle)`.
This change also improves some exception catch blocks.
-
Commit messages:
- 8282220: contentType should not be a PKCS7's member
Changes:
On Mon, 21 Feb 2022 08:13:01 GMT, John Jiang wrote:
> JDK-8282158 changed ECParameters' package from sun.security.util to
> java.security by accident.
>
> So sorry for this trouble!
This pull request has now been integrated.
Changeset: 34aae32d
Author: John Jiang
URL:
JDK-8282158 changed ECParameters' package from sun.security.util to
java.security by accident.
So sorry for this trouble!
-
Commit messages:
- 8282166: JDK-8282158 changed ECParameters' package by accident
Changes: https://git.openjdk.java.net/jdk/pull/7552/files
Webrev:
On Mon, 21 Feb 2022 08:06:47 GMT, Jaikiran Pai wrote:
>> John Jiang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> update format
>
> src/java.base/share/classes/sun/security/util/ECParameters.java line 2
On Mon, 21 Feb 2022 04:49:42 GMT, John Jiang wrote:
> sun.security.util.ECParameters class supports three AlgorithmParameterSpec
> types, exactly ECParameterSpec, ECGenParameterSpec and
> ECKeySizeParameterSpec, however the InvalidParameterSpecException messages
> sun.security.util.ECParameters class supports three AlgorithmParameterSpec
> types, exactly ECParameterSpec, ECGenParameterSpec and
> ECKeySizeParameterSpec, however the InvalidParameterSpecException messages
> missed ECKeySizeParameterSpec.
John Jiang has updated the
sun.security.util.ECParameters class supports three AlgorithmParameterSpec
types, exactly ECParameterSpec, ECGenParameterSpec and ECKeySizeParameterSpec,
however the InvalidParameterSpecException messages missed
ECKeySizeParameterSpec.
-
Commit messages:
- 8282158: ECParameters
On Thu, 10 Feb 2022 06:18:28 GMT, John Jiang wrote:
> In class sun.security.x509.X509CRLImpl, method getExtension(ObjectIdentifier)
> doesn't declare that IOException would be thrown, so the @throws IOException
> doc should be removed.
This pull request has now been integrated.
In class sun.security.x509.X509CRLImpl, method getExtension(ObjectIdentifier)
doesn't declare that IOException would be thrown, so the @throws IOException
doc should be removed.
-
Commit messages:
- 8281567: Remove @throws IOException from X509CRLImpl::getExtension docs
Changes:
On Tue, 18 Jan 2022 11:11:49 GMT, John Jiang wrote:
> MessageFormat messageFormat = new MessageFormat(
> ""versions": '['{0}']'", Locale.ENGLISH);
>
> In class SupportedGroupsExtension, the above "versions" should be "named
> groups".
On Tue, 18 Jan 2022 19:52:27 GMT, Weijun Wang wrote:
>>> If so, should the `SupportedVersionsExtension` get a more precise
>>> description as well?
>>
>> I did not get the point. Did you mean to update the comment on the
>> SupportedVersionsExtension, by adding RFC 8446?
>
> No, I just meant
MessageFormat messageFormat = new MessageFormat(
""versions": '['{0}']'", Locale.ENGLISH);
In class SupportedGroupsExtension, the above "versions" should be "named
groups".
-
Commit messages:
- 8280122: SupportedGroupsExtension should output "named groups" rather than
On Wed, 12 Jan 2022 06:57:45 GMT, John Jiang wrote:
> In class `sun.security.ec.ECDHKeyAgreement`, the last `mod()` in the below
> line looks redundant,
>
> BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p);
>
> I think this tiny change just be a code c
> In class `sun.security.ec.ECDHKeyAgreement.java`, the last `mod()` in the
> below line looks redundant,
>
> BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p);
John Jiang has updated the pull request incrementally with one additional
commit since the last revisio
In class `sun.security.ec.ECDHKeyAgreement.java`, the last `mod()` in the below
line looks redundant,
BigInteger lhs = y.modPow(BigInteger.valueOf(2), p).mod(p);
-
Commit messages:
- 8279903: Redundant modulo operation in ECDHKeyAgreement
Changes:
On Mon, 8 Mar 2021 15:27:45 GMT, John Jiang wrote:
> If signature_algorithms extension is present, but the algorithms are
> unreconginzed or unsupported, JSSE peers should send fatal alert immediately.
> For example, in this case, it's unnecssary to try to produce ServerHello,
>
On Mon, 29 Mar 2021 04:42:16 GMT, Xue-Lei Andrew Fan wrote:
>> John Jiang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> TLSv1.2 CertificateRequest could fail fast if no common signature scheme
>>
On Mon, 8 Mar 2021 15:27:45 GMT, John Jiang wrote:
> If signature_algorithms extension is present, but the algorithms are
> unreconginzed or unsupported, JSSE peers should send fatal alert immediately.
> For example, in this case, it's unnecssary to try to produce ServerHello,
>
> If signature_algorithms extension is present, but the algorithms are
> unreconginzed or unsupported, JSSE peers should send fatal alert immediately.
> For example, in this case, it's unnecssary to try to produce ServerHello,
> Certificate and ServerKeyExchange messages.
John Jiang
If signature_algorithms extension is present, but the algorithms are
unreconginzed or unsupported, JSSE peers should send fatal alert immediately.
For example, in this case, it's unnecssary to try to produce ServerHello,
Certificate and ServerKeyExchange messages.
-
Commit
On Sun, 7 Mar 2021 03:26:14 GMT, John Jiang wrote:
> Two typos on SCSV "signgling", which should be "signaling".
This pull request has now been integrated.
Changeset: 22a3117d
Author:John Jiang
URL: https://git.openjdk.java.net/jdk/commit/22a3117d
Stats
Two typos on SCSV "signgling", which should be "signaling".
-
Commit messages:
- JDK-8263137: Typos in sun.security.ssl.RenegoInfoExtension
Changes: https://git.openjdk.java.net/jdk/pull/2860/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk=2860=00
Issue:
On Fri, 19 Feb 2021 08:39:23 GMT, John Jiang wrote:
> Similar to the constructor SNIHostName(String hostname), the constructor
> SNIHostName(byte[] encoded) also needs to check if the encoded hostname
> conform to RFC 3490.
This pull request has now been integrated.
Changeset:
On Tue, 2 Mar 2021 21:36:36 GMT, Rajan Halade wrote:
>> John Jiang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Throw RuntimeException instead of Exception
>
> Thanks for updating the test.
@rhal
On Mon, 1 Mar 2021 03:07:12 GMT, John Jiang wrote:
> Per RFC 8446, section 4.1.2, the legacy_version field in ClientHello message
> MUST be set to 0x0303 (TLSv1.2).
> T13ClientHelloConsumer should do this check like that T13ServerHelloConsumer
> does.
This pull request has now bee
Per RFC 8446, section 4.1.2, the legacy_version field in ClientHello message
MUST be set to 0x0303 (TLSv1.2).
T13ClientHelloConsumer should do this check like that T13ServerHelloConsumer
does.
-
Commit messages:
- JDK-8262509: JSSE Server should check the legacy version in TLSv1.3
On Mon, 22 Feb 2021 22:38:19 GMT, John Jiang wrote:
>> Changes requested by rhalade (Reviewer).
>
> I wouldn't merge the master to this branch :-(
Could the latest patch be reviewed?
-
PR: https://git.openjdk.java.net/jdk/pull/2639
> Similar to the constructor SNIHostName(String hostname), the constructor
> SNIHostName(byte[] encoded) also needs to check if the encoded hostname
> conform to RFC 3490.
John Jiang has updated the pull request incrementally with one additional
commit since the last revision:
On Mon, 22 Feb 2021 16:17:28 GMT, Rajan Halade wrote:
>> John Jiang has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains two addi
> Similar to the constructor SNIHostName(String hostname), the constructor
> SNIHostName(byte[] encoded) also needs to check if the encoded hostname
> conform to RFC 3490.
John Jiang has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev
Similar to the constructor SNIHostName(String hostname), the constructor
SNIHostName(byte[] encoded) also needs to check if the encoded hostname conform
to RFC 3490.
-
Commit messages:
- JDK-8261969: SNIHostName would check if the encoded hostname conform to RFC
3490
Changes:
On Wed, 10 Feb 2021 21:22:03 GMT, John Jiang wrote:
> This is a simple cleanup for sun.security.ssl.SSLExtension.
> The comments for the extension groups would use the RFC numbers and the
> protocol titles correspondingly.
> It also removes a trailing space in extension token_bindi
algorithms_cert to RFC 8446 extension
> group.
John Jiang has updated the pull request incrementally with one additional
commit since the last revision:
A extension group comment uses both of RFC number and protocol title
-
Changes:
- all: https://git.openjdk.java.net/j
> This is a simple cleanup for sun.security.ssl.SSLExtension.
> It converts protocol or draft names to RFC numbers correspondingly.
> It also removes a trailing space in extension token_binding, and move
> signature_algorithms_cert to RFC 8446 extension group.
John Jiang has upda
This is a simple cleanup for sun.security.ssl.SSLExtension.
It converts protocol or draft names to RFC numbers correspondingly.
It also removes a trailing space in extension token_binding, and move
signature_algorithms_cert to RFC 8446 extension group.
-
Commit messages:
-
On Sat, 21 Nov 2020 11:45:42 GMT, Kartik Ohri
wrote:
> Hi!
> Kindly review this patch to replace switch statements with switch expressions
> (where it makes sense) in the http client modules. The rationale is to
> improve readability of the code.
> Regards,
> Kartik
Just a question.
Do we
Hi,
This patch includes a set of new test cases for JEP 288.
The cases just focus on the usage constraints TLSSever and TLSClient
with TLS communication.
Issue: https://bugs.openjdk.java.net/browse/JDK-8165367
Webrev: http://cr.openjdk.java.net/~jjiang/8165367/webrev.00
Best regards,
John
b367b/test/javax/net/ssl/SSLSession/SessionTimeOutTests.java#l78
Best regards,
John Jiang
Please review this patch.
Thanks!
John Jiang
On 2017/1/11 11:35, John Jiang wrote:
Hi,
This patch fixes the intermittent SSLHandshakeException failure for
test sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java.
The fix applies some code patterns in
javax/net/ssl/templates
://bugs.openjdk.java.net/browse/JDK-8167146
Best regards,
John Jiang
the existing method runClientApplication(SSLSocket socket)
could do the same things for method configureClientSocket(SSLSocket socket).
Best regards,
John Jiang
On 2016/12/21 1:18, Xuelei Fan wrote:
Hi John,
I was wondering to add three methods in the template:
. configureClientSocket(SSLSocket socket
://cr.openjdk.java.net/~jjiang/8168935/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8168935
Best regards,
John Jiang
+
# jdk_sound
Best regards,
John Jiang
Hi Xuelei,
Thanks for your comments.
Please review this new webrev:
http://cr.openjdk.java.net/~jjiang/8171043/webrev.01/
Best regards,
John Jiang
On 2016/12/12 13:07, Xuelei Fan wrote:
Hi John,
It's a good catch of the problem. Looks like the server side should
read the HTTP request
,
John Jiang
Hi Sean,
Thanks for your comments.
Please take a look at the new wevrev:
http://cr.openjdk.java.net/~jjiang/8170523/webrev.01/
Best regards,
John Jiang
On 2016/12/3 5:02, Sean Mullan wrote:
Hi John,
I don't think we should modify the test to disable a SecurityManager
and then reenable
ored since the tests think that
the OS is not the target.
Webrev: http://cr.openjdk.java.net/~jjiang/8170523/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8170523
Best regards,
John Jiang
Please review this patch. Thanks!
John Jiang
On 2016/11/19 19:38, John Jiang wrote:
After push for JDK-8168969, this fix has to use updated
SSLSocketTemplate.java.
Please review the updated webrev:
http://cr.openjdk.java.net/~jjiang/8164595/webrev.01
Best regards,
John Jiang
On 2016/10/27
After push for JDK-8168969, this fix has to use updated
SSLSocketTemplate.java.
Please review the updated webrev:
http://cr.openjdk.java.net/~jjiang/8164595/webrev.01
Best regards,
John Jiang
On 2016/10/27 12:36, John Jiang wrote:
Hi,
Please review this patch for test
javax/net/ssl
Hi Artem,
On 2016/11/2 23:54, Artem Smotrakov wrote:
Hi John,
Please see inline.
On 11/01/2016 11:48 PM, John Jiang wrote:
Hi Artem,
Thanks for making the template to be used easily.
The tests in your patch extend class SSLSocketTemplate, but
SSLSocketTemplate looks like an utility class
SSLServerSocket. Why not
provide one more extension point in doServerSide()? Then, it unnecessary
to re-write the whole doServerSide() (or, set a new server peer).
The code talks more clearly. Please take a look at my example:
http://cr.openjdk.java.net/~jjiang/8168969/example/
Best regards,
John Jian
://bugs.openjdk.java.net/browse/JDK-8164595
Best regards,
John Jiang
Hi Artem,
Please take a look at this version:
http://cr.openjdk.java.net/~jjiang/8168064/webrev.02/
It set a new Server peer.
Best regards,
John Jiang
On 2016/10/25 1:33, Artem Smotrakov wrote:
Hi John,
I think it is too late to set parameters for server socket in
setServerApplication
Hi Artem,
Thanks for your review.
Would you like take a look at the updated webrev:
http://cr.openjdk.java.net/~jjiang/8168064/webrev.01/
I also modified SSLTest.java a bit to expose SSLServerSocket instance to
support the fixing.
Best regards,
John Jiang
On 2016/10/22 1:50, Artem Smotrakov
: https://bugs.openjdk.java.net/browse/JDK-8168064
Best regards,
John Jiang
://cr.openjdk.java.net/~jjiang/8165566/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8165566
Best regards,
John Jiang
with the patch.
And Mach5 have run the tests after the patch was pushed, no PKCS11 test
failure was found.
Best regards,
John Jiang
Thanks
Max
[1]
https://bugs.openjdk.java.net/browse/JDK-8023434?focusedCommentId=13860118=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment
/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8077138
Best regards,
John Jiang
,
John Jiang
to JDK-8077138.
Issue: https://bugs.openjdk.java.net/browse/JDK-8163435
Webrev: http://cr.openjdk.java.net/~jjiang/8163435/webrev.00
Best regards,
John Jiang
Hi Xuelei,
Thanks for your review.
On 2016/7/13 11:22, Xuelei Fan wrote:
On 7/13/2016 11:17 AM, John Jiang wrote:
Hi,
Please review this small update for ProblemList.
sun/security/pkcs11/ec/TestKeyFactory.java should be associated to
JDK-8026976 rather than JDK-7157786.
Can you give more
regards,
John Jiang
already used in this case? If
no, then I don't think it's necessary to make a change here.
OK. I won't change this test for this issue.
Thanks for your comments.
Best regards,
John Jiang
Thanks
Max
On 7/11/2016 12:28, John Jiang wrote:
Hi Max,
On 2016/7/9 18:04, Wang Weijun wrote:
I am not sure. If
565
35074
34843
...
With the results, the previous port is not reused by the subsequent
round immediately.
Best regards,
John Jiang
--Max
On Jul 9, 2016, at 3:18 PM, John Jiang<sha.ji...@oracle.com> wrote:
Hi Max,
On 2016/7/8 16:19, Wang Weijun wrote:
The reason a
be occupied by another
DatagramSocket.
Please review the updated webrev:
http://cr.openjdk.java.net/~jjiang/8160029/webrev.01
Best regards,
John Jiang
--Max
On Jul 8, 2016, at 2:35 PM, John Jiang <sha.ji...@oracle.com> wrote:
Hi,
Would you like to review this patch for removing unnec
://bugs.openjdk.java.net/browse/JDK-8160029
Webrev: http://cr.openjdk.java.net/~jjiang/8160029/webrev.00
Thanks!
John Jiang
Ping again ;-)
John Jiang
On 2016/6/28 6:42, John Jiang wrote:
Please review this patch.
Thanks!
John Jiang
On 2016/6/24 16:55, John Jiang wrote:
Hi,
Due to JDK-8134577, the test
sun/security/x509/URICertStore/ExtensionsWithLDAP.java cannot resolve
hosts from a local name service
Please review this patch.
Thanks!
John Jiang
On 2016/6/24 16:55, John Jiang wrote:
Hi,
Due to JDK-8134577, the test
sun/security/x509/URICertStore/ExtensionsWithLDAP.java cannot resolve
hosts from a local name service provider.
This fix creates a simple Socks4 proxy, and use it to resolve
Hi,
Please review this small patch for updating ProblemList.
Issue: https://bugs.openjdk.java.net/browse/JDK-8157665
Webrev: http://cr.openjdk.java.net/~jjiang/8157665/webrev.00/
Best regards,
John Jiang
,
sun/security/pkcs11/fips/CipherTest.java and
sun/security/pkcs11/sslecc/CipherTest.java, have the same race
condition issue.
But, in fact, the scenario in the closed JDK test is different from the
open JDK ones.
I'll close this issue.
Best regards,
John Jiang
On 2016/6/7 9:44, Xuelei Fan
Hi,
Please review this patch. Thanks!
John Jiang
On 2016/6/2 20:54, John Jiang wrote:
Hi,
Please review this updated webrev:
http://cr.openjdk.java.net/~jjiang/8158462/webrev.01
I just updated the year in copyright notice.
Best regards,
John Jiang
On 2016/6/2 14:11, John Jiang wrote:
Hi
Hi,
Please review this updated webrev:
http://cr.openjdk.java.net/~jjiang/8158462/webrev.01
I just updated the year in copyright notice.
Best regards,
John Jiang
On 2016/6/2 14:11, John Jiang wrote:
Hi,
Please review this patch on resolving possible race condition for the
following tests
://bugs.openjdk.java.net/browse/JDK-8158462
Best regards,
John Jiang
regards,
John Jiang
Thanks,
Valerie
On 5/22/2016 11:43 PM, John Jiang wrote:
Hi,
Please review the patch for
sun/security/provider/NSASuiteB/TestDSAGenParameterSpec.java timeouts
intermittently.
TestDSAGenParameterSpec.java tests DSA parameter generation, so it's
no need to generate keys
/JDK-8137255
https://bugs.openjdk.java.net/browse/JDK-8157333
Webrev: http://cr.openjdk.java.net/~jjiang/8137255/webrev.00
Best regards,
John Jiang
Hi,
This test failed several times, and it's better to put it to ProblemList
until the issue is resolved.
Please review this patch, thanks!
Best regards,
John Jiang
On 2016/4/1 15:58, John Jiang wrote:
Hi,
Because of JDK-8137255, it needs to add test
sun/security/provider/NSASuiteB
+
# jdk_sound
Best regards,
John Jiang
Valerie,
Thanks for your review.
Best regards,
John Jiang
On 2015/9/24 3:51, Valerie Peng wrote:
Updated webrev looks fine.
Thanks,
Valerie
On 9/22/2015 10:21 PM, John Jiang wrote:
Hi Valerie,
Thanks for your comments.
Please review the updated patch at
http://cr.openjdk.java.net/~fyuan
Hi Valerie,
Thanks for your comments.
Please review the updated patch at
http://cr.openjdk.java.net/~fyuan/jjiang/8075286/webrev.01/
Best regards,
John Jiang
On 2015/9/12 7:50, Valerie Peng wrote:
Mostly are fine, just a few comments:
1) the convention is to place the regression tests
97 matches
Mail list logo
