hg: jdk8/tl/jdk: 8017141: java.util/stream Spliterators from sequential sources should not catch OOME
Changeset: 628432ee4d68 Author:henryjen Date: 2013-07-09 09:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/628432ee4d68 8017141: java.util/stream Spliterators from sequential sources should not catch OOME Reviewed-by: mchung Contributed-by: paul.san...@oracle.com ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/Spliterators.java
Request for review: 8019267: NPE in AbstractSaslImpl when trace level = FINER in KRB5
Hi All An NPE was suppressed in jdk8 with a simple if. This new fix tries to output useful info even for a null argument. Please review the code changes at http://cr.openjdk.java.net/~weijun/8019267/webrev.01/ The added test makes sure logging does not crash and the output is informational. Thanks Max
hg: jdk8/tl/jdk: 8019551: Make BaseStream public
Changeset: 44a634c1edc4 Author:psandoz Date: 2013-07-09 10:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44a634c1edc4 8019551: Make BaseStream public Reviewed-by: chegar, psandoz Contributed-by: brian goetz brian.go...@oracle.com ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/BaseStream.java
Re: Request for review: 8019267: NPE in AbstractSaslImpl when trace level = FINER in KRB5
Looks fine. --Sean On 07/09/2013 03:32 AM, Weijun Wang wrote: Hi All An NPE was suppressed in jdk8 with a simple if. This new fix tries to output useful info even for a null argument. Please review the code changes at http://cr.openjdk.java.net/~weijun/8019267/webrev.01/ The added test makes sure logging does not crash and the output is informational. Thanks Max
Re: 7u40 Review Request for 8017173: XMLCipher with RSA_OAEP Key Transport algorithm can't be instantiated
Your fix looks good. On 8 Jul 2013, at 21:48, Sean Mullan wrote: Hi Xuelei, Can you please review my fix for JDK-8017173? This is a regression introduced in 7u25. It does not affect JDK 8, because the recent fix for JDK-8011547 to integrate the Apache Santuario release 1.5.4 also fixed this issue. However, I am not backporting the JDK 8 code, which is more complicated and higher risk (see the comments in the bug for more information). For 7u40, this is a one line fix which reverts to the code in 7u21 to minimize the risk. webrev: http://cr.openjdk.java.net/~mullan/webrevs/8017173/webrev.00/ Thanks, Sean
RFR : 8019979 : Replace CheckPackageAccess test with better one from closed repo
I'd like to move this testcase from our internal test repo and replace the current test/java/lang/SecurityManager/CheckPackageAccess.java testcase . It's a straightforward test to ensure that the package restrictions enforced via the java.security file are those expected. The testcase should be updated any time the package.access or package.definition properties are updated. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8019979/webrev/ http://cr.openjdk.java.net/%7Ecoffeys/webrev.8019979/webrev/ bug report : http://bugs.sun.com/view_bug.do?bug_id=8019979 regards, Sean.
Re: RFR : 8019979 : Replace CheckPackageAccess test with better one from closed repo
Looks good to me. --Sean On 07/09/2013 09:28 AM, Seán Coffey wrote: I'd like to move this testcase from our internal test repo and replace the current test/java/lang/SecurityManager/CheckPackageAccess.java testcase . It's a straightforward test to ensure that the package restrictions enforced via the java.security file are those expected. The testcase should be updated any time the package.access or package.definition properties are updated. webrev : http://cr.openjdk.java.net/~coffeys/webrev.8019979/webrev/ http://cr.openjdk.java.net/%7Ecoffeys/webrev.8019979/webrev/ bug report : http://bugs.sun.com/view_bug.do?bug_id=8019979 regards, Sean.
hg: jdk8/tl/jdk: 8019370: Sync j.u.c Fork/Join from 166 to tl
Changeset: 43134e79c0bb Author:psandoz Date: 2013-07-09 16:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/43134e79c0bb 8019370: Sync j.u.c Fork/Join from 166 to tl Reviewed-by: chegar, martin Contributed-by: Doug Lea d...@cs.oswego.edu ! src/share/classes/java/util/concurrent/AbstractExecutorService.java ! src/share/classes/java/util/concurrent/Callable.java ! src/share/classes/java/util/concurrent/CancellationException.java ! src/share/classes/java/util/concurrent/CompletableFuture.java ! src/share/classes/java/util/concurrent/CompletionService.java ! src/share/classes/java/util/concurrent/CountedCompleter.java ! src/share/classes/java/util/concurrent/ExecutionException.java ! src/share/classes/java/util/concurrent/Executor.java ! src/share/classes/java/util/concurrent/ExecutorService.java ! src/share/classes/java/util/concurrent/Executors.java ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinTask.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java ! src/share/classes/java/util/concurrent/Future.java ! src/share/classes/java/util/concurrent/FutureTask.java ! src/share/classes/java/util/concurrent/RecursiveAction.java ! src/share/classes/java/util/concurrent/RecursiveTask.java ! src/share/classes/java/util/concurrent/RejectedExecutionException.java ! src/share/classes/java/util/concurrent/RunnableFuture.java ! src/share/classes/java/util/concurrent/RunnableScheduledFuture.java ! src/share/classes/java/util/concurrent/ScheduledExecutorService.java ! src/share/classes/java/util/concurrent/ScheduledThreadPoolExecutor.java ! src/share/classes/java/util/concurrent/ThreadPoolExecutor.java
hg: jdk8/tl/jdk: 8019979: Replace CheckPackageAccess test with better one from closed repo
Changeset: 83c2976ef8ee Author:coffeys Date: 2013-07-09 16:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/83c2976ef8ee 8019979: Replace CheckPackageAccess test with better one from closed repo Reviewed-by: mullan ! test/java/lang/SecurityManager/CheckPackageAccess.java
hg: jdk8/tl/langtools: 8020214: TEST_BUG: test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java broken
Changeset: aedb3bb327d5 Author:ksrini Date: 2013-07-09 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aedb3bb327d5 8020214: TEST_BUG: test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java broken Reviewed-by: jjg ! test/tools/javap/8007907/JavapReturns0AfterClassNotFoundTest.java
hg: jdk8/tl/jaxp: 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown
Changeset: 3b071f506ab9 Author:joehw Date: 2013-07-09 16:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/3b071f506ab9 8016648: FEATURE_SECURE_PROCESSING set to true or false causes SAXParseException to be thrown Summary: jaxp 1.5 feature update Reviewed-by: alanb, dfuchs, lancea ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xalan/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerFactoryImpl.java ! src/com/sun/org/apache/xerces/internal/dom/DOMConfigurationImpl.java ! src/com/sun/org/apache/xerces/internal/impl/Constants.java ! src/com/sun/org/apache/xerces/internal/impl/PropertyManager.java ! src/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaLoader.java ! src/com/sun/org/apache/xerces/internal/impl/xs/XMLSchemaValidator.java ! src/com/sun/org/apache/xerces/internal/impl/xs/traversers/XSDHandler.java ! src/com/sun/org/apache/xerces/internal/jaxp/DocumentBuilderImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/SAXParserImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/StreamValidatorHelper.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/ValidatorHandlerImpl.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaFactory.java ! src/com/sun/org/apache/xerces/internal/jaxp/validation/XMLSchemaValidatorComponentManager.java ! src/com/sun/org/apache/xerces/internal/parsers/DOMParser.java ! src/com/sun/org/apache/xerces/internal/parsers/SAXParser.java ! src/com/sun/org/apache/xerces/internal/parsers/XML11Configuration.java ! src/com/sun/org/apache/xerces/internal/utils/SecuritySupport.java + src/com/sun/org/apache/xerces/internal/utils/XMLSecurityPropertyManager.java ! src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java ! src/com/sun/org/apache/xml/internal/utils/XMLReaderManager.java
Re: Code Review Requests for 7196382 and 8010134
Xuelei, I got side-tracked w/ other bugs before coming back to this one. I have updated the webrev to incorporate your review comments, including 1) auto-adjust the default keysize when it's out of range 2) apply our own range checking besides the native limit checking I also noticed that the DH parameter generator from SunJCE provider relies on DSA, so I checked its keysize checking to match the DSA keysize. The webrev is updated at: http://cr.openjdk.java.net/~valeriep/7196382/webrev.02/ Thanks, Valerie On 04/27/13 01:58, Xuelei Fan wrote: I like this update. On 4/27/2013 7:29 AM, Valerie (Yu-Ching) Peng wrote: Xuelei, I have updated the webrev for 7196382 so it uses the key size range info from the underlying PKCS library for key size checking: http://cr.openjdk.java.net/~valeriep/7196382/webrev.01/ 107 //TBD: auto-adjust default keysize in case it's out-of-range? I think it's nice to enable this following block. The key size will be checked in initialize(), so I think it is a little bit reasonable to select a proper default key size instead of throwing an exception later. 209 private void checkKeySize(int ks, RSAKeyGenParameterSpec params) I think when minKeySize is -1, we need to consider the default key size limit (EC 112, RSA/DH/DSA 512). In this update, it seems that if minKeySize is -1, we can generate small keys. I don't think it is the intended design. It is similar when maxKeySize is -1. I was wondering that if minKeySize is -1 (or less than the default hard-coded key size), or maxKeySize is -1 (or greater than the hard-coded default key size), we may be able to reset them to the default hard-coded sizes. Thanks, Xuelei Thanks, Valerie On 04/25/13 10:59, Valerie (Yu-Ching) Peng wrote: 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: 8016341: java/lang/ref/OOMEInReferenceHandler.java failing intermittently
Changeset: 7bb17aa9a09f Author:dholmes Date: 2013-07-09 22:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bb17aa9a09f 8016341: java/lang/ref/OOMEInReferenceHandler.java failing intermittently Summary: Ensure WeakRef object can't be prematurely gc'd Reviewed-by: chegar, plevart ! test/java/lang/ref/OOMEInReferenceHandler.java
