Re: 8017325, 8017326: Cleanup of javadoc tag
Jason
Can you please add the appropriate noreg- label for the 2 bugs -
JDK-8017325 & JDK-8017326
Thanks
Nithya
On 6/25/2013 1:32 PM, Joe Darcy wrote:
Hi Jason,
The javadoc changes look good to go back.
Thanks,
-Joe
On 6/25/2013 1:23 PM, Jason Uh wrote:
Joe,
Here are the updated webrevs:
- java.security.cert:
http://cr.openjdk.java.net/~juh/8017325/webrev.02/
- java.security.spec:
http://cr.openjdk.java.net/~juh/8017326/webrev.01/
I have converted "..." to "{@code ...}" and have updated the
copyright dates.
I've attached diffs of the patches to show what has been updated in
these new webrevs. There is a little extra noise in them due to the
change in the timestamps.
Thanks,
Jason
On 06/24/2013 06:11 PM, Joseph Darcy wrote:
On 6/24/2013 3:00 PM, Jason Uh wrote:
On 6/24/13 10:51 AM, Joe Darcy wrote:
Hi Jason,
On 6/21/2013 6:58 PM, Jason Uh wrote:
After learning that javadoc is now capable of properly formatting
the
"{@code ...}" construct, I have updated the changeset for
java.security.cert. Please review instead:
Webrevs --
- java.security.cert (updated):
http://cr.openjdk.java.net/~juh/8017325/webrev.01/
- java.security.spec (no change):
http://cr.openjdk.java.net/~juh/8017326/webrev.00/
I've looked over both patches and they look fine.
However, as a follow-up, please also expand the conversion to include
mapping "foo" => "{@code foo}".
Thanks. I can make those changes, but are you suggesting that I add
them to this changeset or that I do that separately?
For review purposes, I'd like to see them separately in some fashion,
even if it was produced by diffing the patch files.
Note that this change does visibly change the generated javadoc, as
reported by specdiff. In particular, the change to {@code
...} in the javadoc for the
X509Extension.getNonCriticalExtensionOIDs() method now allows the
generated HTML to correctly display the line:
Set nonCritSet = badCert.getNonCriticalExtensionOIDs();
which was previously (incorrectly) displayed as
Set nonCritSet = badCert.getNonCriticalExtensionOIDs();
when the text "" was still enclosed within
"...".
Running specdiff is a good double-check in this situation.
Should the scripts you are using here to placed somewhere in the JDK
repo or in the code tools project?
I'm not sure that I follow. Are you requesting that I include
somewhere in the repo the line of Perl that I ran? (It was used to
make most, but not all of these changes.) If so, where would be the
most appropriate place to add that?
If it is a one-liner, it could be included in the summary line of the
commit message or as a comment in the bug. If it is more substantive
(since we will be rolling out this change across the JDK libraries),
having the command in a known-location would be helpful. Especially, if
a check for this pattern is built into future code-quality checks.
-Joe
Thanks,
Jason
Thanks,
-Joe
Thanks,
Jason
The files that have been updated
On 6/21/13 5:47 PM, Jason Uh wrote:
Joe, all,
Could I please get a review of the following changes?
These changesets convert the ... javadoc tags to
{@code
...} as part of an overall effort to clean up doclint warnings.
Webrevs --
- java.security.cert:
http://cr.openjdk.java.net/~juh/8017325/webrev.00/
- java.security.spec:
http://cr.openjdk.java.net/~juh/8017326/webrev.00/
specdiff reported no changes in the generated docs.
More of these to come.
Thanks,
Jason
Re: Smart Cards in Java Kerberos
Java provides the javax.smartcardio package for direct access to the smart card. But that's probably not what he's looking for. Mike Sent from my iPad On Jun 25, 2013, at 19:29, "Henry B. Hotz" wrote: > I'm not authoritative, but AFAIK there is no smart card support in Java, > though there is pkcs11 support. > > If I had to do it, I would do the smart card/PKINIT stuff outside Java, and > then let Java use the acquired tgt. > > On Jun 25, 2013, at 5:52 AM, Ostap Andrusiv wrote: > >> Hi everyone, >> >> I've been playing with smart cards and faced some issues. >> Long story short: >> >> Prerequisites: >> >>• I set up a basic Kerberos realm via Windows Active Directory. >>• I managed to successfully login into service via login/password pair >> using Java Kerberos(Krb5LoginModule), which is provided via JAAS. >> Now I try to implement Kerberos login via smart card. Smart card >> preauthentication in Kerberos is done via AS-REQ/AS-REP messages >> (PA-PK-AS-REQ/P extensions). Unfortunately, JAAS Kerberos hasn't used the >> smartcard. As far as I have seen, there were no PA-PK-AS-REQ/P extensions in >> openjdk sources. Maybe, I missed something. >> >> Question: >> >> 1. Does Java Kerberos support smart card preauthentication out of the box? >> >> 2. If it doesn't, can I somehow extends existing Kerberos module or should I >> implement whole Kerberos from the ground up? >> >> >> >> Thanks in advance, >> Ostap Andrusiv >> >> >> web: http://andrusiv.com >> skype: ostap.andrusiv >> ::p!F >
Code review request, 8017049: rename property jdk.tls.rejectClientInitializedRenego
Hi, webrev: http://cr.openjdk.java.net/~xuelei/8017049/webrev.00/ In update of 7188658 (http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a76858faad59), we defines a new system property, "jdk.tls.rejectClientInitializedRenego", in order to disable client initiated renegotiation. However, the name is not instinctive enough according to feedback. We want a name which can more succinctly captures the intent of this property. In this update, the property name is renamed to "jdk.tls.rejectClientInitiatedRenegotiation". Thanks, Xuelei
On 8017264: Java app crash on it's startup after Java updated to 7u25 from 7u21
Hi, Hotspot guys
We (SE security) received a bug report on a new crash for 7u25 and need
some help from you:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8017264
Here the top frames look like:
C [msvcr100.dll+0x10b3b] wcspbrk+0x12d
V [jvm.dll+0xa9b63]
C [w2k_lsa_auth.dll+0x167c] JNI_OnUnload+0x1c1
j
sun.security.krb5.Credentials.acquireDefaultNativeCreds()Lsun/security/krb5/Credentials;+0
acquireDefaultNativeCreds() is a native method and it's defined at
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/3c08c9ebd1fb/src/windows/native/sun/security/krb5/NativeCreds.c
I'm not sure why JNI_OnUnload is called so immediately, and as you can
see it's simply
338 if ((*jvm)->GetEnv(jvm, (void **)&env, JNI_VERSION_1_2)) {
339 return; /* Nothing else we can do */
340 }
341
342 if (ticketClass != NULL) {
343 (*env)->DeleteWeakGlobalRef(env,ticketClass);
344 }
... More DeleteWeakGlobalRefs
How is it able to call wcspbrk and get crashed?
BTW, the .c file has not been changed for 2 years.
Also, according to the report, the customer (whose automatic reply has
"out of office with no internet access till 15 July") runs 7u25 b16 but
the public release on java.com is b17. Does it matter?
Thanks
Max
Re: Smart Cards in Java Kerberos
Java (at least Oracle JDK) does not support PKINIT. Yes, you can do it outside, create a KerberosTicket and a KerberosPrincipal, create a JAAS Subject containing them, and call Subject.doAs() later. It should work. On Windows, if you manage to use Windows' own login and have the ticket stored inside LSA, Java should be able to read it. There is a registry key allowtgtsessionkey you need to take care of. Or maybe you can use any third party kinit to save a ccache file which can also be picked up by Java. --Max On 6/26/13 7:29 AM, Henry B. Hotz wrote: I'm not authoritative, but AFAIK there is no smart card support in Java, though there is pkcs11 support. If I had to do it, I would do the smart card/PKINIT stuff outside Java, and then let Java use the acquired tgt. On Jun 25, 2013, at 5:52 AM, Ostap Andrusiv wrote: Hi everyone, I've been playing with smart cards and faced some issues. Long story short: Prerequisites: • I set up a basic Kerberos realm via Windows Active Directory. • I managed to successfully login into service via login/password pair using Java Kerberos(Krb5LoginModule), which is provided via JAAS. Now I try to implement Kerberos login via smart card. Smart card preauthentication in Kerberos is done via AS-REQ/AS-REP messages (PA-PK-AS-REQ/P extensions). Unfortunately, JAAS Kerberos hasn't used the smartcard. As far as I have seen, there were no PA-PK-AS-REQ/P extensions in openjdk sources. Maybe, I missed something. Question: 1. Does Java Kerberos support smart card preauthentication out of the box? 2. If it doesn't, can I somehow extends existing Kerberos module or should I implement whole Kerberos from the ground up? Thanks in advance, Ostap Andrusiv web: http://andrusiv.com skype: ostap.andrusiv ::p!F
Re: Code Review Request for 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful
Great, thanks for the review! Valerie On 06/25/13 16:34, Wang Weijun wrote: > > 在 Jun 26, 2013，6:51 AM，"Valerie (Yu-Ching) Peng" 写道： > >> It's covered by SQE interoperability tests. > That's enough. > >> In terms of regression tests, I think we should not put any 3rd party >> provider-related stuff. >> I can add a regression test to make sure that optional component doesn't >> affect the equals check if you see value in doing this kind of test. > That part looks trivial. Not necessary. > > Thanks > Max > >> Thanks, >> Valerie >> >> On 06/24/13 21:20, Weijun Wang wrote: >>> Code change looks fine. No regression test? >>> >>> --Max >>> >>> On 6/20/13 4:45 AM, Valerie (Yu-Ching) Peng wrote: I have updated the webrev to address your comments: http://cr.openjdk.java.net/~valeriep/7196805/webrev.01/ As for using JDK 8 default method feature, I think maybe it's better to delay the adoption to a later release since it's easier for sustaining to just grab current changes and apply to earlier releases. Thanks for the review & please let me know if you have additional comments, Valerie On 06/17/13 22:41, Wang Weijun wrote: >> I will also apply the same change to P11DHPrivateKey/P11DHPublicKey >> then. Equality check using ASN.1 encoding is fine for non-DH >> algorithms but not for DH. > I cannot read the source codes now, but is it possible to implement > the equals method right in the base interface using the JDK 8 default > method feature? > >>> For DHKeyPairGenerator.java, it looks like you don't want the first >>> octet being zero. Is this related to this bug? Is that required in >>> the "Handbook of Applied Cryptography" book? I understand it could >>> be necessary for interop. >> The change is for conforming to the description under section 7.1 >> "Private-value generation" of PKCS#3 DH Key Agreement Standard >> ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc , i.e. >> >> An integer x, the private value, shall be generated >> privately and randomly. This integer shall satisfy 0< x< >> p-1, unless the central authority specifies a private-value >> length l, in which case the integer shall satisfy 2^(l-1)<= >> x< 2^l. > Great. I think you can add a reference to pkcs3. The current wording > seems to say it's suggested by the Handbook. > > Thanks > Max
Re: Smart Cards in Java Kerberos
I'm not authoritative, but AFAIK there is no smart card support in Java, though there is pkcs11 support. If I had to do it, I would do the smart card/PKINIT stuff outside Java, and then let Java use the acquired tgt. On Jun 25, 2013, at 5:52 AM, Ostap Andrusiv wrote: > Hi everyone, > > I've been playing with smart cards and faced some issues. > Long story short: > > Prerequisites: > > • I set up a basic Kerberos realm via Windows Active Directory. > • I managed to successfully login into service via login/password pair > using Java Kerberos(Krb5LoginModule), which is provided via JAAS. > Now I try to implement Kerberos login via smart card. Smart card > preauthentication in Kerberos is done via AS-REQ/AS-REP messages > (PA-PK-AS-REQ/P extensions). Unfortunately, JAAS Kerberos hasn't used the > smartcard. As far as I have seen, there were no PA-PK-AS-REQ/P extensions in > openjdk sources. Maybe, I missed something. > > Question: > > 1. Does Java Kerberos support smart card preauthentication out of the box? > > 2. If it doesn't, can I somehow extends existing Kerberos module or should I > implement whole Kerberos from the ground up? > > > > Thanks in advance, > Ostap Andrusiv > > > web: http://andrusiv.com > skype: ostap.andrusiv > ::p!F
Re: Code Review Request for 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful
在 Jun 26, 2013，6:51 AM，"Valerie (Yu-Ching) Peng" 写道： > It's covered by SQE interoperability tests. That's enough. > In terms of regression tests, I think we should not put any 3rd party > provider-related stuff. > I can add a regression test to make sure that optional component doesn't > affect the equals check if you see value in doing this kind of test. That part looks trivial. Not necessary. Thanks Max > Thanks, > Valerie > > On 06/24/13 21:20, Weijun Wang wrote: >> Code change looks fine. No regression test? >> >> --Max >> >> On 6/20/13 4:45 AM, Valerie (Yu-Ching) Peng wrote: >>> I have updated the webrev to address your comments: >>> http://cr.openjdk.java.net/~valeriep/7196805/webrev.01/ >>> >>> As for using JDK 8 default method feature, I think maybe it's better to >>> delay the adoption to a later release since it's easier for sustaining >>> to just grab current changes and apply to earlier releases. >>> Thanks for the review & please let me know if you have additional comments, >>> Valerie >>> >>> On 06/17/13 22:41, Wang Weijun wrote: > I will also apply the same change to P11DHPrivateKey/P11DHPublicKey > then. Equality check using ASN.1 encoding is fine for non-DH > algorithms but not for DH. I cannot read the source codes now, but is it possible to implement the equals method right in the base interface using the JDK 8 default method feature? >> For DHKeyPairGenerator.java, it looks like you don't want the first >> octet being zero. Is this related to this bug? Is that required in >> the "Handbook of Applied Cryptography" book? I understand it could >> be necessary for interop. > The change is for conforming to the description under section 7.1 > "Private-value generation" of PKCS#3 DH Key Agreement Standard > ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc , i.e. > > An integer x, the private value, shall be generated > privately and randomly. This integer shall satisfy 0< x< > p-1, unless the central authority specifies a private-value > length l, in which case the integer shall satisfy 2^(l-1)<= > x< 2^l. Great. I think you can add a reference to pkcs3. The current wording seems to say it's suggested by the Handbook. Thanks Max >
Re: [8] code review request for 7165807: Non optimized initialization of NSS crypto library leads to scalability issues
- The private static native boolean nssInit(...) method should be removed? It seems obsolete by nssInitWithOptions(...) and I didn't see it being used anywhere. Same goes for the corresponding JNI method impl, i.e. Java_sun_security_pkcs11_Secmod_nssInit, in the j2secmod.c file. - Particular reason to use different variable name, i.e. "nssUseOptimizeSpace" and property/option name "nssOptimizeSpace"? It seems inconsistent as most config variable name matches the property/option name. Can't we just use "nssOptimizeSpace"across board? - line 127, empty string is used instead of the passed configDir. I am not sure if this correct. Why not just pass the configDir to this call? Lastly, is the "NSS_Initialize(...)" method always available for the supported NSS library versions, i.e. 3.7+? Is this a newer method meant to replace "NSS_Init(...)"? Thanks, Valerie On 06/19/13 10:38, Vincent Ryan wrote: Thanks for the review. I've simplified the name of the NSS flag, updated the bug report and filed a doc bug, as you suggest. On 19 Jun 2013, at 18:21, Sean Mullan wrote: Looks good, just a couple of comments: 1. I think the name "nssOptimizeSpace" is clearer. The "Use" part seems a bit odd in the property name. 2. Add the appropriate noreg label to the bug. 3. File a followup doc bug to document the attribute in the PKCS11 guide. --Sean On 06/19/2013 08:49 AM, Vincent Ryan wrote: I've made some corrections to the native method that initializes NSS. The new webrev is at: http://cr.openjdk.java.net/~vinnie/7165807/webrev.01 On 14 Jun 2013, at 18:38, Vincent Ryan wrote: Please review the following fix: http://cr.openjdk.java.net/~vinnie/7165807/webrev.00/ http://bugs.sun.com/view_bug.do?bug_id=7165807 NSS may be initialized to favour performance or to favour memory footprint. This fix introduces a new configuration flag to allow Java applications to choose. By default, NSS will be initialized for performance. Thanks.
Re: Code Review Request for 7196805: DH Key interoperability testing between SunJCE and JsafeJCE not successful
It's covered by SQE interoperability tests. In terms of regression tests, I think we should not put any 3rd party provider-related stuff. I can add a regression test to make sure that optional component doesn't affect the equals check if you see value in doing this kind of test. Thanks, Valerie On 06/24/13 21:20, Weijun Wang wrote: Code change looks fine. No regression test? --Max On 6/20/13 4:45 AM, Valerie (Yu-Ching) Peng wrote: I have updated the webrev to address your comments: http://cr.openjdk.java.net/~valeriep/7196805/webrev.01/ As for using JDK 8 default method feature, I think maybe it's better to delay the adoption to a later release since it's easier for sustaining to just grab current changes and apply to earlier releases. Thanks for the review & please let me know if you have additional comments, Valerie On 06/17/13 22:41, Wang Weijun wrote: I will also apply the same change to P11DHPrivateKey/P11DHPublicKey then. Equality check using ASN.1 encoding is fine for non-DH algorithms but not for DH. I cannot read the source codes now, but is it possible to implement the equals method right in the base interface using the JDK 8 default method feature? For DHKeyPairGenerator.java, it looks like you don't want the first octet being zero. Is this related to this bug? Is that required in the "Handbook of Applied Cryptography" book? I understand it could be necessary for interop. The change is for conforming to the description under section 7.1 "Private-value generation" of PKCS#3 DH Key Agreement Standard ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-3.asc , i.e. An integer x, the private value, shall be generated privately and randomly. This integer shall satisfy 0< x< p-1, unless the central authority specifies a private-value length l, in which case the integer shall satisfy 2^(l-1)<= x< 2^l. Great. I think you can add a reference to pkcs3. The current wording seems to say it's suggested by the Handbook. Thanks Max
hg: jdk8/tl/langtools: 8012722: Single comma in array initializer should parse
Changeset: bf020de5a6db
Author:emc
Date: 2013-06-24 22:03 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bf020de5a6db
8012722: Single comma in array initializer should parse
Summary: Annotations of the form @Foo({,}) should parse
Reviewed-by: jjg
! src/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/tools/javac/parser/SingleCommaAnnotationValue.java
+ test/tools/javac/parser/SingleCommaAnnotationValueFail.java
+ test/tools/javac/parser/SingleCommaAnnotationValueFail.out
Smart Cards in Java Kerberos
Hi everyone, I've been playing with smart cards and faced some issues. Long story short: *Prerequisites*: - I set up a basic Kerberos realm via Windows Active Directory. - I managed to successfully login into service via *login/password* pair using Java Kerberos(Krb5LoginModule), which is provided via JAAS. Now I try to implement Kerberos login via smart card. Smart card preauthentication in Kerberos is done via AS-REQ/AS-REP messages ( PA-PK-AS-REQ/P extensions). Unfortunately, JAAS Kerberos hasn't used the smartcard. As far as I have seen, there were no PA-PK-AS-REQ/P extensions in openjdk sources. Maybe, I missed something. *Question*: 1. Does Java Kerberos support smart card preauthentication out of the box? 2. If it doesn't, can I somehow extends existing Kerberos module or should I implement whole Kerberos from the ground up? Thanks in advance, Ostap Andrusiv web: http://andrusiv.com skype: ostap.andrusiv ::p!F
hg: jdk8/tl/jdk: 8017326: Cleanup of the javadoc tag in java.security.spec
Changeset: 3700bb58c9a2
Author:juh
Date: 2013-06-25 14:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3700bb58c9a2
8017326: Cleanup of the javadoc tag in java.security.spec
Summary: Convert javadoc and tags to {@code ...}
Reviewed-by: darcy
! src/share/classes/java/security/spec/DSAGenParameterSpec.java
! src/share/classes/java/security/spec/DSAParameterSpec.java
! src/share/classes/java/security/spec/DSAPrivateKeySpec.java
! src/share/classes/java/security/spec/DSAPublicKeySpec.java
! src/share/classes/java/security/spec/ECFieldF2m.java
! src/share/classes/java/security/spec/ECFieldFp.java
! src/share/classes/java/security/spec/ECGenParameterSpec.java
! src/share/classes/java/security/spec/ECParameterSpec.java
! src/share/classes/java/security/spec/ECPoint.java
! src/share/classes/java/security/spec/ECPrivateKeySpec.java
! src/share/classes/java/security/spec/ECPublicKeySpec.java
! src/share/classes/java/security/spec/EllipticCurve.java
! src/share/classes/java/security/spec/EncodedKeySpec.java
! src/share/classes/java/security/spec/InvalidKeySpecException.java
! src/share/classes/java/security/spec/KeySpec.java
! src/share/classes/java/security/spec/MGF1ParameterSpec.java
! src/share/classes/java/security/spec/PKCS8EncodedKeySpec.java
! src/share/classes/java/security/spec/PSSParameterSpec.java
! src/share/classes/java/security/spec/RSAKeyGenParameterSpec.java
! src/share/classes/java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java
! src/share/classes/java/security/spec/RSAOtherPrimeInfo.java
! src/share/classes/java/security/spec/RSAPrivateCrtKeySpec.java
! src/share/classes/java/security/spec/X509EncodedKeySpec.java
hg: jdk8/tl/jdk: 8017325: Cleanup of the javadoc tag in java.security.cert
Changeset: 757290440a2f
Author:juh
Date: 2013-06-25 14:31 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/757290440a2f
8017325: Cleanup of the javadoc tag in java.security.cert
Summary: Convert javadoc ... and ... tags to {@code ...}
Reviewed-by: darcy
! src/share/classes/java/security/cert/CRLException.java
! src/share/classes/java/security/cert/CRLSelector.java
! src/share/classes/java/security/cert/CertPath.java
! src/share/classes/java/security/cert/CertPathBuilder.java
! src/share/classes/java/security/cert/CertPathBuilderException.java
! src/share/classes/java/security/cert/CertPathBuilderResult.java
! src/share/classes/java/security/cert/CertPathBuilderSpi.java
! src/share/classes/java/security/cert/CertPathParameters.java
! src/share/classes/java/security/cert/CertPathValidator.java
! src/share/classes/java/security/cert/CertPathValidatorException.java
! src/share/classes/java/security/cert/CertPathValidatorResult.java
! src/share/classes/java/security/cert/CertPathValidatorSpi.java
! src/share/classes/java/security/cert/CertSelector.java
! src/share/classes/java/security/cert/CertStore.java
! src/share/classes/java/security/cert/CertStoreException.java
! src/share/classes/java/security/cert/CertStoreParameters.java
! src/share/classes/java/security/cert/CertStoreSpi.java
! src/share/classes/java/security/cert/Certificate.java
! src/share/classes/java/security/cert/CertificateEncodingException.java
! src/share/classes/java/security/cert/CertificateException.java
! src/share/classes/java/security/cert/CertificateExpiredException.java
! src/share/classes/java/security/cert/CertificateFactory.java
! src/share/classes/java/security/cert/CertificateFactorySpi.java
! src/share/classes/java/security/cert/CertificateNotYetValidException.java
! src/share/classes/java/security/cert/CertificateParsingException.java
! src/share/classes/java/security/cert/CertificateRevokedException.java
! src/share/classes/java/security/cert/CollectionCertStoreParameters.java
! src/share/classes/java/security/cert/Extension.java
! src/share/classes/java/security/cert/LDAPCertStoreParameters.java
! src/share/classes/java/security/cert/PKIXBuilderParameters.java
! src/share/classes/java/security/cert/PKIXCertPathBuilderResult.java
! src/share/classes/java/security/cert/PKIXCertPathChecker.java
! src/share/classes/java/security/cert/PKIXCertPathValidatorResult.java
! src/share/classes/java/security/cert/PKIXParameters.java
! src/share/classes/java/security/cert/PKIXReason.java
! src/share/classes/java/security/cert/PolicyNode.java
! src/share/classes/java/security/cert/PolicyQualifierInfo.java
! src/share/classes/java/security/cert/TrustAnchor.java
! src/share/classes/java/security/cert/X509CRL.java
! src/share/classes/java/security/cert/X509CRLEntry.java
! src/share/classes/java/security/cert/X509CRLSelector.java
! src/share/classes/java/security/cert/X509CertSelector.java
! src/share/classes/java/security/cert/X509Certificate.java
! src/share/classes/java/security/cert/X509Extension.java
Re: 8017325, 8017326: Cleanup of javadoc tag
Hi Jason,
The javadoc changes look good to go back.
Thanks,
-Joe
On 6/25/2013 1:23 PM, Jason Uh wrote:
Joe,
Here are the updated webrevs:
- java.security.cert:
http://cr.openjdk.java.net/~juh/8017325/webrev.02/
- java.security.spec:
http://cr.openjdk.java.net/~juh/8017326/webrev.01/
I have converted "..." to "{@code ...}" and have updated the
copyright dates.
I've attached diffs of the patches to show what has been updated in
these new webrevs. There is a little extra noise in them due to the
change in the timestamps.
Thanks,
Jason
On 06/24/2013 06:11 PM, Joseph Darcy wrote:
On 6/24/2013 3:00 PM, Jason Uh wrote:
On 6/24/13 10:51 AM, Joe Darcy wrote:
Hi Jason,
On 6/21/2013 6:58 PM, Jason Uh wrote:
After learning that javadoc is now capable of properly formatting the
"{@code ...}" construct, I have updated the changeset for
java.security.cert. Please review instead:
Webrevs --
- java.security.cert (updated):
http://cr.openjdk.java.net/~juh/8017325/webrev.01/
- java.security.spec (no change):
http://cr.openjdk.java.net/~juh/8017326/webrev.00/
I've looked over both patches and they look fine.
However, as a follow-up, please also expand the conversion to include
mapping "foo" => "{@code foo}".
Thanks. I can make those changes, but are you suggesting that I add
them to this changeset or that I do that separately?
For review purposes, I'd like to see them separately in some fashion,
even if it was produced by diffing the patch files.
Note that this change does visibly change the generated javadoc, as
reported by specdiff. In particular, the change to {@code
...} in the javadoc for the
X509Extension.getNonCriticalExtensionOIDs() method now allows the
generated HTML to correctly display the line:
Set nonCritSet = badCert.getNonCriticalExtensionOIDs();
which was previously (incorrectly) displayed as
Set nonCritSet = badCert.getNonCriticalExtensionOIDs();
when the text "" was still enclosed within
"...".
Running specdiff is a good double-check in this situation.
Should the scripts you are using here to placed somewhere in the JDK
repo or in the code tools project?
I'm not sure that I follow. Are you requesting that I include
somewhere in the repo the line of Perl that I ran? (It was used to
make most, but not all of these changes.) If so, where would be the
most appropriate place to add that?
If it is a one-liner, it could be included in the summary line of the
commit message or as a comment in the bug. If it is more substantive
(since we will be rolling out this change across the JDK libraries),
having the command in a known-location would be helpful. Especially, if
a check for this pattern is built into future code-quality checks.
-Joe
Thanks,
Jason
Thanks,
-Joe
Thanks,
Jason
The files that have been updated
On 6/21/13 5:47 PM, Jason Uh wrote:
Joe, all,
Could I please get a review of the following changes?
These changesets convert the ... javadoc tags to {@code
...} as part of an overall effort to clean up doclint warnings.
Webrevs --
- java.security.cert:
http://cr.openjdk.java.net/~juh/8017325/webrev.00/
- java.security.spec:
http://cr.openjdk.java.net/~juh/8017326/webrev.00/
specdiff reported no changes in the generated docs.
More of these to come.
Thanks,
Jason
hg: jdk8/tl/jdk: 8014233: java.lang.Thread should have @Contended on TLR fields
Changeset: ac61efd8c593 Author:shade Date: 2013-06-25 20:06 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac61efd8c593 8014233: java.lang.Thread should have @Contended on TLR fields Summary: add the @Contended over three TLR fields. Reviewed-by: psandoz, chegar, dholmes, dl ! src/share/classes/java/lang/Thread.java
hg: jdk8/tl/langtools: 8006973: jtreg test fails: test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
Changeset: aceae9ceebbe Author:kizune Date: 2013-06-25 20:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aceae9ceebbe 8006973: jtreg test fails: test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java Reviewed-by: ksrini ! test/tools/javac/warnings/AuxiliaryClass/SelfClassWithAux.java
hg: jdk8/tl/langtools: 8017104: javac should have a class for primitive types that inherits from Type
Changeset: 831467c4c6a7 Author:vromero Date: 2013-06-25 16:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/831467c4c6a7 8017104: javac should have a class for primitive types that inherits from Type Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/api/JavacTrees.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Kinds.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeTag.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java
Re: RFR JDK-8003245
Greetings:
I made a change to
src/share/native/sun/security/pkcs11/wrapper/p11_convert.c... I replaced
all the code that looks like this:
struct fubar bar;
memset(&bar, 0, sizeof(struct fubar));
with code that looks like this:
struct fubar bar = {0};
Also, I looked for similar usage patterns in neighbouring security code
that would cause references to uninitialized data structure memory, and
found none. The basic issue that I discovered was that certain
procedures were returning structures (not pointers to structures) that
were allocated on the stack as uninitialized memory. (I found the bug by
running the native code through doxygen and then I looked at every data
structure instance.)
The latest webrev image is at:
http://cr.openjdk.java.net/~jzavgren/8003245/webrev.02/
Re: Code review request: 8016051: Possible ClassCastException in KdcComm
I pushed the changeset to http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89631a384ee6 You have some TAB characters and one trailing whitespace. I've removed them. Thanks Max On 6/25/13 8:33 PM, Artem Smotrakov wrote: Hi Max I updated the webrev: http://1.smotrakov.z8.ru/8016051/webrev.01/src/share/classes/sun/security/krb5/KdcComm.java.udiff.html I built OpenJDK on Linux x64 according to http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.html, and ran JCK, SQE (related to Kerberos), jdk_security tests (listed in http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.html) Artem On 25.06.2013 16:04, Weijun Wang wrote: Hi Artem Line 221 is a little too long, you may want to break it. Otherwise, fine. Have you tried running JPRT with at least the jdk_security test? Thanks Max On 6/25/2013 1:35 PM, Artem Smotrakov wrote: Hi, please review this fix for 8: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016051 http://1.smotrakov.z8.ru/8016051/webrev.00/ It fixes a possible ClassCastException if an exception thrown from send() method is not IOException or KrbException. The first exception is thrown if all connections to KDC fail. See also: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017714.html Artem
hg: jdk8/tl/jdk: 8016051: Possible ClassCastException in KdcComm
Changeset: 89631a384ee6 Author:weijun Date: 2013-06-25 21:51 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89631a384ee6 8016051: Possible ClassCastException in KdcComm Reviewed-by: weijun Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/krb5/KdcComm.java
hg: jdk8/tl/jdk: 8017570: jfr.jar should not be in compact3 (for now)
Changeset: 4a4d910e1504 Author:alanb Date: 2013-06-25 13:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a4d910e1504 8017570: jfr.jar should not be in compact3 (for now) Reviewed-by: erikj ! makefiles/profile-includes.txt
hg: jdk8/tl/jdk: 4641897: Faster string conversion of large integers
Changeset: 01fcca3d2b8c Author:bpb Date: 2013-06-20 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01fcca3d2b8c 4641897: Faster string conversion of large integers Summary: Accelerate conversion to string by means of Schoenhage recursive base conversion. Reviewed-by: bpb, alanb Contributed-by: Alan Eliasen ! src/share/classes/java/math/BigInteger.java ! test/java/math/BigInteger/BigIntegerTest.java
Re: Code review request: 8016051: Possible ClassCastException in KdcComm
Hi Max I updated the webrev: http://1.smotrakov.z8.ru/8016051/webrev.01/src/share/classes/sun/security/krb5/KdcComm.java.udiff.html I built OpenJDK on Linux x64 according to http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.html, and ran JCK, SQE (related to Kerberos), jdk_security tests (listed in http://hg.openjdk.java.net/jdk8/build/raw-file/tip/README-builds.html) Artem On 25.06.2013 16:04, Weijun Wang wrote: Hi Artem Line 221 is a little too long, you may want to break it. Otherwise, fine. Have you tried running JPRT with at least the jdk_security test? Thanks Max On 6/25/2013 1:35 PM, Artem Smotrakov wrote: Hi, please review this fix for 8: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016051 http://1.smotrakov.z8.ru/8016051/webrev.00/ It fixes a possible ClassCastException if an exception thrown from send() method is not IOException or KrbException. The first exception is thrown if all connections to KDC fail. See also: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017714.html Artem
Re: Code review request: 8016051: Possible ClassCastException in KdcComm
Hi Artem Line 221 is a little too long, you may want to break it. Otherwise, fine. Have you tried running JPRT with at least the jdk_security test? Thanks Max On 6/25/2013 1:35 PM, Artem Smotrakov wrote: Hi, please review this fix for 8: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016051 http://1.smotrakov.z8.ru/8016051/webrev.00/ It fixes a possible ClassCastException if an exception thrown from send() method is not IOException or KrbException. The first exception is thrown if all connections to KDC fail. See also: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017714.html Artem
