hg: jdk8/tl/jdk: 3 new changesets
Changeset: a8da4e516bc3 Author:akhil Date: 2013-04-23 11:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8da4e516bc3 8005051: optimized defaults for Iterator.forEachRemaining Reviewed-by: alanb, mduigou, psandoz, ulfzibis Contributed-by: Akhil Arora ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java Changeset: ceeed0fcb371 Author:jgish Date: 2013-04-02 18:41 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ceeed0fcb371 5015163: (str) String merge/join that is the inverse of String.split() 7172553: A utility class that forms the basis of a String.join() operation Summary: Integrate StringJoiner changes from lambda Reviewed-by: alanb, mduigou ! make/java/java/FILES_java.gmk ! src/share/classes/java/lang/String.java + src/share/classes/java/util/StringJoiner.java + test/java/lang/String/StringJoinTest.java + test/java/util/StringJoiner/StringJoinerTest.java Changeset: 2cb55846c9bb Author:mduigou Date: 2013-04-24 16:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cb55846c9bb 8011920: Main streams implementation 8012542: Stream methods on Collection Reviewed-by: dholmes, mduigou Contributed-by: Brian Goetz , Mike Duigou , Paul Sandoz ! make/docs/CORE_PKGS.gmk ! src/share/classes/java/util/Collection.java + src/share/classes/java/util/stream/AbstractPipeline.java + src/share/classes/java/util/stream/AbstractSpinedBuffer.java + src/share/classes/java/util/stream/DistinctOps.java + src/share/classes/java/util/stream/DoublePipeline.java + src/share/classes/java/util/stream/IntPipeline.java + src/share/classes/java/util/stream/LongPipeline.java + src/share/classes/java/util/stream/Nodes.java + src/share/classes/java/util/stream/ReduceOps.java + src/share/classes/java/util/stream/ReferencePipeline.java + src/share/classes/java/util/stream/SliceOps.java + src/share/classes/java/util/stream/SortedOps.java + src/share/classes/java/util/stream/SpinedBuffer.java + src/share/classes/java/util/stream/StreamSpliterators.java + src/share/classes/java/util/stream/StreamSupport.java
hg: jdk8/tl/langtools: 8013256: javac test failing after Lambda changes to java.util.List
Changeset: 4b0038f66d66 Author:jjg Date: 2013-04-25 17:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4b0038f66d66 8013256: javac test failing after Lambda changes to java.util.List Reviewed-by: mduigou ! test/tools/javac/api/TestJavacTaskScanner.java
hg: jdk8/tl/jdk: 8012530: test/sun/security/provider/SecureRandom/StrongSeedReader.java failing
Changeset: b600d637ef77 Author:wetmore Date: 2013-04-25 17:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b600d637ef77 8012530: test/sun/security/provider/SecureRandom/StrongSeedReader.java failing Reviewed-by: wetmore Contributed-by: alan.bate...@oracle.com ! test/sun/security/provider/SecureRandom/StrongSeedReader.java
Reviewed: JDK-8012530 : test/sun/security/provider/SecureRandom/StrongSeedReader.java failing
This is a simple fix that Alan Bateman noticed during our nightly testing. On some Linux, the java.io.tmp directory does not include the trailing "/", but does on others OS. Apparently, on my JPRT run, whatever Linux machine this ran on did include the slash, or else I was asleep at the switch. Anyway, I've reviewed and am integrating this on his behalf. http://cr.openjdk.java.net/~wetmore/8012530/webrev.00/ Thanks for pointing this out, Alan. Brad
hg: jdk8/tl/jdk: 8000529: Regression: SimpleDateFormat incorrectly parses dates formatted with Z and z pattern letters
Changeset: 5871d7b1673c Author:coffeys Date: 2013-04-25 21:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5871d7b1673c 8000529: Regression: SimpleDateFormat incorrectly parses dates formatted with Z and z pattern letters Reviewed-by: okutsu ! src/share/classes/java/text/CalendarBuilder.java ! src/share/classes/java/text/SimpleDateFormat.java ! test/java/text/Format/DateFormat/Bug7130335.java
Re: [8] Code Review Request for 8013228: Create new system properties to control allowable OCSP clock skew and CRL connection timeout
That fix looks good to me. Thanks. On 25/04/2013 19:47, Sean Mullan wrote: This fix adds support for 2 new system properties to allow users to adjust the maximum allowable clock skew when validating OCSP responses, and a maximum connection timeout for downloading CRLs. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8013228/webrev.00/ Thanks, Sean
hg: jdk8/tl/jdk: 8012937: Correct errors in javadoc comments.
Changeset: ca0957f0d408 Author:emc Date: 2013-04-25 14:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca0957f0d408 8012937: Correct errors in javadoc comments. Summary: Correct some errors in the javadoc comments for parameter reflection. Reviewed-by: darcy ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Parameter.java
[8] Code Review Request for 8013228: Create new system properties to control allowable OCSP clock skew and CRL connection timeout
This fix adds support for 2 new system properties to allow users to adjust the maximum allowable clock skew when validating OCSP responses, and a maximum connection timeout for downloading CRLs. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8013228/webrev.00/ Thanks, Sean
Re: Code Review Requests for 7196382 and 8010134
Xuelei, Thanks for the review and comments. Supposedly, we don't have to have default parameters for all valid key sizes. The pre-generated default parameters are for the most-commonly used keysizes. As for the rest of supported key sizes, the needed parameters will be generated at runtime upon request. Well, I don't quite like the current approach of hardcoding ranges inside the checkKeySize(...) method. There is a way to query the supported keysize ranges from the PKCS11 library and I think that should be the values that we base the key size check on, plus any additional algorithm-specific check (e.g. multiples of 64 bits) that can't be expressed through the ranges. I am still testing out the changes. Will post an updated webrev for 7196382 once I am done testing... Thanks! Valerie On 04/18/13 21:45, Xuelei Fan wrote: On 4/19/2013 10:43 AM, Valerie (Yu-Ching) Peng wrote: Xuelei, Do you have time to review the following two fixes? 7196382: PKCS11 provider should support 2048-bit DH 8010134: A finalizer in sun.security.pkcs11.wrapper.PKCS11 perhaps should be protected The first one removes the hardcoded limit of 1024 for DH and the second one is making the finalize() method protected. Webrevs: http://cr.openjdk.java.net/~valeriep/7196382/webrev.00/ Looks fine. Do we plan to support DH keys bwteen 1024 and 2048 with default (null) parameters, for example 1536, in PKCS11 provider? Recently, I run into a case that uses DH public keys of 1536 bits. I was wondering we may also want to support more. http://cr.openjdk.java.net/~valeriep/8010134/webrev.00/ Looks fine. Xuelei Thanks! Valerie
hg: jdk8/tl/jdk: 8012044: Give more information about self-suppression from Throwable.addSuppressed
Changeset: 4da1d43f5843 Author:darcy Date: 2013-04-25 09:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4da1d43f5843 8012044: Give more information about self-suppression from Throwable.addSuppressed Reviewed-by: alanb, dholmes ! src/share/classes/java/lang/Throwable.java ! test/java/lang/Throwable/SuppressedExceptions.java
Re: [8] Code Review Request for 8011313: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout not defined
Your fix looks fine. Thanks. On 25 Apr 2013, at 16:00, Sean Mullan wrote: > Hi Vinnie, > > Could I get a code review for the fix for 8011313: > > http://cr.openjdk.java.net/~mullan/webrevs/8011313/webrev.00/ > > The bug has been tagged with noreg-sqe since there is an existing SQE test > for this. > > Thanks, > Sean
[8] Code Review Request for 8011313: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout not defined
Hi Vinnie, Could I get a code review for the fix for 8011313: http://cr.openjdk.java.net/~mullan/webrevs/8011313/webrev.00/ The bug has been tagged with noreg-sqe since there is an existing SQE test for this. Thanks, Sean
Re: Review Request for 9000142: PlatformPCSC.java loading unversioned native shared library
On 04/25/2013 12:11 AM, Valerie (Yu-Ching) Peng wrote: Won't this change break systems which don't have libpcsclite.so.1? By linking against libpcsclite.so.1 at the ELF level? Yes. But the dependency is already there, it is just not expressed explicitly, so it will not be discovered by tools which extract the NEEDED ELF attribute. Changes like this need to be thought through. What happens when libpcsclite.so.2 comes out? The current version might continue to work correctly. Or might result in random crashes. Probably the latter, considering the soname bump. As for API changes, shouldn't there be some compatibility requirement on APIs as libpcsclite.so evolves? The convention is that the soname bump implies that the ABI has changed in a backwards-incompatible way. If libj2pcsc linked directly against libpcslite, we'd lose the availability to switch to libpcscspy instead. But the latter is part of the development package only, and I don't know how useful it is for production use. (All this is about GNU/Linux. Windows is clearly different, not sure about the other POSIX platforms.) -- Florian Weimer / Red Hat Product Security Team
Re: Review Request for 9000142: PlatformPCSC.java loading unversioned native shared library
Hi Valerie, Thanks for the review! On Wed, 2013-04-24 at 15:11 -0700, Valerie (Yu-Ching) Peng wrote: > Won't this change break systems which don't have libpcsclite.so.1? Yes. However, currently it breaks systems which don't have libpcsclite.so. [1] would be an example. There is a system property, sun.security.smartcardio.library, which could be used to specify the library path. *If* people really want to use libpcsclite.so (no matter the version), they could use that property. What I think is bad, is that it currently tries to use unversioned libpcsclite.so by default. I mean even when no property has been set. While the static initializer might work in that case it could potentially fail later on when it's used and libpcsclite.so is actually a newer version the Java API does not know how to handle. > Changes like this need to be thought through. What happens when > libpcsclite.so.2 comes out? Exactly. Right now there is the potential to accept a libpcsclite.so.2 if that library providing libpcsclite.so.2 also provides a symlink to libpcsclite.so. My proposed change to PlatformPCSC would make that fail with an IOException right in the static initializer. Failing early seems to be a better approach in this case. > As for API changes, shouldn't there be some compatibility requirement on > APIs as libpcsclite.so evolves? Maybe. It looks to me that PlatformPCSC seems to rely on that. What if API compatibility has been assumed, but does not hold once libpcsclite.so.2 comes out? Cheers, Severin [1] https://bugzilla.redhat.com/show_bug.cgi?id=910107 > On 04/24/13 04:05, Florian Weimer wrote: > > On 03/01/2013 11:30 AM, Severin Gehwolf wrote: > >> Hi, > >> > >> The bug for this review request is at: > >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142 > >> > >> In PlatformPCSC.java unversioned native libraries are loaded by default > >> if no system property is specified. This could lead to a JVM crash if > >> the API of the native library changes, but the Java code still relies on > >> old API. The fix is to load versioned shared libraries instead. > > > > Hmm. Why doesn't the "j2pcsc" library link against the right version > > of libpcsclite.so? > > >
Re: Review Request for 9000142: PlatformPCSC.java loading unversioned native shared library
On Wed, 2013-04-24 at 13:05 +0200, Florian Weimer wrote: > On 03/01/2013 11:30 AM, Severin Gehwolf wrote: > > Hi, > > > > The bug for this review request is at: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9000142 > > > > In PlatformPCSC.java unversioned native libraries are loaded by default > > if no system property is specified. This could lead to a JVM crash if > > the API of the native library changes, but the Java code still relies on > > old API. The fix is to load versioned shared libraries instead. > > Hmm. Why doesn't the "j2pcsc" library link against the right version of > libpcsclite.so? Good question. Anyone who was involved with creating the PlatformPCSC API still around who would be able to answer this question? Cheers, Severin
