I have asked someone who worked on this code and they said:
I believe this is a failsafe to prevent the code from going into an
infinite loop when talking to a bad card or driver.
--Sean
Ming Yung wrote:
Hi there,
This relates to a limitation (bug?) in the implementation of
message is extremely misleading, by the way. If it wasn't
for jpcsc I would have believed that the card did actually stop responding.
Thanks,
Ming
On Tue, Jul 29, 2008 at 1:14 AM, Sean Mullan [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I have asked someone who worked on this code
Changeset: 80fe10573687
Author:mullan
Date: 2008-09-11 14:05 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/80fe10573687
6465942: Add problem identification facility to the CertPathValidator framework
Summary: Add support to the java.security.cert APIs for determining the
Changeset: 74fc78477907
Author:mullan
Date: 2008-09-22 10:43 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/74fc78477907
6469266: Integrate Apache XMLSec 1.4.2 into JDK 7
Reviewed-by: valeriep
! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java
!
Changeset: 486b917ed417
Author:mullan
Date: 2008-10-07 13:41 -0400
URL: http://hg.openjdk.java.net/jdk7/jsn/jdk/rev/486b917ed417
6752764: PIT B37: CertPath/CertPathValidatorTest/KeyParamsInheritanceTest failed
Summary: fix regression introduced by 6465942
Reviewed-by: vinnie
!
I looked at the code changes and it seems fine to me.
--Sean
Joe Darcy wrote:
Hello.
On 10/16/08 12:46 PM, Martin Buchholz wrote:
Hi all,
This is a bug report with fix.
Joe Darcy, please file a bug and review this change,
I've filed 6761678 (ann) SecurityException in
Changeset: 4ff842aee1fd
Author:mullan
Date: 2008-10-30 17:24 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4ff842aee1fd
6764553: com.sun.org.apache.xml.internal.security.utils.IdResolver is not
thread safe
Reviewed-by: valeriep
!
Changeset: 5102df668164
Author:mullan
Date: 2008-11-05 15:55 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5102df668164
6744888: OCSP validation code should permit some clock skew when checking
validity of OCSP responses
Summary: Allow for up to 10 minutes of clock skew
Changeset: 3a3e02a55de8
Author:mullan
Date: 2008-11-06 12:12 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3a3e02a55de8
6765046: CertPathValidatorException(Throwable).getMessage() always returns null
since b37
Reviewed-by: vinnie
!
Hi Bruno,
Bruno Harbulot wrote:
Hi Xuelei,
Thanks for looking into this.
I agree with you, everything that's required is already in the JavaSE
API. I find, however, that using these classes requires a careful
reading of the JSSE ref. guide and the Certification path ref. guide,
both of
The W3C XML Security Working Group has just released 7 first public working
drafts of new XML Signature and Encryption specifications. If you use or are
interested in JSR 105 (Java XML Digital Signature API) or JSR 106 (Java XML
Encryption API), please try to review them and send any comments
Hi Max,
Can you review: http://cr.openjdk.java.net/~mullan/6787130/webrev/
Thanks,
Sean
Changeset: c769c46c27ce
Author:mullan
Date: 2009-03-09 09:46 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c769c46c27ce
6787130: java.policy file contains stale link to http://java.sun.com/notes
Reviewed-by: weijun
! src/share/lib/security/java.policy
Changeset:
Weijun Wang wrote:
Hi
In keytool's installReply(), there is:
if (replyCerts.length == 1) {
// single-cert reply
newChain = establishCertChain(userCert, replyCerts[0]);
} else {
// cert-chain reply (e.g., PKCS#7)
newChain =
Xuelei Fan wrote:
Many, many Verisign root certs are V1, and the intermediate cert are V3.
I believe that is because many Verisign roots were issued in the late 1990's and
perhaps v3 (published in 1996) had not gained enough support in the market yet.
I am wondering if you know if there
Some additional comments in the new tests describing what path building
scenarios are being tested would be very useful.
A few comments below. Everything else looks good.
Xuelei Fan wrote:
new webrev: http://cr.openjdk.java.net/~xuelei/6852744/webrev.01/
Sean Mullan wrote:
Hi Andrew,
Here
Xuelei Fan wrote:
In this block of code:
858 if (principal != null publicKey != null
859
principal.equals(cert.getSubjectX500Principal())) {
860 if (publicKey.equals(cert.getPublicKey())) {
861
Xuelei Fan wrote:
webrev updated, adding comments to tests:
http://cr.openjdk.java.net/~xuelei/6852744/webrev.02/
In DisableRevocation.java, why do you add CRLs to the CertStore if revocation is
disabled?
I think I understand what are your concerns now. If I'm right, you think
that the
Changeset: 1203425b5742
Author:mullan
Date: 2009-07-20 17:16 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1203425b5742
6787645: CRL validation code should permit some clock skew when checking
validity of CRLs
Reviewed-by: vinnie
!
Hi Najeeb,
Please see an earlier message/thread about a DTLS implementation:
http://mail.openjdk.java.net/pipermail/security-dev/2008-January/50.html
I am not sure what the status of that project is, but I suggest you try
to contact Christian to see what the status is and if you can
Changeset: 8252729d51a3
Author:mullan
Date: 2009-09-09 09:54 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8252729d51a3
6745437: Add option to only check revocation of end-entity certificate in a
chain of certificates
6869739: Cannot check revocation of single certificate
Changeset: 6fac6e5fdf0c
Author:mullan
Date: 2009-11-18 12:34 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6fac6e5fdf0c
6894461: OCSP Checker should not wrap all Exception as Unable to send OCSP
request.(introduced by #6885667)
Reviewed-by: vinnie, xuelei
!
Mandy Chung wrote:
Fixed 6903638: Remove dependency on AuthPermission from SecurityConstants
Webrev at:
http://cr.openjdk.java.net/~mchung/6903638/webrev.00/
Move the two static fields defined in the SecurityConstants to
javax.security.auth.Subject class. javax.security.auth classes are
Changeset: 5d2e63dad298
Author:mullan
Date: 2009-11-23 12:36 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5d2e63dad298
6899503: Security code issue using Verisign root certificate
Summary: Add support for reordering out-of-order certificate chains
Reviewed-by: vinnie,
Changeset: 7c9be6c9385a
Author:mullan
Date: 2009-12-10 11:31 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7c9be6c9385a
6867348: Digest Value of References inside Manifest - calculation order problem
Reviewed-by: xuelei
!
Hi Todd,
This should be fixed in OpenJDK 7. Can you test against JDK 7 to see if it works
and I'll investigate porting the fix to OpenJDK 6?
--Sean
Todd E. Johnson wrote:
Hello,
I posted a bug on this issue at http://bugreport.sun.com/
The Sun provider currently ignores all but the first
A new version (3.0) of the Secure Coding Guidelines for the Java Programming
Language has just been published at http://java.sun.com/security/seccodeguide.html
The secure coding guidelines documents best practices and patterns that you
should adhere to when writing Java code in order to avoid
Changeset: 51d62db10c93
Author:mullan
Date: 2010-01-15 09:48 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/51d62db10c93
6915939: Exception should be thrown if OCSP SingleResponses contain unresolved
critical extensions
Reviewed-by: xuelei
!
Looks fine to me.
--Sean
Vincent Ryan wrote:
Please review this minor change to eliminate a reference to the
sun.security.provider.IdentityDatabase class in the java.security
configuration file. That class was removed as part of our
modularization effort.
Christopher Hegarty -Sun Microsystems Ireland wrote:
Pavel Tisnovsky wrote:
Christopher Hegarty -Sun Microsystems Ireland wrote:
Alan Bateman wrote:
Pavel Tisnovsky wrote:
Hi,
please review new regression test for java.net.* API. This test
check if the cacerts keytool database is
Andrew John Hughes wrote:
This has been posted about before; OpenJDK currently can't bootstrap
itself because it doesn't have a working cacerts store (the JAXP URL
uses https).
I don't know how to solve this; we can certainly have the cacerts file
populated on GNU/Linux systems, but I don't
Andrew John Hughes wrote:
On Windows you can use the Windows-ROOT KeyStore type, ex:
keytool -list -keystore NONE -storetype Windows-ROOT
Ok, so that presumably makes some Windows system call, right?
Yes.
I haven't tried it, but you could probably use the keytool -importkeystore
Hi Andrew,
Could I get a quick code review for 6909281 which also needs to be fixed in JDK
7:
http://cr.openjdk.java.net/~mullan/6909281/webrev/
Thanks,
Sean
Changeset: 710c4493902f
Author:mullan
Date: 2010-04-09 07:21 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/710c4493902f
6909281: 6u19 b99(pit):Error loading first applet in browser session( both FF
IE, windows ): NPE is thrown
Summary: Fix for 6633872 causes NPE due to
Yes, looks good to me.
--Sean
Xuelei Fan wrote:
Looks fine to me.
Andrew
On 5/21/2010 5:34 PM, Weijun Wang wrote:
Hi Sean and Andrew
This webrev is 6948803 for opejdk-7. Please review it:
http://cr.openjdk.java.net/~weijun/6948803/webrev.00/
The src/ changes are identical to the 6u21
Changeset: 9bffc32b645d
Author:mullan
Date: 2010-07-01 15:20 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9bffc32b645d
6782979: Add JNLPAppletLauncher (6618105) to blacklist
Reviewed-by: ohair
! make/java/security/Makefile
Changeset: c0d2a097eb99
Author:mullan
Date:
Hi,
I would like to try to fix a long-standing XMLDSig issue with the current DSA
and ECDSA signature bytes format.
The format of the Signature bytes for these algorithms is an ASN.1 encoded
sequence of the integers r and s:
SEQUENCE ::= { r INTEGER, s INTEGER }
Unfortunately, this is
Hi Maarten,
Thanks for the comments, a few replies below -
Maarten Bodewes wrote:
On Thu, Jul 15, 2010 at 6:57 PM, Sean Mullan sean.mul...@oracle.com
mailto:sean.mul...@oracle.com wrote:
I would like to try to fix a long-standing XMLDSig issue with the
current DSA and ECDSA
On 7/19/10 5:32 PM, Maarten Bodewes wrote:
Darn, that was a bit premature, I don't see how the PKCS#11 provider can
support this. Currently it only lists the SHA256withECDSA and such.
This would make it near impossible to directly perform XML signatures
using a HSM or software PKCS#11 lib.
I'm
Changeset: 9d1994d53a67
Author:mullan
Date: 2010-07-20 10:41 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d1994d53a67
6870553: X509Certificate.getSigAlgName method description uses non-standard
algorithm name as example
Reviewed-by: xuelei
!
Hi Max,
I'm not sure about this change. There's a definitely a change in behavior.
Before generateCertificate would only read one PEM block from the stream, and
throw an exception if it wasn't a certificate. But the current fix ignores non
certificate blocks until it finds a certificate or
Hi Max,
Can you review this simple fix?
http://cr.openjdk.java.net/~mullan/6653372/webrev.00/
Thanks,
Sean
Changeset: a21c46dac6cf
Author:mullan
Date: 2010-08-03 09:39 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a21c46dac6cf
6653372: Error in java.security.KeyStore example code
Reviewed-by: weijun
! src/share/classes/java/security/KeyStore.java
Changeset: 2feeefb45a44
Lance,
Could you also file a doc CR to update the list of SQLPermission targets
at
http://download.oracle.com/javase/7/docs/technotes/guides/security/permissions.html#SQLPermission
?
Thanks,
Sean
On 09/11/2010 06:19 AM, Lance Andersen wrote:
Hi Max,
Thank you. It looks good. Yes I mean
Hi Andrew,
Can you please review my fix for 6954275 (XML signatures with reference data
larger 16KB and cacheRef on fails to validate)
http://cr.openjdk.java.net/~mullan/6954275/webrev.00/
This was already fixed in the Apache codebase and we are integrating the patch
with a new unit test.
Changeset: 0fc51ca3467d
Author:mullan
Date: 2010-10-15 10:55 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0fc51ca3467d
6954275: XML signatures with reference data larger 16KB and cacheRef on fails
to validate
Reviewed-by: xuelei
!
Vinnie,
Can you review this trivial javadoc change? No CCC is required because this is a
simple clarification.
http://cr.openjdk.java.net/~mullan/6988599/webrev.00/
Thanks,
Sean
Changeset: 0f5bab573e01
Author:mullan
Date: 2010-10-18 09:00 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f5bab573e01
6988599: CertificateRevokedException specifies name of authority but interacts
with authority instance
Reviewed-by: vinnie
!
Vinnie,
Could I get a quick code review:
http://cr.openjdk.java.net/~mullan/6994717/webrev.00/
Thanks,
Sean
Changeset: 34faa22a8ce8
Author:mullan
Date: 2010-11-08 11:33 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/34faa22a8ce8
6994717: expired certificate in test ValidateCertPath
Reviewed-by: vinnie
!
On 11/17/2010 02:34 PM, Mandy Chung wrote:
Hi Sean,
On 11/16/10 5:56 AM, Sean Mullan wrote:
http://cr.openjdk.java.net/~mullan/6995424/webrev.00/
Policy.java:
I was initially confused with the meaning of 'compatPolicy'. I thought
that when 'compatPolicy' is set to true, it means
On 11/17/10 5:18 PM, Mandy Chung wrote:
how about isCustomProvider? Your comment above describing the flag already
explains it's for backward compatibility.
I changed it to isCustomPolicy since technically it isn't a Provider. I also
added more comments.
New webrev:
Mandy, Vinnie -
Can you review my webrev for 6995424 (Eliminate dependency to a deprecated API
com.sun.security.auth.PolicyFile)?
http://cr.openjdk.java.net/~mullan/6995424/webrev.00/
Thanks,
Sean
Changeset: 951db417fc3c
Author:mullan
Date: 2010-11-22 10:16 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/951db417fc3c
6995424: Eliminate dependency to a deprecated API
com.sun.security.auth.PolicyFile
Reviewed-by: mchung
!
On 12/3/10 4:35 AM, Weijun Wang wrote:
Hi Sean
Please review my code changes:
http://cr.openjdk.java.net/~weijun/7004035/webrev.00/
After this change, MANIFEST.MF's getSigners() and getCertificates() will be not
null. Since every signer of the jar file has a hash of the manifest header, I
Hi Mandy,
Could I get a code review for 6998860:
http://cr.openjdk.java.net/~mullan/6998860/webrev.00/
Thanks,
Sean
On 12/7/10 8:20 PM, Mandy Chung wrote:
Hi Sean,
On 12/7/10 12:47 PM, Sean Mullan wrote:
Hi Mandy,
Could I get a code review for 6998860:
http://cr.openjdk.java.net/~mullan/6998860/webrev.00/
Is Providers.getSunProvider() specified to create a new instance of the provider
every time it's
Changeset: 291128e77395
Author:mullan
Date: 2010-12-08 10:21 -0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/291128e77395
6998860: Signed jar file verification is currently creating many extra new Sun
providers.
Reviewed-by: mchung
!
Hello,
Currently, the Java security APIs do not specify algorithm requirements for
implementations of Java SE. This makes it difficult to develop conformance
tests. Additionally, there is no guarantee that Java applications using these
algorithms can inter-operate. See bug 5001004 for more
On 12/15/10 10:38 AM, Florian Weimer wrote:
* Sean Mullan:
Please review the following list:
http://cr.openjdk.java.net/~mullan/5001004/review.00/StandardNames.html#impl
SHA-1 or SHA1? (Our code uses SHA1 for some reason, perhaps for
consistency with HmacSHA1.)
SHA-1 is the standard name
On 12/16/2010 11:30 AM, Florian Weimer wrote:
* Sean Mullan:
On 12/15/10 10:38 AM, Florian Weimer wrote:
* Sean Mullan:
Please review the following list:
http://cr.openjdk.java.net/~mullan/5001004/review.00/StandardNames.html#impl
SHA-1 or SHA1? (Our code uses SHA1 for some reason
.
--Sean
On 12/16/2010 09:40 AM, Tomas Gustavsson wrote:
I don't see any ECC algorithms. These are in wide use today to say the
least. And will be so even more tomorrow (i.e. when Java SE 7 is out you
can not live without it).
Regards,
Tomas
On 12/15/2010 04:11 PM, Sean Mullan wrote:
Hello
On 12/20/10 7:29 AM, Florian Weimer wrote:
* Sean Mullan:
Oh, and I just realized that MD5 and HmacMD5 are missing. These
algorithms are still heavily used (and HmacMD5 is not really broken,
it's only guilty by association).
Yes, MD5 is still in use, but I think it is decreasing in use
,
Sean
On 12/15/10 10:11 AM, Sean Mullan wrote:
Hello,
Currently, the Java security APIs do not specify algorithm requirements for
implementations of Java SE. This makes it difficult to develop conformance
tests. Additionally, there is no guarantee that Java applications using these
algorithms can
On 1/13/11 6:38 AM, Xuelei Fan wrote:
Hi Sean,
Would you please review the fix for CR 7011497?
http://cr.openjdk.java.net/~xuelei/7011497/webrev/
Thanks,
Xuelei
CPValidatorEndEntity.java:
307 /* coment out useless trust anchor
308 is = new
Changeset: ae38d1374e31
Author:mullan
Date: 2011-01-24 14:56 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ae38d1374e31
5001004: Required Security Algorithms need to be defined
Reviewed-by: wetmore
! src/share/classes/java/security/AlgorithmParameterGenerator.java
!
().equals(cert.getPublicKey())) {
+ break;
}
Now if A signs B and B signs A again, there would be a loop. This should seldom
happen I guess.
Thanks
Max
On 01/26/2011 02:50 AM, Sean Mullan wrote:
On 1/25/11 10:09 AM, Weijun Wang wrote:
On 01/25/2011 10:44 PM, Sean Mullan wrote:
Hi Max,
For #3
On 1/15/2011 5:37 AM, Sean Mullan wrote:
Hi Andrew,
Did you consider using the existing X509CertSelector class to match on
the authority key identifier? I actually think this should work, and it
will avoid having to create the AKIDMatchState class. Take a look at the
ForwardBuilder.getMatchingCACerts
Hi Max,
This is looking good. I'm about halfway through. Here are some code comments to
start with. I think we'll need a couple more rounds of code reviews before we
finish so I wanted to get these to you now.
* JarFile
[329-330]: How about adding a SignatureFileVerifier.isBlock method
name. Also
can you add a comment describing what this method does?
* JarVerifier
[267]: this should be printed in debug only
--Sean
On 2/10/11 3:08 AM, Weijun Wang wrote:
On 02/02/2011 04:42 AM, Sean Mullan wrote:
Hi Max,
This is looking good. I'm about halfway through. Here are some
Changeset: bc0c58d65e97
Author:mullan
Date: 2011-03-07 13:20 -0500
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bc0c58d65e97
7022467: SecretKeyFactory doesn't support algorithm AES on Windows and Linux
Reviewed-by: wetmore, valeriep
!
/Makefile to run the tests.
http://cr.openjdk.java.net/~ramap/CR7020513-open-webrev/
thanks,
Rama Pulavarthi
On 02/25/2011 12:21 PM, Sean Mullan wrote:
Looks good to me.
--Sean
On 2/25/11 1:12 PM, Rama Pulavarthi wrote:
Please review this updated webrev that has the patch for JDK 7 repo.
http
Max, Freda,
Could you please review this webrev for a batch of translatability bugs:
http://cr.openjdk.java.net/~mullan/webrevs/7019937_et_al/webrev.00/
Thanks,
Sean
Hi Max,
The fix looks good. I suggest you also remove this comment in
ManifestEntryVerifier:
198 // MANIFEST.MF should not be skipped. It has signers.
and add a similar comment to JarSigner.doneWithMeta.
Also, in the test, I think you should add a try/finally clause and close the 2
04:15 AM, Brad Wetmore wrote:
On 3/24/2011 6:49 AM, Sean Mullan wrote:
Max, Freda,
Could you please review this webrev for a batch of translatability bugs:
http://cr.openjdk.java.net/~mullan/webrevs/7019937_et_al/webrev.00/
KeyTool.java:
=
Looks good. Only minor comments about line
Moving to security-dev@openjdk.java.net
On 3/31/11 4:11 PM, Kurt Yoder wrote:
Hello all,
I'm trying to run Apache Archiva using OpenJDK, and authenticating off SSL-protected
LDAP. This is throwing an exception
sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid
This fix looks fine to me.
--Sean
On 4/8/11 5:46 PM, Valerie (Yu-Ching) Peng wrote:
Sean,
Do you have cycles to review this following fix:
7001094: Can't initialize SunPKCS11 more times than PKCS11 driver
maxSessionCount
The webrev can be found at:
Changeset: 2c46bf0a462c
Author:mullan
Date: 2011-04-21 17:39 -0400
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2c46bf0a462c
7038175: Expired PKITS certificates causing CertPathBuilder and
CertPathValidator regression test failures
Reviewed-by: xuelei
!
This looks fine. However, the bug report never mentions why it is ok to remove
the CKM_SSL3_KEY_AND_MAC_DERIVE and CKM_TLS_KEY_AND_MAC_DERIVE mechanisms. I
think it should be updated.
Also, isn't this the kind of thing we should periodically review each release?
If so, maybe we should create
Hi Omair,
Did you also file a corresponding bug report with this patch? I cannot find one.
That would have helped, as it would have been less likely to have been missed.
I can file a bug on your behalf, or you can file one yourself via
http://bugs.sun.com/bugdatabase/index.jsp but I can't
Changeset: 0a80650409e1
Author:mullan
Date: 2011-05-24 14:15 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0a80650409e1
703: Permissions resolved incorrectly for jar protocol (Patch from
bugs.openjdk.java.net)
Reviewed-by: alanb, chegar
Contributed-by:
Hi Alan,
Would you be able to review my fix for 7050329? In the fix, I removed the
dependency on the java.ext.dirs system property and the default java.policy
file, which may contain implementation-specific content and thus could vary on
JREs from other vendors.
On 6/2/11 9:36 AM, Alan Bateman wrote:
Sean Mullan wrote:
Hi Alan,
Would you be able to review my fix for 7050329? In the fix, I removed the
dependency on the java.ext.dirs system property and the default java.policy
file, which may contain implementation-specific content and thus could vary
Changeset: 49aef5a5416e
Author:mullan
Date: 2011-06-04 06:45 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/49aef5a5416e
7050329: test/java/security/Policy/GetPermissions/JarURL.java fails on Windows
Reviewed-by: alanb
! test/java/security/Policy/GetPermissions/JarURL.java
I was thinking the same thing. I'll file a bug to have this fixed in JDK 8.
--Sean
On 06/14/2011 08:43 AM, Chris Hegarty wrote:
In fact this looks like a good candidate for try-with-resources.
-Chris.
On 06/14/11 12:26 PM, Florian Weimer wrote:
It seems to me this incorrect advice should be
Bug has been filed. See:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7054969
--Sean
On 6/14/11 9:45 AM, Sean Mullan wrote:
I was thinking the same thing. I'll file a bug to have this fixed in JDK 8.
--Sean
On 06/14/2011 08:43 AM, Chris Hegarty wrote:
In fact this looks like a good
Looks good.
--Sean
On 6/22/11 11:51 PM, Xuelei Fan wrote:
bug detail: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7057022
webrev: http://cr.openjdk.java.net/~xuelei/7057022/webrev.00/
Thanks,
Xuelei
Are you using JDK 7? There were some bugs fixed with indirect CRLs in JDK 7.
Also, make sure you set the system property com.sun.security.enableCRLDP to the
value true when running, ex: java -Dcom.sun.security.enableCRLDP=true ...
--Sean
On 6/28/11 1:05 AM, xuelei@oracle.com wrote:
Can
On Tue, Jun 28, 2011 at 5:46 AM, Sean Mullan sean.mul...@oracle.com
mailto:sean.mul...@oracle.com wrote:
Are you using JDK 7? There were some bugs fixed with indirect CRLs in JDK 7.
Also, make sure you set the system property com.sun.security.enableCRLDP to
the
value true when
On 6/27/11 9:29 PM, Xuelei Fan wrote:
webrev: http://cr.openjdk.java.net/~xuelei/7059709/webrev.00/
It seems you could restructure this code by moving the instantiation of the
FileInputStream down just before the KeyStore.load and use a try-with-resources
block instead.
--Sean
All the changes look good. I only have a couple of questions/comments:
1) How did you calculate the serialVersionUID for the classes that had omitted
this field? Ideally you want to calculate it on a previous version of the class,
for compatibility reasons. This is especially important for
On 7/18/11 1:17 PM, Alexandre Boulgakov wrote:
Please see my responses in-line.
Thanks for reviewing!
-Sasha
On 7/15/2011 6:18 AM, Chris Hegarty wrote:
On 07/15/11 01:19 PM, Sean Mullan wrote:
All the changes look good. I only have a couple of questions/comments:
1) How did you
On 7/18/11 5:35 PM, Alexandre Boulgakov wrote:
Is there an easy way to see when a class was added to the JDK?
For standard API classes, you can use the @since javadoc tag which will indicate
the release it was first introduced in.
For internal classes, there is no easy way, since most don't
.
Thanks,
Sasha
On 7/18/2011 5:33 PM, Brad Wetmore wrote:
(Apologies to folks without access to the older sources.)
On 07/18/11 15:00, Sean Mullan wrote:
On 7/18/11 5:35 PM, Alexandre Boulgakov wrote:
Is there an easy way to see when a class was added to the JDK?
For standard API classes, you
(dropping core-libs-dev)
On 8/22/11 9:03 AM, Sebastian Sickelmann wrote:
Hi,
while making some change for using exception-chaining on RuntimeException in
more cases, i found that javax.xml.crypto.NoSuchMechnismException had a
private
cause field that isn't necessary since throwable can
policy file.
JPRT runs fine except that one windows-i586 job is still initializing.
Ignored.
Thanks
Max
On 08/26/2011 03:26 AM, Sean Mullan wrote:
I noticed that none of the jprt test targets in test/Makefile run tests in
the
javax/xml/crypto directory (i.e. JSR 105 tests) - would
On 8/26/11 9:42 AM, Weijun Wang wrote:
On 08/26/2011 09:15 PM, Sean Mullan wrote:
Looks fine though you missed updating the copyright date on the test.
Recently I form a new habit of not touching copyright years at all, so
that a changeset can be ported to another version with no change
I agree that we should not remove all tests for DSA keypair generation - this
could also hide any new regressions in that area.
It's my understanding that there are still some tests that test DSA keypair
generation, just not as many, so the likelihood of encountering the Solaris bug
is smaller.
On 8/31/11 3:26 PM, Sebastian Sickelmann wrote:
Some discussions went on in this thread as i tried to apply this
solution to some other classes.
These classes has adressed the new chaining support in Throwable quite
different.
In the meanwhile i think it is done best the way it is done in
On 9/3/11 1:04 PM, Sebastian Sickelmann wrote:
Am 02.09.2011 21:58, schrieb Sean Mullan:
On 9/2/11 1:43 AM, Sebastian Sickelmann wrote:
Here is the updated webrev:
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/7011804_0/
Hmm, the main problem I have with this change
1 - 100 of 2178 matches
Mail list logo
