From lana.steuck at oracle.com Tue Jan 1 21:31:25 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:25 +0000 Subject: hg: jdk8/tl: 10 new changesets Message-ID: <20130102053126.5650B4749D@hg.openjdk.java.net> Changeset: 8e36a0fabf58 Author: ohrstrom Date: 2012-12-18 09:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8e36a0fabf58 8004145: New improved hgforest.sh, ctrl-c now properly terminates mercurial processes. Reviewed-by: ohair, erikj + common/bin/hgforest.sh ! get_source.sh Changeset: 51d3b65b8093 Author: erikj Date: 2012-12-18 17:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/51d3b65b8093 8001901: build-infra: Fix "misbehaving" which command on Solaris Summary: Removed all uses of which in configure on solaris. Reviewed-by: ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: 6ee8080a6efe Author: katleman Date: 2012-12-19 13:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6ee8080a6efe Merge Changeset: 32148e971ac8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/32148e971ac8 Added tag jdk8-b69 for changeset 6ee8080a6efe ! .hgtags Changeset: 6b93e7a4401d Author: dholmes Date: 2012-12-20 01:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6b93e7a4401d 7190137: Add support for JVM_VARIANT minimal1 Summary: Allow configuration of minimal1 as a target VM along with client and server Reviewed-by: ohair, erikj ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/toolchain.m4 Changeset: cd06b2ea58dd Author: katleman Date: 2012-12-20 16:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cd06b2ea58dd 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! common/makefiles/RMICompilation.gmk Changeset: 105a25ffa4a4 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/105a25ffa4a4 Merge Changeset: 3fb32a5a2388 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3fb32a5a2388 Added tag jdk8-b70 for changeset 105a25ffa4a4 ! .hgtags Changeset: 51ad2a343420 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/51ad2a343420 Merge Changeset: b845a2494261 Author: lana Date: 2013-01-01 12:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b845a2494261 Merge From lana.steuck at oracle.com Tue Jan 1 21:31:24 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:24 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130102053127.70EEC4749E@hg.openjdk.java.net> Changeset: 603cceb495c8 Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/603cceb495c8 Added tag jdk8-b69 for changeset 22ddcac208a8 ! .hgtags Changeset: 8171d23e914d Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/8171d23e914d Added tag jdk8-b70 for changeset 603cceb495c8 ! .hgtags From lana.steuck at oracle.com Tue Jan 1 21:31:25 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:25 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130102053130.DFAE54749F@hg.openjdk.java.net> Changeset: 3b1c2733d47e Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/3b1c2733d47e Added tag jdk8-b69 for changeset 756323c99011 ! .hgtags Changeset: f577a39c9fb3 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/f577a39c9fb3 Added tag jdk8-b70 for changeset 3b1c2733d47e ! .hgtags From lana.steuck at oracle.com Tue Jan 1 21:31:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:27 +0000 Subject: hg: jdk8/tl/jaxp: 5 new changesets Message-ID: <20130102053141.B1FB7474A0@hg.openjdk.java.net> Changeset: 27421008f050 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/27421008f050 Added tag jdk8-b69 for changeset 789a855de959 ! .hgtags Changeset: a72c8391cdd6 Author: katleman Date: 2012-12-20 16:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a72c8391cdd6 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/com/sun/org/apache/xalan/internal/XalanConstants.java ! src/com/sun/org/apache/xalan/internal/utils/FactoryImpl.java Changeset: 6ec9edffc286 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6ec9edffc286 Merge Changeset: 63815efd132f Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/63815efd132f Added tag jdk8-b70 for changeset 6ec9edffc286 ! .hgtags Changeset: 499be952a291 Author: lana Date: 2012-12-28 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/499be952a291 Merge From lana.steuck at oracle.com Tue Jan 1 21:31:35 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:35 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20130102053153.F32DA474A1@hg.openjdk.java.net> Changeset: 2001991b1b40 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2001991b1b40 Added tag jdk8-b69 for changeset d7360bf35ee1 ! .hgtags Changeset: 7d34e91f66bb Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d34e91f66bb 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! make/Makefile-classic ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! test/tools/javac/StringsInSwitch/StringSwitches.java ! test/tools/javac/api/T6395981.java ! test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java ! test/tools/javac/diags/examples/DuplicateAnnotation.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestKinds.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase1.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase2.java ! test/tools/javac/lambda/methodReferenceExecution/MethodReferenceTestSueCase4.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/AttributeInjector.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFile.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassFilePreprocessor.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/ClassToInterfaceConverter.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/Compiler.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/DirectedClassLoader.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/SourceModel.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/separate/TestHarness.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/nativeHeaders/javahComparison/CompareTest.java ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 47f71d7c124f Author: katleman Date: 2012-12-26 14:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/47f71d7c124f Merge Changeset: 7d5032c2d747 Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d5032c2d747 Added tag jdk8-b70 for changeset 47f71d7c124f ! .hgtags Changeset: 467e4d9281bc Author: lana Date: 2012-12-28 18:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/467e4d9281bc Merge ! test/tools/javac/processing/model/util/deprecation/TestDeprecation.java Changeset: 1d8438db45f2 Author: lana Date: 2013-01-01 17:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1d8438db45f2 Merge From lana.steuck at oracle.com Tue Jan 1 21:31:45 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:31:45 +0000 Subject: hg: jdk8/tl/hotspot: 47 new changesets Message-ID: <20130102053316.55C33474A2@hg.openjdk.java.net> Changeset: 4a2ed49abd51 Author: amurillo Date: 2012-12-07 10:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a2ed49abd51 8004724: new hotspot build - hs25-b13 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 442f942757c0 Author: johnc Date: 2012-10-01 09:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/442f942757c0 8000244: G1: Ergonomically set MarkStackSize and use virtual space for global marking stack Summary: Set the value of MarkStackSize to a value based on the number of parallel marking threads with a reasonable minimum. Expand the marking stack if we have to restart marking due to an overflow up to a reasonable maximum. Allocate the underlying space for the marking stack from virtual memory. Reviewed-by: jmasa, brutisso ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a14c5698a162 Author: johnc Date: 2012-12-07 16:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a14c5698a162 Merge Changeset: 2aa953165ade Author: brutisso Date: 2012-12-13 10:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2aa953165ade 8004661: Comment and function name java_lang_String::toHash is wrong Summary: renamed to hash_code Reviewed-by: dholmes, coleenp, brutisso Contributed-by: erik.helin at oracle.com ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/symbolTable.cpp Changeset: db8a7163c682 Author: stefank Date: 2012-12-13 09:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/db8a7163c682 8004674: Add necessary .inline.hpp files to fix non-PCH build Reviewed-by: stefank, coleenp Contributed-by: volker.simonis at gmail.com ! src/share/vm/gc_implementation/parallelScavenge/adjoiningVirtualSpaces.cpp ! src/share/vm/gc_implementation/shared/gcStats.cpp Changeset: 4459ef2189f5 Author: stefank Date: 2012-12-13 09:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4459ef2189f5 Merge Changeset: fd74228fd5ca Author: jiangli Date: 2012-12-11 12:41 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fd74228fd5ca 8004076: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Summary: Move _max_locals and _size_of_parameters to ConstMethod for better sharing. Reviewed-by: coleenp, minqi, jrose ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstMethod.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 807f1d348f7b Author: collins Date: 2012-12-14 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/807f1d348f7b Merge Changeset: b6c9c0109a60 Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6c9c0109a60 Merge Changeset: cb8a4e04bc8c Author: amurillo Date: 2012-12-14 14:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cb8a4e04bc8c Added tag hs25-b13 for changeset b6c9c0109a60 ! .hgtags Changeset: 8b4810c80f5d Author: katleman Date: 2012-12-20 09:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8b4810c80f5d Added tag jdk8-b69 for changeset cb8a4e04bc8c ! .hgtags Changeset: 1f323009c3ea Author: amurillo Date: 2012-12-14 14:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f323009c3ea 8005036: new hotspot build - hs25-b14 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 892acf0431ef Author: dcubed Date: 2012-12-14 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/892acf0431ef 7153050: remove crufty '_g' support from HotSpot repo makefiles Summary: Phase 1 is removing '_g' support from the Makefiles. Reviewed-by: dcubed, sspitsyn, coleenp, tbell Contributed-by: ron.durbin at oracle.com ! make/bsd/Makefile ! make/bsd/makefiles/buildtree.make ! make/bsd/makefiles/debug.make ! make/bsd/makefiles/dtrace.make ! make/bsd/makefiles/fastdebug.make ! make/bsd/makefiles/gcc.make ! make/bsd/makefiles/jsig.make ! make/bsd/makefiles/jvmg.make ! make/bsd/makefiles/optimized.make ! make/bsd/makefiles/product.make ! make/bsd/makefiles/saproc.make ! make/bsd/makefiles/vm.make ! make/linux/Makefile ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/debug.make ! make/linux/makefiles/fastdebug.make ! make/linux/makefiles/gcc.make ! make/linux/makefiles/jsig.make ! make/linux/makefiles/jvmg.make ! make/linux/makefiles/optimized.make ! make/linux/makefiles/product.make ! make/linux/makefiles/saproc.make ! make/linux/makefiles/vm.make ! make/solaris/Makefile ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/debug.make ! make/solaris/makefiles/dtrace.make ! make/solaris/makefiles/fastdebug.make ! make/solaris/makefiles/gcc.make ! make/solaris/makefiles/jsig.make ! make/solaris/makefiles/jvmg.make ! make/solaris/makefiles/optimized.make ! make/solaris/makefiles/product.make ! make/solaris/makefiles/saproc.make ! make/solaris/makefiles/vm.make ! make/windows/build.make ! make/windows/projectfiles/compiler2/ADLCompiler.dsp ! make/windows/projectfiles/tiered/ADLCompiler.dsp Changeset: 30866cd626b0 Author: coleenp Date: 2012-12-12 11:39 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/30866cd626b0 8004883: NPG: clean up anonymous class fix Summary: Add klass_holder() to return either mirror or class_loader depending on if the class is anonymous or not. Reviewed-by: stefank, jrose ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/klass.hpp Changeset: 18712b1caf7a Author: rkennke Date: 2012-12-12 21:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18712b1caf7a 8004898: library_call.cpp build error after 7172640 with GCC 4.7.2 Summary: fix opto/library_call.cpp compilation errors Reviewed-by: twisti, coleenp ! src/share/vm/opto/library_call.cpp Changeset: 8580f22db905 Author: coleenp Date: 2012-12-14 16:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8580f22db905 Merge Changeset: 3f84e17b6bca Author: zgu Date: 2012-12-17 13:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f84e17b6bca 8004802: jcmd VM.native_memory baseline=false crashes VM Summary: NMT has to check option's value also to determine which command to execute Reviewed-by: acorn, coleenp, hseigel ! src/share/vm/services/nmtDCmd.cpp Changeset: 805aa223d540 Author: zgu Date: 2012-12-17 10:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/805aa223d540 Merge Changeset: 594b9b2119ed Author: minqi Date: 2012-12-19 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/594b9b2119ed Merge Changeset: 0c535211ef13 Author: bharadwaj Date: 2012-12-07 18:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c535211ef13 8004668: Build failure for Zero target Summary: fixed build failure for Zero target Reviewed-by: twisti, kvn ! src/cpu/zero/vm/assembler_zero.cpp Changeset: a70c88896791 Author: kvn Date: 2012-12-13 17:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a70c88896791 8004713: Stackoverflowerror thrown when thread stack straddles 0x80000000 Summary: use unsigned comparison when checking for stack overflow Reviewed-by: kvn, twisti Contributed-by: paul.nauman at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp Changeset: 1b1e16471e46 Author: stefank Date: 2012-12-12 22:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b1e16471e46 8005002: Crash because of a raw oop in ClassLoaderData::add_dependency Summary: Move the handelization of 'last' to a point before the GC might enter. Reviewed-by: dholmes, sspitsyn, coleenp ! src/share/vm/classfile/classLoaderData.cpp Changeset: 5c0931d15474 Author: twisti Date: 2012-12-14 12:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5c0931d15474 8003238: JSR 292: intermittent exception failure with java/lang/invoke/CallSiteTest.java Reviewed-by: jrose, kvn ! src/share/vm/prims/methodHandles.cpp Changeset: 3c433d080bae Author: twisti Date: 2012-12-14 12:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3c433d080bae Merge Changeset: 18d56ca3e901 Author: twisti Date: 2012-12-17 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18d56ca3e901 8004548: remove unused AbstractAssembler::print(Label&) Reviewed-by: kvn, twisti Contributed-by: Bharadwaj Yadavalli ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.hpp ! src/cpu/sparc/vm/macroAssembler_sparc.inline.hpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/cpu/zero/vm/assembler_zero.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: ad5dd04754ee Author: roland Date: 2012-12-18 14:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ad5dd04754ee 8005031: Some cleanup in c2 to prepare for incremental inlining support Summary: collection of small changes to prepare for incremental inlining. Reviewed-by: twisti, kvn ! src/share/vm/ci/ciField.cpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/stringopts.cpp Changeset: eb409f2f146e Author: vlivanov Date: 2012-12-18 06:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eb409f2f146e 8003135: HotSpot inlines and hoists the Thread.currentThread().isInterrupted() out of the loop Summary: Make the load of TLS._osthread._interrupted flag in Thread.isInterrupted(Z)Z intrinsic effectively volatile. Reviewed-by: kvn, jrose ! src/share/vm/opto/library_call.cpp Changeset: 620e502e3f47 Author: vlivanov Date: 2012-12-18 08:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/620e502e3f47 Merge ! src/share/vm/opto/library_call.cpp Changeset: c4bd2eccea46 Author: twisti Date: 2012-12-18 10:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c4bd2eccea46 8004536: replace AbstractAssembler emit_word with emit_int16 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/x86/vm/assembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 1e41b0bc58a0 Author: kvn Date: 2012-12-18 17:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e41b0bc58a0 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/prims/unsafe.cpp Changeset: 65c8342f726a Author: twisti Date: 2012-12-19 14:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/65c8342f726a 8005033: clear high word for integer pop count on SPARC Reviewed-by: kvn, twisti Contributed-by: Richard Reingruber ! src/cpu/sparc/vm/sparc.ad + test/compiler/8005033/Test8005033.java Changeset: 2c7f594145dc Author: kvn Date: 2012-12-19 15:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2c7f594145dc 8004835: Improve AES intrinsics on x86 Summary: Enable AES intrinsics on non-AVX cpus, group together aes instructions in crypto stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! test/compiler/7184394/TestAESBase.java ! test/compiler/7184394/TestAESMain.java Changeset: 2d6c433b1f38 Author: kvn Date: 2012-12-19 19:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2d6c433b1f38 8004741: Missing compiled exception handle table entry for multidimensional array allocation Summary: Added missing exception path for multidimensional array allocation and use Throwable type instead of OutOfMemoryError for allocation's exception. Reviewed-by: twisti ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse3.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/runtime.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp + test/compiler/8004741/Test8004741.java Changeset: a46457045d66 Author: kvn Date: 2012-12-20 14:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a46457045d66 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Fix java names for getAndSet intrinsics Reviewed-by: kvn Contributed-by: aleksey.shipilev at oracle.com ! src/share/vm/classfile/vmSymbols.hpp Changeset: d02120b7a34f Author: twisti Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d02120b7a34f 8004250: replace AbstractAssembler a_byte/a_long with emit_int8/emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/zero/vm/assembler_zero.cpp ! src/os_cpu/solaris_x86/vm/assembler_solaris_x86.cpp ! src/os_cpu/windows_x86/vm/assembler_windows_x86.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: c52660592f37 Author: roland Date: 2012-12-21 01:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c52660592f37 Merge ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/opto/library_call.cpp Changeset: 0b3d19153cc6 Author: johnc Date: 2012-12-12 12:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b3d19153cc6 8001028: Improve GC option handling Summary: If there are not enough native resources to create the ReferenceHandler or Finalizer Java threads, the VM will attempt to throw an OOME before the java.lang.Class class has been initialized. This can result in assertion failures and other crashes. Move the initialization of the java.lang.Class class to just before the initialization of the java.lang.ref.Finalizer class. Reviewed-by: jwilhelm, dholmes, coleenp ! src/share/vm/runtime/thread.cpp Changeset: 730cc4ddd550 Author: brutisso Date: 2012-12-17 08:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/730cc4ddd550 7173959: Jvm crashed during coherence exabus (tmb) testing Summary: Mapping of aligned memory needs to be MT safe. Also reviewed by: vitalyd at gmail.com Reviewed-by: dholmes, coleenp, zgu ! src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/virtualspace.cpp Changeset: 32164d89fe9c Author: brutisso Date: 2012-12-17 15:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/32164d89fe9c 8004845: Catch incorrect usage of new and delete during compile time for value objects and stack objects Summary: Makes the "new" and "delete" operator of _ValueObj and StackObj private Reviewed-by: dholmes, coleenp Contributed-by: erik.helin at oracle.com ! src/share/vm/memory/allocation.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/services/memBaseline.hpp ! src/share/vm/utilities/workgroup.hpp ! src/share/vm/utilities/yieldingWorkgroup.hpp Changeset: c71879335291 Author: stefank Date: 2012-12-18 10:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c71879335291 8005108: NPG: MetaspaceAux::used_in_bytes(), capacity_in_bytes() and reserved_in_bytes() return inconsistent numbers Summary: Reverted the changes to these functions from JDK-8000662 Reviewed-by: brutisso, jmasa ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp Changeset: 345bd97a77be Author: brutisso Date: 2012-12-20 05:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/345bd97a77be 8004691: Add a jtreg test that exercises the ExecuteInternalVMTests flag Reviewed-by: stefank, brutisso, kvn, ctornqvi Contributed-by: erik.helin at oracle.com + test/sanity/ExecuteInternalVMTests.java Changeset: 69627aa9ab10 Author: jwilhelm Date: 2012-12-21 16:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69627aa9ab10 Merge ! src/share/vm/runtime/thread.cpp Changeset: 990bbd393c23 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/990bbd393c23 Merge Changeset: 6a1fc440b396 Author: amurillo Date: 2012-12-21 10:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6a1fc440b396 Added tag hs25-b14 for changeset 990bbd393c23 ! .hgtags Changeset: 79f492f184d0 Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79f492f184d0 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! agent/src/share/classes/sun/jvm/hotspot/ci/ciArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciField.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciInstance.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciMetadata.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObject.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciObjectFactory.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciReceiverTypeData.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciSymbol.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciType.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciTypeArrayKlass.java ! agent/src/share/classes/sun/jvm/hotspot/ci/ciVirtualCallData.java ! agent/src/share/classes/sun/jvm/hotspot/classfile/ClassLoaderData.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/BitData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ProfileData.java ! agent/src/share/classes/sun/jvm/hotspot/oops/RetData.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Block_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallDynamicJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/CallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Compile.java ! agent/src/share/classes/sun/jvm/hotspot/opto/HaltNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/InlineTree.java ! agent/src/share/classes/sun/jvm/hotspot/opto/JVMState.java ! agent/src/share/classes/sun/jvm/hotspot/opto/LoopNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallRuntimeNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachCallStaticJavaNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachIfNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachReturnNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MachSafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/MultiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_Array.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Node_List.java ! agent/src/share/classes/sun/jvm/hotspot/opto/Phase.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseRegAlloc.java ! agent/src/share/classes/sun/jvm/hotspot/opto/PhiNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/ProjNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RegionNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/RootNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/SafePointNode.java ! agent/src/share/classes/sun/jvm/hotspot/opto/TypeNode.java ! agent/src/share/classes/sun/jvm/hotspot/prims/JvmtiExport.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GenericGrowableArray.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/GrowableArray.java ! agent/src/share/native/sadis.c ! src/share/vm/classfile/classLoaderData.hpp ! src/share/vm/memory/metaspaceCounters.cpp ! src/share/vm/memory/metaspaceCounters.hpp ! src/share/vm/runtime/os_ext.hpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/diagnosticCommand_ext.hpp ! src/share/vm/services/memReporter.cpp ! src/share/vm/services/memReporter.hpp ! test/runtime/7158804/Test7158804.sh Changeset: e94068d4ff52 Author: katleman Date: 2012-12-26 14:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e94068d4ff52 Merge ! src/share/vm/classfile/classLoaderData.hpp Changeset: 0847210f8548 Author: katleman Date: 2012-12-27 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0847210f8548 Added tag jdk8-b70 for changeset e94068d4ff52 ! .hgtags From lana.steuck at oracle.com Tue Jan 1 21:33:15 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 02 Jan 2013 05:33:15 +0000 Subject: hg: jdk8/tl/jdk: 26 new changesets Message-ID: <20130102053807.24DCB474A5@hg.openjdk.java.net> Changeset: 4ea0ac8e02d2 Author: erikj Date: 2012-12-19 09:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ea0ac8e02d2 8004803: build-infra: Cannot use icedtea as boot for closed build. Summary: Set bootclasspath to javac and not the running jvm Reviewed-by: ohair ! makefiles/CreateJars.gmk Changeset: a8012d8d7e9c Author: katleman Date: 2012-12-19 13:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8012d8d7e9c Merge Changeset: 4d5db5c038b4 Author: katleman Date: 2012-12-20 09:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d5db5c038b4 Added tag jdk8-b69 for changeset a8012d8d7e9c ! .hgtags Changeset: ad6097d547e1 Author: kvn Date: 2012-12-18 17:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ad6097d547e1 8004318: JEP-171: Support Unsafe fences intrinsics Summary: Add three memory-ordering intrinsics to the sun.misc.Unsafe class. Reviewed-by: twisti, kvn Contributed-by: Aleksey Shipilev ! src/share/classes/sun/misc/Unsafe.java Changeset: 12fa4d7ecaf5 Author: twisti Date: 2012-12-20 11:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12fa4d7ecaf5 8005345: JSR 292: JDK performance tweaks Reviewed-by: kvn, jrose ! src/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java ! src/share/classes/java/lang/invoke/LambdaForm.java ! src/share/classes/java/lang/invoke/MethodHandleImpl.java ! src/share/classes/sun/invoke/util/ValueConversions.java Changeset: 8cf5b18488d1 Author: dl Date: 2012-12-20 12:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cf5b18488d1 8004330: Add missing Unsafe entry points for addAndGet() family Summary: Add Unsafe addAndGet() methods which have intrinsics in Hotspot (7023898) Reviewed-by: alanb, kvn ! src/share/classes/sun/misc/Unsafe.java Changeset: 6b41b40526c6 Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6b41b40526c6 Merge Changeset: 1ad29569d6e9 Author: erikj Date: 2012-12-20 13:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ad29569d6e9 8005178: build-infra: Dependency on libfdlibm on mac is broken Reviewed-by: tbell, ohair ! makefiles/CompileNativeLibraries.gmk Changeset: a68090f0dc1a Author: katleman Date: 2012-12-20 16:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a68090f0dc1a 8004982: JDK8 source with GPL header errors Reviewed-by: ohair ! src/macosx/native/sun/font/CCharToGlyphMapper.m ! src/share/classes/java/util/function/BinaryOperator.java ! src/share/classes/java/util/function/Block.java ! src/share/classes/java/util/function/DoubleBlock.java ! src/share/classes/java/util/function/Function.java ! src/share/classes/java/util/function/IntBlock.java ! src/share/classes/java/util/function/LongBlock.java ! src/share/classes/java/util/function/Predicate.java ! src/share/classes/sun/java2d/pipe/ParallelogramPipe.java ! src/share/classes/sun/tools/jcmd/JCmd.java ! src/share/native/java/util/zip/zlib-1.2.5/gzlib.c ! src/solaris/native/common/jdk_util_md.h ! src/solaris/native/sun/tools/attach/BsdVirtualMachine.c ! src/windows/classes/java/net/DualStackPlainDatagramSocketImpl.java ! src/windows/native/common/jdk_util_md.h ! test/com/sun/java/swing/plaf/windows/WindowsRadioButtonUI/7089914/bug7089914.java ! test/java/awt/Focus/6981400/Test1.java ! test/java/awt/Focus/6981400/Test2.java ! test/java/awt/Focus/6981400/Test3.java ! test/java/awt/Frame/ResizeAfterSetFont/ResizeAfterSetFont.java ! test/java/awt/JAWT/JAWT.sh ! test/java/awt/JAWT/Makefile.cygwin ! test/java/awt/JAWT/Makefile.unix ! test/java/awt/JAWT/Makefile.win ! test/java/awt/JAWT/MyCanvas.java ! test/java/awt/JAWT/myfile.c ! test/java/awt/JAWT/myfile.cpp ! test/java/awt/TextArea/DisposeTest/TestDispose.java ! test/java/awt/TextArea/TextAreaCaretVisibilityTest/bug7129742.java ! test/java/awt/TextField/DisposeTest/TestDispose.java ! test/java/lang/Integer/Unsigned.java ! test/java/lang/Long/Unsigned.java ! test/java/lang/Math/CubeRootTests.java ! test/java/lang/Math/Expm1Tests.java ! test/java/lang/Math/HyperbolicTests.java ! test/java/lang/Math/Log10Tests.java ! test/java/lang/Math/Log1pTests.java ! test/java/lang/Math/Tests.java ! test/java/lang/StringBuffer/TestSynchronization.java ! test/java/lang/invoke/remote/RemoteExample.java ! test/java/math/BigDecimal/FloatDoubleValueTests.java ! test/java/math/BigDecimal/StrippingZerosTest.java ! test/java/net/Inet4Address/PingThis.java ! test/java/net/ProxySelector/MultiThreadedSystemProxies.java ! test/java/security/Signature/VerifyRangeCheckOverflow.java ! test/java/util/AbstractCollection/ToArrayTest.java ! test/java/util/Map/EntryHashCode.java ! test/java/util/concurrent/FutureTask/DoneTimedGetLoops.java ! test/java/util/logging/LoggerResourceBundleRace.java ! test/java/util/logging/LoggingDeadlock2.java ! test/java/util/logging/LoggingDeadlock3.java ! test/java/util/logging/SimpleFormatterFormat.java ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB.xml ! test/java/util/spi/ResourceBundleControlProvider/providersrc/XmlRB_ja.xml ! test/javax/swing/JComponent/7154030/bug7154030.java ! test/javax/swing/JTabbedPane/4310381/bug4310381.java ! test/javax/swing/JTable/4235420/bug4235420.java ! test/javax/swing/JTable/6788484/bug6788484.java ! test/javax/swing/JTable/7055065/bug7055065.java ! test/javax/swing/JTable/7188612/JTableAccessibleGetLocationOnScreen.java ! test/javax/swing/JTextArea/7049024/bug7049024.java ! test/javax/swing/border/Test7022041.java ! test/javax/swing/text/DefaultCaret/6938583/bug6938583.java ! test/sun/management/AgentCMETest.java ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/nio/ch/SelProvider.java ! test/sun/rmi/rmic/classpath/RMICClassPathTest.java ! test/sun/security/krb5/auto/ReplayCache.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/HttpsProxyStackOverflow.java ! test/sun/tools/jps/jps-V_2.sh ! test/tools/jar/JarBackSlash.java ! test/tools/launcher/UnicodeTest.java Changeset: 9dc1990c7d90 Author: yhuang Date: 2012-12-20 18:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9dc1990c7d90 7195759: ISO 4217 Amendment 154 Reviewed-by: naoto ! src/share/classes/java/util/CurrencyData.properties ! src/share/classes/java/util/LocaleISOData.java ! src/share/classes/sun/util/resources/CurrencyNames.properties ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Currency/tablea1.txt ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: cbf255324369 Author: yhuang Date: 2012-12-23 19:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cbf255324369 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: a996b57e5541 Author: katleman Date: 2012-12-26 14:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a996b57e5541 Merge Changeset: 8d7651351cfe Author: katleman Date: 2012-12-27 12:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8d7651351cfe Added tag jdk8-b70 for changeset a996b57e5541 ! .hgtags Changeset: a988c23b8553 Author: jgodinez Date: 2012-12-20 14:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a988c23b8553 7180359: Assertion in awt_Win32GraphicsDevice.cpp when running specjbb in jprt Reviewed-by: bae, prr ! src/windows/native/sun/windows/awt_Debug.cpp Changeset: 2cf07dbdee64 Author: bae Date: 2012-12-24 14:03 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cf07dbdee64 7124245: [lcms] ColorConvertOp to color space CS_GRAY apparently converts orange to 244,244,0 Reviewed-by: prr ! src/share/classes/sun/java2d/cmm/lcms/LCMS.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java ! src/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java ! src/share/native/sun/java2d/cmm/lcms/LCMS.c + test/sun/java2d/cmm/ColorConvertOp/GrayTest.java Changeset: 3c1c0b7abe51 Author: bae Date: 2012-12-24 14:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1c0b7abe51 8005402: Need to provide benchmarks for color management Reviewed-by: jgodinez, prr ! src/share/demo/java2d/J2DBench/build.xml ! src/share/demo/java2d/J2DBench/src/j2dbench/J2DBench.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/CMMTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ColorConvertOpTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/DataConversionTests.java + src/share/demo/java2d/J2DBench/src/j2dbench/tests/cmm/ProfileTests.java Changeset: 1316d6d0900e Author: lana Date: 2012-12-28 18:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1316d6d0900e Merge Changeset: c25ea633b4de Author: malenkov Date: 2012-12-17 16:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c25ea633b4de 8005065: [findbugs] reference to mutable array in JavaBeans Reviewed-by: alexsch ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventSetDescriptor.java ! src/share/classes/java/beans/MethodDescriptor.java ! src/share/classes/java/beans/Statement.java + test/java/beans/Introspector/Test8005065.java Changeset: a78cb3c5d434 Author: neugens Date: 2012-12-17 17:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a78cb3c5d434 8005018: X11: focus problems with openjdk 1.7.0 under gnome3 when selected keyboard is not the first in keyboard list Summary: Don't consider extraenous bits when checking button mask, so that grabWindowRef on the window is not confused and released correctly Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XBaseWindow.java ! src/solaris/classes/sun/awt/X11/XConstants.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/classes/sun/awt/X11/XWindow.java ! src/solaris/classes/sun/awt/X11/XWindowPeer.java ! src/solaris/classes/sun/awt/X11/XlibUtil.java Changeset: 985b523712c8 Author: kshefov Date: 2012-12-18 15:17 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/985b523712c8 7104594: [macosx] Test closed/javax/swing/JFrame/4962534/bug4962534 expects Metal L&F by default Reviewed-by: yan, alexsch + test/javax/swing/JFrame/4962534/bug4962534.html + test/javax/swing/JFrame/4962534/bug4962534.java Changeset: 90ad9e922042 Author: lana Date: 2012-12-18 16:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/90ad9e922042 Merge - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: 7082a96c02d2 Author: alexp Date: 2012-12-21 19:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7082a96c02d2 8003982: new test javax/swing/AncestorNotifier/7193219/bug7193219.java failed on macosx Reviewed-by: anthony, alexsch ! test/javax/swing/AncestorNotifier/7193219/bug7193219.java Changeset: 14269f504837 Author: dcherepanov Date: 2012-12-27 16:08 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/14269f504837 8001161: mac: EmbeddedFrame doesn't become active window Reviewed-by: ant ! src/macosx/classes/sun/lwawt/macosx/CEmbeddedFrame.java Changeset: cf2bcb293f0b Author: lana Date: 2012-12-28 18:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cf2bcb293f0b Merge Changeset: 2a5af0f766d0 Author: lana Date: 2012-12-28 18:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2a5af0f766d0 Merge - make/jdk/asm/Makefile ! makefiles/CreateJars.gmk ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh Changeset: 38b9a7646093 Author: lana Date: 2013-01-01 17:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/38b9a7646093 Merge ! makefiles/CreateJars.gmk From stuart.marks at oracle.com Wed Jan 2 14:21:21 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 02 Jan 2013 22:21:21 +0000 Subject: hg: jdk8/tl/jdk: 8005118: Javadoc styles are inconsistent Message-ID: <20130102222134.1A575474D1@hg.openjdk.java.net> Changeset: cc78ceb99284 Author: jgish Date: 2012-12-28 16:56 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc78ceb99284 8005118: Javadoc styles are inconsistent Summary: use a common javadoc style in the String classes Reviewed-by: darcy ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java ! src/share/classes/java/lang/StringIndexOutOfBoundsException.java From bradford.wetmore at oracle.com Wed Jan 2 17:58:29 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 02 Jan 2013 17:58:29 -0800 Subject: JEP 123: SecureRandom First Draft and Implementation. Message-ID: <50E4E5C5.2080404@oracle.com> Hi, Please review the API/impl for JEP 123: http://openjdk.java.net/jeps/123 http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/ Oracle folks, there is also the internal CCC that needs review. The bug id is 6425477. There are several SecureRandom implementations in Oracle's JDK, and together with the "configuration" options in the java.security file, it can be very confusing for users to understand. As part of the work on JEP 123, I took a comprehensive look at the different SecureRandom implementations and how we got here. There are these implementations: PKCS11: Direct calls to the native PKCS11 library. Only enabled by default on Solaris, but available for any OS. No difference between seed/random. NativePRNG: uses /dev/random and /dev/urandom for seeds/random numbers respectively. Doesn't exist on Windows. SHA1PRNG: Available on all platforms. By default, uses a confusing mix of /dev/[u]random for internal seeding and external seed generation, along with a SHA1 MessageDigest for generating random numbers. The properties (below) control seeding, but in a confusing manner. Windows-PRNG: Direct calls to the MSCAPI library, only available for Windows. No difference between seed/random. There were two main points for this JEP: 1. Provide an API that allows applications to indicate whether they want the "strongest-possible" (possibly blocking) values, or if just regular values will do. 2. See if we can clarify the configuration model, and eliminate some of the confusion caused by the securerandom.source/java.security.egd variables. This second point has caused a lot of pain for developers/deployers/support. The "workaround" of specifying "file:/dev/./urandom" or "file:///dev/urandom" instead of "file:/dev/urandom" has to be one of the most unintuitive ever. [1] ;) The default value of the variable is changed to file:/dev/random to reflect the actual implementation we've been shipping since JDK 5, but will also install NativePRNG as more preferred over the SHA1PRNG. Otherwise, the part of the implementation stays the same, and is now better documented in the java.security file. We'll also be updating the Oracle Provider documentation to reflect the implementations, but that work will be done later. Thanks, Brad [1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101 From chris.hegarty at oracle.com Thu Jan 3 02:01:53 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 03 Jan 2013 10:01:53 +0000 Subject: hg: jdk8/tl/jdk: 8005634: tools/launcher/VersionCheck.java fails version check on jdeps Message-ID: <20130103100231.C1768474E8@hg.openjdk.java.net> Changeset: 21708d15553b Author: chegar Date: 2013-01-03 10:00 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21708d15553b 8005634: tools/launcher/VersionCheck.java fails version check on jdeps Summary: add jdeps to the list of tools that do not support '-version' Reviewed-by: mchung ! test/tools/launcher/VersionCheck.java From valerie.peng at oracle.com Thu Jan 3 18:17:10 2013 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 03 Jan 2013 18:17:10 -0800 Subject: Code Review Request for 6996769: support AEAD ciphers In-Reply-To: <201212171854.qBHIsAp5025606@userp1030.oracle.com> References: <50945D35.8010201@oracle.com> <5098CECB.3020409@oracle.com> <509AE548.4020804@oracle.com> <509B481A.6010307@oracle.com> <50C29674.6000800@oracle.com> <201212140407.qBE47J5R021114@aserp1020.oracle.com> <50CBD33D.9050902@oracle.com> <201212171854.qBHIsAp5025606@userp1030.oracle.com> Message-ID: <50E63BA6.5070109@oracle.com> Michael, I thought this some more. I think a cleaner way to do what you wanted may be achieved by adding an AlgorithmParameterGenerator impl for GCM. I've read through your email multiple times but yet I can't think of a good way to fit all the functionality that you wanted into the GCMParameterSpec class while maintaining the contract of AlgorithmParameterSpec and AlgorithmParameters. The GCMParameterSpec.generateNextIV() method also seems a bit strange to me since you need a random source and GCMParameterSpec is just a spec and isn't associated with any provider. This also means that the conversion between GCMParameterSpec and GCM AlgorithmParameters object and vice versa, may not return you the same spec. I guess I have a hard time accepting the idea of an AlgorithmParameterSpec object with changing values. This are just my opinion, however. I will file a separate RFE to keep track of this as I think more discussion are needed. JDK8 feature deadline is approaching and we can address this as an RFE separately. Regards, Valerie On 12/17/12 10:54, Michael StJohns wrote: > Hi Valerie - > > Comments in line. > > At 08:32 PM 12/14/2012, Valerie (Yu-Ching) Peng wrote: >> Mike, >> >> Thanks for the comments... >> With the current API, it is still possible to have the IV generated at the provider level by calling Cipher.init(...) without GCM parameters. >> This means that provider will generate IVs using provider-default iv length as well as provider-default value for tag length. >> Of course, things may be a little awkward if you need to use custom tag length and a different iv length from what the provider uses as default. > Right. And that may be required by specific protocols. Not saying it is now, but there needs to be support for this in the API. > > >> SunJCE provider uses 128-bit tag length as well as 96-bit IVs as default. If there are demands to use other non-default values, then we should see if something can be done to facilitate these scenarios. > It's perfectly acceptable for any given implementation to only permit 96 bit IVs, But the AEAD algorithms have the possibility of some really unique initialization variables. > > Going back to just the 96 bit IV you've got two ways of constructing the IV - a deterministic and a random (8.2.1 and 8.2.2). For the both of these you have a "fixed field" (aka the "free field" which may be empty in 8.2.2) which is specified by the user. For 8.2.1 you also have an invocation field which is either a linear counter or an LFSR based value. For 8.2.2 you have a random field. > > You really need an API for the GCMParameterSpec which allows you to specify either the IV value or the generation parameters. > > > >> As for preventing the same IV from being re-used, I think it takes more than just adding a new constructor for GCMParameterSpec. > > Right - but the enforcement has to be in the cipher engine, and only for the ENCRYPT operation. > >> Generally, AlgorithmParameterSpec objects can be converted to AlgorithmParameters objects and vice versa. If the GCMParameterSpec only specifies iv length, would you expect the provider to automatically generate a new IV w/o explicit re-init? If yes, then what should the Cipher.getParameters() return, the new one or the old one? > Depends on whether there is a contract of immutability for AlgorithmParameterSpec's - if no, then you update the state in the existing object and return that object. If yes, you create a new object from the existing object with the generated IV. > > >> Regardless which way we choose, it introduces a window on when Cipher.getParameters() should be called. > > If you pass in the GCMParameterSpec with just the IV format info, then when you call init, you cause that object to do a generate of the IV. The GCMParameterSpec object should indicate whether the IV was passed or generated. > > Thinking this through, the GCMParameterSpec needs "generateNextIV()" method. If the GCMParameterSpec is an IV generator rather than an IV container, then generateNextIV() updates the internal state of the parameter spec and IV. Every time you pass this is as an init() argument, you call generateNextIV() - the spec will either ignore the call (IV container) or update the IV (IV generator). (Hmm... possibly a common interface method for AEAD and CTR mode parameter spec object). > > For the pass back and forth between the GCMAlgorithmParameter object and this, just reflect the state at the time called. > > I think this works for the ordering specified in the GCM spec. > > This isn't perfect - what you really want is some state to continue from Cipher.init to Cipher.init call without reference to an externally twiddleable object. Cipher.updateIV which would do an internal reset and then update the parameter counter appropriately to get a new IV for the next message? > > Something similar will probably be needed for CCM as well. > > >> Valerie >> >> On 12/13/12 20:07, Michael StJohns wrote: >>> Sorry for the late comment - >>> >>> You might want to consider section 9.1, first paragraph of SP800-38D which defines the GCM mode. Basically, for FIPS validated implementations, to prevent accidental reuse, the IV needs to be generated inside the cryptographic boundary using one of the defined mechanism. Obviously, that's on the ENCRYPT side since you need to match the IV on the DECRYPT side. >>> >>> I think you may need to add a GCMParameterSpec that allows you to specify either the IV or the IV length as a subclass of IvParameterSpec. >>> >>> Mike >>> >>> >>> >>> >>> At 08:23 PM 12/7/2012, Valerie (Yu-Ching) Peng wrote: >>>> Max, >>>> >>>> The webrev has been updated so that different key + iv values have to be used for AES/GCM encryption. >>>> Latest version at: http://cr.openjdk.java.net/~valeriep/6996769/webrev.03/ >>>> >>>> Please review and send me comments. >>>> Thanks! >>>> Valerie >>>> >>>> On 11/07/12 21:50, Valerie (Yu-Ching) Peng wrote: >>>>> Max, >>>>> >>>>> Update: I removed the block (starting line 580 in CipherCore.java) for handling RC2 since it's never used. >>>>> >>>>> It turns out that the current impl in RC2Cipher always convert the AlgorithmParameters object to RC2ParameterSpec and only uses CipherCore.init(..., AlgorithmParameterSpec,...) method. Thus, I won't be adding a regression test, but rather simply document the current RC2Cipher behavior in CipherCore.java to clarify things up. >>>>> >>>>> The updated webrev is at: >>>>> http://cr.openjdk.java.net/~valeriep/6996769/webrev.01/ >>>>> >>>>> Xuelei brought up the issue of enforcing (Key+IV) uniqueness for GCM mode during this afternoon's meeting. >>>>> I think more changes may be made after we decide what to do. >>>>> So, there may be a webrev.02 coming... Just a heads up. >>>>> >>>>> Thanks! >>>>> Valerie >>>>> >>>>> On 11/07/12 14:48, Valerie (Yu-Ching) Peng wrote: >>>>>>> 580 } else if (key.getAlgorithm().equals("RC2")) { >>>>>>> >>>>>>> This seems a bug fix. Is there a regression test for it? >>>>>> I just noticed this problem when make the enhancement for GCM mode. >>>>>> I will add a regression test for this. > From valerie.peng at oracle.com Thu Jan 3 18:21:37 2013 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 03 Jan 2013 18:21:37 -0800 Subject: Code Review Request for 6996769: support AEAD ciphers In-Reply-To: <50E63BA6.5070109@oracle.com> References: <50945D35.8010201@oracle.com> <5098CECB.3020409@oracle.com> <509AE548.4020804@oracle.com> <509B481A.6010307@oracle.com> <50C29674.6000800@oracle.com> <201212140407.qBE47J5R021114@aserp1020.oracle.com> <50CBD33D.9050902@oracle.com> <201212171854.qBHIsAp5025606@userp1030.oracle.com> <50E63BA6.5070109@oracle.com> Message-ID: <50E63CB1.7050004@oracle.com> Max, Forgot to mention that the latest webrev has been updated: http://cr.openjdk.java.net/~valeriep/6996769/webrev.05/ I shall proceed with putbacks if you have no further comments tomorrow. Thanks, Valerie On 01/03/13 18:17, Valerie (Yu-Ching) Peng wrote: > Michael, > > I thought this some more. I think a cleaner way to do what you wanted > may be achieved by adding an AlgorithmParameterGenerator impl for GCM. > I've read through your email multiple times but yet I can't think of a > good way to fit all the functionality that you wanted into the > GCMParameterSpec class while maintaining the contract of > AlgorithmParameterSpec and AlgorithmParameters. The > GCMParameterSpec.generateNextIV() method also seems a bit strange to > me since you need a random source and GCMParameterSpec is just a spec > and isn't associated with any provider. This also means that the > conversion between GCMParameterSpec and GCM AlgorithmParameters object > and vice versa, may not return you the same spec. I guess I have a > hard time accepting the idea of an AlgorithmParameterSpec object with > changing values. This are just my opinion, however. > > I will file a separate RFE to keep track of this as I think more > discussion are needed. > JDK8 feature deadline is approaching and we can address this as an RFE > separately. > Regards, > Valerie > > On 12/17/12 10:54, Michael StJohns wrote: >> Hi Valerie - >> >> Comments in line. >> >> At 08:32 PM 12/14/2012, Valerie (Yu-Ching) Peng wrote: >>> Mike, >>> >>> Thanks for the comments... >>> With the current API, it is still possible to have the IV generated >>> at the provider level by calling Cipher.init(...) without GCM >>> parameters. >>> This means that provider will generate IVs using provider-default iv >>> length as well as provider-default value for tag length. >>> Of course, things may be a little awkward if you need to use custom >>> tag length and a different iv length from what the provider uses as >>> default. >> Right. And that may be required by specific protocols. Not saying >> it is now, but there needs to be support for this in the API. >> >> >>> SunJCE provider uses 128-bit tag length as well as 96-bit IVs as >>> default. If there are demands to use other non-default values, then >>> we should see if something can be done to facilitate these scenarios. >> It's perfectly acceptable for any given implementation to only permit >> 96 bit IVs, But the AEAD algorithms have the possibility of some >> really unique initialization variables. >> >> Going back to just the 96 bit IV you've got two ways of constructing >> the IV - a deterministic and a random (8.2.1 and 8.2.2). For the >> both of these you have a "fixed field" (aka the "free field" which >> may be empty in 8.2.2) which is specified by the user. For 8.2.1 you >> also have an invocation field which is either a linear counter or an >> LFSR based value. For 8.2.2 you have a random field. >> >> You really need an API for the GCMParameterSpec which allows you to >> specify either the IV value or the generation parameters. >> >> >> >>> As for preventing the same IV from being re-used, I think it takes >>> more than just adding a new constructor for GCMParameterSpec. >> >> Right - but the enforcement has to be in the cipher engine, and only >> for the ENCRYPT operation. >> >>> Generally, AlgorithmParameterSpec objects can be converted to >>> AlgorithmParameters objects and vice versa. If the GCMParameterSpec >>> only specifies iv length, would you expect the provider to >>> automatically generate a new IV w/o explicit re-init? If yes, then >>> what should the Cipher.getParameters() return, the new one or the >>> old one? >> Depends on whether there is a contract of immutability for >> AlgorithmParameterSpec's - if no, then you update the state in the >> existing object and return that object. If yes, you create a new >> object from the existing object with the generated IV. >> >> >>> Regardless which way we choose, it introduces a window on when >>> Cipher.getParameters() should be called. >> >> If you pass in the GCMParameterSpec with just the IV format info, >> then when you call init, you cause that object to do a generate of >> the IV. The GCMParameterSpec object should indicate whether the IV >> was passed or generated. >> >> Thinking this through, the GCMParameterSpec needs "generateNextIV()" >> method. If the GCMParameterSpec is an IV generator rather than an IV >> container, then generateNextIV() updates the internal state of the >> parameter spec and IV. Every time you pass this is as an init() >> argument, you call generateNextIV() - the spec will either ignore the >> call (IV container) or update the IV (IV generator). (Hmm... >> possibly a common interface method for AEAD and CTR mode parameter >> spec object). >> >> For the pass back and forth between the GCMAlgorithmParameter object >> and this, just reflect the state at the time called. >> >> I think this works for the ordering specified in the GCM spec. >> >> This isn't perfect - what you really want is some state to continue >> from Cipher.init to Cipher.init call without reference to an >> externally twiddleable object. Cipher.updateIV which would do an >> internal reset and then update the parameter counter appropriately to >> get a new IV for the next message? >> >> Something similar will probably be needed for CCM as well. >> >> >>> Valerie >>> >>> On 12/13/12 20:07, Michael StJohns wrote: >>>> Sorry for the late comment - >>>> >>>> You might want to consider section 9.1, first paragraph of >>>> SP800-38D which defines the GCM mode. Basically, for FIPS >>>> validated implementations, to prevent accidental reuse, the IV >>>> needs to be generated inside the cryptographic boundary using one >>>> of the defined mechanism. Obviously, that's on the ENCRYPT side >>>> since you need to match the IV on the DECRYPT side. >>>> >>>> I think you may need to add a GCMParameterSpec that allows you to >>>> specify either the IV or the IV length as a subclass of >>>> IvParameterSpec. >>>> >>>> Mike >>>> >>>> >>>> >>>> >>>> At 08:23 PM 12/7/2012, Valerie (Yu-Ching) Peng wrote: >>>>> Max, >>>>> >>>>> The webrev has been updated so that different key + iv values have >>>>> to be used for AES/GCM encryption. >>>>> Latest version at: >>>>> http://cr.openjdk.java.net/~valeriep/6996769/webrev.03/ >>>>> >>>>> Please review and send me comments. >>>>> Thanks! >>>>> Valerie >>>>> >>>>> On 11/07/12 21:50, Valerie (Yu-Ching) Peng wrote: >>>>>> Max, >>>>>> >>>>>> Update: I removed the block (starting line 580 in >>>>>> CipherCore.java) for handling RC2 since it's never used. >>>>>> >>>>>> It turns out that the current impl in RC2Cipher always convert >>>>>> the AlgorithmParameters object to RC2ParameterSpec and only uses >>>>>> CipherCore.init(..., AlgorithmParameterSpec,...) method. Thus, I >>>>>> won't be adding a regression test, but rather simply document the >>>>>> current RC2Cipher behavior in CipherCore.java to clarify things up. >>>>>> >>>>>> The updated webrev is at: >>>>>> http://cr.openjdk.java.net/~valeriep/6996769/webrev.01/ >>>>>> >>>>>> Xuelei brought up the issue of enforcing (Key+IV) uniqueness for >>>>>> GCM mode during this afternoon's meeting. >>>>>> I think more changes may be made after we decide what to do. >>>>>> So, there may be a webrev.02 coming... Just a heads up. >>>>>> >>>>>> Thanks! >>>>>> Valerie >>>>>> >>>>>> On 11/07/12 14:48, Valerie (Yu-Ching) Peng wrote: >>>>>>>> 580 } else if >>>>>>>> (key.getAlgorithm().equals("RC2")) { >>>>>>>> >>>>>>>> This seems a bug fix. Is there a regression test for it? >>>>>>> I just noticed this problem when make the enhancement for GCM mode. >>>>>>> I will add a regression test for this. >> > From mstjohns at comcast.net Thu Jan 3 20:14:58 2013 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 03 Jan 2013 23:14:58 -0500 Subject: Code Review Request for 6996769: support AEAD ciphers In-Reply-To: <50E63BA6.5070109@oracle.com> References: <50945D35.8010201@oracle.com> <5098CECB.3020409@oracle.com> <509AE548.4020804@oracle.com> <509B481A.6010307@oracle.com> <50C29674.6000800@oracle.com> <201212140407.qBE47J5R021114@aserp1020.oracle.com> <50CBD33D.9050902@oracle.com> <201212171854.qBHIsAp5025606@userp1030.oracle.com> <50E63BA6.5070109@oracle.com> Message-ID: <20130104041452.90098672F@mail.openjdk.java.net> Hi Valerie - Comments in line. At 09:17 PM 1/3/2013, Valerie (Yu-Ching) Peng wrote: >Michael, > >I thought this some more. I think a cleaner way to do what you wanted may be achieved by adding an AlgorithmParameterGenerator impl for GCM. >I've read through your email multiple times but yet I can't think of a good way to fit all the functionality that you wanted into the GCMParameterSpec class while maintaining the contract of AlgorithmParameterSpec and AlgorithmParameters. I've been trying to figure out if what I was looking for was a contract violation. The problem is that the counter based encryption modes have a state requirement beyond that usually handled by the AlgorithmParam* and Cipher classes. Each message (or rather, each init of the Cipher object) needs to get a unique IV. Mostly the IV for message N+1 is based on a counter increment of the IV for message N. That ensures you don't repeat the IV. You can do this out of band to the Cipher and AlgorithmParam* objects by managing the IV as external data, but there are some guidances (especially in the case of GCM) which would really rather the IV uniqueness was enforced inside the cryptographic context. In some ways what's needed is a CipherConext class which wraps a Cipher object and an IV generator >The GCMParameterSpec.generateNextIV() method also seems a bit strange to me since you need a random source and GCMParameterSpec is just a spec and isn't associated with any provider. Fair. But in the end the IV is really just a formatting convention over a set of common (nonce) data and a variable part (which is constant for each Cipher.init() context). There are only a few defined ways of generating an IV for GCM (and for that matter for CCM and CTR) based on the previous or first IV. I keep going back and forth on whether the spec or the parameters object should get the generateNextIv() function, but in the end, it may be both (to deal with how you implement this to support an IV generator inside an HSM). I think you can build a Spec class that provides the right functionality to get started. >This also means that the conversion between GCMParameterSpec and GCM AlgorithmParameters object and vice versa, may not return you the same spec. I now think that the right answer is that generateNextIv() should return an immutable AlgorithmParam* object. That should keep the relationship contract that currently exists. > I guess I have a hard time accepting the idea of an AlgorithmParameterSpec object with changing values. This are just my opinion, however. I was trying to avoid the garbage collection of a per-message AlgorithmParam* object. Is there a design document that requires AlgorithmParameterSpec's to be immutable? If so, just return a new object rather than updating the internal state of the Spec object. >I will file a separate RFE to keep track of this as I think more discussion are needed. >JDK8 feature deadline is approaching and we can address this as an RFE separately. I think that's reasonable. I may take a whack at defining the three or four Spec classes (a CounterSpec and the three CTR, GCM and CCM mode specs derived from that spec). Thanks - Mike >Regards, >Valerie > >On 12/17/12 10:54, Michael StJohns wrote: >>Hi Valerie - >> >>Comments in line. >> >>At 08:32 PM 12/14/2012, Valerie (Yu-Ching) Peng wrote: >>>Mike, >>> >>>Thanks for the comments... >>>With the current API, it is still possible to have the IV generated at the provider level by calling Cipher.init(...) without GCM parameters. >>>This means that provider will generate IVs using provider-default iv length as well as provider-default value for tag length. >>>Of course, things may be a little awkward if you need to use custom tag length and a different iv length from what the provider uses as default. >>Right. And that may be required by specific protocols. Not saying it is now, but there needs to be support for this in the API. >> >> >>>SunJCE provider uses 128-bit tag length as well as 96-bit IVs as default. If there are demands to use other non-default values, then we should see if something can be done to facilitate these scenarios. >>It's perfectly acceptable for any given implementation to only permit 96 bit IVs, But the AEAD algorithms have the possibility of some really unique initialization variables. >> >>Going back to just the 96 bit IV you've got two ways of constructing the IV - a deterministic and a random (8.2.1 and 8.2.2). For the both of these you have a "fixed field" (aka the "free field" which may be empty in 8.2.2) which is specified by the user. For 8.2.1 you also have an invocation field which is either a linear counter or an LFSR based value. For 8.2.2 you have a random field. >> >>You really need an API for the GCMParameterSpec which allows you to specify either the IV value or the generation parameters. >> >> >> >>>As for preventing the same IV from being re-used, I think it takes more than just adding a new constructor for GCMParameterSpec. >> >>Right - but the enforcement has to be in the cipher engine, and only for the ENCRYPT operation. >> >>>Generally, AlgorithmParameterSpec objects can be converted to AlgorithmParameters objects and vice versa. If the GCMParameterSpec only specifies iv length, would you expect the provider to automatically generate a new IV w/o explicit re-init? If yes, then what should the Cipher.getParameters() return, the new one or the old one? >>Depends on whether there is a contract of immutability for AlgorithmParameterSpec's - if no, then you update the state in the existing object and return that object. If yes, you create a new object from the existing object with the generated IV. >> >> >>>Regardless which way we choose, it introduces a window on when Cipher.getParameters() should be called. >> >>If you pass in the GCMParameterSpec with just the IV format info, then when you call init, you cause that object to do a generate of the IV. The GCMParameterSpec object should indicate whether the IV was passed or generated. >> >>Thinking this through, the GCMParameterSpec needs "generateNextIV()" method. If the GCMParameterSpec is an IV generator rather than an IV container, then generateNextIV() updates the internal state of the parameter spec and IV. Every time you pass this is as an init() argument, you call generateNextIV() - the spec will either ignore the call (IV container) or update the IV (IV generator). (Hmm... possibly a common interface method for AEAD and CTR mode parameter spec object). >> >>For the pass back and forth between the GCMAlgorithmParameter object and this, just reflect the state at the time called. >> >>I think this works for the ordering specified in the GCM spec. >> >>This isn't perfect - what you really want is some state to continue from Cipher.init to Cipher.init call without reference to an externally twiddleable object. Cipher.updateIV which would do an internal reset and then update the parameter counter appropriately to get a new IV for the next message? >> >>Something similar will probably be needed for CCM as well. >> >> >>>Valerie >>> >>>On 12/13/12 20:07, Michael StJohns wrote: >>>>Sorry for the late comment - >>>> >>>>You might want to consider section 9.1, first paragraph of SP800-38D which defines the GCM mode. Basically, for FIPS validated implementations, to prevent accidental reuse, the IV needs to be generated inside the cryptographic boundary using one of the defined mechanism. Obviously, that's on the ENCRYPT side since you need to match the IV on the DECRYPT side. >>>> >>>>I think you may need to add a GCMParameterSpec that allows you to specify either the IV or the IV length as a subclass of IvParameterSpec. >>>> >>>>Mike >>>> >>>> >>>> >>>> >>>>At 08:23 PM 12/7/2012, Valerie (Yu-Ching) Peng wrote: >>>>>Max, >>>>> >>>>>The webrev has been updated so that different key + iv values have to be used for AES/GCM encryption. >>>>>Latest version at: http://cr.openjdk.java.net/~valeriep/6996769/webrev.03/ >>>>> >>>>>Please review and send me comments. >>>>>Thanks! >>>>>Valerie >>>>> >>>>>On 11/07/12 21:50, Valerie (Yu-Ching) Peng wrote: >>>>>>Max, >>>>>> >>>>>>Update: I removed the block (starting line 580 in CipherCore.java) for handling RC2 since it's never used. >>>>>> >>>>>>It turns out that the current impl in RC2Cipher always convert the AlgorithmParameters object to RC2ParameterSpec and only uses CipherCore.init(..., AlgorithmParameterSpec,...) method. Thus, I won't be adding a regression test, but rather simply document the current RC2Cipher behavior in CipherCore.java to clarify things up. >>>>>> >>>>>>The updated webrev is at: >>>>>>http://cr.openjdk.java.net/~valeriep/6996769/webrev.01/ >>>>>> >>>>>>Xuelei brought up the issue of enforcing (Key+IV) uniqueness for GCM mode during this afternoon's meeting. >>>>>>I think more changes may be made after we decide what to do. >>>>>>So, there may be a webrev.02 coming... Just a heads up. >>>>>> >>>>>>Thanks! >>>>>>Valerie >>>>>> >>>>>>On 11/07/12 14:48, Valerie (Yu-Ching) Peng wrote: >>>>>>>>580 } else if (key.getAlgorithm().equals("RC2")) { >>>>>>>> >>>>>>>>This seems a bug fix. Is there a regression test for it? >>>>>>>I just noticed this problem when make the enhancement for GCM mode. >>>>>>>I will add a regression test for this. From mstjohns at comcast.net Thu Jan 3 20:24:26 2013 From: mstjohns at comcast.net (Michael StJohns) Date: Thu, 03 Jan 2013 23:24:26 -0500 Subject: Code Review Request for 6996769: support AEAD ciphers In-Reply-To: <50E63BA6.5070109@oracle.com> References: <50945D35.8010201@oracle.com> <5098CECB.3020409@oracle.com> <509AE548.4020804@oracle.com> <509B481A.6010307@oracle.com> <50C29674.6000800@oracle.com> <201212140407.qBE47J5R021114@aserp1020.oracle.com> <50CBD33D.9050902@oracle.com> <201212171854.qBHIsAp5025606@userp1030.oracle.com> <50E63BA6.5070109@oracle.com> Message-ID: <20130104042420.5305D6732@mail.openjdk.java.net> At 09:17 PM 1/3/2013, Valerie (Yu-Ching) Peng wrote: >Michael, > >I thought this some more. I think a cleaner way to do what you wanted may be achieved by adding an AlgorithmParameterGenerator impl for GCM. *sigh* I forgot to answer this. I think this would probably work too. But I agree that its going to require more thought. The counter and AEAD modes have some unique edges. Mike From chris.hegarty at oracle.com Fri Jan 4 03:25:38 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 04 Jan 2013 11:25:38 +0000 Subject: hg: jdk8/tl/jdk: 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters Message-ID: <20130104112631.13C8B47551@hg.openjdk.java.net> Changeset: 438d37d16417 Author: chegar Date: 2013-01-04 11:18 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/438d37d16417 8005659: Add tools/pack200/AttributeTests.java to exclude list (ProblemList.txt) until pack200 updated to support method parameters Reviewed-by: mchung, ksrini ! test/ProblemList.txt From chris.hegarty at oracle.com Fri Jan 4 03:35:55 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 04 Jan 2013 11:35:55 +0000 Subject: hg: jdk8/tl/jdk: 8005638: Less secure Authentication schemes should work when more secure schemes are not available Message-ID: <20130104113607.6248D47552@hg.openjdk.java.net> Changeset: 6d814b2f9112 Author: chegar Date: 2013-01-04 11:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d814b2f9112 8005638: Less secure Authentication schemes should work when more secure schemes are not available Reviewed-by: alanb ! src/share/classes/sun/net/www/protocol/http/AuthenticationHeader.java From sean.mullan at oracle.com Fri Jan 4 14:03:45 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 04 Jan 2013 17:03:45 -0500 Subject: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50E4E5C5.2080404@oracle.com> References: <50E4E5C5.2080404@oracle.com> Message-ID: <50E751C1.9060601@oracle.com> Just some initial comments on the API. I have not looked at the code yet. 1. getStrongSecureRandom says: * If the underlying SPI implementation does not support the * {@link SecureRandomSpi.engineSetStrongMode(boolean) * SecureRandomSpi.engineSetStrongMode(boolean)} method, * then a wrapper class will redirect SecureRandomSpi * calls from nextBytes() to generateSeed(). Can you explain in a bit more detail what this means? Is the SecureRandom object that is returned the same whether mode is true or false, even if the underlying implementation could be upgraded to support a strong mode? 2. The name for the method getStrongMode seems a bit odd since it returns a boolean. How about isStrong instead? 3. Nit: Use {@code} instead of 4. Consider marking getStrongSecureRandom and getStrongMode final. I think the other methods on SecureRandom are not final because the SPI was added later, unlike other security SPI classes. --Sean On 01/02/2013 08:58 PM, Brad Wetmore wrote: > > Hi, > > Please review the API/impl for JEP 123: > > http://openjdk.java.net/jeps/123 > http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/ > > Oracle folks, there is also the internal CCC that needs review. The bug > id is 6425477. > > There are several SecureRandom implementations in Oracle's JDK, and > together with the "configuration" options in the java.security file, it > can be very confusing for users to understand. As part of the work on > JEP 123, I took a comprehensive look at the different SecureRandom > implementations and how we got here. > > There are these implementations: > > PKCS11: > Direct calls to the native PKCS11 library. Only enabled > by default on Solaris, but available for any OS. No difference > between seed/random. > > NativePRNG: > uses /dev/random and /dev/urandom for seeds/random numbers > respectively. Doesn't exist on Windows. > > SHA1PRNG: > Available on all platforms. By default, uses a confusing mix of > /dev/[u]random for internal seeding and external seed > generation, along with a SHA1 MessageDigest for > generating random numbers. The properties (below) control > seeding, but in a confusing manner. > > Windows-PRNG: > Direct calls to the MSCAPI library, only available for Windows. > No difference between seed/random. > > There were two main points for this JEP: > > 1. Provide an API that allows applications to indicate whether they > want the "strongest-possible" (possibly blocking) values, or if just > regular values will do. > > 2. See if we can clarify the configuration model, and eliminate some of > the confusion caused by the securerandom.source/java.security.egd > variables. > > This second point has caused a lot of pain for > developers/deployers/support. The "workaround" of specifying > "file:/dev/./urandom" or "file:///dev/urandom" instead of > "file:/dev/urandom" has to be one of the most unintuitive ever. [1] ;) > > The default value of the variable is changed to file:/dev/random to > reflect the actual implementation we've been shipping since JDK 5, but > will also install NativePRNG as more preferred over the SHA1PRNG. > Otherwise, the part of the implementation stays the same, and is now > better documented in the java.security file. > > We'll also be updating the Oracle Provider documentation to reflect the > implementations, but that work will be done later. > > Thanks, > > Brad > > [1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101 > From bradford.wetmore at oracle.com Fri Jan 4 15:18:20 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 04 Jan 2013 15:18:20 -0800 Subject: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50E4E5C5.2080404@oracle.com> References: <50E4E5C5.2080404@oracle.com> Message-ID: <50E7633C.20208@oracle.com> Forwarding some relevant comments: Brad Set #1 of 2: From weijun.wang (at) oracle (dot) com: SecureRandom.java: First you have "If mode is set to true, successive calls..." then you also says the return value "may not necessarily be the same as the original object". Shall I use the return value or "this"? Also, what if I call the method with false? The spec says the strong mode "may block". Does this imply that the "weak" mode never blocks? SecureRandomSpi.java: * Calls to engineSetStrongMode will return * the current mode. You mean engineGetStrongMode? java.security: 100 # On Unix-like systems (for example, Solaris/Linux/MacOS), there is a 101 # separate "NativePRNG" implementation that obtains seed and random numbers 102 # from special device files. If a file is specified and does not exist, 103 # "NativePRNG" will not be available. "file" is the only currently 104 # supported protocol type. If a file is specified and it does exist, will NatievPRNG read from *this* specified file? Or still from some mysterious "special devide file"? 106 # In addition, if "file:/dev/random" or "file:/dev/urandom" is 107 # specified, the "NativePRNG" implementation will be more preferred than 108 # SHA1PRNG. Is "more" needed when "preferred" is used? Also, I haven't read the impl codes for a while, but by specifying one of the 2 sources above, is SHA1PRNG almost the same as NativePRNG? I'll read the code changes later. Thanks Max From bradford.wetmore at oracle.com Fri Jan 4 15:18:23 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 04 Jan 2013 15:18:23 -0800 Subject: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50E4E5C5.2080404@oracle.com> References: <50E4E5C5.2080404@oracle.com> Message-ID: <50E7633F.6000604@oracle.com> Forwarding some relevant comments: Brad Set #2 of 2: From xuelei.fan (at) oracle (dot) com: From the specification, looks like that a provider would have to support both high-quality and normal-quality mode. Otherwise, SecureRandomSpi.engineSetStrongMode() should throw exception if the provider does not support high-quality mode. It does not look intuitive to me, I think a few (many be only a very few) providers may only support normal-quality or blocking mode. From the spec of SecureRandom.getStrongSecureRandom(), my understand is that the returned value may be not configured with the request mode. I mean that if application request to use high-quality secure random, the returned value may be not a high-quality secure random because the underlying provider does not support the SecureRandomSpi.engineSetStrongMode() or only supports normal-quality mode. It's confusing. Or am I miss-understanding something? BTW, the returned value of SecureRandom.getStrongSecureRandom() may not inherit the secure properties from the original caller instance, for example, the initialized seed. I think it would be better to call setSeed again on the returned value to add additional randomness. The code may look like: SecureRandom sr = ...; sr.setSeed(...); SecureRandom newSR = sr.getStrongSecureRandom(true); newSR.setSeed(...); // looks like useless, but it is useful // because the previous seed isn't inherited. I think the quality of a secure random depends on the provider. The quality may be a attribute of a provider. Personally, I like more to use block or non-block mode. I think you may have though about to use the algorithm characteristics, as the one proposed in JEP 123 description: sr = new SecureRandom( ..., SR_HIGHQUALITY|SR_NON_BLOCKING); It looks more intuitive to me, and the API may look like: // look for providers that supports the particular mode. + SecureRandom(boolean block); + SecureRandom(byte seed, boolean block); + SecureRandom.getInstance(String algorithm, boolean block); + SecureRandom.isBlockMode(); We may not need to update getInstance(String, Provider) because block or non-block is a character of a provider (get the value by isBlockMode()). Just for your consideration, may be too later. Xuelei On 1/2/2013 5:58 PM, Brad Wetmore wrote: > > Hi, > > Please review the API/impl for JEP 123: > > http://openjdk.java.net/jeps/123 > http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/ > > Oracle folks, there is also the internal CCC that needs review. The bug > id is 6425477. > > There are several SecureRandom implementations in Oracle's JDK, and > together with the "configuration" options in the java.security file, it > can be very confusing for users to understand. As part of the work on > JEP 123, I took a comprehensive look at the different SecureRandom > implementations and how we got here. > > There are these implementations: > > PKCS11: > Direct calls to the native PKCS11 library. Only enabled > by default on Solaris, but available for any OS. No difference > between seed/random. > > NativePRNG: > uses /dev/random and /dev/urandom for seeds/random numbers > respectively. Doesn't exist on Windows. > > SHA1PRNG: > Available on all platforms. By default, uses a confusing mix of > /dev/[u]random for internal seeding and external seed > generation, along with a SHA1 MessageDigest for > generating random numbers. The properties (below) control > seeding, but in a confusing manner. > > Windows-PRNG: > Direct calls to the MSCAPI library, only available for Windows. > No difference between seed/random. > > There were two main points for this JEP: > > 1. Provide an API that allows applications to indicate whether they > want the "strongest-possible" (possibly blocking) values, or if just > regular values will do. > > 2. See if we can clarify the configuration model, and eliminate some of > the confusion caused by the securerandom.source/java.security.egd > variables. > > This second point has caused a lot of pain for > developers/deployers/support. The "workaround" of specifying > "file:/dev/./urandom" or "file:///dev/urandom" instead of > "file:/dev/urandom" has to be one of the most unintuitive ever. [1] ;) > > The default value of the variable is changed to file:/dev/random to > reflect the actual implementation we've been shipping since JDK 5, but > will also install NativePRNG as more preferred over the SHA1PRNG. > Otherwise, the part of the implementation stays the same, and is now > better documented in the java.security file. > > We'll also be updating the Oracle Provider documentation to reflect the > implementations, but that work will be done later. > > Thanks, > > Brad > > [1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101 > From stuart.marks at oracle.com Fri Jan 4 16:17:57 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Sat, 05 Jan 2013 00:17:57 +0000 Subject: hg: jdk8/tl/jdk: 8005683: ProblemList.txt updates (01/2013) Message-ID: <20130105001818.60DFF4756A@hg.openjdk.java.net> Changeset: 92c3b24a8e9a Author: smarks Date: 2013-01-04 16:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92c3b24a8e9a 8005683: ProblemList.txt updates (01/2013) Reviewed-by: mchung, alanb Contributed-by: amy.lu at oracle.com ! test/ProblemList.txt From bradford.wetmore at oracle.com Fri Jan 4 17:49:47 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 04 Jan 2013 17:49:47 -0800 Subject: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50E751C1.9060601@oracle.com> References: <50E4E5C5.2080404@oracle.com> <50E751C1.9060601@oracle.com> Message-ID: <50E786BB.6000600@oracle.com> I had an ugly chicken/egg bug I just figured out, so didn't get a chance to respond to your/Weijun/Xuelei's comments. For the APIs, it's pretty clear I need some clearer explanations here, and maybe some adjustments. I wouldn't suggest you spend much more time on the internals as things will change a bit and I just found another issue, but in case you want to see what I had in mind, there's a new webrev: http://cr.openjdk.java.net/~wetmore/6425477 See: webrev.01 addressed #4 below. in NativePRNG, if the file URL isn't readable, it defaults to /dev/random instead of disabling this implementation. couple bug fixes. BTW, on #3 (@code), the Oracle Javadoc comment page still says to use . I originally didn't change it because there were so many instances of . http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html Thanks, Brad On 1/4/2013 2:03 PM, Sean Mullan wrote: > Just some initial comments on the API. I have not looked at the code yet. > > 1. getStrongSecureRandom says: > > * If the underlying SPI implementation does not support the > * {@link SecureRandomSpi.engineSetStrongMode(boolean) > * SecureRandomSpi.engineSetStrongMode(boolean)} method, > * then a wrapper class will redirect SecureRandomSpi > * calls from nextBytes() to generateSeed(). > > Can you explain in a bit more detail what this means? Is the > SecureRandom object that is returned the same whether mode is true or > false, even if the underlying implementation could be upgraded to > support a strong mode? > > 2. The name for the method getStrongMode seems a bit odd since it > returns a boolean. How about isStrong instead? > > 3. Nit: Use {@code} instead of > > 4. Consider marking getStrongSecureRandom and getStrongMode final. I > think the other methods on SecureRandom are not final because the SPI > was added later, unlike other security SPI classes. > > --Sean > > On 01/02/2013 08:58 PM, Brad Wetmore wrote: >> >> Hi, >> >> Please review the API/impl for JEP 123: >> >> http://openjdk.java.net/jeps/123 >> http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/ >> >> Oracle folks, there is also the internal CCC that needs review. The bug >> id is 6425477. >> >> There are several SecureRandom implementations in Oracle's JDK, and >> together with the "configuration" options in the java.security file, it >> can be very confusing for users to understand. As part of the work on >> JEP 123, I took a comprehensive look at the different SecureRandom >> implementations and how we got here. >> >> There are these implementations: >> >> PKCS11: >> Direct calls to the native PKCS11 library. Only enabled >> by default on Solaris, but available for any OS. No difference >> between seed/random. >> >> NativePRNG: >> uses /dev/random and /dev/urandom for seeds/random numbers >> respectively. Doesn't exist on Windows. >> >> SHA1PRNG: >> Available on all platforms. By default, uses a confusing mix of >> /dev/[u]random for internal seeding and external seed >> generation, along with a SHA1 MessageDigest for >> generating random numbers. The properties (below) control >> seeding, but in a confusing manner. >> >> Windows-PRNG: >> Direct calls to the MSCAPI library, only available for Windows. >> No difference between seed/random. >> >> There were two main points for this JEP: >> >> 1. Provide an API that allows applications to indicate whether they >> want the "strongest-possible" (possibly blocking) values, or if just >> regular values will do. >> >> 2. See if we can clarify the configuration model, and eliminate some of >> the confusion caused by the securerandom.source/java.security.egd >> variables. >> >> This second point has caused a lot of pain for >> developers/deployers/support. The "workaround" of specifying >> "file:/dev/./urandom" or "file:///dev/urandom" instead of >> "file:/dev/urandom" has to be one of the most unintuitive ever. [1] ;) >> >> The default value of the variable is changed to file:/dev/random to >> reflect the actual implementation we've been shipping since JDK 5, but >> will also install NativePRNG as more preferred over the SHA1PRNG. >> Otherwise, the part of the implementation stays the same, and is now >> better documented in the java.security file. >> >> We'll also be updating the Oracle Provider documentation to reflect the >> implementations, but that work will be done later. >> >> Thanks, >> >> Brad >> >> [1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101 >> > From weijun.wang at oracle.com Sat Jan 5 01:05:34 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 05 Jan 2013 17:05:34 +0800 Subject: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50E7633C.20208@oracle.com> References: <50E4E5C5.2080404@oracle.com> <50E7633C.20208@oracle.com> Message-ID: <50E7ECDE.1020904@oracle.com> On 01/05/2013 07:18 AM, Brad Wetmore wrote: > Forwarding some relevant comments: > > Brad > > > Set #1 of 2: From weijun.wang (at) oracle (dot) com: > > > SecureRandom.java: > > First you have "If mode is set to true, successive calls..." then you > also says the return value "may not necessarily be the same as the > original object". Shall I use the return value or "this"? Also, what if > I call the method with false? With the current design, what you really need to warn the users is that after getStrongSecureRandom(true) is called the behavior of the existing instance is not defined. It may be stronger or may stay the same. In fact, the "get" in the name implies the method is non-destructive (to internal states), so this will be a little confusing. Also, you might need to specify if the returned instance is seeded or not (or if it depends on the existing one). In your webrev, if I read correctly, most (but one) of the SecureRandomSpi impls does not really honor the strongMode flag. Can they just extends a new abstract class named AlwaysStrongSecureRandomSpi? Thanks Max > > The spec says the strong mode "may block". Does this imply that the > "weak" mode never blocks? > > SecureRandomSpi.java: > > * Calls to engineSetStrongMode will return > * the current mode. > > You mean engineGetStrongMode? > > java.security: > > 100 # On Unix-like systems (for example, Solaris/Linux/MacOS), there is a > 101 # separate "NativePRNG" implementation that obtains seed and > random numbers > 102 # from special device files. If a file is specified and does not > exist, > 103 # "NativePRNG" will not be available. "file" is the only currently > 104 # supported protocol type. > > If a file is specified and it does exist, will NatievPRNG read from > *this* specified file? Or still from some mysterious "special devide file"? > > 106 # In addition, if "file:/dev/random" or "file:/dev/urandom" is > 107 # specified, the "NativePRNG" implementation will be more > preferred than > 108 # SHA1PRNG. > > Is "more" needed when "preferred" is used? Also, I haven't read the impl > codes for a while, but by specifying one of the 2 sources above, is > SHA1PRNG almost the same as NativePRNG? > > I'll read the code changes later. > > Thanks > Max > > From Alan.Bateman at oracle.com Sat Jan 5 01:36:36 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 05 Jan 2013 09:36:36 +0000 Subject: [8] Code Review Request for 7019834: Eliminate dependency from PolicyFile to com.sun.security.auth.PrincipalComparator In-Reply-To: <50DDD96D.9090400@oracle.com> References: <50DDD96D.9090400@oracle.com> Message-ID: <50E7F424.4080903@oracle.com> On 28/12/2012 17:39, Sean Mullan wrote: > As part of the effort to prepare the platform for modules (see > http://openjdk.java.net/jeps/162) we need to remove or deprecate > undesirable dependencies. One of these is the dependency: > > sun.security.provider.PolicyFile -> > com.sun.security.auth.PrincipalComparator > > which is problematic since the com.sun.security.auth package is not > intended to be part of the base module. > > The solution is to add an implies method to the > java.security.Principal interface. Existing PrincipalComparator > implementations must also implement Principal if they are to be used > by the default "JavaPolicy" Policy implementation. This change will > allow us to remove the dependency on the PrincipalComparator class and > preserve compatibility. > > Since java.security.Principal is an interface, this change requires > the new default method feature of lambda. > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/7019834/webrev.00/ > > Thanks, > Sean This looks very good to me and good to have this dependency issue finally resolved. Minor comment is that it might be better to use {@code Principal} rather than "principal" in the method description. In PolicyFile it looks like there are 8 or so imports of permission classes commented out - should this be removed? -Alan From chris.hegarty at oracle.com Sat Jan 5 09:08:28 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 05 Jan 2013 17:08:28 +0000 Subject: hg: jdk8/tl/jdk: 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool Message-ID: <20130105170901.C712947579@hg.openjdk.java.net> Changeset: 0c89465b656a Author: chegar Date: 2013-01-05 17:06 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c89465b656a 8005709: Add at since tags to new FJP getCommonPoolParallelism and commonPool Reviewed-by: dl ! src/share/classes/java/util/concurrent/ForkJoinPool.java From bhavesh.x.patel at oracle.com Fri Jan 4 23:07:57 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Sat, 05 Jan 2013 07:07:57 +0000 Subject: hg: jdk8/tl/langtools: 8004891: Check for abstract method in javadoc does not conform to the language model Message-ID: <20130105070802.29B1847575@hg.openjdk.java.net> Changeset: 0e17c3c23e3b Author: bpatel Date: 2013-01-04 23:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0e17c3c23e3b 8004891: Check for abstract method in javadoc does not conform to the language model Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/javadoc/MethodDocImpl.java + test/com/sun/javadoc/testAbstractMethod/TestAbstractMethod.java + test/com/sun/javadoc/testAbstractMethod/pkg/A.java + test/com/sun/javadoc/testAbstractMethod/pkg/B.java + test/com/sun/javadoc/testAbstractMethod/pkg/C.java From bhavesh.x.patel at oracle.com Sat Jan 5 00:56:51 2013 From: bhavesh.x.patel at oracle.com (bhavesh.x.patel at oracle.com) Date: Sat, 05 Jan 2013 08:56:51 +0000 Subject: hg: jdk8/tl/langtools: 8005092: javadoc should check for synthesized bit on an annotation Message-ID: <20130105085653.85E6B47578@hg.openjdk.java.net> Changeset: 8c0c63a6e3b7 Author: bpatel Date: 2013-01-05 00:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8c0c63a6e3b7 8005092: javadoc should check for synthesized bit on an annotation Reviewed-by: jjg ! src/share/classes/com/sun/javadoc/AnnotationDesc.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/javadoc/AnnotationDescImpl.java + test/com/sun/javadoc/testRepeatedAnnotations/TestRepeatedAnnotations.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/C.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeRegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerRegNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/D.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/NonSynthDocContainer.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegArryDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegContainerNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg/RegDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/C.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerValNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContaineeNotDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValDoc.java + test/com/sun/javadoc/testRepeatedAnnotations/pkg1/RegContainerValNotDoc.java From kumar.x.srinivasan at oracle.com Mon Jan 7 11:10:25 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 07 Jan 2013 19:10:25 +0000 Subject: hg: jdk8/tl/jdk: 8004547: Extend JavaFX launcher support to allow full JavaFX launch feature set Message-ID: <20130107191053.8A920470C0@hg.openjdk.java.net> Changeset: 1d9638ba5202 Author: ksrini Date: 2013-01-07 09:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d9638ba5202 8004547: Extend JavaFX launcher support to allow full JavaFX launch feature set Reviewed-by: mchung, kcr, ksrini Contributed-by: david.dehaven at oracle.com ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! test/tools/launcher/FXLauncherTest.java From mstjohns at comcast.net Mon Jan 7 12:57:07 2013 From: mstjohns at comcast.net (Michael StJohns) Date: Mon, 07 Jan 2013 15:57:07 -0500 Subject: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50E786BB.6000600@oracle.com> References: <50E4E5C5.2080404@oracle.com> <50E751C1.9060601@oracle.com> <50E786BB.6000600@oracle.com> Message-ID: <20130107205711.4B7276265@mail.openjdk.java.net> Hi Brad et al - I think its possible you're focusing too much on implementations and less on the class of random number generator. There are basically three types of RNG - a true RNG which uses a noise source of some sort for its entropy (and which may be *conditioned* in its output to deal with the noise source specifics), a pseudo-RNG of various qualities (contrast rand() and SHA1PRNG), and a hybrid RNG consisting of a pseudo-RNG backed by and seeded by a true RNG. As I understand it, you're looking for both the simple "just give me a good random number generator" and the "I want a good random number generator and I want to know what the heck its doing, and I want to specify certain things". So first thing - shouldn't SecureRandom have a "getInstance" with an AlgorithmParameters argument instead of adding the "getStrong...." stuff? I'd use this for a hybrid RNG to pair a PRNG with a TRNG. Second thing, for the PRNG and hybrid instances, you probably should have a concept of re-seeding intervals and a way to set them. Instead of (or in addition to) the generateSeed/setSeed pair, you could add a setSeeder(SecureRandom rand, long reseedInterval) where the reseed interval is in bits or bytes. For a TRNG, you mostly want to be able to characterize how much data is available how fast. So getSizeOfEntropyPool() - current fill in bits, getMaxSizeOfEntropyPool() - max fill, getBitRate() - number of bits per time interval, getMinSizeOfEntropyPool() - the minimum number of bits that must be in the pool to return anything. Maybe getResetTime() - returns a long of the number of millis needed from reset to bit generation. For the names, add "defaultTRNG", "defaultPRNG" and "defaultHybrid" to the standard instance names. Have new SecureRandom() return an instance of defaultHybrid if available, otherwise defaultPRNG. For PRNGs, it would help if you could return (via getAlgorithm()) the OID of the underlying function, as well as the "bit strength" if available. I've been dealing with RNGs and FIPS for the last few months or so - which explains most of the above. I'd especially like it if the default PRNG ended up being one of the ones in SP800-90A rather than what's there now. Later, Mike At 08:49 PM 1/4/2013, Brad Wetmore wrote: >I had an ugly chicken/egg bug I just figured out, so didn't get a chance to respond to your/Weijun/Xuelei's comments. > >For the APIs, it's pretty clear I need some clearer explanations here, and maybe some adjustments. > >I wouldn't suggest you spend much more time on the internals as things will change a bit and I just found another issue, but in case you want to see what I had in mind, there's a new webrev: > > http://cr.openjdk.java.net/~wetmore/6425477 > >See: webrev.01 > > addressed #4 below. > > in NativePRNG, if the file URL isn't readable, it defaults to > /dev/random instead of disabling this implementation. > > couple bug fixes. > >BTW, on #3 (@code), the Oracle Javadoc comment page still says to use . I originally didn't change it because there were so many instances of . > >http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html > >Thanks, > >Brad > > >On 1/4/2013 2:03 PM, Sean Mullan wrote: >>Just some initial comments on the API. I have not looked at the code yet. >> >>1. getStrongSecureRandom says: >> >> * If the underlying SPI implementation does not support the >> * {@link SecureRandomSpi.engineSetStrongMode(boolean) >> * SecureRandomSpi.engineSetStrongMode(boolean)} method, >> * then a wrapper class will redirect SecureRandomSpi >> * calls from nextBytes() to generateSeed(). >> >>Can you explain in a bit more detail what this means? Is the >>SecureRandom object that is returned the same whether mode is true or >>false, even if the underlying implementation could be upgraded to >>support a strong mode? >> >>2. The name for the method getStrongMode seems a bit odd since it >>returns a boolean. How about isStrong instead? >> >>3. Nit: Use {@code} instead of >> >>4. Consider marking getStrongSecureRandom and getStrongMode final. I >>think the other methods on SecureRandom are not final because the SPI >>was added later, unlike other security SPI classes. >> >>--Sean >> >>On 01/02/2013 08:58 PM, Brad Wetmore wrote: >>> >>>Hi, >>> >>>Please review the API/impl for JEP 123: >>> >>> http://openjdk.java.net/jeps/123 >>> http://cr.openjdk.java.net/~wetmore/6425477/webrev.00/ >>> >>>Oracle folks, there is also the internal CCC that needs review. The bug >>>id is 6425477. >>> >>>There are several SecureRandom implementations in Oracle's JDK, and >>>together with the "configuration" options in the java.security file, it >>>can be very confusing for users to understand. As part of the work on >>>JEP 123, I took a comprehensive look at the different SecureRandom >>>implementations and how we got here. >>> >>>There are these implementations: >>> >>> PKCS11: >>> Direct calls to the native PKCS11 library. Only enabled >>> by default on Solaris, but available for any OS. No difference >>> between seed/random. >>> >>> NativePRNG: >>> uses /dev/random and /dev/urandom for seeds/random numbers >>> respectively. Doesn't exist on Windows. >>> >>> SHA1PRNG: >>> Available on all platforms. By default, uses a confusing mix of >>> /dev/[u]random for internal seeding and external seed >>> generation, along with a SHA1 MessageDigest for >>> generating random numbers. The properties (below) control >>> seeding, but in a confusing manner. >>> >>> Windows-PRNG: >>> Direct calls to the MSCAPI library, only available for Windows. >>> No difference between seed/random. >>> >>>There were two main points for this JEP: >>> >>>1. Provide an API that allows applications to indicate whether they >>>want the "strongest-possible" (possibly blocking) values, or if just >>>regular values will do. >>> >>>2. See if we can clarify the configuration model, and eliminate some of >>>the confusion caused by the securerandom.source/java.security.egd >>>variables. >>> >>>This second point has caused a lot of pain for >>>developers/deployers/support. The "workaround" of specifying >>>"file:/dev/./urandom" or "file:///dev/urandom" instead of >>>"file:/dev/urandom" has to be one of the most unintuitive ever. [1] ;) >>> >>>The default value of the variable is changed to file:/dev/random to >>>reflect the actual implementation we've been shipping since JDK 5, but >>>will also install NativePRNG as more preferred over the SHA1PRNG. >>>Otherwise, the part of the implementation stays the same, and is now >>>better documented in the java.security file. >>> >>>We'll also be updating the Oracle Provider documentation to reflect the >>>implementations, but that work will be done later. >>> >>>Thanks, >>> >>>Brad >>> >>>[1] https://forums.oracle.com/forums/thread.jspa?messageID=3793101 From naoto.sato at oracle.com Mon Jan 7 13:19:36 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 07 Jan 2013 21:19:36 +0000 Subject: hg: jdk8/tl/jdk: 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx] Message-ID: <20130107211949.6CCF7470C8@hg.openjdk.java.net> Changeset: dbc692ea3f0a Author: bchristi Date: 2013-01-07 13:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dbc692ea3f0a 8003228: (props) sun.jnu.encoding should be set to UTF-8 [macosx] Summary: Hard-code sun.jnu.encoding to UTF-8 on Mac Reviewed-by: naoto ! src/share/native/java/lang/System.c ! src/solaris/native/java/lang/java_props_md.c + test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java + test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh From james.holmlund at oracle.com Mon Jan 7 13:12:56 2013 From: james.holmlund at oracle.com (james.holmlund at oracle.com) Date: Mon, 07 Jan 2013 21:12:56 +0000 Subject: hg: jdk8/tl/langtools: 8005647: langtools/test/tools/javap/MethodParameters.java fails on windows Message-ID: <20130107211301.D1DD5470C7@hg.openjdk.java.net> Changeset: a9cb93cca229 Author: jjh Date: 2013-01-07 17:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a9cb93cca229 8005647: langtools/test/tools/javap/MethodParameters.java fails on windows Summary: Fix javap to not output \r\r\n Reviewed-by: jjg ! src/share/classes/com/sun/tools/javap/ClassWriter.java ! test/tools/javac/MethodParameters.java ! test/tools/javap/MethodParameters.java From stuart.marks at oracle.com Mon Jan 7 18:10:15 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 08 Jan 2013 02:10:15 +0000 Subject: hg: jdk8/tl/jdk: 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently Message-ID: <20130108021026.D017E470D5@hg.openjdk.java.net> Changeset: 797e8a3dcd51 Author: smarks Date: 2013-01-07 18:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/797e8a3dcd51 7187882: TEST_BUG: java/rmi/activation/checkusage/CheckUsage.java fails intermittently Summary: Tighten up JavaVM test library API, and adjust tests to match. Reviewed-by: mchung, dmocek ! test/ProblemList.txt ! test/java/rmi/activation/Activatable/shutdownGracefully/ShutdownGracefully.java ! test/java/rmi/activation/checkusage/CheckUsage.java ! test/java/rmi/registry/altSecurityManager/AltSecurityManager.java ! test/java/rmi/registry/checkusage/CheckUsage.java ! test/java/rmi/registry/reexport/Reexport.java ! test/java/rmi/testlibrary/JavaVM.java ! test/java/rmi/testlibrary/RMID.java ! test/java/rmi/transport/checkFQDN/CheckFQDN.java ! test/java/rmi/transport/checkLeaseInfoLeak/CheckLeaseLeak.java ! test/sun/rmi/runtime/Log/4504153/Test4504153.java ! test/sun/rmi/runtime/Log/6409194/NoConsoleOutput.java ! test/sun/rmi/transport/tcp/DeadCachedConnection.java From valerie.peng at oracle.com Mon Jan 7 18:22:59 2013 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Mon, 07 Jan 2013 18:22:59 -0800 Subject: Code Review Request for 6996769: support AEAD ciphers In-Reply-To: <201301040414.r044EtSD008041@aserp1030.oracle.com> References: <50945D35.8010201@oracle.com> <5098CECB.3020409@oracle.com> <509AE548.4020804@oracle.com> <509B481A.6010307@oracle.com> <50C29674.6000800@oracle.com> <201212140407.qBE47J5R021114@aserp1020.oracle.com> <50CBD33D.9050902@oracle.com> <201212171854.qBHIsAp5025606@userp1030.oracle.com> <50E63BA6.5070109@oracle.com> <201301040414.r044EtSD008041@aserp1030.oracle.com> Message-ID: <50EB8303.1000905@oracle.com> FYI, I have filed 8005830 "Enhance GCM parameters generation" Thanks, Valerie On 01/03/13 20:14, Michael StJohns wrote: > Hi Valerie - Comments in line. > > At 09:17 PM 1/3/2013, Valerie (Yu-Ching) Peng wrote: >> Michael, >> >> I thought this some more. I think a cleaner way to do what you wanted may be achieved by adding an AlgorithmParameterGenerator impl for GCM. >> I've read through your email multiple times but yet I can't think of a good way to fit all the functionality that you wanted into the GCMParameterSpec class while maintaining the contract of AlgorithmParameterSpec and AlgorithmParameters. > I've been trying to figure out if what I was looking for was a contract violation. The problem is that the counter based encryption modes have a state requirement beyond that usually handled by the AlgorithmParam* and Cipher classes. Each message (or rather, each init of the Cipher object) needs to get a unique IV. Mostly the IV for message N+1 is based on a counter increment of the IV for message N. That ensures you don't repeat the IV. You can do this out of band to the Cipher and AlgorithmParam* objects by managing the IV as external data, but there are some guidances (especially in the case of GCM) which would really rather the IV uniqueness was enforced inside the cryptographic context. In some ways what's needed is a CipherConext class which wraps a Cipher object and an IV generator > >> The GCMParameterSpec.generateNextIV() method also seems a bit strange to me since you need a random source and GCMParameterSpec is just a spec and isn't associated with any provider. > Fair. But in the end the IV is really just a formatting convention over a set of common (nonce) data and a variable part (which is constant for each Cipher.init() context). There are only a few defined ways of generating an IV for GCM (and for that matter for CCM and CTR) based on the previous or first IV. > > I keep going back and forth on whether the spec or the parameters object should get the generateNextIv() function, but in the end, it may be both (to deal with how you implement this to support an IV generator inside an HSM). I think you can build a Spec class that provides the right functionality to get started. > > >> This also means that the conversion between GCMParameterSpec and GCM AlgorithmParameters object and vice versa, may not return you the same spec. > I now think that the right answer is that generateNextIv() should return an immutable AlgorithmParam* object. That should keep the relationship contract that currently exists. > > >> I guess I have a hard time accepting the idea of an AlgorithmParameterSpec object with changing values. This are just my opinion, however. > I was trying to avoid the garbage collection of a per-message AlgorithmParam* object. Is there a design document that requires AlgorithmParameterSpec's to be immutable? If so, just return a new object rather than updating the internal state of the Spec object. > > >> I will file a separate RFE to keep track of this as I think more discussion are needed. >> JDK8 feature deadline is approaching and we can address this as an RFE separately. > I think that's reasonable. I may take a whack at defining the three or four Spec classes (a CounterSpec and the three CTR, GCM and CCM mode specs derived from that spec). > > Thanks - Mike > > >> Regards, >> Valerie >> >> On 12/17/12 10:54, Michael StJohns wrote: >>> Hi Valerie - >>> >>> Comments in line. >>> >>> At 08:32 PM 12/14/2012, Valerie (Yu-Ching) Peng wrote: >>>> Mike, >>>> >>>> Thanks for the comments... >>>> With the current API, it is still possible to have the IV generated at the provider level by calling Cipher.init(...) without GCM parameters. >>>> This means that provider will generate IVs using provider-default iv length as well as provider-default value for tag length. >>>> Of course, things may be a little awkward if you need to use custom tag length and a different iv length from what the provider uses as default. >>> Right. And that may be required by specific protocols. Not saying it is now, but there needs to be support for this in the API. >>> >>> >>>> SunJCE provider uses 128-bit tag length as well as 96-bit IVs as default. If there are demands to use other non-default values, then we should see if something can be done to facilitate these scenarios. >>> It's perfectly acceptable for any given implementation to only permit 96 bit IVs, But the AEAD algorithms have the possibility of some really unique initialization variables. >>> >>> Going back to just the 96 bit IV you've got two ways of constructing the IV - a deterministic and a random (8.2.1 and 8.2.2). For the both of these you have a "fixed field" (aka the "free field" which may be empty in 8.2.2) which is specified by the user. For 8.2.1 you also have an invocation field which is either a linear counter or an LFSR based value. For 8.2.2 you have a random field. >>> >>> You really need an API for the GCMParameterSpec which allows you to specify either the IV value or the generation parameters. >>> >>> >>> >>>> As for preventing the same IV from being re-used, I think it takes more than just adding a new constructor for GCMParameterSpec. >>> Right - but the enforcement has to be in the cipher engine, and only for the ENCRYPT operation. >>> >>>> Generally, AlgorithmParameterSpec objects can be converted to AlgorithmParameters objects and vice versa. If the GCMParameterSpec only specifies iv length, would you expect the provider to automatically generate a new IV w/o explicit re-init? If yes, then what should the Cipher.getParameters() return, the new one or the old one? >>> Depends on whether there is a contract of immutability for AlgorithmParameterSpec's - if no, then you update the state in the existing object and return that object. If yes, you create a new object from the existing object with the generated IV. >>> >>> >>>> Regardless which way we choose, it introduces a window on when Cipher.getParameters() should be called. >>> If you pass in the GCMParameterSpec with just the IV format info, then when you call init, you cause that object to do a generate of the IV. The GCMParameterSpec object should indicate whether the IV was passed or generated. >>> >>> Thinking this through, the GCMParameterSpec needs "generateNextIV()" method. If the GCMParameterSpec is an IV generator rather than an IV container, then generateNextIV() updates the internal state of the parameter spec and IV. Every time you pass this is as an init() argument, you call generateNextIV() - the spec will either ignore the call (IV container) or update the IV (IV generator). (Hmm... possibly a common interface method for AEAD and CTR mode parameter spec object). >>> >>> For the pass back and forth between the GCMAlgorithmParameter object and this, just reflect the state at the time called. >>> >>> I think this works for the ordering specified in the GCM spec. >>> >>> This isn't perfect - what you really want is some state to continue from Cipher.init to Cipher.init call without reference to an externally twiddleable object. Cipher.updateIV which would do an internal reset and then update the parameter counter appropriately to get a new IV for the next message? >>> >>> Something similar will probably be needed for CCM as well. >>> >>> >>>> Valerie >>>> >>>> On 12/13/12 20:07, Michael StJohns wrote: >>>>> Sorry for the late comment - >>>>> >>>>> You might want to consider section 9.1, first paragraph of SP800-38D which defines the GCM mode. Basically, for FIPS validated implementations, to prevent accidental reuse, the IV needs to be generated inside the cryptographic boundary using one of the defined mechanism. Obviously, that's on the ENCRYPT side since you need to match the IV on the DECRYPT side. >>>>> >>>>> I think you may need to add a GCMParameterSpec that allows you to specify either the IV or the IV length as a subclass of IvParameterSpec. >>>>> >>>>> Mike >>>>> >>>>> >>>>> >>>>> >>>>> At 08:23 PM 12/7/2012, Valerie (Yu-Ching) Peng wrote: >>>>>> Max, >>>>>> >>>>>> The webrev has been updated so that different key + iv values have to be used for AES/GCM encryption. >>>>>> Latest version at: http://cr.openjdk.java.net/~valeriep/6996769/webrev.03/ >>>>>> >>>>>> Please review and send me comments. >>>>>> Thanks! >>>>>> Valerie >>>>>> >>>>>> On 11/07/12 21:50, Valerie (Yu-Ching) Peng wrote: >>>>>>> Max, >>>>>>> >>>>>>> Update: I removed the block (starting line 580 in CipherCore.java) for handling RC2 since it's never used. >>>>>>> >>>>>>> It turns out that the current impl in RC2Cipher always convert the AlgorithmParameters object to RC2ParameterSpec and only uses CipherCore.init(..., AlgorithmParameterSpec,...) method. Thus, I won't be adding a regression test, but rather simply document the current RC2Cipher behavior in CipherCore.java to clarify things up. >>>>>>> >>>>>>> The updated webrev is at: >>>>>>> http://cr.openjdk.java.net/~valeriep/6996769/webrev.01/ >>>>>>> >>>>>>> Xuelei brought up the issue of enforcing (Key+IV) uniqueness for GCM mode during this afternoon's meeting. >>>>>>> I think more changes may be made after we decide what to do. >>>>>>> So, there may be a webrev.02 coming... Just a heads up. >>>>>>> >>>>>>> Thanks! >>>>>>> Valerie >>>>>>> >>>>>>> On 11/07/12 14:48, Valerie (Yu-Ching) Peng wrote: >>>>>>>>> 580 } else if (key.getAlgorithm().equals("RC2")) { >>>>>>>>> >>>>>>>>> This seems a bug fix. Is there a regression test for it? >>>>>>>> I just noticed this problem when make the enhancement for GCM mode. >>>>>>>> I will add a regression test for this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130107/9db6a5d0/attachment-0001.html From weijun.wang at oracle.com Mon Jan 7 22:55:23 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 08 Jan 2013 06:55:23 +0000 Subject: hg: jdk8/tl/jdk: 8005447: default principal should act as anyone Message-ID: <20130108065534.EDCB5470DC@hg.openjdk.java.net> Changeset: 98935c514de4 Author: weijun Date: 2013-01-08 14:54 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98935c514de4 8005447: default principal should act as anyone Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/krb5/InitSecContextToken.java ! src/share/classes/sun/security/jgss/krb5/Krb5AcceptCredential.java ! src/share/classes/sun/security/jgss/krb5/Krb5Context.java ! src/share/classes/sun/security/jgss/krb5/Krb5MechFactory.java ! src/share/classes/sun/security/jgss/krb5/Krb5Util.java + src/share/classes/sun/security/jgss/krb5/ServiceCreds.java ! src/share/classes/sun/security/jgss/krb5/SubjectComber.java ! src/share/classes/sun/security/krb5/KrbApReq.java ! src/share/classes/sun/security/krb5/internal/ktab/KeyTab.java ! src/share/classes/sun/security/ssl/krb5/Krb5ProxyImpl.java + test/sun/security/krb5/ServiceCredsCombination.java + test/sun/security/krb5/auto/AcceptPermissions.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/Context.java + test/sun/security/krb5/auto/DiffNameSameKey.java ! test/sun/security/krb5/auto/DynamicKeytab.java ! test/sun/security/krb5/auto/KDC.java ! test/sun/security/krb5/auto/KeyTabCompat.java + test/sun/security/krb5/auto/TwoOrThree.java From maurizio.cimadamore at oracle.com Tue Jan 8 01:18:38 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 08 Jan 2013 09:18:38 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130108091845.95809470E1@hg.openjdk.java.net> Changeset: 38d3d1027f5a Author: mcimadamore Date: 2013-01-08 10:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/38d3d1027f5a 8005243: Restructure method check code to allow pluggable checkers Summary: Add interface to perform a method check - to be implemented by helper classes Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java Changeset: db91d860156a Author: mcimadamore Date: 2013-01-08 10:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/db91d860156a 8005179: Cleanup Resolve.AmbiguityError Summary: Linearize nested ambiguity errors Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out Changeset: d07340b61e6a Author: mcimadamore Date: 2013-01-08 10:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d07340b61e6a 8005184: Restructure DeferredAttr to allow pluggable deferred type completers Summary: Add hooks to generalize deferred type completion via custom helper objects Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/DeferredAttr.java From vicente.romero at oracle.com Tue Jan 8 05:53:40 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 08 Jan 2013 13:53:40 +0000 Subject: hg: jdk8/tl/langtools: 8005167: execution time of combo tests in javac should be improved Message-ID: <20130108135342.EC5A5470EC@hg.openjdk.java.net> Changeset: 954541f13717 Author: vromero Date: 2013-01-08 13:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/954541f13717 8005167: execution time of combo tests in javac should be improved Reviewed-by: jjg, jjh ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T7093325.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java + test/tools/javac/lib/JavacTestingAbstractThreadedTest.java ! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java ! test/tools/javac/varargs/7042566/T7042566.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java From sean.mullan at oracle.com Tue Jan 8 10:49:33 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 08 Jan 2013 13:49:33 -0500 Subject: [8] Code Review Request for 7019834: Eliminate dependency from PolicyFile to com.sun.security.auth.PrincipalComparator In-Reply-To: <50E7F424.4080903@oracle.com> References: <50DDD96D.9090400@oracle.com> <50E7F424.4080903@oracle.com> Message-ID: <50EC6A3D.50405@oracle.com> On 01/05/2013 04:36 AM, Alan Bateman wrote: > On 28/12/2012 17:39, Sean Mullan wrote: >> As part of the effort to prepare the platform for modules (see >> http://openjdk.java.net/jeps/162) we need to remove or deprecate >> undesirable dependencies. One of these is the dependency: >> >> sun.security.provider.PolicyFile -> >> com.sun.security.auth.PrincipalComparator >> >> which is problematic since the com.sun.security.auth package is not >> intended to be part of the base module. >> >> The solution is to add an implies method to the >> java.security.Principal interface. Existing PrincipalComparator >> implementations must also implement Principal if they are to be used >> by the default "JavaPolicy" Policy implementation. This change will >> allow us to remove the dependency on the PrincipalComparator class and >> preserve compatibility. >> >> Since java.security.Principal is an interface, this change requires >> the new default method feature of lambda. >> >> webrev: http://cr.openjdk.java.net/~mullan/webrevs/7019834/webrev.00/ >> >> Thanks, >> Sean > This looks very good to me and good to have this dependency issue > finally resolved. > > Minor comment is that it might be better to use {@code Principal} rather > than "principal" in the method description. That seems to be a somewhat subjective style issue. Some APIs do that while others don't (ex: java.util.Collection refers to itself as "this collection"). Since the rest of the Principal API doesn't do this, I left it as is for consistency. > In PolicyFile it looks like there are 8 or so imports of permission > classes commented out - should this be removed? I've removed it (as well as the lines in getKnownInstance that were commented out. --Sean From alan.bateman at oracle.com Tue Jan 8 12:48:41 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 08 Jan 2013 20:48:41 +0000 Subject: hg: jdk8/tl/jdk: 8002306: (se) Selector.open fails if invoked with thread interrupt status set [win] Message-ID: <20130108204915.2507F4710E@hg.openjdk.java.net> Changeset: d29a7ce28189 Author: dxu Date: 2013-01-08 20:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d29a7ce28189 8002306: (se) Selector.open fails if invoked with thread interrupt status set [win] Reviewed-by: alanb ! src/windows/classes/sun/nio/ch/PipeImpl.java + test/java/nio/channels/Pipe/PipeInterrupt.java From valerie.peng at oracle.com Tue Jan 8 13:07:27 2013 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Tue, 08 Jan 2013 21:07:27 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20130108210812.56F8A4710F@hg.openjdk.java.net> Changeset: 46e6a4b7ca26 Author: valeriep Date: 2013-01-07 11:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/46e6a4b7ca26 6996769: support AEAD cipher Summary: Added implementation for GCM mode under AES cipher Reviewed-by: weijun ! src/share/classes/com/sun/crypto/provider/AESCipher.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/CipherTextStealing.java ! src/share/classes/com/sun/crypto/provider/FeedbackCipher.java + src/share/classes/com/sun/crypto/provider/GCMParameters.java + src/share/classes/com/sun/crypto/provider/GCTR.java + src/share/classes/com/sun/crypto/provider/GHASH.java + src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java ! src/share/classes/javax/crypto/Cipher.java ! src/share/classes/javax/crypto/spec/GCMParameterSpec.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512524.java ! test/com/sun/crypto/provider/Cipher/AES/Test4512704.java ! test/com/sun/crypto/provider/Cipher/AES/Test4517355.java ! test/com/sun/crypto/provider/Cipher/AES/Test4626070.java + test/com/sun/crypto/provider/Cipher/AES/TestGCMKeyAndIvCheck.java + test/com/sun/crypto/provider/Cipher/AES/TestKATForGCM.java ! test/javax/crypto/Cipher/GCMAPI.java Changeset: 5333a4c8cade Author: valeriep Date: 2013-01-07 14:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5333a4c8cade Merge Changeset: 3c5a62290939 Author: valeriep Date: 2013-01-08 11:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c5a62290939 8004044: Lazily instantiate SunJCE.RANDOM Summary: Replace the static initialization of SunJCE.RANDOM object w/ lazy initialization Reviewed-by: mchung ! src/share/classes/com/sun/crypto/provider/AESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/BlowfishKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/CipherCore.java ! src/share/classes/com/sun/crypto/provider/DESKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeKeyGenerator.java ! src/share/classes/com/sun/crypto/provider/DESedeWrapCipher.java ! src/share/classes/com/sun/crypto/provider/DHKeyPairGenerator.java ! src/share/classes/com/sun/crypto/provider/DHParameterGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacMD5KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/HmacPKCS12PBESHA1.java ! src/share/classes/com/sun/crypto/provider/HmacSHA1KeyGenerator.java ! src/share/classes/com/sun/crypto/provider/ISO10126Padding.java ! src/share/classes/com/sun/crypto/provider/KeyGeneratorCore.java ! src/share/classes/com/sun/crypto/provider/KeyProtector.java ! src/share/classes/com/sun/crypto/provider/PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/PBES1Core.java ! src/share/classes/com/sun/crypto/provider/PBES2Core.java ! src/share/classes/com/sun/crypto/provider/PBMAC1Core.java ! src/share/classes/com/sun/crypto/provider/PKCS12PBECipherCore.java ! src/share/classes/com/sun/crypto/provider/SunJCE.java Changeset: 9b6a29cb04ac Author: valeriep Date: 2013-01-08 13:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9b6a29cb04ac Merge From joe.darcy at oracle.com Tue Jan 8 16:08:44 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 09 Jan 2013 00:08:44 +0000 Subject: hg: jdk8/tl/jdk: 8005298: Add FunctionalInterface type to the core libraries Message-ID: <20130109000855.ED2ED4711C@hg.openjdk.java.net> Changeset: ac5fd681a7a2 Author: darcy Date: 2013-01-08 16:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac5fd681a7a2 8005298: Add FunctionalInterface type to the core libraries Reviewed-by: mduigou + src/share/classes/java/lang/FunctionalInterface.java From bradford.wetmore at oracle.com Wed Jan 9 00:44:13 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 09 Jan 2013 00:44:13 -0800 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. Message-ID: <50ED2DDD.2000009@oracle.com> Greetings, Thanks so much for all of the constructive feedback. I wasn't terribly happy with the previous API proposal, and the comments reflected that. Sean Mullan came up with a nice API idea which greatly simplifies the goal of helping applications/deployers select a "strong" SecureRandom implementation. I agree with the comments from Xuelei and Micheal StJohns (and others). As Xuelei mentioned, the original scoping a year ago included some of those larger configuration ideas, and Michael gave some great additional food for thought. With the JDK 8 M6 deadline quickly drawing near, we unfortunately don't have time to explore this further, but what I'm proposing should complement and not preclude such future work. As additional goals for this JEP, I wanted to address three problems in the current implementation: 1. Many customer escalations/complaints of "slow SecureRandom performance" because of the limited entropy collection problem on Linux boxes, and there's much confusion about how to workaround this problem. (e.g. "file:/dev/./urandom") 2. The documentation/configuration in the java.security file does not match the implementations, and is very confusing when trying to figure out #1 above. 3. It's not clear what the four different Oracle JDK SecureRandom implementations do. (Solution: update the Oracle Security Providers page.) I think the current proposal addresses these issues. The highlights: A Security property called "securerandom.strongAlgorithm". There are defaults for each supported platform, and deployers can change this value if they have access to better ones. static String SecureRandom.getStrongAlgorithm() which obtains the property. The expected usage: * SecureRandom sr = SecureRandom.getInstance( * SecureRandom.getStrongAlgorithm()); * ...deleted... * keyPairGenerator.initialize(2048, sr); Cleaned out the incorrect information in the java.security files. The default securerandom.source Security property is set to "file:/dev/random" to properly reflect the implementation. (Ideally, I'd like to push this back to earlier JDK's.) If the java.security.egd/securerandom.source properties are set to either "file:/dev/random" or "file:/dev/urandom", NativePRNG will be preferred to SHA1PRNG. NativePRNG now respects the java.security.egd/securerandom.source properties. NativePRNG reads seeds from /dev/random and nextBytes from /dev/urandom. I added two new NativePRNG implementations which are completely blocking or nonblocking. The "securerandom.strongAlgorithm" property points to the blocking variant. I still have some cleanup work to do on the NativePRNG.java file, but the rest (minus test cases) is ready in the webrev.02 directory. http://cr.openjdk.java.net/~wetmore/6425477/ Thanks, Brad From bradford.wetmore at oracle.com Wed Jan 9 01:19:28 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 09 Jan 2013 01:19:28 -0800 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50ED2DDD.2000009@oracle.com> References: <50ED2DDD.2000009@oracle.com> Message-ID: <50ED3620.4010908@oracle.com> One minor omission. On 1/9/2013 12:44 AM, Brad Wetmore wrote: > NativePRNG reads seeds from /dev/random and nextBytes from /dev/urandom. > I added two new NativePRNG implementations which are completely > blocking or nonblocking. The "securerandom.strongAlgorithm" property > points to the blocking variant on Unix-like OS's (Solaris/Linux/MacOS), and "Windows-PRNG" on Windows. Brad From xuelei.fan at oracle.com Wed Jan 9 03:41:55 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 09 Jan 2013 19:41:55 +0800 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50ED2DDD.2000009@oracle.com> References: <50ED2DDD.2000009@oracle.com> Message-ID: <50ED5783.4070003@oracle.com> I like this new proposal. Some minor comments here. 1. The name of SecureRandom.getStrongAlgorithm() In the specification of the method and java.security, the word "strongest" is used to describe the algorithm. While the name use the word "strong". I think the method name and specification should use the same word, "strong" or "strongest". Using both may cause some miss-understanding. My very first feeling of the "strongest" is that it may depends on both providers and algorithms. If two providers support the same "strongest" algorithms, which one is the strongest? It's a little bit confusing to me to set security property. I would prefer to use "strong". 2. Do we really need the SecureRandom.getStrongAlgorithm()? As the strong algorithm is specified by security property. I think it should be enough to use Java.Security.getProperty(). We properly don't need a new method here. We properly need to add some additional description about the default value of strong algorithm that is recommended to use when the security property is not set. Look at the examples, With this method, the application call looks like (1): String strongAlg = SecureRandom.getStrongAlgorithm(); SecureRandom sr = SecureRandom.getInstance(strongAlg); While using security property, the application call (2): String strongAlg = Security.getProperty("securerandom.strongAlgorithm"); SecureRandom sr = SecureRandom.getInstance(strongAlg); if (strongAlg == null) { strongAlg = new SecureRandom(). } else { sr = SecureRandom.getInstance(strongAlg); } As we have defined security property, the (2) code style is always useable. Looks like that the (1) style is not really necessary, because (2) does the same thing. What I want to express here is that we properly don't need to add a new method to get security property in SecureRandom class. Adding a new security property should be enough. Please consider it. Thanks, Xuelei On 1/9/2013 4:44 PM, Brad Wetmore wrote: > > Greetings, > > Thanks so much for all of the constructive feedback. I wasn't terribly > happy with the previous API proposal, and the comments reflected that. > Sean Mullan came up with a nice API idea which greatly simplifies the > goal of helping applications/deployers select a "strong" SecureRandom > implementation. > > I agree with the comments from Xuelei and Micheal StJohns (and others). > As Xuelei mentioned, the original scoping a year ago included some of > those larger configuration ideas, and Michael gave some great additional > food for thought. With the JDK 8 M6 deadline quickly drawing near, we > unfortunately don't have time to explore this further, but what I'm > proposing should complement and not preclude such future work. > > As additional goals for this JEP, I wanted to address three problems in > the current implementation: > > 1. Many customer escalations/complaints of "slow SecureRandom > performance" because of the limited entropy collection problem on Linux > boxes, and there's much confusion about how to workaround this problem. > (e.g. "file:/dev/./urandom") > > 2. The documentation/configuration in the java.security file does not > match the implementations, and is very confusing when trying to figure > out #1 above. > > 3. It's not clear what the four different Oracle JDK SecureRandom > implementations do. (Solution: update the Oracle Security Providers page.) > > I think the current proposal addresses these issues. > > The highlights: > > A Security property called "securerandom.strongAlgorithm". There are > defaults for each supported platform, and deployers can change this > value if they have access to better ones. > > static String SecureRandom.getStrongAlgorithm() which obtains the > property. The expected usage: > > * SecureRandom sr = SecureRandom.getInstance( > * SecureRandom.getStrongAlgorithm()); > * ...deleted... > * keyPairGenerator.initialize(2048, sr); > > Cleaned out the incorrect information in the java.security files. > > The default securerandom.source Security property is set to > "file:/dev/random" to properly reflect the implementation. (Ideally, > I'd like to push this back to earlier JDK's.) > > If the java.security.egd/securerandom.source properties are set to > either "file:/dev/random" or "file:/dev/urandom", NativePRNG will be > preferred to SHA1PRNG. > > NativePRNG now respects the java.security.egd/securerandom.source > properties. > > NativePRNG reads seeds from /dev/random and nextBytes from /dev/urandom. > I added two new NativePRNG implementations which are completely > blocking or nonblocking. The "securerandom.strongAlgorithm" property > points to the blocking variant. > > I still have some cleanup work to do on the NativePRNG.java file, but > the rest (minus test cases) is ready in the webrev.02 directory. > > http://cr.openjdk.java.net/~wetmore/6425477/ > > Thanks, > > Brad From weijun.wang at oracle.com Wed Jan 9 05:17:25 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Wed, 9 Jan 2013 21:17:25 +0800 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50ED5783.4070003@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> Message-ID: Which provider will provide this strong algorithm? If multiple do, are they equally strong? I had proposed using alg names like "Native/Strong/NonBlocking" in the meeting. Will it still of help? -Max On Jan 9, 2013, at 7:41 PM, Xuelei Fan wrote: > I like this new proposal. Some minor comments here. > > 1. The name of SecureRandom.getStrongAlgorithm() > > In the specification of the method and java.security, the word > "strongest" is used to describe the algorithm. While the name use the > word "strong". I think the method name and specification should use the > same word, "strong" or "strongest". Using both may cause some > miss-understanding. > > My very first feeling of the "strongest" is that it may depends on > both providers and algorithms. If two providers support the same > "strongest" algorithms, which one is the strongest? It's a little bit > confusing to me to set security property. I would prefer to use "strong". > > 2. Do we really need the SecureRandom.getStrongAlgorithm()? > > As the strong algorithm is specified by security property. I think it > should be enough to use Java.Security.getProperty(). We properly don't > need a new method here. We properly need to add some additional > description about the default value of strong algorithm that is > recommended to use when the security property is not set. > > Look at the examples, > > With this method, the application call looks like (1): > String strongAlg = SecureRandom.getStrongAlgorithm(); > SecureRandom sr = SecureRandom.getInstance(strongAlg); > > While using security property, the application call (2): > String strongAlg = > Security.getProperty("securerandom.strongAlgorithm"); > SecureRandom sr = SecureRandom.getInstance(strongAlg); > if (strongAlg == null) { > strongAlg = new SecureRandom(). > } else { > sr = SecureRandom.getInstance(strongAlg); > } > > As we have defined security property, the (2) code style is always > useable. Looks like that the (1) style is not really necessary, because > (2) does the same thing. > > What I want to express here is that we properly don't need to add a new > method to get security property in SecureRandom class. Adding a new > security property should be enough. > > Please consider it. > > Thanks, > Xuelei > > On 1/9/2013 4:44 PM, Brad Wetmore wrote: >> >> Greetings, >> >> Thanks so much for all of the constructive feedback. I wasn't terribly >> happy with the previous API proposal, and the comments reflected that. >> Sean Mullan came up with a nice API idea which greatly simplifies the >> goal of helping applications/deployers select a "strong" SecureRandom >> implementation. >> >> I agree with the comments from Xuelei and Micheal StJohns (and others). >> As Xuelei mentioned, the original scoping a year ago included some of >> those larger configuration ideas, and Michael gave some great additional >> food for thought. With the JDK 8 M6 deadline quickly drawing near, we >> unfortunately don't have time to explore this further, but what I'm >> proposing should complement and not preclude such future work. >> >> As additional goals for this JEP, I wanted to address three problems in >> the current implementation: >> >> 1. Many customer escalations/complaints of "slow SecureRandom >> performance" because of the limited entropy collection problem on Linux >> boxes, and there's much confusion about how to workaround this problem. >> (e.g. "file:/dev/./urandom") >> >> 2. The documentation/configuration in the java.security file does not >> match the implementations, and is very confusing when trying to figure >> out #1 above. >> >> 3. It's not clear what the four different Oracle JDK SecureRandom >> implementations do. (Solution: update the Oracle Security Providers page.) >> >> I think the current proposal addresses these issues. >> >> The highlights: >> >> A Security property called "securerandom.strongAlgorithm". There are >> defaults for each supported platform, and deployers can change this >> value if they have access to better ones. >> >> static String SecureRandom.getStrongAlgorithm() which obtains the >> property. The expected usage: >> >> * SecureRandom sr = SecureRandom.getInstance( >> * SecureRandom.getStrongAlgorithm()); >> * ...deleted... >> * keyPairGenerator.initialize(2048, sr); >> >> Cleaned out the incorrect information in the java.security files. >> >> The default securerandom.source Security property is set to >> "file:/dev/random" to properly reflect the implementation. (Ideally, >> I'd like to push this back to earlier JDK's.) >> >> If the java.security.egd/securerandom.source properties are set to >> either "file:/dev/random" or "file:/dev/urandom", NativePRNG will be >> preferred to SHA1PRNG. >> >> NativePRNG now respects the java.security.egd/securerandom.source >> properties. >> >> NativePRNG reads seeds from /dev/random and nextBytes from /dev/urandom. >> I added two new NativePRNG implementations which are completely >> blocking or nonblocking. The "securerandom.strongAlgorithm" property >> points to the blocking variant. >> >> I still have some cleanup work to do on the NativePRNG.java file, but >> the rest (minus test cases) is ready in the webrev.02 directory. >> >> http://cr.openjdk.java.net/~wetmore/6425477/ >> >> Thanks, >> >> Brad > From xuelei.fan at oracle.com Wed Jan 9 05:37:36 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 09 Jan 2013 21:37:36 +0800 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50ED5783.4070003@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> Message-ID: <50ED72A0.8000805@oracle.com> Form the implementation of SecureRandom.getStrongAlgorithm(), it is possible that returned value are not "strong" (if the related property is not defined). It's really confusing to the application when it requires a real strong one (for example, for certificate generation), but only get a normal one and the behaviors (blocking or not, strong or weak) of the normal one is unknown. The horrible thing may be that the caller never know that it is not a "strong" one, as the method name, getStrongAlgorithm, implies that the returned value is "strong" but not weak. That's another reason that I don't like this new method (SecureRandom.getStrongAlgorithm()). We don't have such problems if we only define the new security property without this new method. Xuelei On 1/9/2013 7:41 PM, Xuelei Fan wrote: > I like this new proposal. Some minor comments here. > > 1. The name of SecureRandom.getStrongAlgorithm() > > In the specification of the method and java.security, the word > "strongest" is used to describe the algorithm. While the name use the > word "strong". I think the method name and specification should use the > same word, "strong" or "strongest". Using both may cause some > miss-understanding. > > My very first feeling of the "strongest" is that it may depends on > both providers and algorithms. If two providers support the same > "strongest" algorithms, which one is the strongest? It's a little bit > confusing to me to set security property. I would prefer to use "strong". > > 2. Do we really need the SecureRandom.getStrongAlgorithm()? > > As the strong algorithm is specified by security property. I think it > should be enough to use Java.Security.getProperty(). We properly don't > need a new method here. We properly need to add some additional > description about the default value of strong algorithm that is > recommended to use when the security property is not set. > > Look at the examples, > > With this method, the application call looks like (1): > String strongAlg = SecureRandom.getStrongAlgorithm(); > SecureRandom sr = SecureRandom.getInstance(strongAlg); > > While using security property, the application call (2): > String strongAlg = > Security.getProperty("securerandom.strongAlgorithm"); > SecureRandom sr = SecureRandom.getInstance(strongAlg); > if (strongAlg == null) { > strongAlg = new SecureRandom(). > } else { > sr = SecureRandom.getInstance(strongAlg); > } > > As we have defined security property, the (2) code style is always > useable. Looks like that the (1) style is not really necessary, because > (2) does the same thing. > > What I want to express here is that we properly don't need to add a new > method to get security property in SecureRandom class. Adding a new > security property should be enough. > > Please consider it. > > Thanks, > Xuelei > > On 1/9/2013 4:44 PM, Brad Wetmore wrote: >> >> Greetings, >> >> Thanks so much for all of the constructive feedback. I wasn't terribly >> happy with the previous API proposal, and the comments reflected that. >> Sean Mullan came up with a nice API idea which greatly simplifies the >> goal of helping applications/deployers select a "strong" SecureRandom >> implementation. >> >> I agree with the comments from Xuelei and Micheal StJohns (and others). >> As Xuelei mentioned, the original scoping a year ago included some of >> those larger configuration ideas, and Michael gave some great additional >> food for thought. With the JDK 8 M6 deadline quickly drawing near, we >> unfortunately don't have time to explore this further, but what I'm >> proposing should complement and not preclude such future work. >> >> As additional goals for this JEP, I wanted to address three problems in >> the current implementation: >> >> 1. Many customer escalations/complaints of "slow SecureRandom >> performance" because of the limited entropy collection problem on Linux >> boxes, and there's much confusion about how to workaround this problem. >> (e.g. "file:/dev/./urandom") >> >> 2. The documentation/configuration in the java.security file does not >> match the implementations, and is very confusing when trying to figure >> out #1 above. >> >> 3. It's not clear what the four different Oracle JDK SecureRandom >> implementations do. (Solution: update the Oracle Security Providers page.) >> >> I think the current proposal addresses these issues. >> >> The highlights: >> >> A Security property called "securerandom.strongAlgorithm". There are >> defaults for each supported platform, and deployers can change this >> value if they have access to better ones. >> >> static String SecureRandom.getStrongAlgorithm() which obtains the >> property. The expected usage: >> >> * SecureRandom sr = SecureRandom.getInstance( >> * SecureRandom.getStrongAlgorithm()); >> * ...deleted... >> * keyPairGenerator.initialize(2048, sr); >> >> Cleaned out the incorrect information in the java.security files. >> >> The default securerandom.source Security property is set to >> "file:/dev/random" to properly reflect the implementation. (Ideally, >> I'd like to push this back to earlier JDK's.) >> >> If the java.security.egd/securerandom.source properties are set to >> either "file:/dev/random" or "file:/dev/urandom", NativePRNG will be >> preferred to SHA1PRNG. >> >> NativePRNG now respects the java.security.egd/securerandom.source >> properties. >> >> NativePRNG reads seeds from /dev/random and nextBytes from /dev/urandom. >> I added two new NativePRNG implementations which are completely >> blocking or nonblocking. The "securerandom.strongAlgorithm" property >> points to the blocking variant. >> >> I still have some cleanup work to do on the NativePRNG.java file, but >> the rest (minus test cases) is ready in the webrev.02 directory. >> >> http://cr.openjdk.java.net/~wetmore/6425477/ >> >> Thanks, >> >> Brad > From sean.mullan at oracle.com Wed Jan 9 06:45:35 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 09 Jan 2013 09:45:35 -0500 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50ED5783.4070003@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> Message-ID: <50ED828F.5020602@oracle.com> On 01/09/2013 06:41 AM, Xuelei Fan wrote: > I like this new proposal. Some minor comments here. > > 1. The name of SecureRandom.getStrongAlgorithm() > > In the specification of the method and java.security, the word > "strongest" is used to describe the algorithm. While the name use the > word "strong". I think the method name and specification should use the > same word, "strong" or "strongest". Using both may cause some > miss-understanding. > > My very first feeling of the "strongest" is that it may depends on > both providers and algorithms. If two providers support the same > "strongest" algorithms, which one is the strongest? I think it is unlikely that 2 providers would implement the same SecureRandom algorithm, since the names are not standardized like other cryptographic algorithms such as SHA-256, RSA, etc. > It's a little bit > confusing to me to set security property. I would prefer to use "strong". Yes, but grammatically the term "Returns the strong algorithm name" doesn't work. So I think using "strongest" instead is ok and not overly confusing. > 2. Do we really need the SecureRandom.getStrongAlgorithm()? > > As the strong algorithm is specified by security property. I think it > should be enough to use Java.Security.getProperty(). We properly don't > need a new method here. We properly need to add some additional > description about the default value of strong algorithm that is > recommended to use when the security property is not set. > > Look at the examples, > > With this method, the application call looks like (1): > String strongAlg = SecureRandom.getStrongAlgorithm(); > SecureRandom sr = SecureRandom.getInstance(strongAlg); > > While using security property, the application call (2): > String strongAlg = > Security.getProperty("securerandom.strongAlgorithm"); > SecureRandom sr = SecureRandom.getInstance(strongAlg); > if (strongAlg == null) { > strongAlg = new SecureRandom(). > } else { > sr = SecureRandom.getInstance(strongAlg); > } > > As we have defined security property, the (2) code style is always > useable. Looks like that the (1) style is not really necessary, because > (2) does the same thing. Yes, but (2) contains a lot of boilerplate code. Also the app may not have permission to read the security property, so you may have to deal with that too. All of that is taken care of for you in the new method. In my opinion, developers are more likely to use this new feature if we make it as easy as possible. In fact, I thought of an even simpler solution. I think we should replace the new getStrongAlgorithm method with the following method instead: public static SecureRandom getStrongSecureRandom() which essentially does the following: SecureRandom.getInstance(SecureRandom.getStrongAlgorithm()); This makes it really simple for apps when they just want to use the most secure RNG available. Let's see what Brad thinks about this later. > What I want to express here is that we properly don't need to add a new > method to get security property in SecureRandom class. Adding a new > security property should be enough. I respectfully disagree. I think it's a very useful method that avoids a lot of boilerplate code and also the potential issue of not having permission to read the security property. --Sean From sean.mullan at oracle.com Wed Jan 9 06:51:11 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 09 Jan 2013 09:51:11 -0500 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50ED72A0.8000805@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> <50ED72A0.8000805@oracle.com> Message-ID: <50ED83DF.9080504@oracle.com> On 01/09/2013 08:37 AM, Xuelei Fan wrote: > Form the implementation of SecureRandom.getStrongAlgorithm(), it is > possible that returned value are not "strong" (if the related property > is not defined). It's really confusing to the application when it > requires a real strong one (for example, for certificate generation), > but only get a normal one and the behaviors (blocking or not, strong or > weak) of the normal one is unknown. The horrible thing may be that the > caller never know that it is not a "strong" one, as the method name, > getStrongAlgorithm, implies that the returned value is "strong" but not > weak. There's an assumption that the securerandom.strongAlgorithm has been configured appropriately. For the OpenJDK we will set this property to what we think is the strongest algorithm on each platform. Yes, someone can later change or unset the property, but this assumes they can modify the security properties file, so worse things can happen in that case. --Sean > > That's another reason that I don't like this new method > (SecureRandom.getStrongAlgorithm()). We don't have such problems if we > only define the new security property without this new method. > > Xuelei > > On 1/9/2013 7:41 PM, Xuelei Fan wrote: >> I like this new proposal. Some minor comments here. >> >> 1. The name of SecureRandom.getStrongAlgorithm() >> >> In the specification of the method and java.security, the word >> "strongest" is used to describe the algorithm. While the name use the >> word "strong". I think the method name and specification should use the >> same word, "strong" or "strongest". Using both may cause some >> miss-understanding. >> >> My very first feeling of the "strongest" is that it may depends on >> both providers and algorithms. If two providers support the same >> "strongest" algorithms, which one is the strongest? It's a little bit >> confusing to me to set security property. I would prefer to use "strong". >> >> 2. Do we really need the SecureRandom.getStrongAlgorithm()? >> >> As the strong algorithm is specified by security property. I think it >> should be enough to use Java.Security.getProperty(). We properly don't >> need a new method here. We properly need to add some additional >> description about the default value of strong algorithm that is >> recommended to use when the security property is not set. >> >> Look at the examples, >> >> With this method, the application call looks like (1): >> String strongAlg = SecureRandom.getStrongAlgorithm(); >> SecureRandom sr = SecureRandom.getInstance(strongAlg); >> >> While using security property, the application call (2): >> String strongAlg = >> Security.getProperty("securerandom.strongAlgorithm"); >> SecureRandom sr = SecureRandom.getInstance(strongAlg); >> if (strongAlg == null) { >> strongAlg = new SecureRandom(). >> } else { >> sr = SecureRandom.getInstance(strongAlg); >> } >> >> As we have defined security property, the (2) code style is always >> useable. Looks like that the (1) style is not really necessary, because >> (2) does the same thing. >> >> What I want to express here is that we properly don't need to add a new >> method to get security property in SecureRandom class. Adding a new >> security property should be enough. >> >> Please consider it. >> >> Thanks, >> Xuelei >> >> On 1/9/2013 4:44 PM, Brad Wetmore wrote: >>> >>> Greetings, >>> >>> Thanks so much for all of the constructive feedback. I wasn't terribly >>> happy with the previous API proposal, and the comments reflected that. >>> Sean Mullan came up with a nice API idea which greatly simplifies the >>> goal of helping applications/deployers select a "strong" SecureRandom >>> implementation. >>> >>> I agree with the comments from Xuelei and Micheal StJohns (and others). >>> As Xuelei mentioned, the original scoping a year ago included some of >>> those larger configuration ideas, and Michael gave some great additional >>> food for thought. With the JDK 8 M6 deadline quickly drawing near, we >>> unfortunately don't have time to explore this further, but what I'm >>> proposing should complement and not preclude such future work. >>> >>> As additional goals for this JEP, I wanted to address three problems in >>> the current implementation: >>> >>> 1. Many customer escalations/complaints of "slow SecureRandom >>> performance" because of the limited entropy collection problem on Linux >>> boxes, and there's much confusion about how to workaround this problem. >>> (e.g. "file:/dev/./urandom") >>> >>> 2. The documentation/configuration in the java.security file does not >>> match the implementations, and is very confusing when trying to figure >>> out #1 above. >>> >>> 3. It's not clear what the four different Oracle JDK SecureRandom >>> implementations do. (Solution: update the Oracle Security Providers page.) >>> >>> I think the current proposal addresses these issues. >>> >>> The highlights: >>> >>> A Security property called "securerandom.strongAlgorithm". There are >>> defaults for each supported platform, and deployers can change this >>> value if they have access to better ones. >>> >>> static String SecureRandom.getStrongAlgorithm() which obtains the >>> property. The expected usage: >>> >>> * SecureRandom sr = SecureRandom.getInstance( >>> * SecureRandom.getStrongAlgorithm()); >>> * ...deleted... >>> * keyPairGenerator.initialize(2048, sr); >>> >>> Cleaned out the incorrect information in the java.security files. >>> >>> The default securerandom.source Security property is set to >>> "file:/dev/random" to properly reflect the implementation. (Ideally, >>> I'd like to push this back to earlier JDK's.) >>> >>> If the java.security.egd/securerandom.source properties are set to >>> either "file:/dev/random" or "file:/dev/urandom", NativePRNG will be >>> preferred to SHA1PRNG. >>> >>> NativePRNG now respects the java.security.egd/securerandom.source >>> properties. >>> >>> NativePRNG reads seeds from /dev/random and nextBytes from /dev/urandom. >>> I added two new NativePRNG implementations which are completely >>> blocking or nonblocking. The "securerandom.strongAlgorithm" property >>> points to the blocking variant. >>> >>> I still have some cleanup work to do on the NativePRNG.java file, but >>> the rest (minus test cases) is ready in the webrev.02 directory. >>> >>> http://cr.openjdk.java.net/~wetmore/6425477/ >>> >>> Thanks, >>> >>> Brad >> > From sean.mullan at oracle.com Wed Jan 9 06:58:34 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 09 Jan 2013 14:58:34 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130109145938.EA84547143@hg.openjdk.java.net> Changeset: 86828e84654f Author: mullan Date: 2013-01-08 19:00 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86828e84654f 7019834: Eliminate dependency from PolicyFile to com.sun.security.auth.PrincipalComparator Summary: Add new java.security.Principal.implies method Reviewed-by: alanb ! src/share/classes/java/security/Principal.java ! src/share/classes/sun/security/provider/PolicyFile.java ! src/share/classes/sun/security/provider/PolicyParser.java ! src/share/classes/sun/security/tools/policytool/PolicyTool.java + test/java/security/Principal/Implies.java ! test/sun/security/provider/PolicyFile/Comparator.java Changeset: bf6d0bca5ea7 Author: mullan Date: 2013-01-08 19:02 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf6d0bca5ea7 Merge - make/jdk/asm/Makefile - src/share/classes/sun/awt/TextureSizeConstraining.java - src/share/lib/security/java.security - test/java/rmi/server/Unmarshal/checkUnmarshalOnStopThread/CheckUnmarshall.java Changeset: f0ed9ef84637 Author: mullan Date: 2013-01-09 08:59 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f0ed9ef84637 Merge From jonathan.gibbons at oracle.com Wed Jan 9 10:27:28 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Jan 2013 18:27:28 +0000 Subject: hg: jdk8/tl/langtools: 8005644: set default max errs and max warns Message-ID: <20130109182733.888E24714D@hg.openjdk.java.net> Changeset: d2eb08b3f64f Author: jjg Date: 2013-01-09 10:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d2eb08b3f64f 8005644: set default max errs and max warns Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/Messager.java + test/tools/javadoc/MaxWarns.java From weijun.wang at oracle.com Wed Jan 9 16:56:39 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 10 Jan 2013 08:56:39 +0800 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50ED83DF.9080504@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> <50ED72A0.8000805@oracle.com> <50ED83DF.9080504@oracle.com> Message-ID: <50EE11C7.9040001@oracle.com> It seems to me that setting a security property that always point to the strongest algorithm is like creating an alias for it. How about we generalize this idea? In java.security, alg.alias.securerandom.strongest = SUN:sha1prng Every other provider-based security class can use it. Thanks Max On 01/09/2013 10:51 PM, Sean Mullan wrote: > On 01/09/2013 08:37 AM, Xuelei Fan wrote: >> Form the implementation of SecureRandom.getStrongAlgorithm(), it is >> possible that returned value are not "strong" (if the related property >> is not defined). It's really confusing to the application when it >> requires a real strong one (for example, for certificate generation), >> but only get a normal one and the behaviors (blocking or not, strong or >> weak) of the normal one is unknown. The horrible thing may be that the >> caller never know that it is not a "strong" one, as the method name, >> getStrongAlgorithm, implies that the returned value is "strong" but not >> weak. > > There's an assumption that the securerandom.strongAlgorithm has been > configured appropriately. For the OpenJDK we will set this property to > what we think is the strongest algorithm on each platform. Yes, someone > can later change or unset the property, but this assumes they can modify > the security properties file, so worse things can happen in that case. > > --Sean > >> >> That's another reason that I don't like this new method >> (SecureRandom.getStrongAlgorithm()). We don't have such problems if we >> only define the new security property without this new method. >> >> Xuelei >> >> On 1/9/2013 7:41 PM, Xuelei Fan wrote: >>> I like this new proposal. Some minor comments here. >>> >>> 1. The name of SecureRandom.getStrongAlgorithm() >>> >>> In the specification of the method and java.security, the word >>> "strongest" is used to describe the algorithm. While the name use the >>> word "strong". I think the method name and specification should use the >>> same word, "strong" or "strongest". Using both may cause some >>> miss-understanding. >>> >>> My very first feeling of the "strongest" is that it may depends on >>> both providers and algorithms. If two providers support the same >>> "strongest" algorithms, which one is the strongest? It's a little bit >>> confusing to me to set security property. I would prefer to use >>> "strong". >>> >>> 2. Do we really need the SecureRandom.getStrongAlgorithm()? >>> >>> As the strong algorithm is specified by security property. I think it >>> should be enough to use Java.Security.getProperty(). We properly don't >>> need a new method here. We properly need to add some additional >>> description about the default value of strong algorithm that is >>> recommended to use when the security property is not set. >>> >>> Look at the examples, >>> >>> With this method, the application call looks like (1): >>> String strongAlg = SecureRandom.getStrongAlgorithm(); >>> SecureRandom sr = SecureRandom.getInstance(strongAlg); >>> >>> While using security property, the application call (2): >>> String strongAlg = >>> Security.getProperty("securerandom.strongAlgorithm"); >>> SecureRandom sr = SecureRandom.getInstance(strongAlg); >>> if (strongAlg == null) { >>> strongAlg = new SecureRandom(). >>> } else { >>> sr = SecureRandom.getInstance(strongAlg); >>> } >>> >>> As we have defined security property, the (2) code style is always >>> useable. Looks like that the (1) style is not really necessary, because >>> (2) does the same thing. >>> >>> What I want to express here is that we properly don't need to add a new >>> method to get security property in SecureRandom class. Adding a new >>> security property should be enough. >>> >>> Please consider it. >>> >>> Thanks, >>> Xuelei >>> >>> On 1/9/2013 4:44 PM, Brad Wetmore wrote: >>>> >>>> Greetings, >>>> >>>> Thanks so much for all of the constructive feedback. I wasn't terribly >>>> happy with the previous API proposal, and the comments reflected that. >>>> Sean Mullan came up with a nice API idea which greatly simplifies the >>>> goal of helping applications/deployers select a "strong" SecureRandom >>>> implementation. >>>> >>>> I agree with the comments from Xuelei and Micheal StJohns (and others). >>>> As Xuelei mentioned, the original scoping a year ago included some of >>>> those larger configuration ideas, and Michael gave some great >>>> additional >>>> food for thought. With the JDK 8 M6 deadline quickly drawing near, we >>>> unfortunately don't have time to explore this further, but what I'm >>>> proposing should complement and not preclude such future work. >>>> >>>> As additional goals for this JEP, I wanted to address three problems in >>>> the current implementation: >>>> >>>> 1. Many customer escalations/complaints of "slow SecureRandom >>>> performance" because of the limited entropy collection problem on Linux >>>> boxes, and there's much confusion about how to workaround this problem. >>>> (e.g. "file:/dev/./urandom") >>>> >>>> 2. The documentation/configuration in the java.security file does not >>>> match the implementations, and is very confusing when trying to figure >>>> out #1 above. >>>> >>>> 3. It's not clear what the four different Oracle JDK SecureRandom >>>> implementations do. (Solution: update the Oracle Security Providers >>>> page.) >>>> >>>> I think the current proposal addresses these issues. >>>> >>>> The highlights: >>>> >>>> A Security property called "securerandom.strongAlgorithm". There are >>>> defaults for each supported platform, and deployers can change this >>>> value if they have access to better ones. >>>> >>>> static String SecureRandom.getStrongAlgorithm() which obtains the >>>> property. The expected usage: >>>> >>>> * SecureRandom sr = SecureRandom.getInstance( >>>> * SecureRandom.getStrongAlgorithm()); >>>> * ...deleted... >>>> * keyPairGenerator.initialize(2048, sr); >>>> >>>> Cleaned out the incorrect information in the java.security files. >>>> >>>> The default securerandom.source Security property is set to >>>> "file:/dev/random" to properly reflect the implementation. (Ideally, >>>> I'd like to push this back to earlier JDK's.) >>>> >>>> If the java.security.egd/securerandom.source properties are set to >>>> either "file:/dev/random" or "file:/dev/urandom", NativePRNG will be >>>> preferred to SHA1PRNG. >>>> >>>> NativePRNG now respects the java.security.egd/securerandom.source >>>> properties. >>>> >>>> NativePRNG reads seeds from /dev/random and nextBytes from >>>> /dev/urandom. >>>> I added two new NativePRNG implementations which are completely >>>> blocking or nonblocking. The "securerandom.strongAlgorithm" property >>>> points to the blocking variant. >>>> >>>> I still have some cleanup work to do on the NativePRNG.java file, but >>>> the rest (minus test cases) is ready in the webrev.02 directory. >>>> >>>> http://cr.openjdk.java.net/~wetmore/6425477/ >>>> >>>> Thanks, >>>> >>>> Brad >>> >> > From mandy.chung at oracle.com Wed Jan 9 17:12:23 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 10 Jan 2013 01:12:23 +0000 Subject: hg: jdk8/tl/jdk: 7103957: NegativeArraySizeException while initializing class IntegerCache Message-ID: <20130110011234.EAE414715F@hg.openjdk.java.net> Changeset: 4c8b37f159f9 Author: mchung Date: 2013-01-09 16:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c8b37f159f9 7103957: NegativeArraySizeException while initializing class IntegerCache Reviewed-by: darcy, mchung Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/lang/Integer.java From xuelei.fan at oracle.com Wed Jan 9 17:47:25 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 10 Jan 2013 09:47:25 +0800 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50ED828F.5020602@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> <50ED828F.5020602@oracle.com> Message-ID: <50EE1DAD.9070305@oracle.com> On 1/9/2013 10:45 PM, Sean Mullan wrote: > On 01/09/2013 06:41 AM, Xuelei Fan wrote: >> I like this new proposal. Some minor comments here. >> >> 1. The name of SecureRandom.getStrongAlgorithm() >> >> In the specification of the method and java.security, the word >> "strongest" is used to describe the algorithm. While the name use the >> word "strong". I think the method name and specification should use the >> same word, "strong" or "strongest". Using both may cause some >> miss-understanding. >> >> My very first feeling of the "strongest" is that it may depends on >> both providers and algorithms. If two providers support the same >> "strongest" algorithms, which one is the strongest? > > I think it is unlikely that 2 providers would implement the same > SecureRandom algorithm, since the names are not standardized like other > cryptographic algorithms such as SHA-256, RSA, etc. > It's OK if the algorithm name is not standardized. But then there is a close connection between provider and this security property. The administrator must be aware of which providers are supported and what is the provider-private algorithm name before he can edit the security property. It would be better to describe the behavior in the spec of the security property. Not sure about whether it is possible that the provider that support the provider-private algorithm are not loaded at runtime. If it happens, the effect to get strong secure random may not work, a weak one may return. >> It's a little bit >> confusing to me to set security property. I would prefer to use "strong". > > Yes, but grammatically the term "Returns the strong algorithm name" > doesn't work. So I think using "strongest" instead is ok and not overly > confusing. > >> 2. Do we really need the SecureRandom.getStrongAlgorithm()? >> >> As the strong algorithm is specified by security property. I think it >> should be enough to use Java.Security.getProperty(). We properly don't >> need a new method here. We properly need to add some additional >> description about the default value of strong algorithm that is >> recommended to use when the security property is not set. >> >> Look at the examples, >> >> With this method, the application call looks like (1): >> String strongAlg = SecureRandom.getStrongAlgorithm(); >> SecureRandom sr = SecureRandom.getInstance(strongAlg); >> >> While using security property, the application call (2): >> String strongAlg = >> Security.getProperty("securerandom.strongAlgorithm"); >> SecureRandom sr = SecureRandom.getInstance(strongAlg); >> if (strongAlg == null) { >> strongAlg = new SecureRandom(). >> } else { >> sr = SecureRandom.getInstance(strongAlg); >> } >> >> As we have defined security property, the (2) code style is always >> useable. Looks like that the (1) style is not really necessary, because >> (2) does the same thing. > > Yes, but (2) contains a lot of boilerplate code. Also the app may not > have permission to read the security property, so you may have to deal > with that too. All of that is taken care of for you in the new method. > In my opinion, developers are more likely to use this new feature if we > make it as easy as possible. > > In fact, I thought of an even simpler solution. I think we should > replace the new getStrongAlgorithm method with the following method > instead: > > public static SecureRandom getStrongSecureRandom() > I like this method more. How about just name it as "getStrongInstance()", or "getStrong()"? There are two solutions to get this. As this proposal, the 1st one is to define a security property (pros: the admin can control the behaviors of strong secure random). The 2nd one is to define a SPI method (pros: the admin won't need to set the property. The admin does not always know what kind of providers will be used at runtime). Both need to update the existing providers. Both have pros and cons, I have no preferences here. > which essentially does the following: > > SecureRandom.getInstance(SecureRandom.getStrongAlgorithm()); > > This makes it really simple for apps when they just want to use the most > secure RNG available. Let's see what Brad thinks about this later. > >> What I want to express here is that we properly don't need to add a new >> method to get security property in SecureRandom class. Adding a new >> security property should be enough. > > I respectfully disagree. I think it's a very useful method that avoids a > lot of boilerplate code and also the potential issue of not having > permission to read the security property. > It's reasonable to me. To decrease the miss-understanding of the method, can we always return the configured "strong" secure random? If not "strong" secure random found, throws an exception or return null. I really worry about the case that applications request a strong one, but get a weak one and applications may never be able to know that a weak one is got instead. Xuelei From bradford.wetmore at oracle.com Wed Jan 9 19:21:10 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 09 Jan 2013 19:21:10 -0800 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50EE1DAD.9070305@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> <50ED828F.5020602@oracle.com> <50EE1DAD.9070305@oracle.com> Message-ID: <50EE33A6.7080504@oracle.com> Thanks for the feedback. I also received some privately which had similar comments. Wrapping up several emails into some bullet points: 1. I like Sean's suggested tweak to the API. I'm thinking of adjusting it slightly. 2. Xuelei has a point about my fallback of "most preferred" implementation may not actually be strong. And like Max, I've also had concerns about "which provider". In my previous proposal laundry list for SecureRandom, I had something like: securerandom.strongAlgorithms=algname1,algname2.provname1,algname3 which addresses both issues. The property will contain a list of algs or algs/providers, and we'll iterate through them. If we can't create an instance of one of these, return a null. public static SecureRandom getStrongSecureRandom() Given these comments, I think I'm going to move forward on this. The application will do: SecureRandom sr = SecureRandom.getStrongSecureRandom(); if (sr == null) { // Decide if this is a problem, and whether to recover. // sr = new SecureRandom(); or return; } 3. Sean wrote: > There's an assumption that the securerandom.strongAlgorithm has been > configured appropriately. Exactly, we'll ship with default values for each platform, and programs/deployers can add/subtract as needed. 4. Xuelei wrote: > The 2nd one is to define a SPI method (pros: the > admin won't need to set the property. The admin does not always know > what kind of providers will be used at runtime). If I'm reading this comment right, given the pros of the current approach, I hesitate letting implementations make comparative strength decisions. Thanks! I should have a new version out tonight. Brad On 1/9/2013 5:47 PM, Xuelei Fan wrote: > On 1/9/2013 10:45 PM, Sean Mullan wrote: >> On 01/09/2013 06:41 AM, Xuelei Fan wrote: >>> I like this new proposal. Some minor comments here. >>> >>> 1. The name of SecureRandom.getStrongAlgorithm() >>> >>> In the specification of the method and java.security, the word >>> "strongest" is used to describe the algorithm. While the name use the >>> word "strong". I think the method name and specification should use the >>> same word, "strong" or "strongest". Using both may cause some >>> miss-understanding. >>> >>> My very first feeling of the "strongest" is that it may depends on >>> both providers and algorithms. If two providers support the same >>> "strongest" algorithms, which one is the strongest? >> >> I think it is unlikely that 2 providers would implement the same >> SecureRandom algorithm, since the names are not standardized like other >> cryptographic algorithms such as SHA-256, RSA, etc. >> > It's OK if the algorithm name is not standardized. > > But then there is a close connection between provider and this security > property. The administrator must be aware of which providers are > supported and what is the provider-private algorithm name before he can > edit the security property. It would be better to describe the behavior > in the spec of the security property. > > Not sure about whether it is possible that the provider that support the > provider-private algorithm are not loaded at runtime. If it happens, > the effect to get strong secure random may not work, a weak one may return. > >>> It's a little bit >>> confusing to me to set security property. I would prefer to use "strong". >> >> Yes, but grammatically the term "Returns the strong algorithm name" >> doesn't work. So I think using "strongest" instead is ok and not overly >> confusing. >> >>> 2. Do we really need the SecureRandom.getStrongAlgorithm()? >>> >>> As the strong algorithm is specified by security property. I think it >>> should be enough to use Java.Security.getProperty(). We properly don't >>> need a new method here. We properly need to add some additional >>> description about the default value of strong algorithm that is >>> recommended to use when the security property is not set. >>> >>> Look at the examples, >>> >>> With this method, the application call looks like (1): >>> String strongAlg = SecureRandom.getStrongAlgorithm(); >>> SecureRandom sr = SecureRandom.getInstance(strongAlg); >>> >>> While using security property, the application call (2): >>> String strongAlg = >>> Security.getProperty("securerandom.strongAlgorithm"); >>> SecureRandom sr = SecureRandom.getInstance(strongAlg); >>> if (strongAlg == null) { >>> strongAlg = new SecureRandom(). >>> } else { >>> sr = SecureRandom.getInstance(strongAlg); >>> } >>> >>> As we have defined security property, the (2) code style is always >>> useable. Looks like that the (1) style is not really necessary, because >>> (2) does the same thing. >> >> Yes, but (2) contains a lot of boilerplate code. Also the app may not >> have permission to read the security property, so you may have to deal >> with that too. All of that is taken care of for you in the new method. >> In my opinion, developers are more likely to use this new feature if we >> make it as easy as possible. >> >> In fact, I thought of an even simpler solution. I think we should >> replace the new getStrongAlgorithm method with the following method >> instead: >> >> public static SecureRandom getStrongSecureRandom() >> > I like this method more. How about just name it as > "getStrongInstance()", or "getStrong()"? > > There are two solutions to get this. As this proposal, the 1st one is to > define a security property (pros: the admin can control the behaviors of > strong secure random). The 2nd one is to define a SPI method (pros: the > admin won't need to set the property. The admin does not always know > what kind of providers will be used at runtime). Both need to update > the existing providers. Both have pros and cons, I have no preferences > here. > >> which essentially does the following: >> >> SecureRandom.getInstance(SecureRandom.getStrongAlgorithm()); >> >> This makes it really simple for apps when they just want to use the most >> secure RNG available. Let's see what Brad thinks about this later. >> >>> What I want to express here is that we properly don't need to add a new >>> method to get security property in SecureRandom class. Adding a new >>> security property should be enough. >> >> I respectfully disagree. I think it's a very useful method that avoids a >> lot of boilerplate code and also the potential issue of not having >> permission to read the security property. >> > It's reasonable to me. > > To decrease the miss-understanding of the method, can we always return > the configured "strong" secure random? If not "strong" secure random > found, throws an exception or return null. I really worry about the case > that applications request a strong one, but get a weak one and > applications may never be able to know that a weak one is got instead. > > Xuelei > From mstjohns at comcast.net Wed Jan 9 19:31:37 2013 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 09 Jan 2013 22:31:37 -0500 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50ED828F.5020602@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> <50ED828F.5020602@oracle.com> Message-ID: <20130110033137.515CA6E10@mail.openjdk.java.net> At 09:45 AM 1/9/2013, Sean Mullan wrote: >think it is unlikely that 2 providers would implement the same SecureRandom algorithm, since the names are not standardized like other cryptographic algorithms such as SHA-256, RSA, etc. Can this be fixed? There really should be a flavor for this. E.g. SP800-90a/SHA256/HASH SP800-90A/SHA256/HMAC SP800-90A/AES/CTR NRBG/NoisyDiode[/implementation id] NRBG/RingOscillator[/Implementation id] There are about 6 classes of NIST "approved" deterministic random number generators. See http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf. I wouldn't be surprised to find that multiple providers implement the same RNGs, but don't have a common name for them. In fact, according to wikipedia, the underlying function for MSCAPI is the FIPS186-2 appendix 3.1 with SHA1 function. Mike From bradford.wetmore at oracle.com Wed Jan 9 19:40:47 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Wed, 09 Jan 2013 19:40:47 -0800 Subject: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <20130110033137.515CA6E10@mail.openjdk.java.net> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> <50ED828F.5020602@oracle.com> <20130110033137.515CA6E10@mail.openjdk.java.net> Message-ID: <50EE383F.60709@oracle.com> I don't see any reason why not. We just need to come up with a good naming convention, and then we can add that into the Standard Algorithms document. The existing names were established years ago, based on functional implementations rather than a specific algorithmic basis. Brad On 1/9/2013 7:31 PM, Michael StJohns wrote: > At 09:45 AM 1/9/2013, Sean Mullan wrote: >> think it is unlikely that 2 providers would implement the same SecureRandom algorithm, since the names are not standardized like other cryptographic algorithms such as SHA-256, RSA, etc. > > Can this be fixed? There really should be a flavor for this. > > > E.g. > > SP800-90a/SHA256/HASH > SP800-90A/SHA256/HMAC > SP800-90A/AES/CTR > NRBG/NoisyDiode[/implementation id] > NRBG/RingOscillator[/Implementation id] > > There are about 6 classes of NIST "approved" deterministic random number generators. See http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf. > > > > I wouldn't be surprised to find that multiple providers implement the same RNGs, but don't have a common name for them. In fact, according to wikipedia, the underlying function for MSCAPI is the FIPS186-2 appendix 3.1 with SHA1 function. > > Mike > > > From joe.darcy at oracle.com Wed Jan 9 20:03:14 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 10 Jan 2013 04:03:14 +0000 Subject: hg: jdk8/tl/langtools: 8004730: Add language model support for parameter reflection Message-ID: <20130110040316.EE49E47166@hg.openjdk.java.net> Changeset: 7612fe48be90 Author: darcy Date: 2013-01-09 20:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7612fe48be90 8004730: Add language model support for parameter reflection Reviewed-by: abuckley ! src/share/classes/javax/lang/model/element/Element.java ! src/share/classes/javax/lang/model/element/VariableElement.java ! src/share/classes/javax/lang/model/element/package-info.java From joe.darcy at oracle.com Wed Jan 9 20:20:30 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 10 Jan 2013 04:20:30 +0000 Subject: hg: jdk8/tl/jdk: 8005713: Simplify library support for repeating annotations in java.lang.annotation Message-ID: <20130110042043.518CA47167@hg.openjdk.java.net> Changeset: 4176e6cc499e Author: darcy Date: 2013-01-09 20:20 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4176e6cc499e 8005713: Simplify library support for repeating annotations in java.lang.annotation Reviewed-by: abuckley + src/share/classes/java/lang/annotation/Repeatable.java From bradford.wetmore at oracle.com Thu Jan 10 00:40:13 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 10 Jan 2013 00:40:13 -0800 Subject: Update #3: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50EE33A6.7080504@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> <50ED828F.5020602@oracle.com> <50EE1DAD.9070305@oracle.com> <50EE33A6.7080504@oracle.com> Message-ID: <50EE7E6D.3060001@oracle.com> The third version is now out (minus test cases), and is ready in the webrev.03 directory. http://cr.openjdk.java.net/~wetmore/6425477/ The only change is the API as we discussed. Brad On 1/9/2013 7:21 PM, Brad Wetmore wrote: > Thanks for the feedback. I also received some privately which had > similar comments. > > Wrapping up several emails into some bullet points: > > 1. I like Sean's suggested tweak to the API. I'm thinking of adjusting > it slightly. > > 2. Xuelei has a point about my fallback of "most preferred" > implementation may not actually be strong. And like Max, I've also had > concerns about "which provider". > > In my previous proposal laundry list for SecureRandom, I had something > like: > > securerandom.strongAlgorithms=algname1,algname2.provname1,algname3 > > which addresses both issues. The property will contain a list of algs > or algs/providers, and we'll iterate through them. If we can't create > an instance of one of these, return a null. > > public static SecureRandom getStrongSecureRandom() > > Given these comments, I think I'm going to move forward on this. The > application will do: > > SecureRandom sr = SecureRandom.getStrongSecureRandom(); > > if (sr == null) { > // Decide if this is a problem, and whether to recover. > // sr = new SecureRandom(); or return; > } > > 3. Sean wrote: > > > There's an assumption that the securerandom.strongAlgorithm has been > > configured appropriately. > > Exactly, we'll ship with default values for each platform, and > programs/deployers can add/subtract as needed. > > 4. Xuelei wrote: > > > The 2nd one is to define a SPI method (pros: the > > admin won't need to set the property. The admin does not always know > > what kind of providers will be used at runtime). > > If I'm reading this comment right, given the pros of the current > approach, I hesitate letting implementations make comparative strength > decisions. > > Thanks! I should have a new version out tonight. > > Brad > > > From xuelei.fan at oracle.com Thu Jan 10 01:05:03 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 10 Jan 2013 17:05:03 +0800 Subject: Update #3: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50EE7E6D.3060001@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> <50ED828F.5020602@oracle.com> <50EE1DAD.9070305@oracle.com> <50EE33A6.7080504@oracle.com> <50EE7E6D.3060001@oracle.com> Message-ID: <50EE843F.1000905@oracle.com> The new specification looks fine to me. Thanks, Xuelei On 1/10/2013 4:40 PM, Brad Wetmore wrote: > The third version is now out (minus test cases), and is ready in the > webrev.03 directory. > > http://cr.openjdk.java.net/~wetmore/6425477/ > > The only change is the API as we discussed. > > Brad > > > > > On 1/9/2013 7:21 PM, Brad Wetmore wrote: >> Thanks for the feedback. I also received some privately which had >> similar comments. >> >> Wrapping up several emails into some bullet points: >> >> 1. I like Sean's suggested tweak to the API. I'm thinking of adjusting >> it slightly. >> >> 2. Xuelei has a point about my fallback of "most preferred" >> implementation may not actually be strong. And like Max, I've also had >> concerns about "which provider". >> >> In my previous proposal laundry list for SecureRandom, I had something >> like: >> >> securerandom.strongAlgorithms=algname1,algname2.provname1,algname3 >> >> which addresses both issues. The property will contain a list of algs >> or algs/providers, and we'll iterate through them. If we can't create >> an instance of one of these, return a null. >> >> public static SecureRandom getStrongSecureRandom() >> >> Given these comments, I think I'm going to move forward on this. The >> application will do: >> >> SecureRandom sr = SecureRandom.getStrongSecureRandom(); >> >> if (sr == null) { >> // Decide if this is a problem, and whether to recover. >> // sr = new SecureRandom(); or return; >> } >> >> 3. Sean wrote: >> >> > There's an assumption that the securerandom.strongAlgorithm has been >> > configured appropriately. >> >> Exactly, we'll ship with default values for each platform, and >> programs/deployers can add/subtract as needed. >> >> 4. Xuelei wrote: >> >> > The 2nd one is to define a SPI method (pros: the >> > admin won't need to set the property. The admin does not always know >> > what kind of providers will be used at runtime). >> >> If I'm reading this comment right, given the pros of the current >> approach, I hesitate letting implementations make comparative strength >> decisions. >> >> Thanks! I should have a new version out tonight. >> >> Brad >> >> >> From sean.mullan at oracle.com Thu Jan 10 07:52:19 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 10 Jan 2013 10:52:19 -0500 Subject: Update #3: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: <50EE7E6D.3060001@oracle.com> References: <50ED2DDD.2000009@oracle.com> <50ED5783.4070003@oracle.com> <50ED828F.5020602@oracle.com> <50EE1DAD.9070305@oracle.com> <50EE33A6.7080504@oracle.com> <50EE7E6D.3060001@oracle.com> Message-ID: <50EEE3B3.70109@oracle.com> On 01/10/2013 03:40 AM, Brad Wetmore wrote: > The third version is now out (minus test cases), and is ready in the > webrev.03 directory. > > http://cr.openjdk.java.net/~wetmore/6425477/ > > The only change is the API as we discussed. Line 585: 585 * by the {@code securerandom.strong} security property, or null should be securerandom.strongAlgorithms Otherwise API looks good. A couple of comments on the implementation (both of which can be handled later), I would log any exceptions for debugging purposes. There's also some potential for performance improvements -- you could cache the property and avoid reparsing the property if it hasn't changed. --Sean From brich at us.ibm.com Thu Jan 10 09:48:49 2013 From: brich at us.ibm.com (Bruce Rich) Date: Thu, 10 Jan 2013 11:48:49 -0600 Subject: Fw: Update #2: JEP 123: SecureRandom First Draft and Implementation. Message-ID: +1 IBM already has SP800-90a/SHA256/HASH, SP800-90a/SHA384/HASH, and SP800-90a/SHA512/HASH in our provider, but without standardized names, they are not very useable for the Java community as a whole. Bruce A Rich brich at-sign us dot ibm dot com ----- Forwarded by Bruce Rich/Austin/IBM on 01/10/2013 11:44 AM ----- From: Michael StJohns To: Sean Mullan , Xuelei Fan Cc: OpenJDK Dev list , Brad Wetmore Date: 01/09/2013 09:32 PM Subject: Re: Update #2: JEP 123: SecureRandom First Draft and Implementation. Sent by: security-dev-bounces at openjdk.java.net At 09:45 AM 1/9/2013, Sean Mullan wrote: >think it is unlikely that 2 providers would implement the same SecureRandom algorithm, since the names are not standardized like other cryptographic algorithms such as SHA-256, RSA, etc. Can this be fixed? There really should be a flavor for this. E.g. SP800-90a/SHA256/HASH SP800-90A/SHA256/HMAC SP800-90A/AES/CTR NRBG/NoisyDiode[/implementation id] NRBG/RingOscillator[/Implementation id] There are about 6 classes of NIST "approved" deterministic random number generators. See http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf. I wouldn't be surprised to find that multiple providers implement the same RNGs, but don't have a common name for them. In fact, according to wikipedia, the underlying function for MSCAPI is the FIPS186-2 appendix 3.1 with SHA1 function. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130110/09009800/attachment.html From naoto.sato at oracle.com Thu Jan 10 11:36:17 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 10 Jan 2013 19:36:17 +0000 Subject: hg: jdk8/tl/jdk: 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments Message-ID: <20130110193629.349734718F@hg.openjdk.java.net> Changeset: c622df692bfb Author: bchristi Date: 2013-01-10 10:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c622df692bfb 8005962: TEST_BUG: java/util/Properties/MacJNUEncoding can fail in certain environments Summary: Test script now sets LC_ALL, other small changes, relocate test Reviewed-by: naoto, alanb + test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java + test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh - test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java - test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh From stuart.marks at oracle.com Thu Jan 10 13:50:38 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 10 Jan 2013 21:50:38 +0000 Subject: hg: jdk8/tl/jdk: 8005582: java/lang/Runtime/exec/WinCommand.java intermittent test failures Message-ID: <20130110215100.F093A4719D@hg.openjdk.java.net> Changeset: 13ff1089e625 Author: jgish Date: 2013-01-10 15:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/13ff1089e625 8005582: java/lang/Runtime/exec/WinCommand.java intermittent test failures Summary: Remove file-deletion code at cleanup which conflicts with jtreg cleanup Reviewed-by: chegar ! test/java/lang/Runtime/exec/WinCommand.java From chris.hegarty at oracle.com Thu Jan 10 13:53:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 10 Jan 2013 21:53:49 +0000 Subject: hg: jdk8/tl/jdk: 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 Message-ID: <20130110215400.8B9C54719E@hg.openjdk.java.net> Changeset: 3e906ccad412 Author: chegar Date: 2013-01-10 21:52 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3e906ccad412 8006007: j.u.c.atomic classes should use intrinsic getAndXXX provided by 7023898 Reviewed-by: dl, shade ! src/share/classes/java/util/concurrent/atomic/AtomicBoolean.java ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java From jonathan.gibbons at oracle.com Thu Jan 10 14:10:01 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Jan 2013 22:10:01 +0000 Subject: hg: jdk8/tl/langtools: 8006037: extra space in javac -help for -J and @ options Message-ID: <20130110221004.60C4A4719F@hg.openjdk.java.net> Changeset: d462da465da6 Author: jjg Date: 2013-01-10 14:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d462da465da6 8006037: extra space in javac -help for -J and @ options Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java + test/tools/javac/main/Option_J_At_Test.java From bernd-2013 at eckenfels.net Thu Jan 10 14:21:40 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Thu, 10 Jan 2013 23:21:40 +0100 Subject: Random points Message-ID: Hello, while trying to understand the exact behaviour of SecureRandom in Oracle JavaSE I found some places with potential improvements. I am new to the list, so let me know if and how I should submit the RFE (or patches) differently. http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/file/32a57e645e01/src/share/classes/sun/security/provider/SeedGenerator.java sun.security.provider.SeedGenerator#getSystemEntropy() 159: (if resolution is 20ms then this will only contribute 4bits) would it make sense to use nano seconds instead of millisenconds and submit more than one byte to the hashing? (longToByteArray() already exists) 170: instead of looping through the enumeration of the system property names I would loop over the entry set, since this avoids the hash lookups http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/file/32a57e645e01/src/share/classes/sun/security/provider/SunEntries.java 32: this javadoc comment does not format nicely into html http://hg.openjdk.java.net/jdk8/jdk8-gate/jdk/file/32a57e645e01/src/solaris/classes/sun/security/provider/NativePRNG.java 77: this logic requires both random and urandom to exist. The idea behind that is not using this native seeder if one of both is missing, since both are used. However on a system where one of both exists I would expect it to be used since it is for sure better than using the threaded alternative. In addition to that user might have specified one of both with java.security.egd and it is confusing if it is not observed. 130: MAX_BUFFER_TIME what is the idea behind expiring the urandom buffer? The content does not get worse or bad if it lays around. Especially not within 100ms. 252: implSetSeed() the comment says it is always adding the seed to the mixer and optionally writing it to dev/random, however the code is different, the engineSetSeed() is called at the end outside of a finally block, so in case there is a ioerror writing to /dev/random (likely!) there will also be additional seeding of the mixer 278: implNextBytes() this logic with calling ensureBufferValid() for every single byte has the disadvantage that it will call System.currentTimeMillis() for every byte EVEN when there are more/enough bytes in the internal buffer. This shoould be changed into two loops (the inner loop consumes all remaining buffered bytes without using the validity check). Another option would be to skip the validity check completely, I dont see a need for it. Greetings Bernd -- http://bernd.eckenfels.net From bradford.wetmore at oracle.com Thu Jan 10 15:02:31 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 10 Jan 2013 15:02:31 -0800 Subject: Fw: Update #2: JEP 123: SecureRandom First Draft and Implementation. In-Reply-To: References: Message-ID: <50EF4887.5050902@oracle.com> Thanks Bruce/Michael, FYI, I've created: 8006041: Create SecureRandom standard algorithm names. against JDK 8 to track this issue, and I had previously filed: 8003584: Consider adding a more modern SecureRandom implementation to add the SP800-90a algorithms in JDK. Brad On 1/10/2013 9:48 AM, Bruce Rich wrote: > +1 > > IBM already has SP800-90a/SHA256/HASH, SP800-90a/SHA384/HASH, and > SP800-90a/SHA512/HASH in our provider, but without standardized names, > they are not very useable for the Java community as a whole. > > Bruce A Rich > brich at-sign us dot ibm dot com > > ----- Forwarded by Bruce Rich/Austin/IBM on 01/10/2013 11:44 AM ----- > > From: Michael StJohns > To: Sean Mullan , Xuelei Fan > > Cc: OpenJDK Dev list , Brad Wetmore > > Date: 01/09/2013 09:32 PM > Subject: Re: Update #2: JEP 123: SecureRandom First Draft and > Implementation. > Sent by: security-dev-bounces at openjdk.java.net > ------------------------------------------------------------------------ > > > > At 09:45 AM 1/9/2013, Sean Mullan wrote: > >think it is unlikely that 2 providers would implement the same > SecureRandom algorithm, since the names are not standardized like other > cryptographic algorithms such as SHA-256, RSA, etc. > > Can this be fixed? There really should be a flavor for this. > > > E.g. > > SP800-90a/SHA256/HASH > SP800-90A/SHA256/HMAC > SP800-90A/AES/CTR > NRBG/NoisyDiode[/implementation id] > NRBG/RingOscillator[/Implementation id] > > There are about 6 classes of NIST "approved" deterministic random number > generators. See > http://csrc.nist.gov/publications/fips/fips140-2/fips1402annexc.pdf. > > > > I wouldn't be surprised to find that multiple providers implement the > same RNGs, but don't have a common name for them. In fact, according to > wikipedia, the underlying function for MSCAPI is the FIPS186-2 appendix > 3.1 with SHA1 function. > > Mike > > > From jonathan.gibbons at oracle.com Thu Jan 10 15:49:08 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Jan 2013 23:49:08 +0000 Subject: hg: jdk8/tl/langtools: 8006033: bug in Pretty.toSimpleString Message-ID: <20130110234910.ABCC9471AD@hg.openjdk.java.net> Changeset: 7d2f628f04f1 Author: jjg Date: 2013-01-10 15:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7d2f628f04f1 8006033: bug in Pretty.toSimpleString Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/tree/Pretty.java + test/tools/javac/tree/PrettySimpleStringTest.java From bradford.wetmore at oracle.com Thu Jan 10 16:24:07 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 10 Jan 2013 16:24:07 -0800 Subject: Update #4: JEP 123: SecureRandom Draft and Implementation. Message-ID: <50EF5BA7.2040606@oracle.com> Minor tweak. It occurred to me that people might use "." as separators (for example using some OIDs scheme), so I changed the syntax slightly of the system property to use ":" instead. For example: # This is a comma-separated list of algorithm and/or algorithm:provider # entries. # securerandom.strongAlgorithms=NativePRNGBlocking:SUN, SP800-90A/AES/CTR:IBMJDK Latest is now webrev.04. http://cr.openjdk.java.net/~wetmore/6425477/ Brad From bernd-2013 at eckenfels.net Thu Jan 10 16:49:28 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Fri, 11 Jan 2013 01:49:28 +0100 Subject: Update #4: JEP 123: SecureRandom Draft and Implementation. In-Reply-To: <50EF5BA7.2040606@oracle.com> References: <50EF5BA7.2040606@oracle.com> Message-ID: Am 11.01.2013, 01:24 Uhr, schrieb Brad Wetmore : > Minor tweak. It occurred to me that people might use "." as separators > (for example using some OIDs scheme), so I changed the syntax slightly > of the system property to use ":" instead. You could keep the patterns static (it is thread safe and would avoid repeating parsing). I would actually use StringTokenzier and trim instead but I guess it is not very performance relevant (even using one pattern with optional second group is an option). Gruss Bernd -- http://bernd.eckenfels.net From bernd-2013 at eckenfels.net Thu Jan 10 16:53:11 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Fri, 11 Jan 2013 01:53:11 +0100 Subject: Update #4: JEP 123: SecureRandom Draft and Implementation. In-Reply-To: <50EF5BA7.2040606@oracle.com> References: <50EF5BA7.2040606@oracle.com> Message-ID: Am 11.01.2013, 01:24 Uhr, schrieb Brad Wetmore : > Minor tweak. It occurred to me that people might use "." as separators > (for example using some OIDs scheme), so I changed the syntax slightly > of the system property to use ":" instead. The comment needs fixing as well: + // First try "algorithm.provider" From jonathan.gibbons at oracle.com Thu Jan 10 19:39:02 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2013 03:39:02 +0000 Subject: hg: jdk8/tl/langtools: 8004834: Add doclint support into javadoc Message-ID: <20130111033905.490CC471B9@hg.openjdk.java.net> Changeset: fc4cb1577ad6 Author: jjg Date: 2013-01-10 19:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fc4cb1577ad6 8004834: Add doclint support into javadoc Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! test/com/sun/javadoc/5093723/T5093723.java ! test/com/sun/javadoc/testBadSourceFile/TestBadSourceFile.java ! test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testReturnTag/TestReturnTag.java ! test/com/sun/javadoc/testTagInheritence/TestTagInheritence.java ! test/com/sun/javadoc/testTagMisuse/TestTagMisuse.java ! test/com/sun/javadoc/testValueTag/TestValueTag.java ! test/com/sun/javadoc/testWarnBadParamNames/TestWarnBadParamNames.java ! test/com/sun/javadoc/testWarnings/TestWarnings.java ! test/tools/javadoc/6958836/Test.java ! test/tools/javadoc/6964914/Test.java ! test/tools/javadoc/6964914/TestStdDoclet.java ! test/tools/javadoc/MaxWarns.java ! test/tools/javadoc/T6551367.java + test/tools/javadoc/doclint/DocLintTest.java From jonathan.gibbons at oracle.com Thu Jan 10 19:39:27 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2013 03:39:27 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130111033950.61FC7471BA@hg.openjdk.java.net> Changeset: c6e8a518c3cd Author: jjg Date: 2013-01-10 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6e8a518c3cd 8004834: Add doclint support into javadoc Reviewed-by: erikj, tbell ! make/docs/Makefile Changeset: c9308137ad9e Author: jjg Date: 2013-01-10 19:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9308137ad9e Merge - test/java/util/Properties/MacJNUEncoding/ExpectedEncoding.java - test/java/util/Properties/MacJNUEncoding/MacJNUEncoding.sh From jonathan.gibbons at oracle.com Thu Jan 10 19:40:02 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 11 Jan 2013 03:40:02 +0000 Subject: hg: jdk8/tl: 8004834: Add doclint support into javadoc Message-ID: <20130111034003.326D6471BB@hg.openjdk.java.net> Changeset: 1129fb75f611 Author: jjg Date: 2013-01-10 19:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/1129fb75f611 8004834: Add doclint support into javadoc Reviewed-by: erikj, tbell ! common/makefiles/javadoc/Javadoc.gmk From joe.darcy at oracle.com Thu Jan 10 21:12:36 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 11 Jan 2013 05:12:36 +0000 Subject: hg: jdk8/tl/jdk: 8006062: Add @Repeatable to repeating annotations regression tests in JDK repo Message-ID: <20130111051247.E47CC471DB@hg.openjdk.java.net> Changeset: 86c563dc70ca Author: darcy Date: 2013-01-10 21:12 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86c563dc70ca 8006062: Add @Repeatable to repeating annotations regression tests in JDK repo Reviewed-by: jjg ! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java From alan.bateman at oracle.com Fri Jan 11 04:29:23 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Jan 2013 12:29:23 +0000 Subject: hg: jdk8/tl/jdk: 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) Message-ID: <20130111123228.01781471E5@hg.openjdk.java.net> Changeset: 0ca2e39a110d Author: alanb Date: 2013-01-11 12:27 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ca2e39a110d 8005566: (fs) test/java/nio/file/Files/Misc.java failing (sol) Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/SolarisAclFileAttributeView.java ! test/java/nio/file/Files/Misc.java From vikram.aroskar at oracle.com Thu Jan 10 21:10:12 2013 From: vikram.aroskar at oracle.com (vikram.aroskar at oracle.com) Date: Fri, 11 Jan 2013 05:10:12 +0000 Subject: hg: jdk8/tl/jaxp: 8003147: port fix for BCEL bug 39695 Message-ID: <20130111051017.93E67471DA@hg.openjdk.java.net> Changeset: 47738fa4d411 Author: dbuck Date: 2013-01-10 20:26 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/47738fa4d411 8003147: port fix for BCEL bug 39695 Summary: Added support for Local Variable Type Table so that BCEL library can be used to modify methods with generics-related debug data without violating class file format Reviewed-by: lancea ! src/com/sun/org/apache/bcel/internal/Constants.java ! src/com/sun/org/apache/bcel/internal/classfile/Attribute.java ! src/com/sun/org/apache/bcel/internal/classfile/DescendingVisitor.java ! src/com/sun/org/apache/bcel/internal/classfile/EmptyVisitor.java + src/com/sun/org/apache/bcel/internal/classfile/LocalVariableTypeTable.java ! src/com/sun/org/apache/bcel/internal/classfile/Visitor.java ! src/com/sun/org/apache/bcel/internal/generic/MethodGen.java From alan.bateman at oracle.com Fri Jan 11 12:22:17 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 11 Jan 2013 20:22:17 +0000 Subject: hg: jdk8/tl/jdk: 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools Message-ID: <20130111202241.5D59A47203@hg.openjdk.java.net> Changeset: 7da291690aa0 Author: alanb Date: 2013-01-11 20:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7da291690aa0 8005978: shell tests need to use the $COMPILEJDK for javac, jar and other tools Reviewed-by: chegar ! test/ProblemList.txt ! test/com/sun/management/HotSpotDiagnosticMXBean/DumpHeap.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetMaxFileDescriptorCount.sh ! test/com/sun/management/UnixOperatingSystemMXBean/GetOpenFileDescriptorCount.sh ! test/java/io/FileOutputStream/FileOpen.sh ! test/java/io/Serializable/class/run.sh ! test/java/io/Serializable/evolution/RenamePackage/run.sh ! test/java/io/Serializable/maskSyntheticModifier/run.sh ! test/java/io/Serializable/packageAccess/run.sh ! test/java/io/Serializable/resolveClass/consTest/run.sh ! test/java/io/Serializable/resolveClass/deserializeButton/run.sh ! test/java/io/Serializable/superclassDataLoss/run.sh ! test/java/io/Serializable/unnamedPackageSwitch/run.sh ! test/java/lang/Class/getEnclosingClass/build.sh ! test/java/lang/ClassLoader/Assert.sh ! test/java/lang/ClassLoader/deadlock/TestCrossDelegate.sh ! test/java/lang/ClassLoader/deadlock/TestOneWayDelegate.sh ! test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh ! test/java/lang/Thread/UncaughtExceptions.sh ! test/java/lang/annotation/loaderLeak/LoaderLeak.sh ! test/java/lang/instrument/AppendToBootstrapClassPathSetUp.sh ! test/java/lang/instrument/AppendToClassPathSetUp.sh ! test/java/lang/instrument/BootClassPath/BootClassPathTest.sh ! test/java/lang/instrument/MakeJAR.sh ! test/java/lang/instrument/MakeJAR2.sh ! test/java/lang/instrument/MakeJAR3.sh ! test/java/lang/instrument/MakeJAR4.sh ! test/java/lang/instrument/ManifestTest.sh ! test/java/lang/instrument/ParallelTransformerLoader.sh ! test/java/lang/instrument/PremainClass/NoPremainAgent.sh ! test/java/lang/instrument/PremainClass/PremainClassTest.sh ! test/java/lang/instrument/PremainClass/ZeroArgPremainAgent.sh ! test/java/lang/instrument/RedefineBigClass.sh ! test/java/lang/instrument/RedefineClassWithNativeMethod.sh ! test/java/lang/instrument/RedefineMethodAddInvoke.sh ! test/java/lang/instrument/RedefineSetUp.sh ! test/java/lang/instrument/RetransformBigClass.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CircularityErrorTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/ClassUnloadTest.sh ! test/java/lang/instrument/appendToClassLoaderSearch/CommonSetup.sh ! test/java/lang/instrument/appendToClassLoaderSearch/run_tests.sh ! test/java/net/Authenticator/B4933582.sh ! test/java/net/URL/B5086147.sh ! test/java/net/URL/runconstructor.sh ! test/java/net/URLClassLoader/B5077773.sh ! test/java/net/URLClassLoader/closetest/build.sh ! test/java/net/URLClassLoader/getresourceasstream/test.sh ! test/java/net/URLClassLoader/sealing/checksealed.sh ! test/java/net/URLConnection/6212146/test.sh ! test/java/net/URLConnection/UNCTest.sh ! test/java/nio/charset/spi/basic.sh ! test/java/rmi/activation/Activatable/extLoadedImpl/ext.sh ! test/java/rmi/registry/readTest/readTest.sh ! test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.sh ! test/java/security/Security/ClassLoaderDeadlock/Deadlock2.sh ! test/java/security/Security/signedfirst/Dyn.sh ! test/java/security/Security/signedfirst/Static.sh ! test/java/security/cert/CertificateFactory/slowstream.sh ! test/java/util/Formatter/Basic.sh ! test/java/util/Locale/LocaleProviders.sh ! test/java/util/PluggableLocale/ExecTest.sh ! test/java/util/ServiceLoader/basic.sh ! test/java/util/TimeZone/TimeZoneDatePermissionCheck.sh ! test/java/util/prefs/PrefsSpi.sh ! test/javax/crypto/SecretKeyFactory/FailOverTest.sh ! test/javax/script/CommonSetup.sh ! test/javax/script/ProviderTest.sh ! test/javax/security/auth/Subject/doAs/Test.sh ! test/lib/security/java.policy/Ext_AllPolicy.sh ! test/sun/management/jmxremote/bootstrap/PasswordFilePermissionTest.sh ! test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.sh ! test/sun/management/jmxremote/startstop/JMXStartStopTest.sh ! test/sun/net/www/MarkResetTest.sh ! test/sun/net/www/http/HttpClient/RetryPost.sh ! test/sun/net/www/protocol/jar/B5105410.sh ! test/sun/net/www/protocol/jar/jarbug/run.sh ! test/sun/security/krb5/config/dns.sh ! test/sun/security/krb5/runNameEquals.sh ! test/sun/security/mscapi/IsSunMSCAPIAvailable.sh ! test/sun/security/pkcs11/KeyStore/Basic.sh ! test/sun/security/pkcs11/KeyStore/ClientAuth.sh ! test/sun/security/pkcs11/KeyStore/Solaris.sh ! test/sun/security/pkcs11/Provider/ConfigQuotedString.sh ! test/sun/security/pkcs11/Provider/Login.sh ! test/sun/security/provider/PolicyFile/GrantAllPermToExtWhenNoPolicy.sh ! test/sun/security/provider/PolicyFile/getinstance/getinstance.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/EngineArgs/DebugReportsOneExtraByte.sh ! test/sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLSocketImpl/NotifyHandshakeTest.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh ! test/sun/security/tools/keytool/autotest.sh ! test/sun/security/tools/keytool/printssl.sh ! test/sun/security/tools/keytool/readjar.sh ! test/sun/security/tools/keytool/standard.sh ! test/sun/security/util/Oid/S11N.sh ! test/sun/security/validator/certreplace.sh ! test/sun/security/validator/samedn.sh ! test/tools/launcher/ClassPathWildCard.sh ! test/tools/launcher/MultipleJRE.sh From joe.darcy at oracle.com Fri Jan 11 15:39:20 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 11 Jan 2013 23:39:20 +0000 Subject: hg: jdk8/tl/jdk: 7131459: [Fmt-De] DecimalFormat produces wrong format() results when close to a tie Message-ID: <20130111233932.0041F4720E@hg.openjdk.java.net> Changeset: bc1f16f5566f Author: darcy Date: 2013-01-11 15:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc1f16f5566f 7131459: [Fmt-De] DecimalFormat produces wrong format() results when close to a tie Reviewed-by: darcy Contributed-by: olivier.lagneau at oracle.com ! src/share/classes/java/text/DigitList.java ! src/share/classes/sun/misc/FloatingDecimal.java + test/java/text/Format/DecimalFormat/TieRoundingTest.java From xueming.shen at oracle.com Fri Jan 11 22:43:14 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Sat, 12 Jan 2013 06:43:14 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130112064336.B631A47222@hg.openjdk.java.net> Changeset: 6f6246aced89 Author: sherman Date: 2013-01-11 22:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f6246aced89 8005466: JAR file entry hash table uses too much memory (zlib_util.c) Summary: realign the fields of jzcell struct Reviewed-by: sherman Contributed-by: ioi.lam at oracle.com ! src/share/native/java/util/zip/zip_util.h Changeset: 8009c7e3899e Author: sherman Date: 2013-01-11 22:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8009c7e3899e Merge From chris.hegarty at oracle.com Sun Jan 13 14:14:36 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 13 Jan 2013 22:14:36 +0000 Subject: hg: jdk8/tl/jdk: 8006153: HTTP protocol handler authenication should use Base64 API Message-ID: <20130113221518.BD0B247237@hg.openjdk.java.net> Changeset: 7db04ae3378f Author: chegar Date: 2013-01-13 22:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7db04ae3378f 8006153: HTTP protocol handler authenication should use Base64 API Reviewed-by: chegar, alanb Contributed-by: Mark Sheppard ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java ! src/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java From david.holmes at oracle.com Sun Jan 13 16:57:35 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 14 Jan 2013 00:57:35 +0000 Subject: hg: jdk8/tl/jdk: 8005232: (JEP-149) Class Instance size reduction Message-ID: <20130114005756.0533447239@hg.openjdk.java.net> Changeset: 1109bfff4e92 Author: dholmes Date: 2013-01-13 19:57 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1109bfff4e92 8005232: (JEP-149) Class Instance size reduction Summary: Moved the fields for cached reflection objects into a seperate ReflectionData object to reduce dynamic footprint. Reviewed-by: dholmes, mchung, shade Contributed-by: Peter Levart ! src/share/classes/java/lang/Class.java From vincent.x.ryan at oracle.com Mon Jan 14 06:31:57 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 14 Jan 2013 14:31:57 +0000 Subject: Draft API for JEP-166: Overhaul JKS-JCEKS-PKCS12 Keystores In-Reply-To: <50F367C5.1050602@oracle.com> References: <50F367C5.1050602@oracle.com> Message-ID: <50F416DD.5020907@oracle.com> Hello all, I am seeking feedback on a draft of the public APIs that I believe are needed to address the features described in JEP-166 [1]. JEP-166 is targeted to JDK 8 Milestone 6 so I am keen to get the bulk of these API changes integrated into the last remaining build of M6: Build 75. Note that there will be ample time in Milestone 7 to make API modifications and improvements as necessary. I have divided the API changes into 5 main sections: 1. To support metadata for keystore entries 2. To support stronger entry protection algorithms 3. To support the destruction of sensitive information associated with cryptographic keys 4. To support the logical grouping of keystores and entries 5. To support the secure storage of passwords To speed up the process I am providing the javadoc specification now and will follow-up with a more complete webrev. Your comments are welcome. Thanks. ____ [1] http://openjdk.java.net/jeps/166 =========================================== 1. To support metadata for keystore entries =========================================== This involves adding a new nested interface to the java.security.KeyStore.Entry interface along with a new getAttributes method. In addition a new constructor that takes a set of attributes is defined for each of the concrete classes that implement KeyStore.Entry. Finally a new PKCS12Attribute if defined to specifically support attributes in PKCS12 keystores. ----------------------------------------------------------- New interface in the java.security.KeyStore.Entry interface ----------------------------------------------------------- /** * An attribute associated with a keystore entry. * It comprises a name and one or more values. * * @since 1.8 */ public interface Attribute { /** * Returns the attribute's name. * * @return the attribute name */ public String getName(); /** * Returns the attribute's value. * Multi-valued attributes encode their values as a single string. * * @return the attribute value */ public String getValue(); } -------------------------------------------------------- New method in the java.security.KeyStore.Entry interface -------------------------------------------------------- /** * Retrieves the attributes associated with an entry. *

* The default implementation returns an empty {@code Set}. * * @return an unmodifiable {@code Set} of attributes, possibly empty * * @since 1.8 */ public default Set getAttributes() { ... }; ------------------------------------------------------------------- New constructor for the java.security.KeyStore.SecretKeyEntry class ------------------------------------------------------------------- /** * Constructs a {@code SecretKeyEntry} with a {@code SecretKey} and * associated entry attributes. * *

The specified {@code attributes} is cloned before it is stored * in the new {@code SecretKeyEntry} object. * * @param secretKey the {@code SecretKey} * @param attributes the attributes * * @exception NullPointerException if {@code secretKey} or * {@code attributes} is {@code null} * * @since 1.8 */ public SecretKeyEntry(SecretKey secretKey, Set attributes) { ... }; -------------------------------------------------------------------- New constructor for the java.security.KeyStore.PrivateKeyEntry class -------------------------------------------------------------------- /** * Constructs a {@code PrivateKeyEntry} with a {@code PrivateKey} and * corresponding certificate chain and associated entry attributes. * *

The specified {@code chain} and {@code attributes} are cloned * before they are stored in the new {@code PrivateKeyEntry} object. * * @param privateKey the {@code PrivateKey} * @param chain an array of {@code Certificate}s * representing the certificate chain. * The chain must be ordered and contain a * {@code Certificate} at index 0 * corresponding to the private key. * @param attributes the attributes * * @exception NullPointerException if {@code privateKey}, {@code chain} * or {@code attributes} is {@code null} * @exception IllegalArgumentException if the specified chain has a * length of 0, if the specified chain does not contain * {@code Certificate}s of the same type, * or if the {@code PrivateKey} algorithm * does not match the algorithm of the {@code PublicKey} * in the end entity {@code Certificate} (at index 0) * * @since 1.8 */ public PrivateKeyEntry(PrivateKey privateKey, Certificate[] chain, Set attributes) { ... }; ------------------------------------------------------------------------ New constructor for java.security.KeyStore.TrustedCertificateEntry class ------------------------------------------------------------------------ /** * Constructs a {@code TrustedCertificateEntry} with a * trusted {@code Certificate} and associated entry attributes. * *

The specified {@code attributes} is cloned before it is stored * in the new {@code TrustedCertificateEntry} object. * * @param trustedCert the trusted {@code Certificate} * @param attributes the attributes * * @exception NullPointerException if {@code trustedCert} or * {@code attributes} is {@code null} * * @since 1.8 */ public TrustedCertificateEntry(Certificate trustedCert, Set attributes) { ... }; -------------------------------------- New class in the java.security package -------------------------------------- /** * An attribute associated with a PKCS12 keystore entry. * The attribute name is an ASN.1 Object Identifier and the attribute * value is a set of arbitrary ASN.1 types. * * @since 1.8 */ public final class PKCS12Attribute implements KeyStore.Entry.Attribute { /** * Constructs a PKCS12 attribute from its name and value. * The name is an ASN.1 Object Identifier represented as a list of * dot-separated integers. * A string value is represented as the string itself. * A binary value is represented as a string of colon-separated * pairs of hexadecimal digits. * Multi-valued attributes are represented as a comma-separated * list of values, enclosed in square brackets. See * {@link Arrays.toString}. *

* A string value will be DER-encoded as an ASN.1 UTF8String and a * binary value will be DER-encoded as an ASN.1 Octet String. * * @param name the attribute's identifier * @param value the attribute's value * * @exception NullPointerException if {@code name} or {@code value} * is {@code null} * @exception IllegalArgumentException if {@code name} or * {@code value} is incorrectly formatted */ public PKCS12Attribute(String name, String value) { ... }; /** * Constructs a PKCS12 attribute from its ASN.1 DER encoding. * The DER encoding is specified by the following ASN.1 definition: * 

      *
      * Attribute ::= SEQUENCE {
      *     type   AttributeType,
      *     values SET OF AttributeValue
      * }
      * AttributeType ::= OBJECT IDENTIFIER
      * AttributeValue ::= ANY defined by type
      *
      *
* * @param encoded the attribute's ASN.1 DER encoding. It is cloned * to prevent subsequent modificaion. * * @exception NullPointerException if {@code encoded} is * {@code null} * @exception IllegalArgumentException if {@code encoded} is * incorrectly formatted */ public PKCS12Attribute(byte[] encoded) { ... }; /** * Returns the attribute's ASN.1 Object Identifier represented as a * list of dot-separated integers. * * @return the attribute's identifier */ @Override public String getName() { ... }; /** * Returns the attribute's ASN.1 DER-encoded value as a string. * An ASN.1 DER-encoded value is returned in one of the following * {@code String} formats: *
    *
  • the DER encoding of a basic ASN.1 type that has a natural * string representation is returned as the string itself. * Such types are currently limited to BOOLEAN, INTEGER, * OBJECT IDENTIFIER, UTCTime, GeneralizedTime and the * following six ASN.1 string types: UTF8String, * PrintableString, T61String, IA5String, BMPString and * GeneralString. *
  • the DER encoding of any other ASN.1 type is not decoded but * returned as a binary string of colon-separated pairs of * hexadecimal digits. *
* Multi-valued attributes are represented as a comma-separated * list of values, enclosed in square brackets. See * {@link Arrays.toString}. * * @return the attribute value's string encoding */ @Override public String getValue() { ... }; /** * Returns the attribute's ASN.1 DER encoding. * * @return a clone of the attribute's DER encoding */ public byte[] getEncoded() { ... }; /** * Compares this {@code PKCS12Attribute} and a specified object for * equality. * * @param obj the comparison object * * @return true if {@code obj} is a {@code PKCS12Attribute} and * their DER encodings are equal. */ @Override public boolean equals(Object obj) { ... }; /** * Returns the hashcode for this {@code PKCS12Attribute}. * The hash code is computed from its DER encoding. * * @return the hash code */ @Override public int hashCode() { ... }; /** * Returns a string representation of this {@code PKCS12Attribute}. * * @return a name/value pair separated by an 'equals' symbol */ @Override public String toString() { ... }; } ================================================== 2. To support stronger entry protection algorithms ================================================== This involves enhancing the KeyStore.PasswordProtection class to enable a password-based encryption algorithm (PBE) to be specified along with any necessary parameters. The PBE algorithm is used to encrypt a keystore entry containing a private key or a secret key when the KeyStore.setEntry or KeyStore.seyKeyEntry methods are used. ------------------------------------------------------------------ New methods in the java.security.KeyStore.PasswordProtection class ------------------------------------------------------------------ /** * Creates a password parameter and specifies the protection algorithm * and associated parameters to use when encrypting a keystore entry. *

* The specified {@code password} is cloned before it is stored in the * new {@code PasswordProtection} object. * * @param password the password, which may be {@code null} * @param protectionAlgorithm the encryption algorithm name, for * example, {@code PBEWithHmacSHA256AndAES_256}. * See the Cipher section in the * Java Cryptography Architecture Standard Algorithm Name * Documentation * for information about standard encryption algorithm names. * @param protectionParameters the encryption algorithm parameter * specification, which may be {@code null} * @exception NullPointerException if {@code protectionAlgorithm} is * {@code null} * * @since 1.8 */ public PasswordProtection(char[] password, String protectionAlgorithm, AlgorithmParameterSpec protectionParameters); /** * Gets the name of the protection algorithm. * If none was set then the default algorithm name is returned. * The default algorithm name for a given keystore type is set using the * {@code 'keystore..entryProtectionAlgorithm'} Security property. * For example, the * {@code keystore.PKCS12.entryProtectionAlgorithm} property stores the * name of the default entry protection algorithm used for PKCS12 * keystores. * * @return the algorithm name * * @since 1.8 */ public String getProtectionAlgorithm(); /** * Gets the parameters supplied for the protection algorithm. * * @return the algorithm parameter specification, or {@code null}, * if none was set * * @since 1.8 */ public AlgorithmParameterSpec getProtectionParameters(); ========================================================== 3. To support the destruction of sensitive key information ========================================================== This involves defining default method implementations for the destroy and isDestroyed methods of the javax.security.auth.Destroyable interface. And modifying the java.security.PrivateKey and javax.crypto.SecretKey interfaces to extend Destroyable. ------------------------------------------------------------------- Changes to methods in the javax.security.auth.Destroyable interface ------------------------------------------------------------------- /** * Destroys this {@code Object}. * Sensitive information associated with this {@code Object} is * destroyed or cleared. Subsequent calls to methods on this * {@code Object} will result in an {@code IllegalStateException} * being thrown. *

* The default implementation throws {@code DestroyFailedException}. * * @exception DestroyFailedException if the destroy operation fails. * @exception SecurityException if the caller does not have * permission to destroy this {@code Object}. * * @since 1.8 */ public default void destroy() throws DestroyFailedException { ... }; /** * Determines if this {@code SecretKey} has been destroyed. *

* The default implementation returns false. * * @return true if this {@code SecretKey} has been destroyed, * false otherwise. * * @since 1.8 */ public default boolean isDestroyed() { ... }; -------------------------------------------------------------------- Changed class inheritance for the java.security.PrivateKey interface -------------------------------------------------------------------- /** * A private key. * The purpose of this interface is to group (and provide type safety * for) all private key interfaces. *

* Note: The specialized private key interfaces extend this interface. * See, for example, the {@code DSAPrivateKey} interface in * {@link java.security.interfaces}. *

* Implementations should override the default {@code destroy} and * {@code isDestroyed} methods from the * {@link javax.security.auth.Destroyable} interface to enable * sensitive key information to be destroyed or cleared. * * @see Key * @see PublicKey * @see Certificate * @see Signature#initVerify * @see java.security.interfaces.DSAPrivateKey * @see java.security.interfaces.RSAPrivateKey * @see java.security.interfaces.RSAPrivateCrtKey * * @author Benjamin Renaud * @author Josh Bloch */ public interface PrivateKey extends Key, Destroyable { ... } ------------------------------------------------------------------ Changed class inheritance for the javax.crypto.SecretKey interface ------------------------------------------------------------------ /** * A secret (symmetric) key. * The purpose of this interface is to group (and provide type safety * for) all secret key interfaces. *

* Provider implementations of this interface must overwrite the * {@code equals} and {@code hashCode} methods inherited from * {@link java.lang.Object}, so that secret keys are compared based on * their underlying key material and not based on reference. * Implementations should also override the default {@code destroy} and * {@code isDestroyed} methods from the * {@link javax.security.auth.Destroyable} interface to enable * sensitive key information to be destroyed or cleared. * *

Keys that implement this interface return the string {@code RAW} * as their encoding format (see {@code getFormat}), and return the * raw key bytes as the result of a {@code getEncoded} method call. (The * {@code getFormat} and {@code getEncoded} methods are inherited * from the {@link java.security.Key} parent interface.) * * @author Jan Luehe * * @see SecretKeyFactory * @see Cipher * @since 1.4 */ public interface SecretKey extends Key, Destroyable { ... } =========================================================== 4. To support the logical grouping of keystores and entries =========================================================== This involves defining an implementation of the KeyStore.LoadStoreParameter interface that conveys the configuration data that defines a keystore domain to the load and store methods of KeyStore. --------------------------------------------- New class in the java.security.KeyStore class --------------------------------------------- /** * Configuration data that specifies the collection of keystores in * a keystore domain. * It is used during {@code KeyStore} * {@link #load(KeyStore.LoadStoreParameter) load} and * {@link #store(KeyStore.LoadStoreParameter) store} operations. *

* The following syntax is supported for configuration data: * 

  *
  *     domain  [ ...] {
  *         keystore  [ ...] ;
  *         ...
  *     };
  *     ...
  *
  *
* where {@code domainName} and {@code keystoreName} are strings * enclosed in double quotes and * {@code domainProperty} and {@code keystoreProperty} are key/value * pairings. * The key and value are strings separated by an 'equals' symbol and * the value is enclosed in double quotes. A value may be either a * printable string or a binary string of colon-separated pairs of * hexadecimal digits. * Multi-valued properties are represented as a comma-separated list of * values, enclosed in square brackets. See {@link Arrays.toString}. *

* The following keystore properties are supported: *

*
{@code keyStoreType=}
*
The keystore type.
*
{@code keyStoreURI=}
*
The keystore location.
*
* *

* For example, configuration data for a simple keystore domain * comprising three keystores is shown below: * 

  *
  * domain "app1" {
  *     keystore "truststore"
  *         keyStoreURI="file://app1/etc/truststore.jks"
  *
  *     keystore "cacerts"
  *         keyStoreURI="${java.home}/lib/security/cacerts"
  *
  *     keystore "keystore"
  *         keyStoreType="PKCS12"
  *         keyStoreURI="file://app1/etc/keystore.p12"
  * };
  *
  *
* @since 1.8 */ public final class DomainLoadStoreParameter implements LoadStoreParameter { /** * Constructs a DomainLoadStoreParameter for a keystore domain with * the parameters used to protect keystore data. * The domain configuration data is identified by the supplied URI. * * @param configuration the domain configuration data * @param protectionParams the parameters used to protect keystore * data. It is cloned to prevent subsequent modification. * * @exception NullPointerExcetion if {@code configuration} or * {@code protectionParams} is {@code null} */ public KeyStore.DomainLoadStoreParameter(URI configuration, Map protectionParams) {...}; /** * Gets the configuration data for this domain. * * @return the identifier for the domain's configuration data */ public URI getConfiguration() {...}; /** * Gets the keystore protection parameters for keystores in this * domain. * * @return an unmodifiable map of keystore names to protection * parameters */ public Map getProtectionParams() {...}; /** * Gets the keystore protection parameters for this domain. * Keystore domains do not support a protection parameter. * * @return always returns {@code null} */ @Override public KeyStore.ProtectionParameter getProtectionParameter() {...}; } ============================================= 5. To support the secure storage of passwords ============================================= This involves introducing a new command option for the keytool utility that accepts a password and stores it securely as a secret key. -------------------------------------------------------------------- Addition to the keytool manpage for the new command: -importpassword -------------------------------------------------------------------- -importpassword {-alias alias} [-keypass keypass] {-storetype storetype} {-keystore keystore} [-storepass storepass] {-providerClass provider_class_name {-providerArg provider_arg}} {-v} {-protected} {-Jjavaoption} Imports a passphrase and stores it in a new KeyStore.SecretKeyEntry identified by alias. The passphrase may be supplied via the standard input stream; otherwise the user is prompted for it. keypass is a password used to protect the imported passphrase. If no password is provided, the user is prompted for it. If you press RETURN at the prompt, the key password is set to the same password as that used for the keystore. keypass must be at least 6 characters long. From naoto.sato at oracle.com Mon Jan 14 11:17:42 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 14 Jan 2013 19:17:42 +0000 Subject: hg: jdk8/tl/jdk: 7162007: Clean up i18n related caches Message-ID: <20130114191803.3DF1247263@hg.openjdk.java.net> Changeset: 1d7a6adf499f Author: naoto Date: 2013-01-14 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d7a6adf499f 7162007: Clean up i18n related caches Reviewed-by: okutsu, ohair ! make/java/java/FILES_java.gmk ! src/share/classes/java/text/DateFormatSymbols.java ! src/share/classes/java/text/DecimalFormat.java ! src/share/classes/java/text/DecimalFormatSymbols.java ! src/share/classes/java/text/NumberFormat.java ! src/share/classes/java/util/Locale.java ! src/share/classes/java/util/TimeZone.java ! src/share/classes/sun/text/resources/zh/CollationData_zh_HK.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_HK.java ! src/share/classes/sun/util/locale/provider/AuxLocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarDataProviderImpl.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/CollatorProviderImpl.java ! src/share/classes/sun/util/locale/provider/CurrencyNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/JRELocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleProviderAdapter.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + src/share/classes/sun/util/locale/provider/ResourceBundleBasedAdapter.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/TimeZoneNameUtility.java ! src/share/classes/sun/util/resources/LocaleData.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/CurrencyNames_zh_SG.java ! src/share/classes/sun/util/resources/zh/LocaleNames_zh_HK.java ! src/share/classes/sun/util/resources/zh/TimeZoneNames_zh_HK.java ! test/java/util/PluggableLocale/BreakIteratorProviderTest.java ! test/java/util/PluggableLocale/CollatorProviderTest.java ! test/java/util/PluggableLocale/CurrencyNameProviderTest.java ! test/java/util/PluggableLocale/DateFormatProviderTest.java ! test/java/util/PluggableLocale/DateFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.java ! test/java/util/PluggableLocale/LocaleNameProviderTest.java ! test/java/util/PluggableLocale/NumberFormatProviderTest.java ! test/java/util/PluggableLocale/TimeZoneNameProviderTest.java From jason.uh at oracle.com Mon Jan 14 13:38:49 2013 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 14 Jan 2013 13:38:49 -0800 Subject: [8] Request for review: 8005414: Removing fix for JDK-6500133 Message-ID: <50F47AE9.6080300@oracle.com> This change removes the fix for 6500133, as it has been determined to be not compliant with the PKIX standard. Webrev: http://cr.openjdk.java.net/~juh/8005414/webrev.00/ Original bug: http://bugs.sun.com/view_bug.do?bug_id=6500133 Thanks, Jason From sean.mullan at oracle.com Mon Jan 14 13:52:17 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Jan 2013 16:52:17 -0500 Subject: [8] Request for review: 8005414: Removing fix for JDK-6500133 In-Reply-To: <50F47AE9.6080300@oracle.com> References: <50F47AE9.6080300@oracle.com> Message-ID: <50F47E11.60109@oracle.com> Looks good to me. --Sean On 01/14/2013 04:38 PM, Jason Uh wrote: > This change removes the fix for 6500133, as it has been determined to be > not compliant with the PKIX standard. > > Webrev: http://cr.openjdk.java.net/~juh/8005414/webrev.00/ > Original bug: http://bugs.sun.com/view_bug.do?bug_id=6500133 > > Thanks, > Jason From jonathan.gibbons at oracle.com Mon Jan 14 13:50:59 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Jan 2013 21:50:59 +0000 Subject: hg: jdk8/tl/langtools: 8006119: update javac to follow latest spec for repeatable annotations Message-ID: <20130114215104.C7FBE47268@hg.openjdk.java.net> Changeset: df694c775e8a Author: jjg Date: 2013-01-14 13:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/df694c775e8a 8006119: update javac to follow latest spec for repeatable annotations Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContaineeSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg/ContainerSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContaineeSynthDoc.java ! test/com/sun/javadoc/testRepeatedAnnotations/pkg1/ContainerSynthNotDoc.java ! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/BaseAnnoAsContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/BasicRepeatingAnnotations.java ! test/tools/javac/annotations/repeatingAnnotations/CheckTargets.java ! test/tools/javac/annotations/repeatingAnnotations/ClassReaderDefault.java ! test/tools/javac/annotations/repeatingAnnotations/ContainerHasRepeatedContained.java ! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.java ! test/tools/javac/annotations/repeatingAnnotations/CyclicAnnotation.out ! test/tools/javac/annotations/repeatingAnnotations/DefaultCasePresent.java ! test/tools/javac/annotations/repeatingAnnotations/DelayRepeatedContainer.java ! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/DocumentedContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.java ! test/tools/javac/annotations/repeatingAnnotations/InheritedContainerAnno.out ! test/tools/javac/annotations/repeatingAnnotations/InvalidTarget.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.java ! test/tools/javac/annotations/repeatingAnnotations/MissingContainer.out - test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase1.out ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.java ! test/tools/javac/annotations/repeatingAnnotations/MissingDefaultCase2.out ! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.java ! test/tools/javac/annotations/repeatingAnnotations/MissingValueMethod.out ! test/tools/javac/annotations/repeatingAnnotations/MultiLevelRepeatableAnno.java ! test/tools/javac/annotations/repeatingAnnotations/MultipleAnnoMixedOrder.java ! test/tools/javac/annotations/repeatingAnnotations/NestedContainers.java ! test/tools/javac/annotations/repeatingAnnotations/NoRepeatableAnno.out ! test/tools/javac/annotations/repeatingAnnotations/RepMemberAnno.java ! test/tools/javac/annotations/repeatingAnnotations/RepSelfMemberAnno.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingAndContainerPresent.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.java ! test/tools/javac/annotations/repeatingAnnotations/RepeatingTargetNotAllowed.out ! test/tools/javac/annotations/repeatingAnnotations/SelfRepeatingAnnotations.java ! test/tools/javac/annotations/repeatingAnnotations/SingleRepeatingAndContainer.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java + test/tools/javac/annotations/repeatingAnnotations/UseWrongRepeatable.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java ! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.java ! test/tools/javac/annotations/repeatingAnnotations/WrongReturnTypeForValue.out ! test/tools/javac/annotations/repeatingAnnotations/combo/BasicSyntaxCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/DeprecatedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/DocumentedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/Helper.java ! test/tools/javac/annotations/repeatingAnnotations/combo/InheritedAnnoCombo.java ! test/tools/javac/annotations/repeatingAnnotations/combo/RetentionAnnoCombo.java ! test/tools/javac/diags/examples.not-yet.txt - test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java - test/tools/javac/diags/examples/ContainedByInheritedMismatch.java - test/tools/javac/diags/examples/ContainedByNoValue.java - test/tools/javac/diags/examples/ContainedByNonDefault.java - test/tools/javac/diags/examples/ContainedByRetentionMismatch.java - test/tools/javac/diags/examples/ContainedByTargetMismatch.java - test/tools/javac/diags/examples/ContainedByWrongValueType.java ! test/tools/javac/diags/examples/InvalidDuplicateAnnotation.java + test/tools/javac/diags/examples/RepeatableDocumentedMismatch.java + test/tools/javac/diags/examples/RepeatableInheritedMismatch.java + test/tools/javac/diags/examples/RepeatableNoValue.java + test/tools/javac/diags/examples/RepeatableNonDefault.java + test/tools/javac/diags/examples/RepeatableRetentionMismatch.java + test/tools/javac/diags/examples/RepeatableTargetMismatch.java + test/tools/javac/diags/examples/RepeatableWrongValueType.java ! test/tools/javac/diags/examples/RepeatingAnnotationAndContainer.java - test/tools/javac/diags/examples/WrongContainedBy.java - test/tools/javac/diags/examples/WrongContainerFor.java From bernd-2013 at eckenfels.net Mon Jan 14 14:00:52 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Mon, 14 Jan 2013 23:00:52 +0100 Subject: [8] Request for review: 8005414: Removing fix for JDK-6500133 In-Reply-To: <50F47E11.60109@oracle.com> References: <50F47AE9.6080300@oracle.com> <50F47E11.60109@oracle.com> Message-ID: Am 14.01.2013, 22:52 Uhr, schrieb Sean Mullan : > Looks good to me. The patch removes all unit tests for this class it seems. There should be one parseable URL and if you intent to reject illegal content you can use the test vectors to test for the expected exception. Gruss Bernd -- http://bernd.eckenfels.net From sean.mullan at oracle.com Mon Jan 14 14:18:47 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 14 Jan 2013 17:18:47 -0500 Subject: [8] Request for review: 8005414: Removing fix for JDK-6500133 In-Reply-To: References: <50F47AE9.6080300@oracle.com> <50F47E11.60109@oracle.com> Message-ID: <50F48447.5090800@oracle.com> On 01/14/2013 05:00 PM, Bernd Eckenfels wrote: > Am 14.01.2013, 22:52 Uhr, schrieb Sean Mullan : > >> Looks good to me. > > The patch removes all unit tests for this class it seems. There should be > one parseable URL and if you intent to reject illegal content you can use > the test vectors to test for the expected exception. Good point. Jason, can you keep the test but readjust to test for an expected exception? Thanks, Sean From jonathan.gibbons at oracle.com Mon Jan 14 14:18:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Jan 2013 22:18:40 +0000 Subject: hg: jdk8/tl/langtools: 8006241: Test DocRootSlash.java fails Message-ID: <20130114221844.D58714726C@hg.openjdk.java.net> Changeset: d54b4a091450 Author: jjg Date: 2013-01-14 14:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d54b4a091450 8006241: Test DocRootSlash.java fails Reviewed-by: darcy ! test/com/sun/javadoc/DocRootSlash/DocRootSlash.java From jason.uh at oracle.com Mon Jan 14 14:29:21 2013 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 14 Jan 2013 14:29:21 -0800 Subject: [8] Request for review: 8005414: Removing fix for JDK-6500133 In-Reply-To: <50F48447.5090800@oracle.com> References: <50F47AE9.6080300@oracle.com> <50F47E11.60109@oracle.com> <50F48447.5090800@oracle.com> Message-ID: <50F486C1.8050602@oracle.com> There used to be a unit test in the closed workspace for this case that was removed when the fix for 6500133 was introduced. That test and its certificate will be restored. Thanks, Jason On 01/14/2013 02:18 PM, Sean Mullan wrote: > On 01/14/2013 05:00 PM, Bernd Eckenfels wrote: >> Am 14.01.2013, 22:52 Uhr, schrieb Sean Mullan : >> >>> Looks good to me. >> >> The patch removes all unit tests for this class it seems. There should be >> one parseable URL and if you intent to reject illegal content you can use >> the test vectors to test for the expected exception. > > Good point. Jason, can you keep the test but readjust to test for an > expected exception? > > Thanks, > Sean From jason.uh at oracle.com Mon Jan 14 15:41:22 2013 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 14 Jan 2013 15:41:22 -0800 Subject: [8] Request for review: 8005414: Removing fix for JDK-6500133 In-Reply-To: <50F486C1.8050602@oracle.com> References: <50F47AE9.6080300@oracle.com> <50F47E11.60109@oracle.com> <50F48447.5090800@oracle.com> <50F486C1.8050602@oracle.com> Message-ID: <50F497A2.4090804@oracle.com> Thanks for your suggestions. I suppose there's no reason to restore the old test, so here's an updated webrev with my test adjusted for the new expected behavior: http://cr.openjdk.java.net/~juh/8005414/webrev.01/ Thanks, Jason On 01/14/2013 02:29 PM, Jason Uh wrote: > There used to be a unit test in the closed workspace for this case that > was removed when the fix for 6500133 was introduced. > > That test and its certificate will be restored. > > Thanks, > Jason > > On 01/14/2013 02:18 PM, Sean Mullan wrote: >> On 01/14/2013 05:00 PM, Bernd Eckenfels wrote: >>> Am 14.01.2013, 22:52 Uhr, schrieb Sean Mullan : >>> >>>> Looks good to me. >>> >>> The patch removes all unit tests for this class it seems. There >>> should be >>> one parseable URL and if you intent to reject illegal content you can >>> use >>> the test vectors to test for the expected exception. >> >> Good point. Jason, can you keep the test but readjust to test for an >> expected exception? >> >> Thanks, >> Sean From joel.franck at oracle.com Mon Jan 14 11:08:32 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Mon, 14 Jan 2013 19:08:32 +0000 Subject: hg: jdk8/tl/langtools: 7193719: Support repeating annotations in javax.lang.model Message-ID: <20130114190837.C51BE47261@hg.openjdk.java.net> Changeset: 9f42a06a49c0 Author: jfranck Date: 2013-01-14 19:52 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9f42a06a49c0 7193719: Support repeating annotations in javax.lang.model Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/model/JavacElements.java ! src/share/classes/javax/lang/model/element/Element.java From jason.uh at oracle.com Mon Jan 14 16:06:15 2013 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 14 Jan 2013 16:06:15 -0800 Subject: [8] Request for review: 8005414: Removing fix for JDK-6500133 In-Reply-To: <50F497A2.4090804@oracle.com> References: <50F47AE9.6080300@oracle.com> <50F47E11.60109@oracle.com> <50F48447.5090800@oracle.com> <50F486C1.8050602@oracle.com> <50F497A2.4090804@oracle.com> Message-ID: <50F49D77.8020305@oracle.com> Sorry, please refer to the following webrev instead: http://cr.openjdk.java.net/~juh/8005414/webrev.02/ (Removed @bug tag as this is no longer fixing 6500133). On 01/14/2013 03:41 PM, Jason Uh wrote: > Thanks for your suggestions. I suppose there's no reason to restore the > old test, so here's an updated webrev with my test adjusted for the new > expected behavior: > > http://cr.openjdk.java.net/~juh/8005414/webrev.01/ > > Thanks, > Jason > > On 01/14/2013 02:29 PM, Jason Uh wrote: >> There used to be a unit test in the closed workspace for this case that >> was removed when the fix for 6500133 was introduced. >> >> That test and its certificate will be restored. >> >> Thanks, >> Jason >> >> On 01/14/2013 02:18 PM, Sean Mullan wrote: >>> On 01/14/2013 05:00 PM, Bernd Eckenfels wrote: >>>> Am 14.01.2013, 22:52 Uhr, schrieb Sean Mullan : >>>> >>>>> Looks good to me. >>>> >>>> The patch removes all unit tests for this class it seems. There >>>> should be >>>> one parseable URL and if you intent to reject illegal content you can >>>> use >>>> the test vectors to test for the expected exception. >>> >>> Good point. Jason, can you keep the test but readjust to test for an >>> expected exception? >>> >>> Thanks, >>> Sean From kumar.x.srinivasan at oracle.com Mon Jan 14 16:23:10 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 15 Jan 2013 00:23:10 +0000 Subject: hg: jdk8/tl/jdk: 8005252: pack200 should support MethodParameters Message-ID: <20130115002332.5968147270@hg.openjdk.java.net> Changeset: dcb64d498d5b Author: ksrini Date: 2013-01-14 15:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dcb64d498d5b 8005252: pack200 should support MethodParameters Reviewed-by: jrose ! src/share/classes/com/sun/java/util/jar/pack/Attribute.java ! src/share/classes/com/sun/java/util/jar/pack/BandStructure.java ! src/share/classes/com/sun/java/util/jar/pack/Constants.java ! src/share/classes/com/sun/java/util/jar/pack/PackageReader.java ! src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java ! src/share/native/com/sun/java/util/jar/pack/bands.cpp ! src/share/native/com/sun/java/util/jar/pack/bands.h ! src/share/native/com/sun/java/util/jar/pack/constants.h ! src/share/native/com/sun/java/util/jar/pack/main.cpp ! src/share/native/com/sun/java/util/jar/pack/unpack.cpp ! test/ProblemList.txt ! test/tools/pack200/AttributeTests.java ! test/tools/pack200/pack200-verifier/src/xmlkit/ClassReader.java From jason.uh at oracle.com Mon Jan 14 18:01:23 2013 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 14 Jan 2013 18:01:23 -0800 Subject: [8] Request for review: sun/security/x509/{X509CRLImpl, X509CertImpl}/Verify.java fail in confusing way when some providers not present Message-ID: <50F4B873.5050503@oracle.com> This change allows the tests sun/security/x509/{X509CRLImpl,X509CertImpl}/Verify.java to fail with a more meaningful message when a provider is not found. Webrev: http://cr.openjdk.java.net/~juh/8005939/webrev.00/ Bug: http://bugs.sun.com/view_bug.do?bug_id=8005939 Thanks, Jason From jason.uh at oracle.com Mon Jan 14 18:05:54 2013 From: jason.uh at oracle.com (Jason Uh) Date: Mon, 14 Jan 2013 18:05:54 -0800 Subject: [8] Request for review: 8005939: sun/security/x509/{X509CRLImpl, X509CertImpl}/Verify.java fail in confusing way when some providers not present In-Reply-To: <50F4B873.5050503@oracle.com> References: <50F4B873.5050503@oracle.com> Message-ID: <50F4B982.2010008@oracle.com> (Resending with bug ID in the Subject.) This change allows the tests sun/security/x509/{X509CRLImpl,X509CertImpl}/Verify.java to fail with a more meaningful message when a provider is not found. Webrev: http://cr.openjdk.java.net/~juh/8005939/webrev.00/ Bug: http://bugs.sun.com/view_bug.do?bug_id=8005939 Thanks, Jason From xuelei.fan at oracle.com Mon Jan 14 18:13:06 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 15 Jan 2013 10:13:06 +0800 Subject: Code review request 8006265, Add test SSLEngineDeadlock.java to ProblemList Message-ID: <50F4BB32.7030705@oracle.com> webrev: http://cr.openjdk.java.net./~xuelei/8006265/webrev.00/ Occasionally, test case SSLEngineDeadlock.java timeout because of performance issue of testing itself, see [JDK-7144048]. Need to add this test to ProblemList. Xuelei [JDK-7144048]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144048 From weijun.wang at oracle.com Mon Jan 14 18:15:26 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 15 Jan 2013 10:15:26 +0800 Subject: [8] Request for review: 8005939: sun/security/x509/{X509CRLImpl, X509CertImpl}/Verify.java fail in confusing way when some providers not present In-Reply-To: <50F4B982.2010008@oracle.com> References: <50F4B873.5050503@oracle.com> <50F4B982.2010008@oracle.com> Message-ID: <50F4BBBE.2010207@oracle.com> Hi Jason The code change looks good. I suppose you mean "smaller profiles" in the first line of the bug description? Thanks Max On 01/15/2013 10:05 AM, Jason Uh wrote: > (Resending with bug ID in the Subject.) > > This change allows the tests > sun/security/x509/{X509CRLImpl,X509CertImpl}/Verify.java > to fail with a more meaningful message when a provider is not found. > > Webrev: http://cr.openjdk.java.net/~juh/8005939/webrev.00/ > Bug: http://bugs.sun.com/view_bug.do?bug_id=8005939 > > Thanks, > Jason From weijun.wang at oracle.com Mon Jan 14 18:17:20 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 15 Jan 2013 10:17:20 +0800 Subject: Code review request 8006265, Add test SSLEngineDeadlock.java to ProblemList In-Reply-To: <50F4BB32.7030705@oracle.com> References: <50F4BB32.7030705@oracle.com> Message-ID: <50F4BC30.6060205@oracle.com> Good. Hopefully the test can be liberated soon. :) Thanks Max On 01/15/2013 10:13 AM, Xuelei Fan wrote: > webrev: http://cr.openjdk.java.net./~xuelei/8006265/webrev.00/ > > Occasionally, test case SSLEngineDeadlock.java timeout because of > performance issue of testing itself, see [JDK-7144048]. Need to add > this test to ProblemList. > > Xuelei > > [JDK-7144048]: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7144048 > From xuelei.fan at oracle.com Mon Jan 14 18:32:53 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 15 Jan 2013 02:32:53 +0000 Subject: hg: jdk8/tl/jdk: 8006265: Add test SSLEngineDeadlock.java to ProblemList Message-ID: <20130115023314.1F84047277@hg.openjdk.java.net> Changeset: edb7e34a0531 Author: xuelei Date: 2013-01-14 18:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/edb7e34a0531 8006265: Add test SSLEngineDeadlock.java to ProblemList Reviewed-by: weijun ! test/ProblemList.txt From chris.hegarty at oracle.com Tue Jan 15 03:45:16 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Jan 2013 11:45:16 +0000 Subject: hg: jdk8/tl/jdk: 8005406: HTTP server implementation should use Base64 API Message-ID: <20130115114538.593DD4728A@hg.openjdk.java.net> Changeset: 4b012af44f24 Author: chegar Date: 2013-01-15 11:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b012af44f24 8005406: HTTP server implementation should use Base64 API Reviewed-by: khazra, alanb, chegar Contributed-by: Mark Sheppard ! src/share/classes/com/sun/net/httpserver/BasicAuthenticator.java ! src/share/classes/sun/net/www/protocol/http/BasicAuthentication.java From sean.mullan at oracle.com Tue Jan 15 07:56:33 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Jan 2013 10:56:33 -0500 Subject: [8] Request for review: 8005939: sun/security/x509/{X509CRLImpl, X509CertImpl}/Verify.java fail in confusing way when some providers not present In-Reply-To: <50F4B982.2010008@oracle.com> References: <50F4B873.5050503@oracle.com> <50F4B982.2010008@oracle.com> Message-ID: <50F57C31.4050407@oracle.com> Hi Jason, This looks good. I also recommending changing this line: 98 verifyCRL(crlIssuerCertPubKey, "SunPCSC"); to a provider that is always going to exist in one of the smaller profiles, but also doesn't have a Signature implementation, for example: 98 verifyCRL(crlIssuerCertPubKey, "SunJCE"); This would allow the test to pass on the compact1/2 profiles. --Sean On 01/14/2013 09:05 PM, Jason Uh wrote: > (Resending with bug ID in the Subject.) > > This change allows the tests > sun/security/x509/{X509CRLImpl,X509CertImpl}/Verify.java > to fail with a more meaningful message when a provider is not found. > > Webrev: http://cr.openjdk.java.net/~juh/8005939/webrev.00/ > Bug: http://bugs.sun.com/view_bug.do?bug_id=8005939 > > Thanks, > Jason From jason.uh at oracle.com Tue Jan 15 10:21:35 2013 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 15 Jan 2013 10:21:35 -0800 Subject: [8] Request for review: 8005939: sun/security/x509/{X509CRLImpl, X509CertImpl}/Verify.java fail in confusing way when some providers not present In-Reply-To: <50F4BBBE.2010207@oracle.com> References: <50F4B873.5050503@oracle.com> <50F4B982.2010008@oracle.com> <50F4BBBE.2010207@oracle.com> Message-ID: <50F59E2F.7070205@oracle.com> Thanks, Max. I didn't write that description, but I'll change it. Jason On 01/14/2013 06:15 PM, Weijun Wang wrote: > Hi Jason > > The code change looks good. > > I suppose you mean "smaller profiles" in the first line of the bug > description? > > Thanks > Max > > On 01/15/2013 10:05 AM, Jason Uh wrote: >> (Resending with bug ID in the Subject.) >> >> This change allows the tests >> sun/security/x509/{X509CRLImpl,X509CertImpl}/Verify.java >> to fail with a more meaningful message when a provider is not found. >> >> Webrev: http://cr.openjdk.java.net/~juh/8005939/webrev.00/ >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8005939 >> >> Thanks, >> Jason From jason.uh at oracle.com Tue Jan 15 10:25:20 2013 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 15 Jan 2013 10:25:20 -0800 Subject: [8] Request for review: 8005939: sun/security/x509/{X509CRLImpl, X509CertImpl}/Verify.java fail in confusing way when some providers not present In-Reply-To: <50F57C31.4050407@oracle.com> References: <50F4B873.5050503@oracle.com> <50F4B982.2010008@oracle.com> <50F57C31.4050407@oracle.com> Message-ID: <50F59F10.3020009@oracle.com> Thanks, Sean. For clarification, you're recommending SunJCE for verifying both the CRL and the Cert? On 01/15/2013 07:56 AM, Sean Mullan wrote: > Hi Jason,nk > > This looks good. I also recommending changing this line: > > 98 verifyCRL(crlIssuerCertPubKey, "SunPCSC"); > > to a provider that is always going to exist in one of the smaller > profiles, but also doesn't have a Signature implementation, for example: > > > 98 verifyCRL(crlIssuerCertPubKey, "SunJCE"); > > This would allow the test to pass on the compact1/2 profiles. > > --Sean > > On 01/14/2013 09:05 PM, Jason Uh wrote: >> (Resending with bug ID in the Subject.) >> >> This change allows the tests >> sun/security/x509/{X509CRLImpl,X509CertImpl}/Verify.java >> to fail with a more meaningful message when a provider is not found. >> >> Webrev: http://cr.openjdk.java.net/~juh/8005939/webrev.00/ >> Bug: http://bugs.sun.com/view_bug.do?bug_id=8005939 >> >> Thanks, >> Jason > From sean.mullan at oracle.com Tue Jan 15 10:26:23 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Jan 2013 13:26:23 -0500 Subject: [8] Request for review: 8005939: sun/security/x509/{X509CRLImpl, X509CertImpl}/Verify.java fail in confusing way when some providers not present In-Reply-To: <50F59F10.3020009@oracle.com> References: <50F4B873.5050503@oracle.com> <50F4B982.2010008@oracle.com> <50F57C31.4050407@oracle.com> <50F59F10.3020009@oracle.com> Message-ID: <50F59F4F.9050303@oracle.com> On 01/15/2013 01:25 PM, Jason Uh wrote: > Thanks, Sean. For clarification, you're recommending SunJCE for > verifying both the CRL and the Cert? Yes. --Sean > > On 01/15/2013 07:56 AM, Sean Mullan wrote: >> Hi Jason,nk >> >> This looks good. I also recommending changing this line: >> >> 98 verifyCRL(crlIssuerCertPubKey, "SunPCSC"); >> >> to a provider that is always going to exist in one of the smaller >> profiles, but also doesn't have a Signature implementation, for example: >> >> >> 98 verifyCRL(crlIssuerCertPubKey, "SunJCE"); >> >> This would allow the test to pass on the compact1/2 profiles. >> >> --Sean >> >> On 01/14/2013 09:05 PM, Jason Uh wrote: >>> (Resending with bug ID in the Subject.) >>> >>> This change allows the tests >>> sun/security/x509/{X509CRLImpl,X509CertImpl}/Verify.java >>> to fail with a more meaningful message when a provider is not found. >>> >>> Webrev: http://cr.openjdk.java.net/~juh/8005939/webrev.00/ >>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8005939 >>> >>> Thanks, >>> Jason >> From jason.uh at oracle.com Tue Jan 15 11:41:57 2013 From: jason.uh at oracle.com (Jason Uh) Date: Tue, 15 Jan 2013 11:41:57 -0800 Subject: [8] Request for review: 8005939: sun/security/x509/{X509CRLImpl, X509CertImpl}/Verify.java fail in confusing way when some providers not present In-Reply-To: <50F59F4F.9050303@oracle.com> References: <50F4B873.5050503@oracle.com> <50F4B982.2010008@oracle.com> <50F57C31.4050407@oracle.com> <50F59F10.3020009@oracle.com> <50F59F4F.9050303@oracle.com> Message-ID: <50F5B105.5010208@oracle.com> Updated to use SunJCE for verification: http://cr.openjdk.java.net/~juh/8005939/webrev.01/ On 01/15/2013 10:26 AM, Sean Mullan wrote: > On 01/15/2013 01:25 PM, Jason Uh wrote: >> Thanks, Sean. For clarification, you're recommending SunJCE for >> verifying both the CRL and the Cert? > > Yes. > > --Sean > >> >> On 01/15/2013 07:56 AM, Sean Mullan wrote: >>> Hi Jason,nk >>> >>> This looks good. I also recommending changing this line: >>> >>> 98 verifyCRL(crlIssuerCertPubKey, "SunPCSC"); >>> >>> to a provider that is always going to exist in one of the smaller >>> profiles, but also doesn't have a Signature implementation, for example: >>> >>> >>> 98 verifyCRL(crlIssuerCertPubKey, "SunJCE"); >>> >>> This would allow the test to pass on the compact1/2 profiles. >>> >>> --Sean >>> >>> On 01/14/2013 09:05 PM, Jason Uh wrote: >>>> (Resending with bug ID in the Subject.) >>>> >>>> This change allows the tests >>>> sun/security/x509/{X509CRLImpl,X509CertImpl}/Verify.java >>>> to fail with a more meaningful message when a provider is not found. >>>> >>>> Webrev: http://cr.openjdk.java.net/~juh/8005939/webrev.00/ >>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8005939 >>>> >>>> Thanks, >>>> Jason >>> > From rob.mckenna at oracle.com Tue Jan 15 11:55:10 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 15 Jan 2013 19:55:10 +0000 Subject: hg: jdk8/tl/jdk: 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Message-ID: <20130115195533.BCBF9472A8@hg.openjdk.java.net> Changeset: 44d6cabc9a3f Author: robm Date: 2013-01-15 19:58 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/44d6cabc9a3f 8005618: TEST_BUG: java/lang/ProcessBuilder/Basic.java failing intermittently Reviewed-by: alanb, martin, dholmes ! test/java/lang/ProcessBuilder/Basic.java From sean.mullan at oracle.com Tue Jan 15 12:10:58 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 15 Jan 2013 15:10:58 -0500 Subject: [8] Request for review: 8005414: Removing fix for JDK-6500133 In-Reply-To: <50F49D77.8020305@oracle.com> References: <50F47AE9.6080300@oracle.com> <50F47E11.60109@oracle.com> <50F48447.5090800@oracle.com> <50F486C1.8050602@oracle.com> <50F497A2.4090804@oracle.com> <50F49D77.8020305@oracle.com> Message-ID: <50F5B7D2.8000709@oracle.com> Looks fine to me. I can push it for you. --Sean On 01/14/2013 07:06 PM, Jason Uh wrote: > Sorry, please refer to the following webrev instead: > http://cr.openjdk.java.net/~juh/8005414/webrev.02/ (Removed @bug tag as > this is no longer fixing 6500133). > > On 01/14/2013 03:41 PM, Jason Uh wrote: >> Thanks for your suggestions. I suppose there's no reason to restore the >> old test, so here's an updated webrev with my test adjusted for the new >> expected behavior: >> >> http://cr.openjdk.java.net/~juh/8005414/webrev.01/ >> >> Thanks, >> Jason >> >> On 01/14/2013 02:29 PM, Jason Uh wrote: >>> There used to be a unit test in the closed workspace for this case that >>> was removed when the fix for 6500133 was introduced. >>> >>> That test and its certificate will be restored. >>> >>> Thanks, >>> Jason >>> >>> On 01/14/2013 02:18 PM, Sean Mullan wrote: >>>> On 01/14/2013 05:00 PM, Bernd Eckenfels wrote: >>>>> Am 14.01.2013, 22:52 Uhr, schrieb Sean Mullan >>>>> : >>>>> >>>>>> Looks good to me. >>>>> >>>>> The patch removes all unit tests for this class it seems. There >>>>> should be >>>>> one parseable URL and if you intent to reject illegal content you can >>>>> use >>>>> the test vectors to test for the expected exception. >>>> >>>> Good point. Jason, can you keep the test but readjust to test for an >>>> expected exception? >>>> >>>> Thanks, >>>> Sean From alexey.utkin at oracle.com Tue Jan 15 02:30:36 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Tue, 15 Jan 2013 10:30:36 +0000 Subject: hg: jdk8/tl/jdk: 8005250: Downgrade normative references to ${java.home}/lib folder from Java client code. Message-ID: <20130115103109.B66EE47285@hg.openjdk.java.net> Changeset: a40052a54801 Author: uta Date: 2013-01-15 14:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a40052a54801 8005250: Downgrade normative references to ${java.home}/lib folder from Java client code. Summary: Javadoc was changed in accordance with CCC-8005250 request. Reviewed-by: alanb, amenkov ! src/share/classes/java/awt/datatransfer/SystemFlavorMap.java ! src/share/classes/javax/imageio/spi/IIORegistry.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/swing/UIManager.java From chris.hegarty at oracle.com Tue Jan 15 12:39:40 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 15 Jan 2013 20:39:40 +0000 Subject: hg: jdk8/tl/langtools: 8006344: Broken javadoc link in javax.lang.model.element.Element Message-ID: <20130115203945.DD1AC472AC@hg.openjdk.java.net> Changeset: f805b5e3c9d1 Author: chegar Date: 2013-01-15 20:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f805b5e3c9d1 8006344: Broken javadoc link in javax.lang.model.element.Element Reviewed-by: lancea, alanb, jfranck ! src/share/classes/javax/lang/model/element/Element.java From bernd-2013 at eckenfels.net Tue Jan 15 13:00:31 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Tue, 15 Jan 2013 22:00:31 +0100 Subject: SSLSocketImpl and Handshake Notifier efficiency/thread pooling Message-ID: Hello, (Line numbers are relative to: http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/733885f57e14/src/share/classes/sun/security/ssl/SSLSocketImpl.java ) while investigating the DOS resilience of SSLSocket with the Sun JSSE Implementation (see other mail) I found out, that the SSLSocketImpl implementation uses a pretty simple method to dispatch SSL handshake events: - every time a handshake happens and one or more listeners are registered there will be a HandshakeCompletedEvent object (and a few more data structures cloned) created (I guess thats unavodable) - there will be a new Thread(!) (subclass of NotifyHandshakeThread) created and started (Line 1081) - the Map of Listeners will be cloned, which results in a new HashSet and all of its supporting classes, even when it will not be used as HashMap and only be used to operate over the Entries. Using a Listener[] and AccessContext[] array might be more efficient. Having a Handshake Listener is most often used for counter measurements or statistics related to overload situations. So it is quite counter productive to start a new Thread (and finalize it at the end) on every handshake with unlimited parallelism. This with also limit the scalability of SocketServers as it consumes additional handles/threads on each initial handshake (aka connect). The starting of the Thread is decoupling the Listener from the protocol engine in terms of waiting and security context. But I think in most cases this is not really needed as the Listener is doing very lightweight work (for example a .notify() or a incrementCounter(), which all would be less intrusive than starting a native thread. It is also not possible to name the Thread or control its priority or concurrency. They are started directly under the will of a external client (SSL renegotiation). So I have a few suggestions/questions: a) allow a Executor to be set on the context or socket factory (with default implementation using a cached thread pool executor). This would even allow to use the lightweight DirectExecutir if listeners are known to be well behaved and nonblocking b) instead of copying the Entry set of the Listener/Context Tuples use a Array (less objects and faster iteration speed) (Line 2574 and Line 2581) c) it might be possible to add the Runnable Interface to the created HandshakeEvent, this would reduce even more object allocations (probably not worth the change) If it is not possible to configure/register the executor (because of the Security Manager or complexity) at least using by default a cached ThreadExecutor will reduce system load and increase robustness in overload situations. Greetings Bernd BTW: I also noticed that the SSLSocketImpl is full of System.out for the Security Debugging (categroy "ssl") and not using the Debug.println() Method. -- http://bernd.eckenfels.net From jonathan.gibbons at oracle.com Tue Jan 15 13:03:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 15 Jan 2013 21:03:40 +0000 Subject: hg: jdk8/tl/langtools: 8006224: Doclint NPE for attribute with no value Message-ID: <20130115210343.8C6AC472AE@hg.openjdk.java.net> Changeset: bc1023e0e533 Author: jjg Date: 2013-01-15 13:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bc1023e0e533 8006224: Doclint NPE for attribute with no value Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/AnchorTest.java + test/tools/doclint/AnchorTest.out From xuelei.fan at oracle.com Tue Jan 15 20:04:36 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 16 Jan 2013 12:04:36 +0800 Subject: SSLSocketImpl and Handshake Notifier efficiency/thread pooling In-Reply-To: References: Message-ID: <50F626D4.5030101@oracle.com> Hi Bernd, I agree with you that create new threads in SSLSocket implementation is not good. The application is the better place to decide what's the right thread model. For the same reason, using Executor in SSLSocket implementation might not be an option from my understanding. Some applications may not want to pay for the additional performance cost of Executor. The HashSet clone should be pretty fast. A kind of "copy" of listeners is necessary here, otherwise, need to consider more about the synchronization between the update (add/remove) and use of the listeners. > c) it might be possible to add the Runnable Interface to the created > HandshakeEvent, this would reduce even more object allocations > (probably not worth the change) I'm not sure I understand the suggestion. Why it is helpful to reduce objects allocations? Can you show some examples? Thanks & Regards, Xuelei On 1/16/2013 5:00 AM, Bernd Eckenfels wrote: > Hello, > > (Line numbers are relative to: > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/733885f57e14/src/share/classes/sun/security/ssl/SSLSocketImpl.java > ) > > while investigating the DOS resilience of SSLSocket with the Sun JSSE > Implementation (see other mail) I found out, that the SSLSocketImpl > implementation uses a pretty simple method to dispatch SSL handshake > events: > > - every time a handshake happens and one or more listeners are > registered there will be a HandshakeCompletedEvent object (and a few > more data structures cloned) created (I guess thats unavodable) > > - there will be a new Thread(!) (subclass of NotifyHandshakeThread) > created and started (Line 1081) > > - the Map of Listeners will be cloned, which results in a new HashSet > and all of its supporting classes, even when it will not be used as > HashMap and only be used to operate over the Entries. Using a Listener[] > and AccessContext[] array might be more efficient. > > > Having a Handshake Listener is most often used for counter measurements > or statistics related to overload situations. So it is quite counter > productive to start a new Thread (and finalize it at the end) on every > handshake with unlimited parallelism. This with also limit the > scalability of SocketServers as it consumes additional handles/threads > on each initial handshake (aka connect). > > The starting of the Thread is decoupling the Listener from the protocol > engine in terms of waiting and security context. But I think in most > cases this is not really needed as the Listener is doing very > lightweight work (for example a .notify() or a incrementCounter(), which > all would be less intrusive than starting a native thread. It is also > not possible to name the Thread or control its priority or concurrency. > They are started directly under the will of a external client (SSL > renegotiation). > > > So I have a few suggestions/questions: > > > > a) allow a Executor to be set on the context or socket factory (with > default implementation using a cached thread pool executor). This would > even allow to use the lightweight DirectExecutir if listeners are known > to be well behaved and nonblocking > > b) instead of copying the Entry set of the Listener/Context Tuples use a > Array (less objects and faster iteration speed) (Line 2574 and Line 2581) > > c) it might be possible to add the Runnable Interface to the created > HandshakeEvent, this would reduce even more object allocations (probably > not worth the change) > > If it is not possible to configure/register the executor (because of the > Security Manager or complexity) at least using by default a cached > ThreadExecutor will reduce system load and increase robustness in > overload situations. > > Greetings > Bernd > > > BTW: I also noticed that the SSLSocketImpl is full of System.out for the > Security Debugging (categroy "ssl") and not using the Debug.println() > Method. From stephen.flores at oracle.com Tue Jan 15 20:46:01 2013 From: stephen.flores at oracle.com (Stephen Flores) Date: Tue, 15 Jan 2013 23:46:01 -0500 Subject: 7194075: Various classes of sunec.jar are duplicated in rt.jar In-Reply-To: <50D25A80.3010009@oracle.com> References: <50B431A3.3080808@oracle.com> <50B7A020.1050609@oracle.com> <50D25A80.3010009@oracle.com> Message-ID: <50F63089.2090703@oracle.com> Sean, Here are the changes for the final version (as outlined in my comments below): http://cr.openjdk.java.net/~sflores/7194075/webrev-2/ Steve. On 12/19/2012 07:23 PM, Stephen Flores wrote: > Sorry, for the delayed response, I have been working in another area. > > Comments below: > > On 11/29/2012 12:49 PM, Sean Mullan wrote: >> Hi Steve, >> >> Most of this looks good. Here are my comments: >> >> * General >> >> You haven't added any new regression tests for this. Since this is >> essentially a lot of code refactoring and covered by existing tests, can >> you add the noreg-cleanup keyword to the bug? >> > > When I figure out the new bug system, will do this. > >> * src/share/classes/java/security/AlgorithmParameters.java >> >> [394] You can't make this change, since it would violate the spec which >> says it returns null. You will need to workaround this some other way. >> > > I will revert the change. > >> * src/share/classes/sun/security/ec/ECDSASignature.java >> >> [278, 305] The comment should be aligned to the left. >> > > OK > >> * src/share/classes/sun/security/pkcs11/P11ECKeyFactory.java >> >> [121-2] The exception message here seems misleading, since it doesn't >> have to be an instance of ECPublicKey, it could just be a PublicKey as >> long as the encoding is correct. Why not just set the cause to the >> InvalidKeySpecException, ex: >> > > OK, I will change the code to use the InvalidKeySpecException from the > key factory to create a InvalidKeyException. > > Sorry, I keep forgetting about the cause constructor on exceptions, > because for 8 years while working on J2ME MIDP I did not have cause > constructor on exceptions or the getCause method. > >> What exception message did the old code throw? It might be best to >> preserve that behavior. >> >> [151-2] same comment as above >> > > OK > >> * src/share/classes/sun/security/util/ECUtil.java >> >> [230-60] Can you add a comment as to why this is commented out? >> > > I will remove it. > > Steve. > >> --Sean >> >> On 11/26/2012 10:21 PM, Stephen Flores wrote: >>> Vincent, Sean, >>> >>> Please review the fix for: >>> >>> CR 7194075: Various classes of sunec.jar are duplicated in rt.jar >>> >>> http://cr.openjdk.java.net/~sflores/7194075/webrev-1/ >>> >>> Changes: >>> >>> *Changed/renamed any of methods that did not support the public API to >>> package private. >>> >>> *Moved the decode and encode point methods out of ECParameters to a new >>> class sun.security.util.ECUtil. >>> >>> *Changed any "new byte[], System.arraycopy" blocks in ECUtil point >>> methods to Arrays.copyOfRange. >>> >>> *Added a new AlgorithmParameterSpec in sun.security.util to get curves >>> by key size, for PKCS11 to use. >>> >>> *Moved all of static lookup methods in ECParameters, NamedCurve and the >>> curve repository to separate class (CurveDB). This made ECParameters and >>> NamedCurve cleaner and easier work on (there was some ECParameters >>> cleanup. >>> >>> *In JSSE and PKCS11 and changed the references to ECParmeters and >>> NamedCurve to the ECUtil which has utility methods that use the public >>> APIs. >>> >>> *Changed to the EC unit test to use the list of supported curves in the >>> property that the SunEC provider has already. >>> >>> *Changed SunECEntries to build the list of supported curves property >>> from the collection in CurveDB. >>> >>> *Changed the JDK makefiles to not duplicate EC classes in rt.jar. >>> >>> Thanks, >>> >>> Steve. >> From chris.hegarty at oracle.com Wed Jan 16 02:15:50 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 16 Jan 2013 10:15:50 +0000 Subject: hg: jdk8/tl/jdk: 8005926: Merge ThreadLocalRandom state into java.lang.Thread Message-ID: <20130116101618.3DE0A472D5@hg.openjdk.java.net> Changeset: 9d8ef6174cfd Author: dl Date: 2013-01-16 10:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d8ef6174cfd 8005926: Merge ThreadLocalRandom state into java.lang.Thread Reviewed-by: shade, chegar ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java From chris.hegarty at oracle.com Wed Jan 16 04:11:13 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 16 Jan 2013 12:11:13 +0000 Subject: hg: jdk8/tl/jdk: 8001666: Add lambda-compatible atomics and accumulators to the ActomicXXX classes Message-ID: <20130116121134.C9446472DD@hg.openjdk.java.net> Changeset: a546d8897e0d Author: dl Date: 2013-01-16 12:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a546d8897e0d 8001666: Add lambda-compatible atomics and accumulators to the ActomicXXX classes Reviewed-by: dl, chegar, darcy, goetz Contributed-by: dl at cs.oswego.edu, chris.hegarty at oracle.com ! src/share/classes/java/util/concurrent/atomic/AtomicInteger.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicLong.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicLongFieldUpdater.java ! src/share/classes/java/util/concurrent/atomic/AtomicReference.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java ! src/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java From sean.mullan at oracle.com Wed Jan 16 06:58:18 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 16 Jan 2013 14:58:18 +0000 Subject: hg: jdk8/tl/jdk: 8005389: Backout fix for JDK-6500133 Message-ID: <20130116145924.3ACC0472E6@hg.openjdk.java.net> Changeset: c7d54f93d3e5 Author: juh Date: 2013-01-16 09:51 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c7d54f93d3e5 8005389: Backout fix for JDK-6500133 Reviewed-by: mullan ! src/share/classes/sun/security/x509/URIName.java ! test/sun/security/x509/URIName/Parse.java From maurizio.cimadamore at oracle.com Wed Jan 16 09:02:04 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 16 Jan 2013 17:02:04 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130116170224.B6AB5472ED@hg.openjdk.java.net> Changeset: f785dcac17b7 Author: mcimadamore Date: 2013-01-16 16:27 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f785dcac17b7 8005854: Add support for array constructor references Summary: Support constructor references of the kind int[]::new Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java + test/tools/javac/lambda/MethodReference59.java + test/tools/javac/lambda/MethodReference60.java + test/tools/javac/lambda/MethodReference60.out Changeset: 7aa2025bbb7b Author: mcimadamore Date: 2013-01-16 16:30 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7aa2025bbb7b 8005299: Add FunctionalInterface checking to javac Summary: Javac should check that types annotated with @FunctionalInterface are indeed functional interfaces Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/RichDiagnosticFormatter.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/BadFunctionalIntfAnno.java ! test/tools/javac/lambda/BadConv03.out ! test/tools/javac/lambda/BadLambdaPos.out ! test/tools/javac/lambda/BadTargetType.out + test/tools/javac/lambda/FunctionalInterfaceAnno.java + test/tools/javac/lambda/FunctionalInterfaceAnno.out ! test/tools/javac/lambda/Intersection01.out ! test/tools/javac/lambda/LambdaConv09.out ! test/tools/javac/lambda/LambdaExpr10.out ! test/tools/javac/lambda/MethodReference04.out ! test/tools/javac/lambda/TargetType17.out ! test/tools/javac/lambda/TargetType43.out ! test/tools/javac/lambda/funcInterfaces/LambdaTest2_neg1.out ! test/tools/javac/lambda/funcInterfaces/NonSAM1.out ! test/tools/javac/lambda/funcInterfaces/NonSAM3.out ! test/tools/javac/lambda/lambdaExpression/AbstractClass_neg.out ! test/tools/javac/lambda/lambdaExpression/InvalidExpression5.out From maurizio.cimadamore at oracle.com Wed Jan 16 09:41:11 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 16 Jan 2013 17:41:11 +0000 Subject: hg: jdk8/tl/langtools: 8005964: Regression: difference in error recovery after ambiguity causes JCK test failure Message-ID: <20130116174116.E1FA4472FA@hg.openjdk.java.net> Changeset: 1afdf1f1472b Author: mcimadamore Date: 2013-01-16 17:40 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1afdf1f1472b 8005964: Regression: difference in error recovery after ambiguity causes JCK test failure Summary: Wrong implementation of ResolveError.access in AmbiguityError Reviewed-by: jjh ! src/share/classes/com/sun/tools/javac/comp/Resolve.java From jonathan.gibbons at oracle.com Wed Jan 16 10:30:26 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 16 Jan 2013 18:30:26 +0000 Subject: hg: jdk8/tl/langtools: 8006236: doclint: structural issue hidden Message-ID: <20130116183032.359CA472FD@hg.openjdk.java.net> Changeset: 6b6311a8c9cc Author: jjg Date: 2013-01-16 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6b6311a8c9cc 8006236: doclint: structural issue hidden Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java + test/tools/doclint/EndTagsTest.java + test/tools/doclint/EndTagsTest.out From sean.mullan at oracle.com Wed Jan 16 10:31:20 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 16 Jan 2013 13:31:20 -0500 Subject: [8] Request for review: 8005939: sun/security/x509/{X509CRLImpl, X509CertImpl}/Verify.java fail in confusing way when some providers not present In-Reply-To: <50F5B105.5010208@oracle.com> References: <50F4B873.5050503@oracle.com> <50F4B982.2010008@oracle.com> <50F57C31.4050407@oracle.com> <50F59F10.3020009@oracle.com> <50F59F4F.9050303@oracle.com> <50F5B105.5010208@oracle.com> Message-ID: <50F6F1F8.7020707@oracle.com> Looks good, I will push it for you. Can you add the noreg-self label to the bug since this is a fix to a regression test? Thanks, Sean On 01/15/2013 02:41 PM, Jason Uh wrote: > Updated to use SunJCE for verification: > http://cr.openjdk.java.net/~juh/8005939/webrev.01/ > > On 01/15/2013 10:26 AM, Sean Mullan wrote: >> On 01/15/2013 01:25 PM, Jason Uh wrote: >>> Thanks, Sean. For clarification, you're recommending SunJCE for >>> verifying both the CRL and the Cert? >> >> Yes. >> >> --Sean >> >>> >>> On 01/15/2013 07:56 AM, Sean Mullan wrote: >>>> Hi Jason,nk >>>> >>>> This looks good. I also recommending changing this line: >>>> >>>> 98 verifyCRL(crlIssuerCertPubKey, "SunPCSC"); >>>> >>>> to a provider that is always going to exist in one of the smaller >>>> profiles, but also doesn't have a Signature implementation, for >>>> example: >>>> >>>> >>>> 98 verifyCRL(crlIssuerCertPubKey, "SunJCE"); >>>> >>>> This would allow the test to pass on the compact1/2 profiles. >>>> >>>> --Sean >>>> >>>> On 01/14/2013 09:05 PM, Jason Uh wrote: >>>>> (Resending with bug ID in the Subject.) >>>>> >>>>> This change allows the tests >>>>> sun/security/x509/{X509CRLImpl,X509CertImpl}/Verify.java >>>>> to fail with a more meaningful message when a provider is not found. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~juh/8005939/webrev.00/ >>>>> Bug: http://bugs.sun.com/view_bug.do?bug_id=8005939 >>>>> >>>>> Thanks, >>>>> Jason >>>> >> From sean.mullan at oracle.com Wed Jan 16 10:37:08 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Wed, 16 Jan 2013 18:37:08 +0000 Subject: hg: jdk8/tl/jdk: 8005939: sun/security/x509/{X509CRLImplX509CertImpl}/Verify.java fail in confusing way when some providers not present Message-ID: <20130116183729.875AE472FE@hg.openjdk.java.net> Changeset: f7f77bdf248b Author: juh Date: 2013-01-16 13:35 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f7f77bdf248b 8005939: sun/security/x509/{X509CRLImplX509CertImpl}/Verify.java fail in confusing way when some providers not present Reviewed-by: mullan, weijun ! test/sun/security/x509/X509CRLImpl/Verify.java ! test/sun/security/x509/X509CertImpl/Verify.java From lana.steuck at oracle.com Wed Jan 16 13:18:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:01 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130116211804.8921F4730F@hg.openjdk.java.net> Changeset: cb40427f4714 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cb40427f4714 Added tag jdk8-b71 for changeset 8171d23e914d ! .hgtags Changeset: 191afde59e7b Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/191afde59e7b Added tag jdk8-b72 for changeset cb40427f4714 ! .hgtags From lana.steuck at oracle.com Wed Jan 16 13:18:06 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:06 +0000 Subject: hg: jdk8/tl/jaxp: 3 new changesets Message-ID: <20130116211821.E15BF47311@hg.openjdk.java.net> Changeset: bdf2af722a6b Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/bdf2af722a6b Added tag jdk8-b71 for changeset 499be952a291 ! .hgtags Changeset: 84946404d1e1 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/84946404d1e1 Added tag jdk8-b72 for changeset bdf2af722a6b ! .hgtags Changeset: 06827097cdd3 Author: lana Date: 2013-01-16 12:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/06827097cdd3 Merge From lana.steuck at oracle.com Wed Jan 16 13:18:09 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:09 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130116211825.1256547312@hg.openjdk.java.net> Changeset: 6f0986ed9b7e Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6f0986ed9b7e Added tag jdk8-b71 for changeset 467e4d9281bc ! .hgtags Changeset: 45fed5cfd1c3 Author: katleman Date: 2013-01-10 09:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/45fed5cfd1c3 Added tag jdk8-b72 for changeset 6f0986ed9b7e ! .hgtags Changeset: 8d0baee36c71 Author: lana Date: 2013-01-10 15:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8d0baee36c71 Merge Changeset: 63b20bde7cd6 Author: lana Date: 2013-01-16 12:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/63b20bde7cd6 Merge From lana.steuck at oracle.com Wed Jan 16 13:18:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:01 +0000 Subject: hg: jdk8/tl: 4 new changesets Message-ID: <20130116211801.EC7084730E@hg.openjdk.java.net> Changeset: c1be681d80a1 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c1be681d80a1 Added tag jdk8-b71 for changeset 51ad2a343420 ! .hgtags Changeset: f03f90a4308d Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f03f90a4308d Added tag jdk8-b72 for changeset c1be681d80a1 ! .hgtags Changeset: 93b9664f97ee Author: lana Date: 2013-01-10 15:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/93b9664f97ee Merge Changeset: cecfba251e4a Author: lana Date: 2013-01-16 11:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cecfba251e4a Merge From lana.steuck at oracle.com Wed Jan 16 13:18:03 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:03 +0000 Subject: hg: jdk8/tl/jaxws: 2 new changesets Message-ID: <20130116211813.6617747310@hg.openjdk.java.net> Changeset: d9707230294d Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d9707230294d Added tag jdk8-b71 for changeset f577a39c9fb3 ! .hgtags Changeset: c606f644a5d9 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/c606f644a5d9 Added tag jdk8-b72 for changeset d9707230294d ! .hgtags From lana.steuck at oracle.com Wed Jan 16 13:18:27 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:27 +0000 Subject: hg: jdk8/tl/hotspot: 39 new changesets Message-ID: <20130116211948.11B1547313@hg.openjdk.java.net> Changeset: d5cb5830f570 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d5cb5830f570 Added tag jdk8-b71 for changeset 0847210f8548 ! .hgtags Changeset: 11619f33cd68 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11619f33cd68 Added tag jdk8-b72 for changeset d5cb5830f570 ! .hgtags Changeset: cd962e15c08e Author: amurillo Date: 2012-12-21 10:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd962e15c08e 8005382: new hotspot build - hs25-b15 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e51c9860cf66 Author: jmasa Date: 2012-12-03 15:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e51c9860cf66 8005082: NPG: Add specialized Metachunk sizes for reflection and anonymous classloaders Reviewed-by: johnc, coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/binaryTreeDictionary.cpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/metachunk.cpp ! src/share/vm/memory/metachunk.hpp ! src/share/vm/memory/metaspace.cpp ! src/share/vm/memory/metaspace.hpp ! src/share/vm/runtime/globals.hpp Changeset: 1de1b145f6bc Author: jmasa Date: 2012-12-26 15:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1de1b145f6bc 8005486: NPG: Incorrect assertion in ChunkManager::list_index() Reviewed-by: coleenp ! src/share/vm/memory/metaspace.cpp Changeset: b735136e0d82 Author: johnc Date: 2013-01-02 11:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b735136e0d82 8004132: SerialGC: ValidateMarkSweep broken when running GCOld Summary: Remove bit-rotten ValidateMarkSweep functionality and flag. Reviewed-by: johnc, jmasa Contributed-by: tamao ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/gc_implementation/shared/markSweep.hpp ! src/share/vm/gc_implementation/shared/markSweep.inline.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/debug.cpp Changeset: 37f7535e5f18 Author: johnc Date: 2012-12-21 11:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37f7535e5f18 8001424: G1: Rename certain G1-specific flags Summary: Rename G1DefaultMinNewGenPercent, G1DefaultMaxNewGenPercent, and G1OldCSetRegionLiveThresholdPercent to G1NewSizePercent, G1MaxNewSizePercent, and G1MixedGCLiveThresholdPercent respectively. The previous names are no longer accepted. Reviewed-by: brutisso, ysr ! src/share/vm/gc_implementation/g1/collectionSetChooser.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: d275c3dc73e6 Author: johnc Date: 2013-01-03 16:28 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d275c3dc73e6 8004816: G1: Kitchensink failures after marking stack changes Summary: Reset the marking state, including the mark stack overflow flag, in the event of a marking stack overflow during serial reference processing. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: ca0a78017dc7 Author: brutisso Date: 2012-12-30 08:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca0a78017dc7 8005396: Use ParNew with only one thread instead of DefNew as default for CMS on single CPU machines Reviewed-by: jmasa, jcoomes ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsCollectorPolicy.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/collectorPolicy.cpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/runtime/arguments.cpp Changeset: e0ab18eafbde Author: brutisso Date: 2013-01-04 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0ab18eafbde 8003820: Deprecate untested and rarely used GC combinations Summary: Log warning messages for DefNew+CMS and ParNew+SerialOld Reviewed-by: ysr, jwilhelm, jcoomes ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp Changeset: c98b676a98b4 Author: brutisso Date: 2013-01-04 21:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c98b676a98b4 8003822: Deprecate the incremental mode of CMS Reviewed-by: johnc, jwilhelm ! src/share/vm/runtime/arguments.cpp Changeset: 6e9174173e00 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e9174173e00 8000325: Change default for CMSClassUnloadingEnabled to true Reviewed-by: stefank, ysr ! src/share/vm/runtime/globals.hpp Changeset: 0b54ffe4c2d3 Author: jmasa Date: 2013-01-04 17:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0b54ffe4c2d3 8005672: Clean up some changes to GC logging with GCCause's Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_interface/gcCause.hpp Changeset: 7d42f3b08300 Author: dcubed Date: 2012-12-19 10:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7d42f3b08300 8005044: remove crufty '_g' support from HS runtime code Summary: Phase 2 is removing '_g' support from the Runtime code. Reviewed-by: dcubed, coleenp, hseigel Contributed-by: ron.durbin at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/vm/runtime/arguments.cpp Changeset: 35431a769282 Author: stefank Date: 2012-12-20 10:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/35431a769282 8004823: Add VM support for type annotation reflection Reviewed-by: dholmes, coleenp Contributed-by: joel.franck at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/annotations.cpp ! src/share/vm/oops/annotations.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/fieldDescriptor.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/reflection.cpp Changeset: 4daebd4cc1dd Author: minqi Date: 2012-12-24 11:46 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4daebd4cc1dd Merge ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/method.hpp ! src/share/vm/runtime/arguments.cpp Changeset: cc6a617fffd2 Author: coleenp Date: 2013-01-02 20:28 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cc6a617fffd2 8005494: SIGSEGV in Rewriter::relocate_and_link() when testing Weblogic with CompressedOops and KlassPtrs Summary: Relocate functions with jsr's when rewriting so not repeated after reading shared archive Reviewed-by: twisti, jrose ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/rewriter.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/handles.inline.hpp Changeset: 6c3f47d964f3 Author: hseigel Date: 2013-01-07 15:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6c3f47d964f3 8003705: CDS failed on Windows: can not map in the CDS. Summary: Map memory only once to prevent 'already mapped' failures. Reviewed-by: acorn, zgu ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/metaspaceShared.cpp Changeset: 561148896559 Author: hseigel Date: 2013-01-08 13:38 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/561148896559 8005076: Creating a CDS archive with one alignment and running another causes a crash. Summary: Save the alignment when writing the CDS and compare it when reading the CDS. Reviewed-by: kvn, coleenp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/filemap.hpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: ade95d680b42 Author: coleenp Date: 2013-01-08 14:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ade95d680b42 8004728: Add hotspot support for parameter reflection Summary: Add hotspot support for parameter reflection Reviewed-by: acorn, jrose, coleenp Contributed-by: eric.mccorkle at oracle.com ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileStream.cpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/defaultMethods.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/constMethod.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp Changeset: 185a2c979a0e Author: coleenp Date: 2013-01-08 13:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/185a2c979a0e Merge Changeset: ecd24264898b Author: zgu Date: 2013-01-08 14:04 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ecd24264898b 8005048: NMT: #loaded classes needs to just show the # defined classes Summary: Count number of instance classes so that it matches class metadata size Reviewed-by: coleenp, acorn ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/services/memBaseline.cpp ! src/share/vm/services/memRecorder.cpp ! src/share/vm/services/memRecorder.hpp ! src/share/vm/services/memSnapshot.cpp ! src/share/vm/services/memSnapshot.hpp ! src/share/vm/services/memTrackWorker.cpp ! src/share/vm/services/memTrackWorker.hpp ! src/share/vm/services/memTracker.cpp ! src/share/vm/services/memTracker.hpp Changeset: 37a3e8b7a1e9 Author: zgu Date: 2013-01-08 11:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/37a3e8b7a1e9 Merge ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp Changeset: 0c93d4818214 Author: zgu Date: 2013-01-08 15:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c93d4818214 Merge Changeset: 1f6d10b4cc0c Author: acorn Date: 2013-01-09 18:06 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1f6d10b4cc0c Merge ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp Changeset: 608b2e8a0063 Author: bpittore Date: 2013-01-03 15:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/608b2e8a0063 8004051: assert(_oprs_len[mode] < maxNumberOfOperands) failed: array overflow Summary: assert is triggered when number of register based arguments passed to a java method exceeds 16. Reviewed-by: roland, vladidan ! src/share/vm/c1/c1_LIR.hpp Changeset: 0c8717a92b2d Author: jiangli Date: 2013-01-08 13:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0c8717a92b2d 8001341: SIGSEGV in methodOopDesc::fast_exception_handler_bci_for(KlassHandle,int,Thread*)+0x3e9. Summary: Use methodHandle. Reviewed-by: coleenp, acorn, twisti, sspitsyn ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 18c3c3fa291b Author: dlong Date: 2013-01-09 21:18 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/18c3c3fa291b Merge ! src/share/vm/oops/method.cpp ! src/share/vm/oops/method.hpp Changeset: 4c8bf5e55392 Author: brutisso Date: 2013-01-09 09:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4c8bf5e55392 8005489: VM hangs during GC with ParallelGC and ParallelGCThreads=0 Summary: Print an error message and exit the VM if UseParallalGC is combined with ParllelGCThreads==0. Also reviewed by vitalyd at gmail.com. Reviewed-by: stefank, ehelin ! src/share/vm/runtime/arguments.cpp Changeset: b2fef6b220e9 Author: jmasa Date: 2013-01-10 07:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b2fef6b220e9 Merge ! src/share/vm/runtime/arguments.cpp Changeset: d092d1b31229 Author: roland Date: 2012-12-23 17:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d092d1b31229 8005071: Incremental inlining for JSR 292 Summary: post parse inlining driven by number of live nodes. Reviewed-by: twisti, kvn, jrose ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/callGenerator.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/cfgnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/phaseX.hpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/runtime/arguments.cpp Changeset: 00af3a3a8df4 Author: kvn Date: 2013-01-03 15:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/00af3a3a8df4 8005522: use fast-string instructions on x86 for zeroing Summary: use 'rep stosb' instead of 'rep stosq' when fast-string operations are available. Reviewed-by: twisti, roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/globals_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/cpu/x86/vm/vm_version_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/memnode.cpp Changeset: e2e6bf86682c Author: kvn Date: 2013-01-03 16:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e2e6bf86682c 8005544: Use 256bit YMM registers in arraycopy stubs on x86 Summary: Use YMM registers in arraycopy and array_fill stubs. Reviewed-by: roland, twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: ffa87474d7a4 Author: twisti Date: 2013-01-07 14:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ffa87474d7a4 8004537: replace AbstractAssembler emit_long with emit_int32 Reviewed-by: jrose, kvn, twisti Contributed-by: Morris Meyer ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/cppInterpreter_sparc.cpp ! src/cpu/sparc/vm/macroAssembler_sparc.cpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/asm/assembler.hpp Changeset: 038dd2875b94 Author: kvn Date: 2013-01-08 11:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/038dd2875b94 8005419: Improve intrinsics code performance on x86 by using AVX2 Summary: use 256bit vpxor,vptest instructions in String.compareTo() and equals() intrinsics. Reviewed-by: twisti ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp + test/compiler/8005419/Test8005419.java Changeset: 5698813d45eb Author: twisti Date: 2013-01-09 15:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5698813d45eb 8005418: JSR 292: virtual dispatch bug in 292 impl Reviewed-by: jrose, kvn ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/doCall.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp Changeset: f1c06dcee0b5 Author: kvn Date: 2013-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1c06dcee0b5 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 1e129851479e Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1e129851479e Merge Changeset: b5e6bec76f4a Author: amurillo Date: 2013-01-11 01:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5e6bec76f4a Added tag hs25-b15 for changeset 1e129851479e ! .hgtags From lana.steuck at oracle.com Wed Jan 16 13:18:29 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 16 Jan 2013 21:18:29 +0000 Subject: hg: jdk8/tl/jdk: 6 new changesets Message-ID: <20130116211951.9531347314@hg.openjdk.java.net> Changeset: 32a57e645e01 Author: katleman Date: 2013-01-03 12:44 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32a57e645e01 Added tag jdk8-b71 for changeset 2a5af0f766d0 ! .hgtags Changeset: c9a914b11436 Author: katleman Date: 2013-01-10 09:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9a914b11436 Added tag jdk8-b72 for changeset 32a57e645e01 ! .hgtags Changeset: d54922883f4c Author: alexsch Date: 2013-01-09 16:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d54922883f4c 8005019: JTable passes row index instead of length when inserts selection interval Reviewed-by: serb, denis ! src/share/classes/javax/swing/JTable.java + test/javax/swing/JTable/8005019/bug8005019.java Changeset: b2c425d7e5be Author: lana Date: 2013-01-10 15:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b2c425d7e5be Merge Changeset: 733885f57e14 Author: lana Date: 2013-01-10 15:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/733885f57e14 Merge Changeset: 9fed48caac80 Author: lana Date: 2013-01-16 12:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9fed48caac80 Merge From joe.darcy at oracle.com Wed Jan 16 13:22:28 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 16 Jan 2013 21:22:28 +0000 Subject: hg: jdk8/tl/langtools: 8006283: Change to Class.cast() in javax.lang.model implementation for repeating annotations Message-ID: <20130116212231.47D6C47315@hg.openjdk.java.net> Changeset: 8b749558767b Author: darcy Date: 2013-01-16 13:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8b749558767b 8006283: Change to Class.cast() in javax.lang.model implementation for repeating annotations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/model/JavacElements.java From bernd-2013 at eckenfels.net Wed Jan 16 17:19:22 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Thu, 17 Jan 2013 02:19:22 +0100 Subject: SSLSocketImpl and Handshake Notifier efficiency/thread pooling In-Reply-To: <50F626D4.5030101@oracle.com> References: <50F626D4.5030101@oracle.com> Message-ID: Hello Xuelei, List, thanks for taking the time to comment: Am 16.01.2013, 05:04 Uhr, schrieb Xuelei Fan : > I agree with you that create new threads in SSLSocket implementation is > not good. The application is the better place to decide what's the > right thread model. > For the same reason, using Executor in SSLSocket > implementation might not be an option from my understanding. A small change without Executor would be to have a boolean setter which deactivates the Thread dispatching. The default will use new Threads, if direct mode is enabled it will directly call the listeners in the data thread: public void setDirectHandshakeListener(boolean enabled) { this.skipListnerBackgroundThread = enabled; } private void readRecord(InputRecord r, boolean needAppData) ... if (handshakeListeners != null) { HandshakeCompletedEvent event = new HandshakeCompletedEvent(this, sess); Runnable r = NotifyHandshakeTask(handshakeListeners.entrySet(), event); if (skipListnerBackgroundThread == false) { Thread t = new Thread("HandshakeEventThread", r); t.start(); } else { r.run(); } } This also would require to transform NotifyHandshakeThread into a runable (or move it to the Event, see below) But I think setter for different Executor strategies is not more overhead but more flexible. It would allow to use a smarter default strategy and it enables the user to request the sync case by passing a: "class DirectExecutor implements Executor { void execute(Runnable r) { r.run(); }}". SSLContextImpl -------------- Executor listenerExecutor = Executors.newCachedExecutor(); SSLSocketFactoryImpl: -------------------- public void setHandshakeListenerExecutor(Executor newExecutor) { context.listenerExecutor = newExecutor; } SSLSocketImpl: private void readRecord(InputRecord r, boolean needAppData) ... if (handshakeListeners != null) { HandshakeCompletedEvent event = new HandshakeCompletedEvent(this, sess); Runnable r = NotifyHandshakeTask(handshakeListeners.entrySet(), event); // if (context.listenerExecutor == null) r.run(); else context.listenerExecutur.execute(r); } > The HashSet clone should be pretty fast. A kind of "copy" of listeners > is necessary here, otherwise, need to consider more about the > synchronization between the update (add/remove) and use of the listeners. Actually that copy constructor was introduced as a IMHO incorrect Fix. Because the copy constructor runs concurrently to the add/removeListener methods and is not concurrency safe (HashMap#putAllForCreate is a foreach!). The fix 7065972 will reduce the race window (which is very small anyway) but it still exists. So if you fix this I would move copy/entrySetCreation/IteratorCreation out of the hot path. Something like this is needed. In this version it remebers the HashMap and a array version of it. It seems there is no good "ListernerRegistrationMapSupport" object similiar to java.beans.ChangeListenerMap in the Java RT lib? // modified by add/removeHandshakeCompletedListener (synchronmized on this only) HashMap handshakeListeners; // never modified only replaced (replace/dereference with monitor on this so no volatile needed) Map.Enty[] handshakeListenersArray = null; public synchronized void addHandshakeCompletedListener(HandshakeCompletedListener listener) { if (listener == null) { throw new IllegalArgumentException("listener is null"); } // implement a copy on write strategy so handshakeListeners is immutable if (handshakeListeners == null) { handshakeListeners = new HashMap(4); } handshakeListeners.put(listener, AccessController.getContext()); // create a immutable array for the iterator handshakeListenersArray = handshakeListeners.entrySet().toArray(new Map.Entry[m.size()]); } ... if (handshakeListenersArray != null) { HandshakeCompletedEvent event = new HandshakeCompletedEvent(this, sess); Thread t = new NotifyHandshakeThread(handshakeListenersArray, event); t.start(); } ... NotifyHandshakeThread( Map.Entry[] entryArray, HandshakeCompletedEvent e) { super("HandshakeCompletedNotify-Thread"); targets = entryArray; // is immutable event = e; } ... public void run() { for (int i=0;i I'm not sure I understand the suggestion. Why it is helpful to reduce > objects allocations? Can you show some examples? Well, for a case where the same functionality can be achieved with less garbage produced I would prefer the more economic implementation. So you can remove the NotifyHandshakeThread class completely by adding a Runnable Interface to HandshakeCompletedEvent. But yes, thats only a minor optimisation for reducing the GC load. BTW: Is there somewhere a Git repository of the JSSE part? Would be faster for me to get it build. If not, I might use a fork of this https://github.com/benmmurphy/ssl_npn to implement my suggestion. Greetings Bernd -- http://bernd.eckenfels.net From jonathan.gibbons at oracle.com Wed Jan 16 20:41:40 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 17 Jan 2013 04:41:40 +0000 Subject: hg: jdk8/tl/langtools: 8006228: Doclint doesn't detect {@code nested inline} Message-ID: <20130117044145.5514147330@hg.openjdk.java.net> Changeset: 916143318f10 Author: jjg Date: 2013-01-16 20:41 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/916143318f10 8006228: Doclint doesn't detect {@code nested inline} Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties + test/tools/doclint/LiteralTest.java + test/tools/doclint/LiteralTest.out From xuelei.fan at oracle.com Thu Jan 17 07:44:33 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 17 Jan 2013 23:44:33 +0800 Subject: Update #4: JEP 123: SecureRandom Draft and Implementation. In-Reply-To: <50EF5BA7.2040606@oracle.com> References: <50EF5BA7.2040606@oracle.com> Message-ID: <50F81C61.1010207@oracle.com> Hi Brad, Please note the priorities for each comment. As the M6 is coming, you can only take P1 comments. P1: need to update P2: suggested update, you can take it after M6. P3: minor comments, it's OK to leave it unchanged. P4: personal preference for your consideration, or my question. java/security/SecureRandom.java ------------------------------------- 1-1. the performance of Pattern.compile [P2] Pattern.compile() is expensive. I would suggest to use private static lazy-initialized class attribute the patterns. public class SecureRandom extends java.util.Random { private static final String regex = "..."; private static final Pattern pattern; public static SecureRandom getStrongSecureRandom() { ... if (pattern == null) { pattern = Pattern.compile(regex); } ... } } 1-2. spaces are allowed between algorithm and provider [P4] According to the regex ("\\s*(\\S+)\\s*\\:\\s*(\\S+)\\s*"), spaces are allowed around the tokens. For example, " NativePRNGBlocking : SUN " is valid. I would like to use a stricter syntax at the beginning in case of any special requirement comes in the future. 1-3. may only need one regex for both "algorithm" and "algorithm:provider" [P3] I think one regex is OK for both: "([\\S&&[^:]]+)(\\:([\\S&&[^:]]+))?". NativePRNGBlocking:Sun group 1: NativePRNGBlocking group 2: :Sun group 3: Sun NativePRNGBlocking group 1: NativePRNGBlocking group 2: null group 3: null If group 2 is non-null, it is of the "algorithm:provider" style. 1-4. a typo at line 614 [P1]: - 614 // Pattern for "algorithm.provider" + 614 // Pattern for "algorithm:provider" java.security-windows ------------------------------------- 2-1. Is it possible to enable "NativePRNGBlocking:SUN" in Windows? [P2] + securerandom.strongAlgorithms=Windows-PRNG:SunMSCAPI I was wondering to enable "NativePRNGBlocking:SUN" here before I know that the "NativePRNGBlocking:SUN" is not available on Windows: + securerandom.strongAlgorithms=Windows-PRNG:SunMSCAPI, \ + NativePRNGBlocking:SUN The availability of "securerandom.strongAlgorithms" property depends on the enabled security providers, and the platform. If "SunMSCAPI" provider is not enabled, the "Windows-PRNG:SunMSCAPI" will not work. I think "NativePRNGBlocking:SUN" is not available on Windows system. It is not as obviously as that the "Windows-PRNG:SunMSCAPI" is not available on Unix/Linux/Mac OS systems. We need to documentation this behaviors clear somewhere else. P11SecureRandom.java ------------------------------------- 3-1: to support strong algorithm in PKCS11 [P4] Is SHA1PRNG:SunPKCS11 a strong algorithm? I think it would be nice to add it as a backup in the strong algorithm property. SeedGenerator.java ------------------------------------- 4-1: downgrade normative reference to java security property file [P3] [line 57-60] As you have already there, I would suggest to use the new style of security property. See http://hg.openjdk.java.net/jdk8/tl/jdk/rev/346c0af4af41 and the description from SeanM, http://mail.openjdk.java.net/pipermail/security-dev/2012-December/006144.html. line 57-60: - * accomplished by setting the value of the "securerandom.source" - * Security property (in the Java security properties file) to a URL - * specifying the location of the entropy gathering device, or by setting - * the "java.security.egd" System property. + * accomplished by setting the value of the + * {@code securerandom.source} security property to a URL + * specifying the location of the entropy gathering device, or by setting + * the {@code java.security.egd} System property. SunEntries.java ------------------------------------- 5-1: what's the usage of "NativePRNGNonBlocking"? [P2] + if (NativePRNG.NonBlocking.isAvailable()) { + map.put("SecureRandom.NativePRNGNonBlocking", + "sun.security.provider.NativePRNG$NonBlocking"); + } I did not find the description of this algorithm in the specification (CCC) or other export documentation. Do you want to add it to Oracle provider names doc? Otherwise, I would suggest to comment out this algorithm. The above would set a external SecureRandom algorithm, I think. sun/security/provider/NativePRNG.java ------------------------------------- 6-1: line 36-42, wordsmithing. [P3] "It obtains seed and random numbers by reading system files such as the special device files /dev/random and /dev/urandom. This implementation respects the {@code securerandom.source} security property and {@code java.security.egd} system property for obtaining seed material. If the file specified by the properties does not exist, /dev/random is the default seed source, and /dev/urandom is the default source of random numbers." 6-2: Do you want to put something here? [P4] 321 // XXX change the urandom/random to seed/next src/windows/classes/sun/security/provider/NativeSeedGenerator.java ------------------------------------- 7-1: Not about this fix, but the code looks strange to me. [P4] The constructor calls: 44 super(); The SeedGenerator static block will be called and SeedGenerator.instance will be initialized. According to the code in SeedGenerator.java: 145 static public void generateSeed(byte[] result) { 146 instance.getSeedBytes(result); 147 } The getSeedBytes() method of the initialized instance will be used. However, in Windows platform, I think the NativeSeedGenerator.getSeedBytes() should be called, I think. I think the NativeSeedGenerator class should override the generateSeed() method. About the super() call in NativeSeedGenerator, I think the initialization of instance (line 92-142, SeedGenerator.java) may be not necessary. The initialized instance in SeedGenerator is useless in Windows from my understand. Am I missing something? Otherwise, looks fine to me. Xuelei On 1/11/2013 8:24 AM, Brad Wetmore wrote: > Minor tweak. It occurred to me that people might use "." as separators > (for example using some OIDs scheme), so I changed the syntax slightly > of the system property to use ":" instead. > > For example: > > # This is a comma-separated list of algorithm and/or algorithm:provider > # entries. > # > securerandom.strongAlgorithms=NativePRNGBlocking:SUN, > SP800-90A/AES/CTR:IBMJDK > > Latest is now webrev.04. > > http://cr.openjdk.java.net/~wetmore/6425477/ > > Brad > > > From vincent.x.ryan at oracle.com Thu Jan 17 09:04:43 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 17 Jan 2013 17:04:43 +0000 Subject: [8] Code review request for 6263419: No way to clean the memory for a java.security.Key Message-ID: <50F82F2B.5050608@oracle.com> Hello, Please review the fix for 6263419. It introduces a mechanism to destroy the sensitive data associated with private keys and secret keys. It is a component of the JEP-166 delivery. Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.00/ Implementers of JCE security providers can override the default method implementations in the Destroyable interface to allow applications to take advantage of this new facility. We intend to update our key implementation classes soon. Thanks. From maurizio.cimadamore at oracle.com Thu Jan 17 10:15:49 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 17 Jan 2013 18:15:49 +0000 Subject: hg: jdk8/tl/langtools: 8005852: Treatment of '_' as identifier Message-ID: <20130117181554.2FFD747375@hg.openjdk.java.net> Changeset: 2d2b2be57c78 Author: mcimadamore Date: 2013-01-17 18:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2d2b2be57c78 8005852: Treatment of '_' as identifier Summary: warn when '_' is found in an identifier position Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Tokens.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/lambda/LambdaParserTest.java From xueming.shen at oracle.com Thu Jan 17 12:45:04 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 17 Jan 2013 20:45:04 +0000 Subject: hg: jdk8/tl/jdk: 8006090: Formatter asserts with -esa Message-ID: <20130117204528.C49394737E@hg.openjdk.java.net> Changeset: 787c7c1c210f Author: sherman Date: 2013-01-17 12:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/787c7c1c210f 8006090: Formatter asserts with -esa Summary: removed the offending assert Reviewed-by: alanb, darcy Contributed-by: brian.burkhalter at oracle.com ! src/share/classes/java/util/Formatter.java ! test/ProblemList.txt From kurchi.subhra.hazra at oracle.com Thu Jan 17 14:44:57 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Thu, 17 Jan 2013 22:44:57 +0000 Subject: hg: jdk8/tl/jdk: 7171415: java.net.URI.equals/hashCode not consistent for some URIs Message-ID: <20130117224517.A557F4738B@hg.openjdk.java.net> Changeset: e8414d69692c Author: khazra Date: 2013-01-17 14:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e8414d69692c 7171415: java.net.URI.equals/hashCode not consistent for some URIs Summary: Rewrite URI.hashCode() to consider encoded characters, also reviewed by vitalyd at gmail.com, schlosna at gmail.com Reviewed-by: chegar ! src/share/classes/java/net/URI.java ! test/java/net/URI/Test.java From stuart.marks at oracle.com Thu Jan 17 15:43:10 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 17 Jan 2013 23:43:10 +0000 Subject: hg: jdk8/tl/jdk: 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times Message-ID: <20130117234322.E862C47395@hg.openjdk.java.net> Changeset: 79fed1733d4a Author: jgish Date: 2013-01-17 15:09 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/79fed1733d4a 8006534: CLONE - TestLibrary.getUnusedRandomPort() fails intermittently-doesn't retry enough times Summary: Increase number of retries to twice the number of ports in the reserved range Reviewed-by: mduigou ! test/java/rmi/testlibrary/TestLibrary.java From bradford.wetmore at oracle.com Thu Jan 17 17:13:06 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 17 Jan 2013 17:13:06 -0800 Subject: Code Review Request for 7030966, Support AEAD CipherSuites (JSSE part of JEP 115) In-Reply-To: <50CE8875.3060104@oracle.com> References: <50AE3DF0.1020400@oracle.com> <50BE11A6.2070205@oracle.com> <50CE8875.3060104@oracle.com> Message-ID: <50F8A1A2.3090508@oracle.com> Hi Xuelei, Minor stuff. A couple things to check. Xuelei wrote: >>> Hi Valerie, Max or Brad, >>> >>> Can you review the update for JDK-7030966? It is the JSSE part of JEP 115. >>> >>> webrev: http://cr.openjdk.java.net./~xuelei/7030966/webrev.00/ >>> JEP 115: http://openjdk.java.net/jeps/115 I looked at webrev.01. >>> In the update, I have not remove the debug synchronization. I will >>> remove them before pushing the changeset. I will be doing a putback of the JCE providers, so I can do your SunJCE signed provider putback for you. Let's coordinate when you are ready. I will probably be ready early next week. Minor nits: =========== What is the indentation style you are using? I noticed a few places where it's not 4/8 spaces, and it's not lining up with anything on the previous line. For example CipherSuite.java:522:544. Also, in several of your new methods, you are writing pseudo-javadoc style (@return/etc), but you're not starting the comment with "/**". This probably doesn't matter since we don't generate javadoc for internal classes. Just mentioning since you took the time to format it and hoping it would render. TlsKeyMaterialGenerator.java ============================ OK TlsKeyMaterialParameterSpec.java ================================ OK TlsKeyMaterialSpec.java ======================= OK P11TlsKeyMaterialGenerator.java =============================== OK CipherBox.java ============== In various places, you mention RFC 5246 (TLS 1.2), but it also applies to RFC 4346 (TLS 1.1). For example in getExplicitNonceSize(). You might want to mention both RFCs in these places for completeness and to avoid confusion. 180: We only need to keep the key around for AEAD, so saving a copy here for CBC prevents GC of an object we'll never use again. In your comment of 126, you also mention that it's reserved for AEAD, so I would not expect to see this key nonnull for anything besides AEAD. 131/205: In a similar vein, tagSize is only used for AEAD, so you could initialize tagSize to 0 and then move line 205 inside the "if (AEAD)" arm. Not critical, but it seems incorrect to have a regular AES/CBC CipherBox with a tagsize of 16. 214/218: Same comment about fixedIV/recordIVSize. Only used in AEAD. No need to keep around this dummy array or calculate a value we don't need. 207/215: Some additional commenting of the AEAD vs. CBC Cipher init logic would be helpful here for people trying to understand the code. Something like: AEAD must completely initialize the cipher for each packet, and so we save initialization parameters for packet processing time. CBC only requires one initialization during its lifetime (future packets/IVs set the proper CBC state), so we can initialize now. 298: Exception chaining for debugging? Minor nit: since you're using the new multi-catch Exceptions here, maybe a name change (ibse) is in order? 312/564: I don't remember why we decided to use the RuntimeException AIOOBE here. Ugh...anyway, can you also use exception chaining to help debug any reported problems? 361: Variable name OutputSize is capitalized. 774/803: Minor nit (take or leave): you might want to change "explicit nonce" -> "nonce_explicit" for readers are following the RFC. The others are fine. 790/849: "alsoe" -> "also" 798: "Applys" -> "Applies" 825: Your exception description just mentions nonces, but your check is for both nonce/tagSize. This description is incomplete. CipherSuite.java ================ 510: I don't think this statement is true anymore. This is likley a carryover from the 1.4 days when we used to have a crypto provider in the JSSE jar file. Not for this review, but maybe we should actually check that implementations are available? If we remove SunEC and SunPKCS11 providers from the provider list, could we potentially disable the EC suites? 522: Why are you also checking for CipherType.AEAD_CIPHER? 577: If you actually pulled out something for b in 538, you're putting it right back in at 577. You should probably have the second if completely inside the first and move 577 inside that if. Boolean b = availableCache.get(cipher); if (b == null) { if (cipher.keySize > 128) ...deleted... if (b == null) { b = Boolean.FALSE; ...deleted... } availableCache.put(cipher, b); } return b.booleanValue(); 540-550: Question: is this just an optimization to see if it's > 128 before actually trying it at 566? You might mention that. 970: "before" -> "while" 1054: From http://www.rfc-editor.org/rfc/rfc6460.txt A Suite B TLS client configured at a minimum level of security of 128 bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite in the ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite is preferred; if offered, it MUST appear before the TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite. I would have thought what you have is the correct order, but it doesn't follow the RFC. Please add a note to remind us, because this order will not make sense in 6 months. ;) EngineInputRecord.java ====================== 191: Your comment is a little confusing here. Does this mean it does this internally? 193: Great comment. Thank you! 213: Also RFC 5246 6.2.3.3 also says that a bad_record_mac should be sent. Although you catch this and send that in the upper layers, you might mention this here. 219: authenticatoin -> authentication EngineOutputRecord.java ======================= 294/296: Another great comment. I might suggest reversing the comments so that the comment about AEAD is in the AEAD arm, and CBC is outside. 306: The original code was bad (double debug != null :) ), and I realize the original code was lacking in parens "()", but can you please add parens to indicate exactly what expression order you intend here. My head is spinning from parsing the various cases: I'm not sure the logic here is correct. I think we should output if debug is on and either handshake/record is active or we're outputing a CCS. That is: if ((debug ! null) && ((Debug.isOn("record") || (Debug.isOn("handshake") || (contentType() == ct_change_cipher_spec))))) { Is my thinking incorrect? EngineWriter.java ================= OK Handshaker.java =============== This is a comment for ClientHandshaker/Handshaker. I just want to confirm some restrictions from Section 4 of RFC 5288: 1. If a remote client offers <= TLS 1.1 and a GCM suite, we won't possibly select a GCM suite. I'm pretty sure this is ok, just wanted to check. 2. If a remote server selects a GCM ciphersuite and a version other than TLS 1.2, our client will send an alert_illegal_parameter. I think this is done at ClientHandshaker:461 calling into Handshaker:isNegotiable(), but the comments in getActiveCipherSuites() only talk about the initial request, not the CipherSuite we actually get back from the server. Can you please double check this? InputRecord.java ================ 166: Another good comment. You're on a roll! ;) 174: Same comment about later RFCs (See first comment in CipherBox) 198: Didn't follow this comment "before the exception occurs"? Before the MAC occurs? Or in the case of an exception in signer.compute. JsseJce.java ============ OK Authenticator.java ================== OK MAC.java ======== OK OutputRecord.java ================= 74: Thanks for the IM session yesterday, just reading this comment I wasn't following the point of this "unused header". My comment here is to point out why you have this unused header. One can eventually figure it out, but it would have been much quicker to have this right up front. Something like: When this is object is created, we don't know the protocol version #/IV length/etc., so reserve space in front to avoid extra data movement (copies). 81: records -> record 193: Could you put in the comments what description is? You're asking "is this alert of type 'description'"? 236: Please add ()'s. 250/252: Same comment about reversing the comments. Record.java =========== 55: Never noticed this before. Is maxIVLength really 256, or were you just being overly cautious? All of our current block ciphers (e.g. AES-CBC) max out at 16 bytes, and there's only 8 bytes for TLS GCM mode nonce-explicit? For each OutputRecord, I think you're reserving an extra 245 bytes here that will never be used. (5 + 256 - 16) If you're nervous about future suites bumping the size, you could add a simple check during CipherSuite.java initialization. 70: The GCM tag size hasn't been mentioned anywhere in this class. You might include a few words to that effect. Even though the tag lives in the Data section, you might talk about it in the MAC section. SSLEngineImpl.java ================== OK SSLSocketImpl.java ================== OK I didn't check the tests. Thanks, Brad From maurizio.cimadamore at oracle.com Fri Jan 18 07:58:03 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 18 Jan 2013 15:58:03 +0000 Subject: hg: jdk8/tl/langtools: 8006561: Langtools test failure: missing diags/examples Message-ID: <20130118155811.3B471473BF@hg.openjdk.java.net> Changeset: 3d84ae209919 Author: mcimadamore Date: 2013-01-18 15:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d84ae209919 8006561: Langtools test failure: missing diags/examples Summary: forgot to hg add tests Reviewed-by: jjg + test/tools/javac/diags/examples/UnderscoreAsIdentifier.java + test/tools/javac/lambda/WarnUnderscoreAsIdent.java + test/tools/javac/lambda/WarnUnderscoreAsIdent.out From xuelei.fan at oracle.com Fri Jan 18 09:09:09 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 19 Jan 2013 01:09:09 +0800 Subject: Code Review Request for 7030966, Support AEAD CipherSuites (JSSE part of JEP 115) In-Reply-To: <50F8A1A2.3090508@oracle.com> References: <50AE3DF0.1020400@oracle.com> <50BE11A6.2070205@oracle.com> <50CE8875.3060104@oracle.com> <50F8A1A2.3090508@oracle.com> Message-ID: <50F981B5.4090206@oracle.com> webrev: http://cr.openjdk.java.net./~xuelei/7030966/webrev.02/ No significant changes in the new webrev. > I will be doing a putback of the JCE providers, so I can do your SunJCE > signed provider putback for you. Let's coordinate when you are ready. > I will probably be ready early next week. > Good! > Minor nits: > =========== > What is the indentation style you are using? I noticed a few places > where it's not 4/8 spaces, and it's not lining up with anything on the > previous line. For example CipherSuite.java:522:544. > I usually use 4 spaces for new lines. But if the next line is a continuation of the previous line, I did not follow the 8 spaces strictly. > Also, in several of your new methods, you are writing pseudo-javadoc > style (@return/etc), but you're not starting the comment with "/**". > This probably doesn't matter since we don't generate javadoc for > internal classes. Just mentioning since you took the time to format > it and hoping it would render. > I just want to use the tag in order to make the comments clear and easy understood. > CipherBox.java > ============== > 312/564: I don't remember why we decided to use the RuntimeException > AIOOBE here. Ugh...anyway, can you also use exception chaining to help > debug any reported problems? > We don't have chaining constructor for ArrayIndexOutOfBoundsException class. > > CipherSuite.java > ================ > 510: I don't think this statement is true anymore. This is likley a > carryover from the 1.4 days when we used to have a crypto provider in > the JSSE jar file. Not for this review, but maybe we should actually > check that implementations are available? If we remove SunEC and > SunPKCS11 providers from the provider list, could we potentially > disable the EC suites? > Good catch. EC algorithm will be checked in KeyExchange, rather than BulkCipher. If EC algorithm is not available, EC cipher suites will be disabled. I worry about the RC4 cipher. The AES/CBC/128 is the minimal requirements of a crypto provider, so I don't worry about AES/CBC/128. However, RC4 is not in the minimal requirements of a crypto provider, so we should check the availability of RC4 here. I will file a new for this issue. > 522: Why are you also checking for CipherType.AEAD_CIPHER? > AEAD/GCM is not implemented in all providers, for example the SunPKCS11 provider. So we need to check the available of AEAD implementation. > > 970: "before" -> "while" > It looks strange to me with two whiles: // ..., we decrease the // priority of cipher suites in GCM mode for a while while GCM // technologies become mature in the industry. I think "before" may be better word here. > 1054: From http://www.rfc-editor.org/rfc/rfc6460.txt > > A Suite B TLS client configured at a minimum level of security of 128 > bits MUST offer the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 or the > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite in the > ClientHello message. The TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 > cipher suite is preferred; if offered, it MUST appear before the > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 cipher suite. > > I would have thought what you have is the correct order, but it > doesn't follow the RFC. Please add a note to remind us, because this > order will not make sense in 6 months. ;) > You are right. The current default cipher suites preference is not Suite-B/RFC6460 compliant. We need additional work to configure the cipher suites in order to comply with RFC 6460. We may want to add a new feature in the future. > EngineInputRecord.java > ====================== > 191: Your comment is a little confusing here. Does this mean it does > this internally? > Need to remove this line. Removed. > EngineOutputRecord.java > ======================= > 294/296: Another great comment. I might suggest reversing the > comments so that the comment about AEAD is in the AEAD arm, and CBC is > outside. > I'm not sure I catch your ideas. ;-) Would you please show me the code? > 306: The original code was bad (double debug != null :) ), and I > realize the original code was lacking in parens "()", but can you > please add parens to indicate exactly what expression order you intend > here. My head is spinning from parsing the various cases: I'm not sure > the logic here is correct. I think we should output if debug is on > and either handshake/record is active or we're outputing a CCS. That > is: > > if ((debug ! null) && > ((Debug.isOn("record") || (Debug.isOn("handshake") || > (contentType() == ct_change_cipher_spec))))) { > > Is my thinking incorrect? > In the old code, there is no dump for "handshake" level log unless it is a change_cipher_spec message. However, the log is dumped for "record" level log. I think it was right because the log here is record information, but not handshake message. I think the update does not changes the behavior. > > Handshaker.java > =============== > This is a comment for ClientHandshaker/Handshaker. I just want to > confirm some restrictions from Section 4 of RFC 5288: > > 1. If a remote client offers <= TLS 1.1 and a GCM suite, we won't > possibly select a GCM suite. I'm pretty sure this is ok, just wanted > to check. > Yes. > 2. If a remote server selects a GCM ciphersuite and a version other > than TLS 1.2, our client will send an alert_illegal_parameter. I > think this is done at ClientHandshaker:461 calling into > Handshaker:isNegotiable(), but the comments in getActiveCipherSuites() > only talk about the initial request, not the CipherSuite we actually > get back from the server. Can you please double check this? > Good catch. We did not check the cipher suite and protocol version together. Need to address this in a new bug so that we can backport the update. > InputRecord.java > ================ > 198: Didn't follow this comment "before the exception occurs"? Before > the MAC occurs? Or in the case of an exception in signer.compute. > Need more comments here: count -= macLen; // Set the count before any MAC checking // exception occurs, so that the following // process can read the actual decrypted // content (minus the MAC) in the fragment // if necessary. > > Record.java > =========== > 55: Never noticed this before. Is maxIVLength really 256, or were you > just being overly cautious? All of our current block ciphers (e.g. > AES-CBC) max out at 16 bytes, and there's only 8 bytes for TLS GCM mode > nonce-explicit? For each OutputRecord, I think you're reserving an > extra 245 bytes here that will never be used. (5 + 256 - 16) If > you're nervous about future suites bumping the size, you could add a > simple check during CipherSuite.java initialization. > Good point. Need to address this in a new bug so that we can backport the update. Thanks, Xuelei From chris.hegarty at oracle.com Fri Jan 18 09:36:01 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 18 Jan 2013 17:36:01 +0000 Subject: hg: jdk8/tl/jdk: 8005120: Compiler warnings in socket transport native code Message-ID: <20130118173649.6DD71473CC@hg.openjdk.java.net> Changeset: f88e963960ae Author: jzavgren Date: 2013-01-18 17:34 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f88e963960ae 8005120: Compiler warnings in socket transport native code Reviewed-by: chegar, dsamersoff ! src/share/transport/socket/socketTransport.c ! src/share/transport/socket/sysSocket.h ! src/solaris/transport/socket/socket_md.c ! src/windows/transport/socket/socket_md.c From alan.bateman at oracle.com Fri Jan 18 10:50:49 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 18 Jan 2013 18:50:49 +0000 Subject: hg: jdk8/tl/jdk: 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision Message-ID: <20130118185127.5897A473D5@hg.openjdk.java.net> Changeset: 06da87777d0e Author: alanb Date: 2013-01-18 18:48 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/06da87777d0e 6939260: (fs) BasicFileAttributes.lastModifiedTime() should return last modified time with higher precision Reviewed-by: chegar ! src/solaris/classes/sun/nio/fs/UnixFileAttributes.java ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c ! test/java/nio/file/attribute/BasicFileAttributeView/Basic.java From vincent.x.ryan at oracle.com Fri Jan 18 11:53:27 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 18 Jan 2013 19:53:27 +0000 Subject: [8] Code review request for 8006591: Protect keystore entries using stronger PBE algorithms Message-ID: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> Hello, Please review the fix for 8006591. It introduces a mechanism to enable stronger PBE algorithms to be specified when encrypting a keystore entry. This allows developers to make use of the new PBE algorithms delivered in JEP-121. Note however that PKCS12 is currently the only keystore that supports this new feature. It is a component of the JEP-166 delivery. Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.00/ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130118/fd2d07cd/attachment.html From jason.uh at oracle.com Fri Jan 18 15:01:28 2013 From: jason.uh at oracle.com (Jason Uh) Date: Fri, 18 Jan 2013 15:01:28 -0800 Subject: [8] Request for review: 8006092: SecurityPermission: printIdentity doesn't exist Message-ID: <50F9D448.5000604@oracle.com> Hi all, This change fixes the test test/sun/security/tools/policytool/UpdatePermissions.sh, a manual policytool test that asks the user to select printIdentity from the list of Target Names for SecurityPermission even though printIdentity is not listed. java.security.Identity is deprecated so its omission is by design. I've replaced printIdentity with a different SecurityPermission target. webrev: http://cr.openjdk.java.net/~juh/8006092/webrev.00/ bug: http://bugs.sun.com/view_bug.do?bug_id=8006092 Thanks, Jason From bradford.wetmore at oracle.com Fri Jan 18 15:55:57 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Fri, 18 Jan 2013 15:55:57 -0800 Subject: Code Review Request for 7030966, Support AEAD CipherSuites (JSSE part of JEP 115) In-Reply-To: <50F981B5.4090206@oracle.com> References: <50AE3DF0.1020400@oracle.com> <50BE11A6.2070205@oracle.com> <50CE8875.3060104@oracle.com> <50F8A1A2.3090508@oracle.com> <50F981B5.4090206@oracle.com> Message-ID: <50F9E10D.6050300@oracle.com> I've pulled out things that need no further discussion. > I will be doing a putback of the JCE providers, so I can do your SunJCE > signed provider putback for you. Let's coordinate when you are ready. > I will probably be ready early next week. I will likely be putting back on Monday, maybe Tuesday. I'll try to coordinate with you over the weekend. >> CipherBox.java >> ============== >> 312/564: I don't remember why we decided to use the RuntimeException >> AIOOBE here. Ugh...anyway, can you also use exception chaining to help >> debug any reported problems? >> > We don't have chaining constructor for ArrayIndexOutOfBoundsException class. Well, that explains it. :) I wonder if there is already a RFE for this? >> CipherSuite.java >> ================ >> 510: I don't think this statement is true anymore. This is likley a >> carryover from the 1.4 days when we used to have a crypto provider in >> the JSSE jar file. Not for this review, but maybe we should actually >> check that implementations are available? If we remove SunEC and >> SunPKCS11 providers from the provider list, could we potentially >> disable the EC suites? >> > Good catch. > > EC algorithm will be checked in KeyExchange, rather than BulkCipher. If > EC algorithm is not available, EC cipher suites will be disabled. > > I worry about the RC4 cipher. The AES/CBC/128 is the minimal > requirements of a crypto provider, so I don't worry about AES/CBC/128. > However, RC4 is not in the minimal requirements of a crypto provider, so > we should check the availability of RC4 here. > > I will file a new for this issue. Thanks. >> 522: Why are you also checking for CipherType.AEAD_CIPHER? >> > AEAD/GCM is not implemented in all providers, for example the SunPKCS11 > provider. So we need to check the available of AEAD implementation. Of course, now I see it. The extra check for AES_256_GCM threw me. If you're also checking for AEAD, you probably don't need the separate check for AES_256_GCM. Maybe: if (this == B_AES_256 || (this.cipherType == CipherType.AEAD_CIPHER)) { is sufficient? >> 970: "before" -> "while" >> > It looks strange to me with two whiles: > > // ..., we decrease the > // priority of cipher suites in GCM mode for a while while GCM > // technologies become mature in the industry. > > I think "before" may be better word here. Sorry, definitely not two whiles. I think I probably meant to say "as" but obviously didn't. Maybe: // Placeholder for cipher suites in GCM mode. // // For better compatibility and interoperability, we decrease the // priority of cipher suites in GCM mode for a while as GCM // technologies mature in the industry. Eventually we'll move // the GCM suites here. >> EngineOutputRecord.java >> ======================= >> 294/296: Another great comment. I might suggest reversing the >> comments so that the comment about AEAD is in the AEAD arm, and CBC is >> outside. >> > I'm not sure I catch your ideas. ;-) Would you please show me the code? Just a simple reversal of the lines so that the code you're talking about is contained in the block that handles it: if (!writeCipher.isAEADMode()) { // DON'T encrypt the nonce_explicit for AEAD mode dstBB.position(dstPos + headerSize); } // The explicit IV in TLS 1.1 and later can be encrypted. Hope that's clearer. >> 306: The original code was bad (double debug != null :) ), and I >> realize the original code was lacking in parens "()", but can you >> please add parens to indicate exactly what expression order you intend >> here. My head is spinning from parsing the various cases: I'm not sure >> the logic here is correct. I think we should output if debug is on >> and either handshake/record is active or we're outputing a CCS. That >> is: >> >> if ((debug ! null) && >> ((Debug.isOn("record") || (Debug.isOn("handshake") || >> (contentType() == ct_change_cipher_spec))))) { >> >> Is my thinking incorrect? >> > In the old code, there is no dump for "handshake" level log unless it is > a change_cipher_spec message. However, the log is dumped for "record" > level log. I think it was right because the log here is record > information, but not handshake message. > > I think the update does not changes the behavior. You are correct, the actual update does not change the observed behavior, but I had to write an app to prove it to myself. However, this code is not following the failfast paradigm of Debug, though it does give the same answer because of the way the Debug.isOn() code was written. debug!=null is supposed to be a lightweight check to see if any Debug options are on, and if so, then do the more heavyweight checks. Abstracting a bit, test1 is the "debug!=null" test. The resulting code is: if (test1() && test2() || test3() && test4()) { System.out... } So if test1 fails, then we jump to the "test3 && test4" case, which then potentially has to go through the isOn processing twice. Granted, because of the way isOn was written (if args == null) it's not adding a lot of overhead or throwing NullPointers, but it's not following the paradigm. Looking a little more closely, I think the original logic was flawed. if ((debug && record) || handshake) if ((debug && record) || CCS) both handshake/CCS are outside the debug check. I think what was intended was: if (debug && (record || (handshake && CCS))) My underlying original comment remains: please add parens here to make it clear what you are intending. (P.S. If you want my test code, it's in my homedir under tmp/Template.java.) >> Handshaker.java >> =============== >> This is a comment for ClientHandshaker/Handshaker. I just want to >> confirm some restrictions from Section 4 of RFC 5288: >> >> 1. If a remote client offers <= TLS 1.1 and a GCM suite, we won't >> possibly select a GCM suite. I'm pretty sure this is ok, just wanted >> to check. >> > Yes. > >> 2. If a remote server selects a GCM ciphersuite and a version other >> than TLS 1.2, our client will send an alert_illegal_parameter. I >> think this is done at ClientHandshaker:461 calling into >> Handshaker:isNegotiable(), but the comments in getActiveCipherSuites() >> only talk about the initial request, not the CipherSuite we actually >> get back from the server. Can you please double check this? >> > Good catch. We did not check the cipher suite and protocol version > together. Need to address this in a new bug so that we can backport the > update. Not following what you mean by "backport the update"? GCM only exists in 8 at the moment. Or do you mean check the other TLS 1.2 ciphersuites besides GCM? >> InputRecord.java >> ================ >> 198: Didn't follow this comment "before the exception occurs"? Before >> the MAC occurs? Or in the case of an exception in signer.compute. >> > Need more comments here: > > count -= macLen; // Set the count before any MAC checking > // exception occurs, so that the following > // process can read the actual decrypted > // content (minus the MAC) in the fragment > // if necessary. Thanks. Hope these comments are helpful to you. Brad From xuelei.fan at oracle.com Fri Jan 18 19:10:23 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 19 Jan 2013 11:10:23 +0800 Subject: Code Review Request for 7030966, Support AEAD CipherSuites (JSSE part of JEP 115) In-Reply-To: <50F9E10D.6050300@oracle.com> References: <50AE3DF0.1020400@oracle.com> <50BE11A6.2070205@oracle.com> <50CE8875.3060104@oracle.com> <50F8A1A2.3090508@oracle.com> <50F981B5.4090206@oracle.com> <50F9E10D.6050300@oracle.com> Message-ID: <50FA0E9F.5090809@oracle.com> On 1/19/2013 7:55 AM, Brad Wetmore wrote: > I've pulled out things that need no further discussion. > >> I will be doing a putback of the JCE providers, so I can do your SunJCE >> signed provider putback for you. Let's coordinate when you are ready. >> I will probably be ready early next week. > > I will likely be putting back on Monday, maybe Tuesday. I'll try to > coordinate with you over the weekend. > OK. I think we are on the same page except the following minor comment style. Thanks for the code review. >>> EngineOutputRecord.java >>> ======================= >>> 294/296: Another great comment. I might suggest reversing the >>> comments so that the comment about AEAD is in the AEAD arm, and CBC is >>> outside. >>> >> I'm not sure I catch your ideas. ;-) Would you please show me the code? > > Just a simple reversal of the lines so that the code you're talking > about is contained in the block that handles it: > > if (!writeCipher.isAEADMode()) { > // DON'T encrypt the nonce_explicit for AEAD mode > dstBB.position(dstPos + headerSize); > } // The explicit IV in TLS 1.1 and later can be encrypted. > > Hope that's clearer. > Looks like my logic is correct. If the cipher is not AEAD mode, the explicit IV can be encrypted; (otherwise) if the cipher is AEAD mode, don't encrypt the nonce_explicit. if (!writeCipher.isAEADMode()) { // The explicit IV in TLS 1.1 and later can be encrypted. dstBB.position(dstPos + headerSize); } // Otherwise, DON'T encrypt the nonce_explicit for AEAD mode >>> Handshaker.java >>> =============== >>> 2. If a remote server selects a GCM ciphersuite and a version other >>> than TLS 1.2, our client will send an alert_illegal_parameter. I >>> think this is done at ClientHandshaker:461 calling into >>> Handshaker:isNegotiable(), but the comments in getActiveCipherSuites() >>> only talk about the initial request, not the CipherSuite we actually >>> get back from the server. Can you please double check this? >>> >> Good catch. We did not check the cipher suite and protocol version >> together. Need to address this in a new bug so that we can backport the >> update. > > Not following what you mean by "backport the update"? GCM only exists > in 8 at the moment. Or do you mean check the other TLS 1.2 ciphersuites > besides GCM? > Yes, besides the GCM cipher suites, there are some new cipher suites are defined since TLS 1.2. I think we'd better check the mismatching for all such cipher suites, in both JDK 7 and 8. Thanks for the code review. It helps a lot to me. Xuelei From bradford.wetmore at oracle.com Sat Jan 19 00:09:18 2013 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Sat, 19 Jan 2013 00:09:18 -0800 Subject: Code Review Request for 7030966, Support AEAD CipherSuites (JSSE part of JEP 115) In-Reply-To: <50FA0E9F.5090809@oracle.com> References: <50AE3DF0.1020400@oracle.com> <50BE11A6.2070205@oracle.com> <50CE8875.3060104@oracle.com> <50F8A1A2.3090508@oracle.com> <50F981B5.4090206@oracle.com> <50F9E10D.6050300@oracle.com> <50FA0E9F.5090809@oracle.com> Message-ID: <50FA54AE.6040701@oracle.com> >>>> EngineOutputRecord.java >>>> ======================= >>>> 294/296: Another great comment. I might suggest reversing the >>>> comments so that the comment about AEAD is in the AEAD arm, and CBC is >>>> outside. >>>> >>> I'm not sure I catch your ideas. ;-) Would you please show me the code? >> >> Just a simple reversal of the lines so that the code you're talking >> about is contained in the block that handles it: >> >> if (!writeCipher.isAEADMode()) { >> // DON'T encrypt the nonce_explicit for AEAD mode >> dstBB.position(dstPos + headerSize); >> } // The explicit IV in TLS 1.1 and later can be encrypted. >> >> Hope that's clearer. >> > Looks like my logic is correct. If the cipher is not AEAD mode, the > explicit IV can be encrypted; (otherwise) if the cipher is AEAD mode, > don't encrypt the nonce_explicit. > > if (!writeCipher.isAEADMode()) { > // The explicit IV in TLS 1.1 and later can be encrypted. > dstBB.position(dstPos + headerSize); > } // Otherwise, DON'T encrypt the nonce_explicit for AEAD mode Good grief. I obviously need more sleep. My apologies. :( Brad From chris.hegarty at oracle.com Sat Jan 19 00:40:34 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sat, 19 Jan 2013 08:40:34 +0000 Subject: hg: jdk8/tl/jdk: 8006568: HTTP protocol handler NLTM Authentication should use Base64 API Message-ID: <20130119084055.AA3A0473F2@hg.openjdk.java.net> Changeset: 33d0175ea8d9 Author: msheppar Date: 2013-01-19 08:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33d0175ea8d9 8006568: HTTP protocol handler NLTM Authentication should use Base64 API Reviewed-by: chegar, alanb ! src/solaris/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java ! src/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.java ! test/sun/net/www/protocol/http/ProxyTunnelServer.java From weijun.wang at oracle.com Sat Jan 19 01:28:16 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 19 Jan 2013 17:28:16 +0800 Subject: [8] Code review request for 8006591: Protect keystore entries using stronger PBE algorithms In-Reply-To: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> References: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> Message-ID: <986E6C3E-3592-472F-9AC4-E72980F64286@oracle.com> + /** + * Gets the name of the protection algorithm. + * If none was set then the default algorithm name is returned. + * The default algorithm name for a given keystore type is set using the + * {@code 'keystore..entryProtectionAlgorithm'} Security property. + * For example, the + * {@code keystore.PKCS12.entryProtectionAlgorithm} property stores the + * name of the default entry protection algorithm used for PKCS12 + * keystores. + * I didn't see the security property used in the pkcs12 codes. -Max On Jan 19, 2013, at 3:53, Vincent Ryan wrote: > Hello, > > Please review the fix for 8006591. It introduces a mechanism to enable > stronger PBE algorithms to be specified when encrypting a keystore entry. > This allows developers to make use of the new PBE algorithms delivered in > JEP-121. Note however that PKCS12 is currently the only keystore that > supports this new feature. > > It is a component of the JEP-166 delivery. > > Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.00/ > > Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130119/d03d101e/attachment-0001.html From weijun.wang at oracle.com Sat Jan 19 01:43:18 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 19 Jan 2013 17:43:18 +0800 Subject: [8] Code review request for 8006591: Protect keystore entries using stronger PBE algorithms In-Reply-To: <986E6C3E-3592-472F-9AC4-E72980F64286@oracle.com> References: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> <986E6C3E-3592-472F-9AC4-E72980F64286@oracle.com> Message-ID: <42D2BA91-6A87-48CD-95E9-3FF31D69A9D2@oracle.com> Also, although we haven't standardized the keystore types, there is still a possibility that different providers using the same storetype name. How can we ensure everyone honoring the security property? Max On Jan 19, 2013, at 17:28, Weijun Wang wrote: > > > + /** > + * Gets the name of the protection algorithm. > + * If none was set then the default algorithm name is returned. > + * The default algorithm name for a given keystore type is set using the > + * {@code 'keystore..entryProtectionAlgorithm'} Security property. > + * For example, the > + * {@code keystore.PKCS12.entryProtectionAlgorithm} property stores the > + * name of the default entry protection algorithm used for PKCS12 > + * keystores. > + * > I didn't see the security property used in the pkcs12 codes. > > -Max > On Jan 19, 2013, at 3:53, Vincent Ryan wrote: > >> Hello, >> >> Please review the fix for 8006591. It introduces a mechanism to enable >> stronger PBE algorithms to be specified when encrypting a keystore entry. >> This allows developers to make use of the new PBE algorithms delivered in >> JEP-121. Note however that PKCS12 is currently the only keystore that >> supports this new feature. >> >> It is a component of the JEP-166 delivery. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.00/ >> >> Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130119/4875a35e/attachment.html From vincent.x.ryan at oracle.com Sat Jan 19 04:24:00 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 19 Jan 2013 12:24:00 +0000 Subject: [8] Code review request for 8006591: Protect keystore entries using stronger PBE algorithms In-Reply-To: <42D2BA91-6A87-48CD-95E9-3FF31D69A9D2@oracle.com> References: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> <986E6C3E-3592-472F-9AC4-E72980F64286@oracle.com> <42D2BA91-6A87-48CD-95E9-3FF31D69A9D2@oracle.com> Message-ID: <50FA9060.8080000@oracle.com> On 19/01/2013 09:43, Weijun Wang wrote: > Also, although we haven't standardized the keystore types, there is > still a possibility that different providers using the same storetype > name. How can we ensure everyone honoring the security property? > If another JCE provider uses the same keystore type name for their implementation as an existing keystore type name then the same default entry protection algorithm would apply to both. I don't think that's a problem. If it became an issue then we could consider making the security property multi-valued and rely on ordering to distinguish been keystore implementations that employ the same keystore type. > Max > > On Jan 19, 2013, at 17:28, Weijun Wang > wrote: > >> >> >> + /** >> + * Gets the name of the protection algorithm. >> + * If none was set then the default algorithm name is returned. >> + * The default algorithm name for a given keystore type is set using the >> + * {@code 'keystore..entryProtectionAlgorithm'} Security property. >> + * For example, the >> + * {@code keystore.PKCS12.entryProtectionAlgorithm} property stores the >> + * name of the default entry protection algorithm used for PKCS12 >> + * keystores. >> + * >> I didn't see the security property used in the pkcs12 codes. >> Right. I need to update the keystore code to support that. Thanks. >> -Max >> On Jan 19, 2013, at 3:53, Vincent Ryan > > wrote: >> >>> Hello, >>> >>> Please review the fix for 8006591. It introduces a mechanism to enable >>> stronger PBE algorithms to be specified when encrypting a keystore entry. >>> This allows developers to make use of the new PBE algorithms delivered in >>> JEP-121. Note however that PKCS12 is currently the only keystore that >>> supports this new feature. >>> >>> It is a component of the JEP-166 delivery. >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.00/ >>> >>> Thanks. From weijun.wang at oracle.com Sat Jan 19 05:07:01 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 19 Jan 2013 21:07:01 +0800 Subject: [8] Code review request for 8006591: Protect keystore entries using stronger PBE algorithms In-Reply-To: <50FA9060.8080000@oracle.com> References: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> <986E6C3E-3592-472F-9AC4-E72980F64286@oracle.com> <42D2BA91-6A87-48CD-95E9-3FF31D69A9D2@oracle.com> <50FA9060.8080000@oracle.com> Message-ID: On Jan 19, 2013, at 20:24, Vincent Ryan wrote: > > On 19/01/2013 09:43, Weijun Wang wrote: >> Also, although we haven't standardized the keystore types, there is >> still a possibility that different providers using the same storetype >> name. How can we ensure everyone honoring the security property? >> > > If another JCE provider uses the same keystore type name for their > implementation as an existing keystore type name then the same default > entry protection algorithm would apply to both. I don't think that's > a problem. > > If it became an issue then we could consider making the security > property multi-valued and rely on ordering to distinguish been keystore > implementations that employ the same keystore type. > > >> Max >> >> On Jan 19, 2013, at 17:28, Weijun Wang > > wrote: >> >>> >>> >>> + /** >>> + * Gets the name of the protection algorithm. >>> + * If none was set then the default algorithm name is returned. >>> + * The default algorithm name for a given keystore type is set using the >>> + * {@code 'keystore..entryProtectionAlgorithm'} Security property. >>> + * For example, the >>> + * {@code keystore.PKCS12.entryProtectionAlgorithm} property stores the >>> + * name of the default entry protection algorithm used for PKCS12 >>> + * keystores. >>> + * >>> I didn't see the security property used in the pkcs12 codes. >>> > > Right. I need to update the keystore code to support that. And probably also the description and example line to java.security file. Max > Thanks. > > >>> -Max >>> On Jan 19, 2013, at 3:53, Vincent Ryan >> > wrote: >>> >>>> Hello, >>>> >>>> Please review the fix for 8006591. It introduces a mechanism to enable >>>> stronger PBE algorithms to be specified when encrypting a keystore entry. >>>> This allows developers to make use of the new PBE algorithms delivered in >>>> JEP-121. Note however that PKCS12 is currently the only keystore that >>>> supports this new feature. >>>> >>>> It is a component of the JEP-166 delivery. >>>> >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.00/ >>>> >>>> Thanks. > From lance.andersen at oracle.com Sat Jan 19 07:12:19 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Sat, 19 Jan 2013 15:12:19 +0000 Subject: hg: jdk8/tl/jdk: 8006139: add missing methods to javax.sql.rowset.serial.SQLInputImpl, SQLOutputImpl Message-ID: <20130119151254.BFB80473F3@hg.openjdk.java.net> Changeset: 78514544980d Author: lancea Date: 2013-01-19 10:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78514544980d 8006139: add missing methods to javax.sql.rowset.serial.SQLInputImpl, SQLOutputImpl Reviewed-by: naoto, ulfzibis, alanb ! src/share/classes/javax/sql/rowset/serial/SQLInputImpl.java ! src/share/classes/javax/sql/rowset/serial/SQLOutputImpl.java From lance.andersen at oracle.com Sat Jan 19 07:53:33 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Sat, 19 Jan 2013 15:53:33 +0000 Subject: hg: jdk8/tl/jdk: 8005080: JDBC 4.2 Core changes Message-ID: <20130119155356.2F255473F4@hg.openjdk.java.net> Changeset: d3da0d29d7cd Author: lancea Date: 2013-01-19 10:53 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d3da0d29d7cd 8005080: JDBC 4.2 Core changes Reviewed-by: naoto ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/CallableStatement.java ! src/share/classes/java/sql/DatabaseMetaData.java ! src/share/classes/java/sql/Driver.java ! src/share/classes/java/sql/DriverManager.java + src/share/classes/java/sql/JDBCType.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/ResultSet.java ! src/share/classes/java/sql/SQLTimeoutException.java + src/share/classes/java/sql/SQLType.java ! src/share/classes/java/sql/Statement.java ! src/share/classes/java/sql/Types.java ! src/share/classes/java/sql/package.html ! src/share/classes/javax/sql/DataSource.java ! src/share/classes/javax/sql/XADataSource.java ! src/share/classes/javax/sql/rowset/BaseRowSet.java From xuelei.fan at oracle.com Sat Jan 19 18:31:30 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sun, 20 Jan 2013 10:31:30 +0800 Subject: Code Review Request for 7030966, Support AEAD CipherSuites (JSSE part of JEP 115) In-Reply-To: <50FA54AE.6040701@oracle.com> References: <50AE3DF0.1020400@oracle.com> <50BE11A6.2070205@oracle.com> <50CE8875.3060104@oracle.com> <50F8A1A2.3090508@oracle.com> <50F981B5.4090206@oracle.com> <50F9E10D.6050300@oracle.com> <50FA0E9F.5090809@oracle.com> <50FA54AE.6040701@oracle.com> Message-ID: <50FB5702.4070709@oracle.com> webrev: http://cr.openjdk.java.net./~xuelei/7030966/webrev.03/ A significant update of CipherBox.java. We are not able to know whether a cipher for a particular key size is available or not until the cipher is successfully initialized. For example, we can get instance for "AES/GCM/NoPadding". But we don't known whether the instance can work with AES-128 or AES-256 or not unless we the Cipher.init() is called. In the past, when a CipherBox is constructed, the cipher is always initialized. However, for AEAD ciphers, we cannot initialized the cipher in the constructor. We need an additional method to tell whether a CipherBox is available or not for AEAD ciphers. The CipherSuite.BulkCipher.isAvailable() will use this method to test the availability of a cipher suites. Thanks, Xuelei -------------- next part -------------- /* * Is this cipher available? * * This method can only be called by CipherSuite.BulkCipher.isAvailable() * to test the availability of a cipher suites. Please DON'T use it in * other places, otherwise, the behavior may be unexpected because we may * initialize AEAD cipher improperly in the method. */ Boolean isAvailable() { // We won't know whether a cipher for a particular key size is // available until the cipher is successfully initialized. // // We do not initialize AEAD cipher in the constructor. Need to // initialize the cipher to ensure that the AEAD mode for a // particular key size is supported. if (cipherType == AEAD_CIPHER) { try { Authenticator authenticator = new Authenticator(protocolVersion); byte[] nonce = authenticator.sequenceNumber(); byte[] iv = Arrays.copyOf(fixedIv, fixedIv.length + nonce.length); System.arraycopy(nonce, 0, iv, fixedIv.length, nonce.length); GCMParameterSpec spec = new GCMParameterSpec(tagSize * 8, iv); cipher.init(mode, key, spec, random); } catch (Exception e) { return Boolean.FALSE; } } // Otherwise, we have initialized the cipher in the constructor. return Boolean.TRUE; } From chris.hegarty at oracle.com Sun Jan 20 01:39:14 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Sun, 20 Jan 2013 09:39:14 +0000 Subject: hg: jdk8/tl/jdk: 8006560: java/net/ipv6tests/B6521014.java fails intermittently Message-ID: <20130120093937.554AE47407@hg.openjdk.java.net> Changeset: bb2ed83676d2 Author: chegar Date: 2013-01-20 09:37 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2ed83676d2 8006560: java/net/ipv6tests/B6521014.java fails intermittently Reviewed-by: khazra, wetmore ! test/java/net/ipv6tests/B6521014.java From bernd-2013 at eckenfels.net Sun Jan 20 15:25:08 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Mon, 21 Jan 2013 00:25:08 +0100 Subject: Ignore SSL server_name extension alerts (Bug 7127374) Message-ID: Hello, quite some time back I reported a bug, that the SSLSocket of Java will terminate connections to servers which respond with a unrecognized_name alert. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7127374 This was introduced since the SSLSocket started to send the SNI extension record in the client hello. My bug was closed without giving me the chance to comment on the analysis, so I will do that here now: The sample SSL Server on timestamp.geotrust.com:443 (still) responds with a unrecognized_name alert when you sent a SNI extension. (It is most likely wronly configured, since there are a lot of different CA francises behind that infrastructure). However the alert which is received by the SSL client is only a warning level, and it could be ignored by the SSL library. openssl or web browsers do continue if they get such a warning. I would argue the same should happen for Java. In fact I wonder if we need a API for SSLSockets which allow to set more options like - what extensions to send - what warnings to accept - what type of renegotiation (and how often) is allowed It should also have a getWarnings() method (similiar to JDBC). BTW: the class SimpleBIOSSLClient on https://github.com/ecki/JavaCryptoTest/tree/master/src/main/java/net/eckenfels/test/ssl will try to do a SSL handshake with hardcoded code and print the output. If you connect that to the geotrust server you can clearly see, that the handshake received is a warning and the endpoint continues with further handshake steps. (see output below). The client is not completed yet, so the Finish message is not valid yet, so this is why you see a second (fatal) alert. I think ignoring the unrecognized_name alert is no security problem, as you will verify the endpoint via the received certificate anway. >>> Record type=22 version=3.1 len=118 Handshake client_hello len=114 bytes=03 01 ff ff ff ff 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 00 00 2a 00 0a 00 07 00 05 00 04 00 39 00 13 00 66 00 65 00 64 00 63 00 62 00 61 00 60 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00 1f 00 00 00 1b 00 19 00 00 16 74 69 6d 65 73 74 61 6d 70 2e 67 65 6f 74 72 75 73 74 2e 63 6f 6d <<< Record type=22 version=3.1 len=80 Handshake server_hello len=76 Version=3.1 serverrandom=50 fc 7b 24 28 ac 20 67 2b 6a b9 e7 63 b8 75 7b 41 d3 1f 5c ad 73 7f ff 17 38 91 4d 94 02 48 ff session =32/6a d8 1d c4 7d 7f d3 17 82 55 bd 32 9b cf 17 d5 35 55 ff 0b c0 ff 5b e2 60 cc 16 db a1 e7 91 77 suite=10 compression=0 bytes=00 04 00 00 00 00 <<< Record type=22 version=3.1 len=876 Handshake certificate len=872 listlen=869 DN=CN=timestamp.geotrust.com, OU=Production Security Services, O=GeoTrust Inc., L=Mountain View, ST=California, C=US, SERIALNUMBER=zeSjNRSVdrWJbAzTb281UTdfbGNtENPJ RSA/500 <<< Record type=22 version=3.1 len=4 Handshake server_hello_done len=0 >>> Record type=22 version=3.1 len=134 Handshake client_key_exchange len=130 bytes=00 80 78 bd f4 70 af 2e f2 d4 7c 11 74 5e 9c 51 12 63 d2 96 99 07 3a ec 19 c5 b6 76 4a 2c da 21 d7 31 6c c6 6e 8a 70 73 80 1f dd 7a e6 5f 58 9b ae 29 92 8b 3c 12 fd f7 b6 8b 13 d6 fa 04 46 84 6e 05 3e 12 a4 87 90 3f 3f 8c 5d 1b 00 65 a4 22 fa 4e 2d b4 6a ec 21 aa 8f f0 0f df 63 cb 8e 6c 1c 05 15 35 fa 53 1d ad 3f fb 3f 3a c0 ce fb 5f 89 a7 c6 6c 1d 2b 98 20 92 37 10 fc 0f 08 11 1d dc 22 >>> Record type=20 version=3.1 len=1 Change Cipher Spec bytes=01 >>> Record type=22 version=3.1 len=36 Handshake Encrypted bytes=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <<< Record type=21 version=3.1 len=2 Alert len=7 fatal(2) decryption_failed BTW: openssl s_server has a option if the alert should be warning or fatal, so it can be expected the servers decide for themself if they want to continue or not. Greetings Bernd PS: there are more affected than only the above time stamping authority (and jarsigner): - http://stackoverflow.com/questions/7615645/ssl-handshake-alert-unrecognized-name-error-since-upgrade-to-java-1-7-0 - http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7177232 -- http://bernd.eckenfels.net From weijun.wang at oracle.com Sun Jan 20 16:57:01 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 21 Jan 2013 08:57:01 +0800 Subject: [8] Request for review: 8006092: SecurityPermission: printIdentity doesn't exist In-Reply-To: <50F9D448.5000604@oracle.com> References: <50F9D448.5000604@oracle.com> Message-ID: <50FC925D.3000903@oracle.com> The fix is fine. Do you want me to push the changes for you? Thanks Max On 01/19/2013 07:01 AM, Jason Uh wrote: > Hi all, > > This change fixes the test > test/sun/security/tools/policytool/UpdatePermissions.sh, a manual > policytool test that asks the user to select printIdentity from the list > of Target Names for SecurityPermission even though printIdentity is not > listed. > > java.security.Identity is deprecated so its omission is by design. I've > replaced printIdentity with a different SecurityPermission target. > > webrev: http://cr.openjdk.java.net/~juh/8006092/webrev.00/ > bug: http://bugs.sun.com/view_bug.do?bug_id=8006092 > > Thanks, > Jason From weijun.wang at oracle.com Sun Jan 20 17:51:58 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 21 Jan 2013 09:51:58 +0800 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit Message-ID: <50FC9F3E.60109@oracle.com> Please take a look at the webrev at http://cr.openjdk.java.net/~weijun/8006564/webrev.00/ Bug is http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006564 The S11N.sh test uses /java to try to access old JDKs. When the test is running at Russia, /java exists but is on the other side of the globe, and a timeout happens. This fix has created a jdk6-style class and use it to check for compatibility. Not precise but enough for this test. Thanks Max From masayoshi.okutsu at oracle.com Sun Jan 20 19:06:51 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Mon, 21 Jan 2013 03:06:51 +0000 Subject: hg: jdk8/tl/jdk: 4745761: (cal) RFE: Support builder for constructing Calendar Message-ID: <20130121030714.D5F3D47410@hg.openjdk.java.net> Changeset: 6ca6b6f07653 Author: okutsu Date: 2013-01-21 12:04 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ca6b6f07653 4745761: (cal) RFE: Support builder for constructing Calendar Reviewed-by: peytoia ! src/share/classes/java/util/Calendar.java ! src/share/classes/java/util/GregorianCalendar.java ! src/share/classes/java/util/JapaneseImperialCalendar.java + test/java/util/Calendar/Builder/BuilderTest.java ! test/java/util/Calendar/CalendarTypeTest.java From bernd-2013 at eckenfels.net Sun Jan 20 20:12:32 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Mon, 21 Jan 2013 05:12:32 +0100 Subject: Ignore SSL server_name extension alerts (Bug 7127374) In-Reply-To: References: Message-ID: Hello, Am 21.01.2013, 00:25 Uhr, schrieb Bernd Eckenfels : > bytes=03 01 ff ff ff ff 11 22 33 44 11 22 33 44 11 22 33 44 11 22 > 33 44 11 22 33 44 11 22 33 44 11 22 33 44 00 00 2a 00 0a 00 07 00 05 00 > 04 00 39 00 13 00 66 00 65 00 64 00 63 00 62 00 61 00 60 00 15 00 12 00 > 09 00 14 00 11 00 08 00 06 00 03 01 00 00 1f 00 00 00 1b 00 19 00 00 16 > 74 69 6d 65 73 74 61 6d 70 2e 67 65 6f 74 72 75 73 74 2e 63 6f 6d It seems like while I was testing this the server was fixed, the warning I saw on the console in the first try did not show up in the next, and was therefore not in the pasted text... strange. Using the correct name now skips the warning alert: #Connecting timestamp.geotrust.com:443 sni=timestamp.geotrust.com #>>> Record type=22 version=3.1 len=118 # Handshake client_hello len=114 # bytes=03 01 ff ff ff ff 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 00 00 2a 00 0a 00 07 00 05 00 04 00 39 00 13 00 66 00 65 00 64 00 63 00 62 00 61 00 60 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00 1f 00 00 00 1b 00 19 00 00 16 74 69 6d 65 73 74 61 6d 70 2e 67 65 6f 74 72 75 73 74 2e 63 6f 6d #<<< Record type=22 version=3.1 len=80 # Handshake server_hello len=76 If I sent a wrong SNI, the warning is still received: #Connecting timestamp.geotrust.com:443 sni=timestamp.geotrust2.com #>>> Record type=22 version=3.1 len=119 # Handshake client_hello len=115 # bytes=03 01 ff ff ff ff 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 00 00 2a 00 0a 00 07 00 05 00 04 00 39 00 13 00 66 00 65 00 64 00 63 00 62 00 61 00 60 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00 20 00 00 00 1c 00 1a 00 00 17 74 69 6d 65 73 74 61 6d 70 2e 67 65 6f 74 72 75 73 74 32 2e 63 6f 6d # <<< Record type=21 version=3.1 len=2 # Alert len=7 # warning(1) unrecognized_name #<<< Record type=22 version=3.1 len=80 # Handshake server_hello len=76 Same behaviour on my (apache) server: #Connecting neskaya.eckenfels.com:443 sni=neskaya.eckenfels.com #>>> Record type=22 version=3.1 len=117 # Handshake client_hello len=113 # bytes=03 01 ff ff ff ff 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 00 00 2a 00 0a 00 07 00 05 00 04 00 39 00 13 00 66 00 65 00 64 00 63 00 62 00 61 00 60 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00 1e 00 00 00 1a 00 18 00 00 15 6e 65 73 6b 61 79 61 2e 65 63 6b 65 6e 66 65 6c 73 2e 63 6f 6d #<<< Record type=22 version=3.1 len=80 # Handshake server_hello len=76 here is an alias which is not properly configured on the server and sends the alert (but it is the alias the certificate is verified, so in case of a web browser there will be no warning - but Java aborts) #Connecting www.eckenfels.com:443 sni=www.eckenfels.com #>>> Record type=22 version=3.1 len=113 # Handshake client_hello len=109 # bytes=03 01 ff ff ff ff 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 11 22 33 44 00 00 2a 00 0a 00 07 00 05 00 04 00 39 00 13 00 66 00 65 00 64 00 63 00 62 00 61 00 60 00 15 00 12 00 09 00 14 00 11 00 08 00 06 00 03 01 00 00 1a 00 00 00 16 00 14 00 00 11 77 77 77 2e 65 63 6b 65 6e 66 65 6c 73 2e 63 6f 6d #<<< Record type=21 version=3.1 len=2 # Alert len=7 # warning(1) unrecognized_name #<<< Record type=22 version=3.1 len=80 # Handshake server_hello len=76 Sorry for the confusion. (the new SimpleBIOSSLClient version which allows 3 arguments is now on github) Bernd From masayoshi.okutsu at oracle.com Sun Jan 20 22:44:38 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Mon, 21 Jan 2013 06:44:38 +0000 Subject: hg: jdk8/tl/jdk: 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI; ... Message-ID: <20130121064458.EBD9847413@hg.openjdk.java.net> Changeset: 3c1a440a1e12 Author: okutsu Date: 2013-01-21 15:41 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c1a440a1e12 8004489: Add support for Minguo and Hijrah calendars to CalendarNameProvider SPI 8006509: Add more calendar symbol names from CLDR Reviewed-by: peytoia ! make/tools/src/build/tools/cldrconverter/Bundle.java ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/CalendarType.java ! make/tools/src/build/tools/cldrconverter/LDMLParseHandler.java ! src/share/classes/java/util/spi/CalendarNameProvider.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! src/share/classes/sun/text/resources/be/FormatData_be.java ! src/share/classes/sun/text/resources/bg/FormatData_bg.java ! src/share/classes/sun/text/resources/ca/FormatData_ca.java ! src/share/classes/sun/text/resources/cs/FormatData_cs.java ! src/share/classes/sun/text/resources/da/FormatData_da.java ! src/share/classes/sun/text/resources/de/FormatData_de.java ! src/share/classes/sun/text/resources/el/FormatData_el.java ! src/share/classes/sun/text/resources/es/FormatData_es.java ! src/share/classes/sun/text/resources/et/FormatData_et.java ! src/share/classes/sun/text/resources/fi/FormatData_fi.java ! src/share/classes/sun/text/resources/fr/FormatData_fr.java ! src/share/classes/sun/text/resources/hi/FormatData_hi_IN.java ! src/share/classes/sun/text/resources/hr/FormatData_hr.java ! src/share/classes/sun/text/resources/hu/FormatData_hu.java ! src/share/classes/sun/text/resources/is/FormatData_is.java ! src/share/classes/sun/text/resources/it/FormatData_it.java ! src/share/classes/sun/text/resources/iw/FormatData_iw.java ! src/share/classes/sun/text/resources/ja/FormatData_ja.java ! src/share/classes/sun/text/resources/ko/FormatData_ko.java ! src/share/classes/sun/text/resources/lt/FormatData_lt.java ! src/share/classes/sun/text/resources/lv/FormatData_lv.java ! src/share/classes/sun/text/resources/mk/FormatData_mk.java ! src/share/classes/sun/text/resources/ms/FormatData_ms.java ! src/share/classes/sun/text/resources/mt/FormatData_mt.java ! src/share/classes/sun/text/resources/nl/FormatData_nl.java ! src/share/classes/sun/text/resources/pl/FormatData_pl.java ! src/share/classes/sun/text/resources/pt/FormatData_pt.java ! src/share/classes/sun/text/resources/ro/FormatData_ro.java ! src/share/classes/sun/text/resources/ru/FormatData_ru.java ! src/share/classes/sun/text/resources/sk/FormatData_sk.java ! src/share/classes/sun/text/resources/sl/FormatData_sl.java ! src/share/classes/sun/text/resources/sr/FormatData_sr.java ! src/share/classes/sun/text/resources/sv/FormatData_sv.java ! src/share/classes/sun/text/resources/th/FormatData_th.java ! src/share/classes/sun/text/resources/tr/FormatData_tr.java ! src/share/classes/sun/text/resources/uk/FormatData_uk.java ! src/share/classes/sun/text/resources/vi/FormatData_vi.java ! src/share/classes/sun/text/resources/zh/FormatData_zh.java ! src/share/classes/sun/text/resources/zh/FormatData_zh_TW.java ! src/share/classes/sun/util/locale/provider/CalendarDataUtility.java ! src/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java ! src/share/classes/sun/util/locale/provider/LocaleResources.java + test/java/util/Calendar/CldrFormatNamesTest.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java From weijun.wang at oracle.com Sun Jan 20 23:06:19 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 21 Jan 2013 07:06:19 +0000 Subject: hg: jdk8/tl/jdk: 8006092: SecurityPermission: printIdentity doesn't exist Message-ID: <20130121070641.C5D8A47414@hg.openjdk.java.net> Changeset: bb940b2107bd Author: juh Date: 2013-01-21 15:05 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb940b2107bd 8006092: SecurityPermission: printIdentity doesn't exist Reviewed-by: weijun ! test/sun/security/tools/policytool/UpdatePermissions.html From taras.ledkov at oracle.com Mon Jan 21 01:44:18 2013 From: taras.ledkov at oracle.com (taras ledkov) Date: Mon, 21 Jan 2013 13:44:18 +0400 Subject: [8] Code review request for 8006591: Protect keystore entries using stronger PBE algorithms In-Reply-To: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> References: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> Message-ID: <50FD0DF2.4070104@oracle.com> class: KeyStore.PasswordProtection method: (char[] password, String protectionAlgorithm, AlgorithmParameterSpec protectionParameters) At the javadoc header about protectionParameters: * @param protectionParameters the encryption algorithm parameter * specification, which may be {@code null} But the first line of the method we can see: if (protectionAlgorithm == null) { throw new NullPointerException("invalid null input"); } I see a contradiction here. Please comment. On 18.01.2013 23:53, Vincent Ryan wrote: > Hello, > > Please review the fix for 8006591. It introduces a mechanism to enable > stronger PBE algorithms to be specified when encrypting a keystore entry. > This allows developers to make use of the new PBE algorithms delivered in > JEP-121. Note however that PKCS12 is currently the only keystore that > supports this new feature. > > It is a component of the JEP-166 delivery. > > Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.00/ > > Thanks. -- With best regards, Taras Ledkov Mail-To: taras.ledkov at oracle.com skype: taras_ledkov Phone: 7(812)3346-157 From vincent.x.ryan at oracle.com Mon Jan 21 02:31:24 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 21 Jan 2013 10:31:24 +0000 Subject: [8] Code review request for 8006591: Protect keystore entries using stronger PBE algorithms In-Reply-To: <50FD0DF2.4070104@oracle.com> References: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> <50FD0DF2.4070104@oracle.com> Message-ID: <4CED7548-A8C3-4036-BD53-45B762EF2EEC@oracle.com> NPE is only thrown if protectionAlgorithm is null. On 21 Jan 2013, at 09:44, taras ledkov wrote: > class: KeyStore.PasswordProtection > method: (char[] password, String protectionAlgorithm, AlgorithmParameterSpec protectionParameters) > > At the javadoc header about protectionParameters: > > * @param protectionParameters the encryption algorithm parameter > * specification, which may be {@code null} > > But the first line of the method we can see: > if (protectionAlgorithm == null) { > throw new NullPointerException("invalid null input"); > } > > I see a contradiction here. > Please comment. > > > On 18.01.2013 23:53, Vincent Ryan wrote: >> Hello, >> >> Please review the fix for 8006591. It introduces a mechanism to enable >> stronger PBE algorithms to be specified when encrypting a keystore entry. >> This allows developers to make use of the new PBE algorithms delivered in >> JEP-121. Note however that PKCS12 is currently the only keystore that >> supports this new feature. >> >> It is a component of the JEP-166 delivery. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.00/ >> >> Thanks. > > -- > With best regards, > Taras Ledkov > Mail-To: taras.ledkov at oracle.com > skype: taras_ledkov > Phone: 7(812)3346-157 From fweimer at redhat.com Mon Jan 21 02:59:25 2013 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 21 Jan 2013 11:59:25 +0100 Subject: [8] Code review request for 6263419: No way to clean the memory for a java.security.Key In-Reply-To: <50F82F2B.5050608@oracle.com> References: <50F82F2B.5050608@oracle.com> Message-ID: <50FD1F8D.5080803@redhat.com> On 01/17/2013 06:04 PM, Vincent Ryan wrote: > Please review the fix for 6263419. It introduces a mechanism to destroy > the sensitive data associated with private keys and secret keys. It is > a component of the JEP-166 delivery. > > Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.00/ > > Implementers of JCE security providers can override the default method > implementations in the Destroyable interface to allow applications to > take advantage of this new facility. We intend to update our key > implementation classes soon. How does this change interact with the existing approaches? Some crypto-related classes use a finalize() method to trigger overwriting the key material. I'm a bit worried that this old approach extends the life time of the key material considerably (because it has to be kept around until finalizers run). Keeping a reference to a key object just to be able to overwrite it could have the same effect. -- Florian Weimer / Red Hat Product Security Team From vincent.x.ryan at oracle.com Mon Jan 21 03:43:49 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 21 Jan 2013 11:43:49 +0000 Subject: [8] Code review request for 6263419: No way to clean the memory for a java.security.Key In-Reply-To: <50FD1F8D.5080803@redhat.com> References: <50F82F2B.5050608@oracle.com> <50FD1F8D.5080803@redhat.com> Message-ID: On 21 Jan 2013, at 10:59, Florian Weimer wrote: > On 01/17/2013 06:04 PM, Vincent Ryan wrote: > >> Please review the fix for 6263419. It introduces a mechanism to destroy >> the sensitive data associated with private keys and secret keys. It is >> a component of the JEP-166 delivery. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.00/ >> >> Implementers of JCE security providers can override the default method >> implementations in the Destroyable interface to allow applications to >> take advantage of this new facility. We intend to update our key >> implementation classes soon. > > How does this change interact with the existing approaches? Some crypto-related classes use a finalize() method to trigger overwriting the key material. > > I'm a bit worried that this old approach extends the life time of the key material considerably (because it has to be kept around until finalizers run). Keeping a reference to a key object just to be able to overwrite it could have the same effect. > > -- > Florian Weimer / Red Hat Product Security Team Hello Florian, Depending on a finalizer is a little unpredictable so this new approach is preferred. I don't think it will have any detrimental impact on existing approaches. Implementers can always choose to destroy key material in advance of any call to its destroy() method. From chris.hegarty at oracle.com Mon Jan 21 05:51:26 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 21 Jan 2013 13:51:26 +0000 Subject: hg: jdk8/tl/jdk: 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder Message-ID: <20130121135207.0FE2947420@hg.openjdk.java.net> Changeset: f21a3c273fb2 Author: dl Date: 2013-01-21 13:50 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f21a3c273fb2 8005311: Add Scalable Updatable Variables, DoubleAccumulator, DoubleAdder, LongAccumulator, LongAdder Reviewed-by: chegar, darcy, goetz ! make/java/java/FILES_java.gmk + src/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java + src/share/classes/java/util/concurrent/atomic/DoubleAdder.java + src/share/classes/java/util/concurrent/atomic/LongAccumulator.java + src/share/classes/java/util/concurrent/atomic/LongAdder.java + src/share/classes/java/util/concurrent/atomic/Striped64.java + test/java/util/concurrent/atomic/DoubleAdderDemo.java + test/java/util/concurrent/atomic/LongAdderDemo.java From Alan.Bateman at oracle.com Mon Jan 21 05:58:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jan 2013 13:58:20 +0000 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <50FC9F3E.60109@oracle.com> References: <50FC9F3E.60109@oracle.com> Message-ID: <50FD497C.3050609@oracle.com> On 21/01/2013 01:51, Weijun Wang wrote: > Please take a look at the webrev at > > http://cr.openjdk.java.net/~weijun/8006564/webrev.00/ > > Bug is > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006564 > > The S11N.sh test uses /java to try to access old JDKs. When the test > is running at Russia, /java exists but is on the other side of the > globe, and a timeout happens. > > This fix has created a jdk6-style class and use it to check for > compatibility. Not precise but enough for this test. > > Thanks > Max It's good to see the dependency on /java/re removed but I'm not sure that I like the -Xbootclasspath/o:old because it is too tied into the implementation. Have you considered just put the serial versions of the older releases into a byte array and have test use that? It would of course require having a way to easily re-create the byte array (should be clear instructions). -Alan From weijun.wang at oracle.com Mon Jan 21 06:19:11 2013 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 21 Jan 2013 22:19:11 +0800 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <50FD497C.3050609@oracle.com> References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> Message-ID: I've thought about that, but it means there is no way to check forward-compatibility. (Am I using the correct word? Deserialize jdk7 format with jdk6). Max ?? 2013-1-21??????9:58??Alan Bateman ?????? > On 21/01/2013 01:51, Weijun Wang wrote: >> Please take a look at the webrev at >> >> http://cr.openjdk.java.net/~weijun/8006564/webrev.00/ >> >> Bug is >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006564 >> >> The S11N.sh test uses /java to try to access old JDKs. When the test is running at Russia, /java exists but is on the other side of the globe, and a timeout happens. >> >> This fix has created a jdk6-style class and use it to check for compatibility. Not precise but enough for this test. >> >> Thanks >> Max > It's good to see the dependency on /java/re removed but I'm not sure that I like the -Xbootclasspath/o:old because it is too tied into the implementation. > > Have you considered just put the serial versions of the older releases into a byte array and have test use that? It would of course require having a way to easily re-create the byte array (should be clear instructions). > > -Alan > From Alan.Bateman at oracle.com Mon Jan 21 06:21:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Jan 2013 14:21:28 +0000 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> Message-ID: <50FD4EE8.4090107@oracle.com> On 21/01/2013 14:19, Wang Weijun wrote: > I've thought about that, but it means there is no way to check forward-compatibility. (Am I using the correct word? Deserialize jdk7 format with jdk6). > > Max Right, but this is a test in the jdk8 forest and so it should only be testing jdk8. -Alan From weijun.wang at oracle.com Mon Jan 21 06:25:38 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 21 Jan 2013 22:25:38 +0800 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <50FD4EE8.4090107@oracle.com> References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> <50FD4EE8.4090107@oracle.com> Message-ID: <50FD4FE2.5090805@oracle.com> Oh, did I mention jdk8 and jdk7 are using the same format? In fact, I don't think it's "too tied to impl", you can see that my fake jdk6-style class is quite clean itself so it's just a reimpl of the jdk6 serialization interface. I was more concerned about using the -Xbootclasspath option, which many people (including you) had said will be unusable after module. -Max On 01/21/2013 10:21 PM, Alan Bateman wrote: > On 21/01/2013 14:19, Wang Weijun wrote: >> I've thought about that, but it means there is no way to check forward-compatibility. (Am I using the correct word? Deserialize jdk7 format with jdk6). >> >> Max > Right, but this is a test in the jdk8 forest and so it should only be > testing jdk8. > > -Alan > From vincent.x.ryan at oracle.com Mon Jan 21 07:18:59 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Mon, 21 Jan 2013 15:18:59 +0000 Subject: [8] Code review request for 8005408: KeyStore API enhancements Message-ID: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> Hello, Please review the fix for 8005408. It adds support for associating attributes with keystore entries. It is yet another component of the JEP-166 delivery. This new API permits several enhancements to the PKCS12 keystore implementation: the storage of trusted certificates, storage of secret keys and support for entry metadata. Currently, only the PKCS12 keystore takes advantage of these new KeyStore APIs. Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ For storing trusted certificates in PKCS12 a new SafeBag attribute (with a familiar syntax) is introduced to indicate a trust usage: trustedKeyUsage ATTRIBUTE ::= { WITH SYNTAX ExtKeyUsageSyntax ID id-at-trustedKeyUsage -- object identifier from an Oracle arc } -- from RFC 5832, Section 4.2.1.12 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } Note that this approach does not preclude the storage of a Trust Anchor List (as defined in RFC 5914) which was proposed earlier on this list. There is one omission from the webrev above: the java.security.PKCS12Attribute class needs some additional changes and will be posted shortly. Again, JEP-166 is on a tight schedule for M6 so your early comments are appreciated. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130121/7b4c63aa/attachment-0001.html From jonathan.gibbons at oracle.com Mon Jan 21 10:01:30 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 21 Jan 2013 18:01:30 +0000 Subject: hg: jdk8/tl/langtools: 8006263: Supplementary test cases needed for doclint Message-ID: <20130121180135.C92B34742C@hg.openjdk.java.net> Changeset: 4a3cfc970c6f Author: jjg Date: 2013-01-21 10:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a3cfc970c6f 8006263: Supplementary test cases needed for doclint Reviewed-by: mcimadamore Contributed-by: peter.jensen at oracle.com ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/DocLint.java ! src/share/classes/com/sun/tools/doclint/Entity.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java + test/tools/doclint/CoverageExtras.java ! test/tools/doclint/DocLintTester.java + test/tools/doclint/html/EntitiesTest.java + test/tools/doclint/html/EntitiesTest.out + test/tools/doclint/tool/HelpTest.java + test/tools/doclint/tool/HelpTest.out + test/tools/doclint/tool/MaxDiagsTest.java + test/tools/doclint/tool/MaxDiagsTest.out + test/tools/doclint/tool/PathsTest.java + test/tools/doclint/tool/RunTest.java + test/tools/doclint/tool/StatsTest.java + test/tools/doclint/tool/StatsTest.out From jonathan.gibbons at oracle.com Mon Jan 21 10:07:48 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 21 Jan 2013 18:07:48 +0000 Subject: hg: jdk8/tl/langtools: 8006251: doclint: incorrect position for diagnostic for illegal text in tags Message-ID: <20130121180751.01A7D4742D@hg.openjdk.java.net> Changeset: 967052c425a1 Author: jjg Date: 2013-01-21 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/967052c425a1 8006251: doclint: incorrect position for diagnostic for illegal text in tags Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/doclint/Checker.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! src/share/classes/com/sun/tools/doclint/resources/doclint.properties ! test/tools/doclint/HtmlTagsTest.java ! test/tools/doclint/HtmlTagsTest.out + test/tools/doclint/html/BlockTagsTest.java + test/tools/doclint/html/InlineTagsTest.java + test/tools/doclint/html/ListTagsTest.java + test/tools/doclint/html/OtherTagsTest.java + test/tools/doclint/html/OtherTagsTest.out + test/tools/doclint/html/TableTagsTest.java + test/tools/doclint/html/TagNotAllowed.java + test/tools/doclint/html/TagNotAllowed.out + test/tools/doclint/html/TextNotAllowed.java + test/tools/doclint/html/TextNotAllowed.out ! test/tools/doclint/tidy/ParaInPre.out ! test/tools/doclint/tidy/TextNotAllowed.out From lance.andersen at oracle.com Mon Jan 21 11:09:16 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 21 Jan 2013 19:09:16 +0000 Subject: hg: jdk8/tl/jdk: 8006642: Fix javadoc warnings due to Integer.MAX_VALUE Message-ID: <20130121190938.951684742F@hg.openjdk.java.net> Changeset: de30e46250c5 Author: lancea Date: 2013-01-21 14:08 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/de30e46250c5 8006642: Fix javadoc warnings due to Integer.MAX_VALUE Reviewed-by: alanb ! src/share/classes/java/sql/BatchUpdateException.java ! src/share/classes/java/sql/PreparedStatement.java ! src/share/classes/java/sql/Statement.java From lana.steuck at oracle.com Mon Jan 21 11:22:20 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:20 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130121192237.0070A47433@hg.openjdk.java.net> Changeset: 56c97aff46bb Author: katleman Date: 2013-01-16 12:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/56c97aff46bb Added tag jdk8-b73 for changeset 8d0baee36c71 ! .hgtags Changeset: b450959b42ff Author: lana Date: 2013-01-20 23:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b450959b42ff Merge Changeset: 1985e35e97b2 Author: lana Date: 2013-01-21 11:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/1985e35e97b2 Merge From lana.steuck at oracle.com Mon Jan 21 11:22:13 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:13 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b73 for changeset 191afde59e7b Message-ID: <20130121192216.0181147430@hg.openjdk.java.net> Changeset: 2132845cf5f7 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/2132845cf5f7 Added tag jdk8-b73 for changeset 191afde59e7b ! .hgtags From lana.steuck at oracle.com Mon Jan 21 11:22:13 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:13 +0000 Subject: hg: jdk8/tl: 28 new changesets Message-ID: <20130121192216.AFCED47431@hg.openjdk.java.net> Changeset: 4090847a5444 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4090847a5444 Added tag jdk8-b73 for changeset 93b9664f97ee ! .hgtags Changeset: 77f062a41850 Author: erikj Date: 2012-12-27 20:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/77f062a41850 8001942: build-infra: General permission problems on Windows/cygwin Summary: Added sanity check for file permissions in configure Reviewed-by: tbell, ohair ! common/autoconf/basics.m4 ! common/autoconf/generated-configure.sh Changeset: d2c1f80118de Author: erikj Date: 2012-12-27 20:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d2c1f80118de 8005540: build-infra: Improve incremental build speed on windows by caching find results Reviewed-by: ohair ! common/makefiles/IdlCompilation.gmk ! common/makefiles/JavaCompilation.gmk ! common/makefiles/MakeBase.gmk ! common/makefiles/NativeCompilation.gmk Changeset: d5f3a6f60d51 Author: erikj Date: 2012-12-27 20:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/d5f3a6f60d51 8005548: build-infra: Fix docs target on windows Summary: Fix path sep variable Reviewed-by: tbell ! common/makefiles/javadoc/Javadoc.gmk Changeset: ef6adbf511cc Author: erikj Date: 2012-12-28 09:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ef6adbf511cc 8005549: build-infra: Merge NewMakefile.gmk and common/makefiles/Makefile Reviewed-by: ohair, tbell ! NewMakefile.gmk ! common/autoconf/Makefile.in ! common/autoconf/generated-configure.sh + common/makefiles/Jprt.gmk ! common/makefiles/Main.gmk ! common/makefiles/MakeHelpers.gmk ! common/makefiles/Makefile Changeset: 2d9bb72b4e34 Author: erikj Date: 2012-12-30 12:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2d9bb72b4e34 8004490: build-infra: mac: hotspot is always built in product, regardless of --with-debug-level setting Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: abc8078e070b Author: erikj Date: 2013-01-01 14:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/abc8078e070b 8001895: build-infra: Make JDK_BUILD_NUMBER and MILESTONE customizable Summary: Added configure params Reviewed-by: ohair ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in ! common/autoconf/version.numbers Changeset: 14d7ebe42c8d Author: erikj Date: 2013-01-02 11:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/14d7ebe42c8d 8005347: build-infra: Verify 'gnumake source' at the top level works ok Reviewed-by: tbell, ohair, dholmes ! common/autoconf/basics.m4 - common/autoconf/closed.version.numbers ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 ! common/autoconf/spec.gmk.in = common/autoconf/version-numbers < common/autoconf/version.numbers Changeset: 348a881c6da0 Author: erikj Date: 2013-01-02 15:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/348a881c6da0 8005355: build-infra: Java security signing (need a top-level make target). Reviewed-by: tbell, ohair ! common/autoconf/spec.gmk.in ! common/makefiles/Main.gmk Changeset: befbad2e4d87 Author: erikj Date: 2013-01-03 20:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/befbad2e4d87 8005635: build-infra: Support building install in jprt Reviewed-by: ohair Contributed-by: tim.bell at oracle.com, erik.joelsson at oracle.com ! common/autoconf/generated-configure.sh ! common/autoconf/spec.gmk.in ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl ! common/makefiles/Jprt.gmk ! common/src/fixpath.c Changeset: 39194e004ade Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/39194e004ade 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! common/autoconf/compare.sh.in ! common/bin/compare.sh Changeset: 9263657c2756 Author: erikj Date: 2013-01-04 16:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9263657c2756 8005692: build-infra: Target "all" should do the right thing Reviewed-by: tbell ! common/makefiles/Main.gmk Changeset: c874a8a27933 Author: erikj Date: 2013-01-04 17:05 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c874a8a27933 8005597: build-infra: bridgeBuild broken for pure openjdk build Reviewed-by: tbell ! common/makefiles/Jprt.gmk Changeset: 7b9c42f14281 Author: erikj Date: 2013-01-04 17:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7b9c42f14281 8005654: build-infra: Create sec-bin.zip Reviewed-by: tbell ! common/bin/compare.sh ! common/makefiles/JavaCompilation.gmk Changeset: 2597feac57c0 Author: erikj Date: 2013-01-04 22:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2597feac57c0 8005723: build-infra: in new infra build, sec-windows-bin-zip and jgss-windows-*-bin.zip are missing Reviewed-by: tbell ! common/bin/compare.sh ! common/bin/compare_exceptions.sh.incl Changeset: 5cf7750c8c43 Author: ohair Date: 2013-01-04 21:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5cf7750c8c43 8004229: build-infra: Umbrella for switch of default "make" to new makefiles Reviewed-by: erikj, tbell ! Makefile ! make/jprt.properties Changeset: 7a3c6ffdf1fb Author: tbell Date: 2013-01-07 14:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/7a3c6ffdf1fb 8005442: autogen.sh sets DATE_WHEN_GENERATED to empty string on Solaris version 11 or later Reviewed-by: ohair ! common/autoconf/autogen.sh Changeset: 64a9ebad39fe Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/64a9ebad39fe Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers Changeset: b284980b7d9a Author: tbell Date: 2013-01-08 16:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b284980b7d9a 8005794: in new infra, how do we change java -version? Summary: Added configure parameter --with-user-release-suffix Reviewed-by: ohair, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: db3984e4eb97 Author: erikj Date: 2013-01-10 12:20 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/db3984e4eb97 8005858: build-infra: Add missed comparison of sec-windows-bin.zip and friends to compare.sh Reviewed-by: tbell, ohair ! common/bin/compare.sh Changeset: 6f8f7a5449f6 Author: erikj Date: 2013-01-11 10:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6f8f7a5449f6 8005850: build-infra: Make --enable-openjdk-only really disable custom Reviewed-by: ohair, dholmes ! common/autoconf/configure.ac ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: b66c81dfa291 Author: ohair Date: 2013-01-14 16:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b66c81dfa291 8005284: build-infra: nonstandard copyright headers under common/autoconf/build-aux Reviewed-by: katleman ! common/autoconf/build-aux/autoconf-config.guess ! common/autoconf/build-aux/config.sub ! common/autoconf/build-aux/pkg.m4 Changeset: 3540aa40c868 Author: erikj Date: 2013-01-14 13:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/3540aa40c868 8006074: build-infra: Configure fails to find SetEnv.Cmd in microsoft sdk Reviewed-by: tbell, ohair ! common/autoconf/basics_windows.m4 ! common/autoconf/generated-configure.sh Changeset: 6e822b534678 Author: erikj Date: 2013-01-14 15:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/6e822b534678 8006100: build-infra: Bundle up the correct images in jprt Reviewed-by: tbell ! NewMakefile.gmk ! common/makefiles/Jprt.gmk Changeset: 52cce3326649 Author: erikj Date: 2013-01-15 09:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/52cce3326649 Merge Changeset: fe1c94aca5a8 Author: katleman Date: 2013-01-15 10:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/fe1c94aca5a8 Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers Changeset: dc84b505b408 Author: katleman Date: 2013-01-16 22:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dc84b505b408 Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers ! common/bin/compare_exceptions.sh.incl Changeset: 2e12a508d7ae Author: lana Date: 2013-01-20 23:35 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2e12a508d7ae Merge - common/autoconf/closed.version.numbers - common/autoconf/version.numbers ! common/makefiles/javadoc/Javadoc.gmk From lana.steuck at oracle.com Mon Jan 21 11:22:19 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:19 +0000 Subject: hg: jdk8/tl/hotspot: 2 new changesets Message-ID: <20130121192230.9073F47432@hg.openjdk.java.net> Changeset: 41ccb2e737fb Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/41ccb2e737fb Added tag jdk8-b73 for changeset 11619f33cd68 ! .hgtags Changeset: 1a3e54283c54 Author: katleman Date: 2013-01-16 20:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1a3e54283c54 Merge ! .hgtags From lana.steuck at oracle.com Mon Jan 21 11:22:16 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:16 +0000 Subject: hg: jdk8/tl/jaxp: 6 new changesets Message-ID: <20130121192241.8359D47435@hg.openjdk.java.net> Changeset: cf0917c0d771 Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/cf0917c0d771 Added tag jdk8-b73 for changeset 84946404d1e1 ! .hgtags Changeset: 278a2f60c55b Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/278a2f60c55b 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! makefiles/BuildJaxp.gmk Changeset: 2e4d87e6662e Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2e4d87e6662e Merge Changeset: a317d3e1bbac Author: katleman Date: 2013-01-15 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a317d3e1bbac Merge Changeset: 2087e24a4357 Author: katleman Date: 2013-01-16 22:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/2087e24a4357 Merge Changeset: 4e049aa2495f Author: lana Date: 2013-01-20 23:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/4e049aa2495f Merge From lana.steuck at oracle.com Mon Jan 21 11:22:24 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:24 +0000 Subject: hg: jdk8/tl/jaxws: 5 new changesets Message-ID: <20130121192241.2371647434@hg.openjdk.java.net> Changeset: 68f508979ffe Author: katleman Date: 2013-01-16 11:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/68f508979ffe Added tag jdk8-b73 for changeset c606f644a5d9 ! .hgtags Changeset: 51f3117e2b75 Author: erikj Date: 2013-01-04 11:31 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/51f3117e2b75 8005575: build-infra: Three JCK tests fails on Solaris with new RE Autoconf-Based build Reviewed-by: ohair ! makefiles/BuildJaxws.gmk Changeset: dd7473082690 Author: katleman Date: 2013-01-08 13:14 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/dd7473082690 Merge Changeset: b8fd32e44c26 Author: katleman Date: 2013-01-15 10:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b8fd32e44c26 Merge Changeset: 12db3c5a3393 Author: katleman Date: 2013-01-16 22:17 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/12db3c5a3393 Merge From lana.steuck at oracle.com Mon Jan 21 11:22:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Mon, 21 Jan 2013 19:22:51 +0000 Subject: hg: jdk8/tl/jdk: 18 new changesets Message-ID: <20130121192706.4089847436@hg.openjdk.java.net> Changeset: 965e89e2abd3 Author: katleman Date: 2013-01-16 12:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/965e89e2abd3 Added tag jdk8-b73 for changeset 733885f57e14 ! .hgtags Changeset: e91caf05f441 Author: erikj Date: 2012-12-27 20:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e91caf05f441 8005540: build-infra: Improve incremental build speed on windows by caching find results Reviewed-by: ohair ! makefiles/BuildJdk.gmk ! makefiles/CompileDemos.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyIntoClasses.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcProperties.gmk ! makefiles/GensrcX11Wrappers.gmk ! makefiles/Images.gmk ! makefiles/Tools.gmk Changeset: 368fa50469da Author: erikj Date: 2012-12-28 09:51 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/368fa50469da 8005549: build-infra: Merge NewMakefile.gmk and common/makefiles/Makefile Reviewed-by: ohair, tbell ! makefiles/BuildJdk.gmk Changeset: 461b069100fa Author: erikj Date: 2013-01-02 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/461b069100fa 8005355: build-infra: Java security signing (need a top-level make target). Reviewed-by: tbell, ohair ! makefiles/BuildJdk.gmk ! makefiles/CompileJavaClasses.gmk ! makefiles/CreateJars.gmk + makefiles/SignJars.gmk Changeset: 3841da683703 Author: erikj Date: 2013-01-03 20:55 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3841da683703 8005635: build-infra: Support building install in jprt Reviewed-by: ohair Contributed-by: tim.bell at oracle.com, erik.joelsson at oracle.com ! make/common/shared/Defs-windows.gmk ! makefiles/BuildJdk.gmk ! makefiles/Bundles.gmk ! makefiles/Images.gmk ! makefiles/Tools.gmk Changeset: a8d25b689563 Author: erikj Date: 2013-01-04 16:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8d25b689563 8005694: build-infra: Cleanup of misc changes in build-infra Reviewed-by: tbell ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CreateJars.gmk Changeset: 3824d8469dcf Author: erikj Date: 2013-01-04 17:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3824d8469dcf 8005654: build-infra: Create sec-bin.zip Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: d98e73b7bc78 Author: erikj Date: 2013-01-04 22:43 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d98e73b7bc78 8005723: build-infra: in new infra build, sec-windows-bin-zip and jgss-windows-*-bin.zip are missing Reviewed-by: tbell ! makefiles/CreateJars.gmk Changeset: 244e481f538b Author: katleman Date: 2013-01-08 13:15 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/244e481f538b Merge ! makefiles/CreateJars.gmk Changeset: 1868bde529b8 Author: ohrstrom Date: 2013-01-09 13:33 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1868bde529b8 8005096: Move a few source files in swing/beaninfo and in a demo. Reviewed-by: ohair, erikj, malenkov ! make/javax/swing/beaninfo/SwingBeans.gmk - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java + make/tools/swing-beans/javax/swing/SwingBeanInfoBase.java + make/tools/swing-beans/sun/swing/BeanInfoUtils.java ! makefiles/CompileJavaClasses.gmk ! makefiles/GensrcSwing.gmk - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java + src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethod.java + src/share/demo/jfc/CodePointIM/com/sun/inputmethods/internal/codepointim/CodePointInputMethodDescriptor.java Changeset: 2cc29d0b9eaf Author: erikj Date: 2013-01-09 16:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cc29d0b9eaf 8005903: build-infra: bad symlink: j2sdk-bundle/jdk1.8.0.jdk/Contents/MacOS/libjli.dylib Reviewed-by: tbell ! makefiles/Bundles.gmk Changeset: f92ab6dbbff8 Author: erikj Date: 2013-01-10 12:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f92ab6dbbff8 8005856: build-infra: Remove special handling of base module classes header generation Reviewed-by: alanb, tbell, ohair Contributed-by: fredrik.ohrstrom at oracle.com ! makefiles/CompileJavaClasses.gmk ! src/share/classes/java/io/FileSystem.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java ! src/share/classes/java/net/SocketOptions.java ! src/share/classes/sun/nio/ch/IOStatus.java ! src/windows/classes/sun/nio/ch/PollArrayWrapper.java Changeset: 4d80ab394efa Author: erikj Date: 2013-01-15 16:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d80ab394efa 8006296: build-infra: Unsigned sunmscapi.jar is missing manifest. Reviewed-by: alanb, tbell ! makefiles/CreateJars.gmk Changeset: 6d1a3d43851d Author: katleman Date: 2013-01-15 10:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d1a3d43851d Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 3eef1e0540c4 Author: erikj Date: 2013-01-16 16:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3eef1e0540c4 8006385: build-infra: linux and solaris *-debuginfo-*.zip file created from the new makefile has extra HUDSON direcotry in jre/lib/i386/server Reviewed-by: tbell ! makefiles/Import.gmk Changeset: 54bbeb149525 Author: katleman Date: 2013-01-16 22:21 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54bbeb149525 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java ! makefiles/CompileLaunchers.gmk ! makefiles/CreateJars.gmk ! makefiles/Images.gmk ! src/share/classes/java/lang/Integer.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 8b1857409159 Author: lana Date: 2013-01-20 23:38 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8b1857409159 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: 7f4e3da76ec1 Author: lana Date: 2013-01-21 11:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f4e3da76ec1 Merge From maurizio.cimadamore at oracle.com Mon Jan 21 12:21:51 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 21 Jan 2013 20:21:51 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130121202204.8A33747438@hg.openjdk.java.net> Changeset: 7873d37f5b37 Author: mcimadamore Date: 2013-01-21 20:13 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7873d37f5b37 8005244: Implement overload resolution as per latest spec EDR Summary: Add support for stuck expressions and provisional applicability Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.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/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! test/tools/javac/Diagnostics/6722234/T6722234d_1.out ! test/tools/javac/Diagnostics/6722234/T6722234d_2.out ! test/tools/javac/diags/examples.not-yet.txt ! test/tools/javac/diags/examples/CyclicInference.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java ! test/tools/javac/diags/examples/WhereIntersection.java ! test/tools/javac/generics/diamond/T6939780.out ! test/tools/javac/generics/diamond/neg/Neg05.out ! test/tools/javac/generics/diamond/neg/Neg10.java ! test/tools/javac/generics/diamond/neg/Neg10.out ! test/tools/javac/generics/inference/6315770/T6315770.out ! test/tools/javac/generics/inference/6638712/T6638712b.out ! test/tools/javac/generics/inference/6650759/T6650759m.out ! test/tools/javac/lambda/MethodReference25.java + test/tools/javac/lambda/MethodReference25.out ! test/tools/javac/lambda/MethodReference26.java - test/tools/javac/lambda/MethodReference26.out ! test/tools/javac/lambda/MethodReference43.java ! test/tools/javac/lambda/TargetType01.java + test/tools/javac/lambda/TargetType01.out ! test/tools/javac/lambda/TargetType06.java - test/tools/javac/lambda/TargetType06.out ! test/tools/javac/lambda/TargetType10.out ! test/tools/javac/lambda/TargetType11.java - test/tools/javac/lambda/TargetType11.out ! test/tools/javac/lambda/TargetType14.out ! test/tools/javac/lambda/TargetType21.java ! test/tools/javac/lambda/TargetType21.out ! test/tools/javac/lambda/TargetType26.out ! test/tools/javac/lambda/TargetType27.out ! test/tools/javac/lambda/TargetType28.out ! test/tools/javac/lambda/TargetType39.out ! test/tools/javac/lambda/TargetType45.java - test/tools/javac/lambda/TargetType45.out ! test/tools/javac/lambda/TargetType50.out + test/tools/javac/lambda/TargetType51.java + test/tools/javac/lambda/TargetType52.java + test/tools/javac/lambda/TargetType52.out ! test/tools/javac/lambda/VoidCompatibility.java - test/tools/javac/lambda/VoidCompatibility.out ! test/tools/javac/lambda/lambdaExpression/SamConversionComboTest.java ! test/tools/javac/lambda/methodReference/SamConversion.java ! test/tools/javac/lambda/methodReference/SamConversionComboTest.java ! test/tools/javac/lambda/typeInference/InferenceTest_neg5.out ! test/tools/javac/resolve/tests/PrimitiveOverReferenceVarargsAmbiguous.java Changeset: c7c41a044e7c Author: mcimadamore Date: 2013-01-21 20:14 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7c41a044e7c 8006566: Remove transient lambda-related guards from JavacParser Summary: Remove transitional internal flag for allowing intersection types in cast Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/cast/intersection/IntersectionTypeParserTest.java ! test/tools/javac/cast/intersection/model/Model01.java ! test/tools/javac/diags/examples/SecondaryBoundMustBeMarkerIntf.java ! test/tools/javac/lambda/Intersection01.java ! test/tools/javac/lambda/intersection/IntersectionTargetTypeTest.java Changeset: b12ffdfa1341 Author: mcimadamore Date: 2013-01-21 20:15 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b12ffdfa1341 8005851: Remove support for synchronized interface methods Summary: Synchronized default methods are no longer supported Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java Changeset: cf84b07a82db Author: mcimadamore Date: 2013-01-21 20:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cf84b07a82db 8005166: Add support for static interface methods Summary: Support public static interface methods Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/defaultMethods/static/Static01.java + test/tools/javac/defaultMethods/static/Static02.java + test/tools/javac/defaultMethods/static/Static02.out + test/tools/javac/defaultMethods/static/hiding/InterfaceMethodHidingTest.java + test/tools/javac/defaultMethods/static/import/StaticImport1.java + test/tools/javac/defaultMethods/static/import/StaticImport2.java + test/tools/javac/defaultMethods/static/import/StaticImport2.out + test/tools/javac/defaultMethods/static/import/StaticImport3.java + test/tools/javac/defaultMethods/static/import/StaticImport3.out + test/tools/javac/defaultMethods/static/import/pkg/A.java + test/tools/javac/defaultMethods/static/import/pkg/B.java + test/tools/javac/defaultMethods/static/import/pkg/C.java ! test/tools/javac/defaultMethods/syntax/TestDefaultMethodsSyntax.java + test/tools/javac/diags/examples/IllegalStaticIntfMethCall.java + test/tools/javac/diags/examples/StaticIntfMethodNotSupported.java From vincent.x.ryan at oracle.com Mon Jan 21 16:18:45 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Jan 2013 00:18:45 +0000 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> Message-ID: <50FDDAE5.5030707@oracle.com> Updated webrev to include java.security.PKCS12Attribute: http://cr.openjdk.java.net/~vinnie/8005408/webrev.01/ On 21/01/2013 15:18, Vincent Ryan wrote: > Hello, > > Please review the fix for 8005408. It adds support for associating > attributes with keystore entries. > It is yet another component of the JEP-166 delivery. > > This new API permits several enhancements to the PKCS12 keystore > implementation: the storage of > trusted certificates, storage of secret keys and support for entry > metadata. Currently, only the > PKCS12 keystore takes advantage of these new KeyStore APIs. > > Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ > > > For storing trusted certificates in PKCS12 a new SafeBag attribute (with > a familiar syntax) is introduced > to indicate a trust usage: > > |trustedKeyUsage ATTRIBUTE ::= {| > |||WITH SYNTAX ExtKeyUsageSyntax| > |||ID id-at-trustedKeyUsage -- object identifier from an Oracle arc| > |}| > |-- from RFC ||5832||, Section ||4.2||.||1.12| > |||ExtKeyUsageSyntax ::= SEQUENCE SIZE (||1||..MAX) OF KeyPurposeId| > |||KeyPurposeId ::= OBJECT IDENTIFIER| > |||anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage ||0| |}| > > Note that this approach does not preclude the storage of a Trust Anchor > List (as defined in RFC 5914) > which was proposed earlier on this list. > > > There is one omission from the webrev above: the > java.security.PKCS12Attribute class needs some > additional changes and will be posted shortly. > > Again, JEP-166 is on a tight schedule for M6 so your early comments are > appreciated. > > Thanks. From weijun.wang at oracle.com Mon Jan 21 16:54:40 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 22 Jan 2013 08:54:40 +0800 Subject: [8] Code review request for 6263419: No way to clean the memory for a java.security.Key In-Reply-To: References: <50F82F2B.5050608@oracle.com> <50FD1F8D.5080803@redhat.com> Message-ID: <50FDE350.1060502@oracle.com> Hi Vinnie I don't feel comfortable to use an interface from the javax.security.auth package which was designed around JAAS. I am also not sure if it will be included in the core module in jdk9. Also, the test seems quite unnecessary. You can add one on real classes after you update the key impl classes. Thanks Max On 01/21/2013 07:43 PM, Vincent Ryan wrote: > > On 21 Jan 2013, at 10:59, Florian Weimer wrote: > >> On 01/17/2013 06:04 PM, Vincent Ryan wrote: >> >>> Please review the fix for 6263419. It introduces a mechanism to destroy >>> the sensitive data associated with private keys and secret keys. It is >>> a component of the JEP-166 delivery. >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.00/ >>> >>> Implementers of JCE security providers can override the default method >>> implementations in the Destroyable interface to allow applications to >>> take advantage of this new facility. We intend to update our key >>> implementation classes soon. >> >> How does this change interact with the existing approaches? Some crypto-related classes use a finalize() method to trigger overwriting the key material. >> >> I'm a bit worried that this old approach extends the life time of the key material considerably (because it has to be kept around until finalizers run). Keeping a reference to a key object just to be able to overwrite it could have the same effect. >> >> -- >> Florian Weimer / Red Hat Product Security Team > > > Hello Florian, > > Depending on a finalizer is a little unpredictable so this new approach is preferred. > I don't think it will have any detrimental impact on existing approaches. Implementers can always > choose to destroy key material in advance of any call to its destroy() method. > From vincent.x.ryan at oracle.com Mon Jan 21 17:02:11 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Jan 2013 01:02:11 +0000 Subject: [8] Code review request for 6263419: No way to clean the memory for a java.security.Key In-Reply-To: <50FDE350.1060502@oracle.com> References: <50F82F2B.5050608@oracle.com> <50FD1F8D.5080803@redhat.com> <50FDE350.1060502@oracle.com> Message-ID: <50FDE513.7060001@oracle.com> FYI javax.security.auth is in the base/compact1 module. On 22/01/2013 00:54, Weijun Wang wrote: > Hi Vinnie > > I don't feel comfortable to use an interface from the > javax.security.auth package which was designed around JAAS. I am also > not sure if it will be included in the core module in jdk9. > > Also, the test seems quite unnecessary. You can add one on real classes > after you update the key impl classes. > > Thanks > Max > > On 01/21/2013 07:43 PM, Vincent Ryan wrote: >> >> On 21 Jan 2013, at 10:59, Florian Weimer wrote: >> >>> On 01/17/2013 06:04 PM, Vincent Ryan wrote: >>> >>>> Please review the fix for 6263419. It introduces a mechanism to destroy >>>> the sensitive data associated with private keys and secret keys. It is >>>> a component of the JEP-166 delivery. >>>> >>>> Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.00/ >>>> >>>> Implementers of JCE security providers can override the default method >>>> implementations in the Destroyable interface to allow applications to >>>> take advantage of this new facility. We intend to update our key >>>> implementation classes soon. >>> >>> How does this change interact with the existing approaches? Some >>> crypto-related classes use a finalize() method to trigger overwriting >>> the key material. >>> >>> I'm a bit worried that this old approach extends the life time of the >>> key material considerably (because it has to be kept around until >>> finalizers run). Keeping a reference to a key object just to be able >>> to overwrite it could have the same effect. >>> >>> -- >>> Florian Weimer / Red Hat Product Security Team >> >> >> Hello Florian, >> >> Depending on a finalizer is a little unpredictable so this new >> approach is preferred. >> I don't think it will have any detrimental impact on existing >> approaches. Implementers can always >> choose to destroy key material in advance of any call to its destroy() >> method. >> From chris.hegarty at oracle.com Tue Jan 22 07:04:31 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 22 Jan 2013 15:04:31 +0000 Subject: RFR(XS) 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac Message-ID: <50FEAA7F.8040106@oracle.com> These tests started failing recently on some mac machines. They appear to hang and timeout. FAILED: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh FAILED: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh Webrev: http://cr.openjdk.java.net/~chegar/8006669/webrev.00/webrev/ Debugging the test shows that the HttpsURLConnection being made by the test is not being proxied, even though the test explicitly sets the system properties, "https.proxyHost" and "https.proxyPort". The properties are being set correctly, but the system has configured values for non proxy hosts: foobar:/tmp/chris> networksetup -getproxybypassdomains Ethernet *.local 169.254/16 *.xx.yy.com So, the connection to foobar.xx.yy.com is made directly, as will all connections to the xx.yy.com domain. This causes the test to hang: The test setups a simple proxy, and has a non daemon thread blocked in ServerSocket accept. It expects the client part of the test to connect to it. And in this case it never does. The specific machines, foobar, network proxybypassdomains could be changed to remove *.xx.yy.com, and this would resolve the problem, but a more robust solution would be to up date the test so that it uses the URL.openConnection(Proxy) API, specifying the actual proxy, rather than URL.openConnection() and allowing the system default proxy selector to choose. -Chris. From sean.mullan at oracle.com Tue Jan 22 08:24:40 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jan 2013 11:24:40 -0500 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <50FDDAE5.5030707@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <50FDDAE5.5030707@oracle.com> Message-ID: <50FEBD48.5020307@oracle.com> Comments so far, will send more as I review more: AlgorithmId.java * Update copyright KeyStore.java [296] I think you want to say: If none was set then null is returned. As I understand it, if none is set, then the KeyStore provider will use a default algorithm as specified by the Security property. This needs to be made clearer in the javadoc, as it reads it says it returns the value of this property, which is not possible since this class doesn't know what keystore type is being used at this point. [304] specify that null can be returned - @return the algorithm name, or null if none was set --Sean On 01/21/2013 07:18 PM, Vincent Ryan wrote: > > Updated webrev to include java.security.PKCS12Attribute: > http://cr.openjdk.java.net/~vinnie/8005408/webrev.01/ > > > > On 21/01/2013 15:18, Vincent Ryan wrote: >> Hello, >> >> Please review the fix for 8005408. It adds support for associating >> attributes with keystore entries. >> It is yet another component of the JEP-166 delivery. >> >> This new API permits several enhancements to the PKCS12 keystore >> implementation: the storage of >> trusted certificates, storage of secret keys and support for entry >> metadata. Currently, only the >> PKCS12 keystore takes advantage of these new KeyStore APIs. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ >> >> >> For storing trusted certificates in PKCS12 a new SafeBag attribute (with >> a familiar syntax) is introduced >> to indicate a trust usage: >> >> |trustedKeyUsage ATTRIBUTE ::= {| >> |||WITH SYNTAX ExtKeyUsageSyntax| >> |||ID id-at-trustedKeyUsage -- object identifier from an Oracle arc| >> |}| >> |-- from RFC ||5832||, Section ||4.2||.||1.12| >> |||ExtKeyUsageSyntax ::= SEQUENCE SIZE (||1||..MAX) OF KeyPurposeId| >> |||KeyPurposeId ::= OBJECT IDENTIFIER| >> |||anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage ||0| |}| >> >> Note that this approach does not preclude the storage of a Trust Anchor >> List (as defined in RFC 5914) >> which was proposed earlier on this list. >> >> >> There is one omission from the webrev above: the >> java.security.PKCS12Attribute class needs some >> additional changes and will be posted shortly. >> >> Again, JEP-166 is on a tight schedule for M6 so your early comments are >> appreciated. >> >> Thanks. > From maurizio.cimadamore at oracle.com Tue Jan 22 08:29:26 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 22 Jan 2013 16:29:26 +0000 Subject: hg: jdk8/tl/langtools: 8006673: TargetType52 fails because of bad golden file Message-ID: <20130122162931.87DFD47461@hg.openjdk.java.net> Changeset: be443002e970 Author: mcimadamore Date: 2013-01-22 16:23 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/be443002e970 8006673: TargetType52 fails because of bad golden file Summary: Fix golden file in negative test Reviewed-by: jjg ! test/tools/javac/lambda/TargetType52.out From maurizio.cimadamore at oracle.com Tue Jan 22 08:40:15 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 22 Jan 2013 16:40:15 +0000 Subject: hg: jdk8/tl/langtools: 8006684: Compiler produces java.lang.VerifyError: Bad type on operand stack Message-ID: <20130122164020.3A9D347463@hg.openjdk.java.net> Changeset: b61e5f801f7c Author: mcimadamore Date: 2013-01-22 16:39 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b61e5f801f7c 8006684: Compiler produces java.lang.VerifyError: Bad type on operand stack Summary: Lambda desugaring generates spurious references to 'this' in static contexts Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/lambda/LambdaExpr21.java From sean.mullan at oracle.com Tue Jan 22 08:50:19 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jan 2013 11:50:19 -0500 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <50FEBD48.5020307@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <50FDDAE5.5030707@oracle.com> <50FEBD48.5020307@oracle.com> Message-ID: <50FEC34B.8020607@oracle.com> More comments: KeyStore.java [551, 670, 753] Needs to make a copy (clone) according to javadoc, so should be: this.attributes = Collections.unmodifiableSet(new HashSet<>(attributes)); --Sean On 01/22/2013 11:24 AM, Sean Mullan wrote: > Comments so far, will send more as I review more: > > AlgorithmId.java > > * Update copyright > > KeyStore.java > > [296] I think you want to say: > > If none was set then null is returned. > > As I understand it, if none is set, then the KeyStore provider will use > a default algorithm as specified by the Security property. This needs to > be made clearer in the javadoc, as it reads it says it returns the value > of this property, which is not possible since this class doesn't know > what keystore type is being used at this point. > > [304] specify that null can be returned - > > @return the algorithm name, or null if none was set > > --Sean > > > On 01/21/2013 07:18 PM, Vincent Ryan wrote: >> >> Updated webrev to include java.security.PKCS12Attribute: >> http://cr.openjdk.java.net/~vinnie/8005408/webrev.01/ >> >> >> >> On 21/01/2013 15:18, Vincent Ryan wrote: >>> Hello, >>> >>> Please review the fix for 8005408. It adds support for associating >>> attributes with keystore entries. >>> It is yet another component of the JEP-166 delivery. >>> >>> This new API permits several enhancements to the PKCS12 keystore >>> implementation: the storage of >>> trusted certificates, storage of secret keys and support for entry >>> metadata. Currently, only the >>> PKCS12 keystore takes advantage of these new KeyStore APIs. >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ >>> >>> >>> For storing trusted certificates in PKCS12 a new SafeBag attribute (with >>> a familiar syntax) is introduced >>> to indicate a trust usage: >>> >>> |trustedKeyUsage ATTRIBUTE ::= {| >>> |||WITH SYNTAX ExtKeyUsageSyntax| >>> |||ID id-at-trustedKeyUsage -- object identifier from an Oracle arc| >>> |}| >>> |-- from RFC ||5832||, Section ||4.2||.||1.12| >>> |||ExtKeyUsageSyntax ::= SEQUENCE SIZE (||1||..MAX) OF KeyPurposeId| >>> |||KeyPurposeId ::= OBJECT IDENTIFIER| >>> |||anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage ||0| >>> |}| >>> >>> Note that this approach does not preclude the storage of a Trust Anchor >>> List (as defined in RFC 5914) >>> which was proposed earlier on this list. >>> >>> >>> There is one omission from the webrev above: the >>> java.security.PKCS12Attribute class needs some >>> additional changes and will be posted shortly. >>> >>> Again, JEP-166 is on a tight schedule for M6 so your early comments are >>> appreciated. >>> >>> Thanks. >> > From vincent.x.ryan at oracle.com Tue Jan 22 09:05:12 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Jan 2013 17:05:12 +0000 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <50FEBD48.5020307@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <50FDDAE5.5030707@oracle.com> <50FEBD48.5020307@oracle.com> Message-ID: <658CC975-9E75-453B-9747-303B61ADAC61@oracle.com> I've made those changes. Thanks. On 22 Jan 2013, at 16:24, Sean Mullan wrote: > Comments so far, will send more as I review more: > > AlgorithmId.java > > * Update copyright > > KeyStore.java > > [296] I think you want to say: > > If none was set then null is returned. > > As I understand it, if none is set, then the KeyStore provider will use a default algorithm as specified by the Security property. This needs to be made clearer in the javadoc, as it reads it says it returns the value of this property, which is not possible since this class doesn't know what keystore type is being used at this point. > That's right. I want to add that behaviour but I need to think about it further. > [304] specify that null can be returned - > > @return the algorithm name, or null if none was set > > --Sean > > > On 01/21/2013 07:18 PM, Vincent Ryan wrote: >> >> Updated webrev to include java.security.PKCS12Attribute: >> http://cr.openjdk.java.net/~vinnie/8005408/webrev.01/ >> >> >> >> On 21/01/2013 15:18, Vincent Ryan wrote: >>> Hello, >>> >>> Please review the fix for 8005408. It adds support for associating >>> attributes with keystore entries. >>> It is yet another component of the JEP-166 delivery. >>> >>> This new API permits several enhancements to the PKCS12 keystore >>> implementation: the storage of >>> trusted certificates, storage of secret keys and support for entry >>> metadata. Currently, only the >>> PKCS12 keystore takes advantage of these new KeyStore APIs. >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ >>> >>> >>> For storing trusted certificates in PKCS12 a new SafeBag attribute (with >>> a familiar syntax) is introduced >>> to indicate a trust usage: >>> >>> |trustedKeyUsage ATTRIBUTE ::= {| >>> |||WITH SYNTAX ExtKeyUsageSyntax| >>> |||ID id-at-trustedKeyUsage -- object identifier from an Oracle arc| >>> |}| >>> |-- from RFC ||5832||, Section ||4.2||.||1.12| >>> |||ExtKeyUsageSyntax ::= SEQUENCE SIZE (||1||..MAX) OF KeyPurposeId| >>> |||KeyPurposeId ::= OBJECT IDENTIFIER| >>> |||anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage ||0| |}| >>> >>> Note that this approach does not preclude the storage of a Trust Anchor >>> List (as defined in RFC 5914) >>> which was proposed earlier on this list. >>> >>> >>> There is one omission from the webrev above: the >>> java.security.PKCS12Attribute class needs some >>> additional changes and will be posted shortly. >>> >>> Again, JEP-166 is on a tight schedule for M6 so your early comments are >>> appreciated. >>> >>> Thanks. >> > From vincent.x.ryan at oracle.com Tue Jan 22 09:11:03 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Jan 2013 17:11:03 +0000 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <50FEC34B.8020607@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <50FDDAE5.5030707@oracle.com> <50FEBD48.5020307@oracle.com> <50FEC34B.8020607@oracle.com> Message-ID: <326DE1A1-D577-483F-AC66-41A14A193103@oracle.com> Correct. Thanks. On 22 Jan 2013, at 16:50, Sean Mullan wrote: > More comments: > > KeyStore.java > > [551, 670, 753] Needs to make a copy (clone) according to javadoc, so should be: > > this.attributes = Collections.unmodifiableSet(new HashSet<>(attributes)); > > --Sean > > On 01/22/2013 11:24 AM, Sean Mullan wrote: >> Comments so far, will send more as I review more: >> >> AlgorithmId.java >> >> * Update copyright >> >> KeyStore.java >> >> [296] I think you want to say: >> >> If none was set then null is returned. >> >> As I understand it, if none is set, then the KeyStore provider will use >> a default algorithm as specified by the Security property. This needs to >> be made clearer in the javadoc, as it reads it says it returns the value >> of this property, which is not possible since this class doesn't know >> what keystore type is being used at this point. >> >> [304] specify that null can be returned - >> >> @return the algorithm name, or null if none was set >> >> --Sean >> >> >> On 01/21/2013 07:18 PM, Vincent Ryan wrote: >>> >>> Updated webrev to include java.security.PKCS12Attribute: >>> http://cr.openjdk.java.net/~vinnie/8005408/webrev.01/ >>> >>> >>> >>> On 21/01/2013 15:18, Vincent Ryan wrote: >>>> Hello, >>>> >>>> Please review the fix for 8005408. It adds support for associating >>>> attributes with keystore entries. >>>> It is yet another component of the JEP-166 delivery. >>>> >>>> This new API permits several enhancements to the PKCS12 keystore >>>> implementation: the storage of >>>> trusted certificates, storage of secret keys and support for entry >>>> metadata. Currently, only the >>>> PKCS12 keystore takes advantage of these new KeyStore APIs. >>>> >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ >>>> >>>> >>>> For storing trusted certificates in PKCS12 a new SafeBag attribute (with >>>> a familiar syntax) is introduced >>>> to indicate a trust usage: >>>> >>>> |trustedKeyUsage ATTRIBUTE ::= {| >>>> |||WITH SYNTAX ExtKeyUsageSyntax| >>>> |||ID id-at-trustedKeyUsage -- object identifier from an Oracle arc| >>>> |}| >>>> |-- from RFC ||5832||, Section ||4.2||.||1.12| >>>> |||ExtKeyUsageSyntax ::= SEQUENCE SIZE (||1||..MAX) OF KeyPurposeId| >>>> |||KeyPurposeId ::= OBJECT IDENTIFIER| >>>> |||anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage ||0| >>>> |}| >>>> >>>> Note that this approach does not preclude the storage of a Trust Anchor >>>> List (as defined in RFC 5914) >>>> which was proposed earlier on this list. >>>> >>>> >>>> There is one omission from the webrev above: the >>>> java.security.PKCS12Attribute class needs some >>>> additional changes and will be posted shortly. >>>> >>>> Again, JEP-166 is on a tight schedule for M6 so your early comments are >>>> appreciated. >>>> >>>> Thanks. >>> >> > From sean.mullan at oracle.com Tue Jan 22 10:22:26 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jan 2013 13:22:26 -0500 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <50FEC34B.8020607@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <50FDDAE5.5030707@oracle.com> <50FEBD48.5020307@oracle.com> <50FEC34B.8020607@oracle.com> Message-ID: <50FED8E2.8020509@oracle.com> More comments ... PKCS12Attribute.java: [213-215] You can replace this with Arrays.hashCode(byte[]). --Sean On 01/22/2013 11:50 AM, Sean Mullan wrote: > More comments: > > KeyStore.java > > [551, 670, 753] Needs to make a copy (clone) according to javadoc, so > should be: > > this.attributes = Collections.unmodifiableSet(new HashSet<>(attributes)); > > --Sean > > On 01/22/2013 11:24 AM, Sean Mullan wrote: >> Comments so far, will send more as I review more: >> >> AlgorithmId.java >> >> * Update copyright >> >> KeyStore.java >> >> [296] I think you want to say: >> >> If none was set then null is returned. >> >> As I understand it, if none is set, then the KeyStore provider will use >> a default algorithm as specified by the Security property. This needs to >> be made clearer in the javadoc, as it reads it says it returns the value >> of this property, which is not possible since this class doesn't know >> what keystore type is being used at this point. >> >> [304] specify that null can be returned - >> >> @return the algorithm name, or null if none was set >> >> --Sean >> >> >> On 01/21/2013 07:18 PM, Vincent Ryan wrote: >>> >>> Updated webrev to include java.security.PKCS12Attribute: >>> http://cr.openjdk.java.net/~vinnie/8005408/webrev.01/ >>> >>> >>> >>> On 21/01/2013 15:18, Vincent Ryan wrote: >>>> Hello, >>>> >>>> Please review the fix for 8005408. It adds support for associating >>>> attributes with keystore entries. >>>> It is yet another component of the JEP-166 delivery. >>>> >>>> This new API permits several enhancements to the PKCS12 keystore >>>> implementation: the storage of >>>> trusted certificates, storage of secret keys and support for entry >>>> metadata. Currently, only the >>>> PKCS12 keystore takes advantage of these new KeyStore APIs. >>>> >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ >>>> >>>> >>>> For storing trusted certificates in PKCS12 a new SafeBag attribute >>>> (with >>>> a familiar syntax) is introduced >>>> to indicate a trust usage: >>>> >>>> |trustedKeyUsage ATTRIBUTE ::= {| >>>> |||WITH SYNTAX ExtKeyUsageSyntax| >>>> |||ID id-at-trustedKeyUsage -- object identifier from an Oracle arc| >>>> |}| >>>> |-- from RFC ||5832||, Section ||4.2||.||1.12| >>>> |||ExtKeyUsageSyntax ::= SEQUENCE SIZE (||1||..MAX) OF KeyPurposeId| >>>> |||KeyPurposeId ::= OBJECT IDENTIFIER| >>>> |||anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage ||0| >>>> |}| >>>> >>>> Note that this approach does not preclude the storage of a Trust Anchor >>>> List (as defined in RFC 5914) >>>> which was proposed earlier on this list. >>>> >>>> >>>> There is one omission from the webrev above: the >>>> java.security.PKCS12Attribute class needs some >>>> additional changes and will be posted shortly. >>>> >>>> Again, JEP-166 is on a tight schedule for M6 so your early comments are >>>> appreciated. >>>> >>>> Thanks. >>> >> > From fredrik.ohrstrom at oracle.com Thu Jan 17 15:19:22 2013 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 17 Jan 2013 23:19:22 +0000 Subject: hg: jdk8/tl/langtools: 8004658: Add internal smart javac wrapper to solve JEP 139 Message-ID: <20130117231925.B122947393@hg.openjdk.java.net> Changeset: 22e417cdddee Author: ohrstrom Date: 2013-01-18 00:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/22e417cdddee 8004658: Add internal smart javac wrapper to solve JEP 139 Reviewed-by: jjg ! make/build.properties ! make/build.xml + src/share/classes/com/sun/tools/sjavac/BuildState.java + src/share/classes/com/sun/tools/sjavac/CleanProperties.java + src/share/classes/com/sun/tools/sjavac/CompileChunk.java + src/share/classes/com/sun/tools/sjavac/CompileJavaPackages.java + src/share/classes/com/sun/tools/sjavac/CompileProperties.java + src/share/classes/com/sun/tools/sjavac/CopyFile.java + src/share/classes/com/sun/tools/sjavac/JavacState.java + src/share/classes/com/sun/tools/sjavac/Log.java + src/share/classes/com/sun/tools/sjavac/Main.java + src/share/classes/com/sun/tools/sjavac/Module.java + src/share/classes/com/sun/tools/sjavac/Package.java + src/share/classes/com/sun/tools/sjavac/ProblemException.java + src/share/classes/com/sun/tools/sjavac/Source.java + src/share/classes/com/sun/tools/sjavac/Transformer.java + src/share/classes/com/sun/tools/sjavac/Util.java + src/share/classes/com/sun/tools/sjavac/comp/Dependencies.java + src/share/classes/com/sun/tools/sjavac/comp/JavaCompilerWithDeps.java + src/share/classes/com/sun/tools/sjavac/comp/PubapiVisitor.java + src/share/classes/com/sun/tools/sjavac/comp/ResolveWithDeps.java + src/share/classes/com/sun/tools/sjavac/comp/SmartFileManager.java + src/share/classes/com/sun/tools/sjavac/comp/SmartFileObject.java + src/share/classes/com/sun/tools/sjavac/comp/SmartWriter.java + src/share/classes/com/sun/tools/sjavac/server/CompilerPool.java + src/share/classes/com/sun/tools/sjavac/server/CompilerThread.java + src/share/classes/com/sun/tools/sjavac/server/JavacServer.java + src/share/classes/com/sun/tools/sjavac/server/PortFile.java + src/share/classes/com/sun/tools/sjavac/server/SysInfo.java + test/tools/sjavac/SJavac.java From vincent.x.ryan at oracle.com Tue Jan 22 12:01:34 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Jan 2013 20:01:34 +0000 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <50FED8E2.8020509@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <50FDDAE5.5030707@oracle.com> <50FEBD48.5020307@oracle.com> <50FEC34B.8020607@oracle.com> <50FED8E2.8020509@oracle.com> Message-ID: <50FEF01E.6040409@oracle.com> That's better. Thanks. On 22/01/2013 18:22, Sean Mullan wrote: > More comments ... > > PKCS12Attribute.java: > > [213-215] You can replace this with Arrays.hashCode(byte[]). > > --Sean > > On 01/22/2013 11:50 AM, Sean Mullan wrote: >> More comments: >> >> KeyStore.java >> >> [551, 670, 753] Needs to make a copy (clone) according to javadoc, so >> should be: >> >> this.attributes = Collections.unmodifiableSet(new HashSet<>(attributes)); >> >> --Sean >> >> On 01/22/2013 11:24 AM, Sean Mullan wrote: >>> Comments so far, will send more as I review more: >>> >>> AlgorithmId.java >>> >>> * Update copyright >>> >>> KeyStore.java >>> >>> [296] I think you want to say: >>> >>> If none was set then null is returned. >>> >>> As I understand it, if none is set, then the KeyStore provider will use >>> a default algorithm as specified by the Security property. This needs to >>> be made clearer in the javadoc, as it reads it says it returns the value >>> of this property, which is not possible since this class doesn't know >>> what keystore type is being used at this point. >>> >>> [304] specify that null can be returned - >>> >>> @return the algorithm name, or null if none was set >>> >>> --Sean >>> >>> >>> On 01/21/2013 07:18 PM, Vincent Ryan wrote: >>>> >>>> Updated webrev to include java.security.PKCS12Attribute: >>>> http://cr.openjdk.java.net/~vinnie/8005408/webrev.01/ >>>> >>>> >>>> >>>> On 21/01/2013 15:18, Vincent Ryan wrote: >>>>> Hello, >>>>> >>>>> Please review the fix for 8005408. It adds support for associating >>>>> attributes with keystore entries. >>>>> It is yet another component of the JEP-166 delivery. >>>>> >>>>> This new API permits several enhancements to the PKCS12 keystore >>>>> implementation: the storage of >>>>> trusted certificates, storage of secret keys and support for entry >>>>> metadata. Currently, only the >>>>> PKCS12 keystore takes advantage of these new KeyStore APIs. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ >>>>> >>>>> >>>>> For storing trusted certificates in PKCS12 a new SafeBag attribute >>>>> (with >>>>> a familiar syntax) is introduced >>>>> to indicate a trust usage: >>>>> >>>>> |trustedKeyUsage ATTRIBUTE ::= {| >>>>> |||WITH SYNTAX ExtKeyUsageSyntax| >>>>> |||ID id-at-trustedKeyUsage -- object identifier from an Oracle arc| >>>>> |}| >>>>> |-- from RFC ||5832||, Section ||4.2||.||1.12| >>>>> |||ExtKeyUsageSyntax ::= SEQUENCE SIZE (||1||..MAX) OF KeyPurposeId| >>>>> |||KeyPurposeId ::= OBJECT IDENTIFIER| >>>>> |||anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage ||0| >>>>> |}| >>>>> >>>>> Note that this approach does not preclude the storage of a Trust >>>>> Anchor >>>>> List (as defined in RFC 5914) >>>>> which was proposed earlier on this list. >>>>> >>>>> >>>>> There is one omission from the webrev above: the >>>>> java.security.PKCS12Attribute class needs some >>>>> additional changes and will be posted shortly. >>>>> >>>>> Again, JEP-166 is on a tight schedule for M6 so your early comments >>>>> are >>>>> appreciated. >>>>> >>>>> Thanks. >>>> >>> >> > From vincent.x.ryan at oracle.com Tue Jan 22 13:17:07 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Jan 2013 21:17:07 +0000 Subject: [8] Code review request for 6263419: No way to clean the memory for a java.security.Key In-Reply-To: <50F82F2B.5050608@oracle.com> References: <50F82F2B.5050608@oracle.com> Message-ID: <50FF01D3.5000406@oracle.com> Last call on this. And an updated webrev containing a minor javadoc change to the Implementer's Note in PrivateKey and SecretKey. Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.01/ Thanks. On 17/01/2013 17:04, Vincent Ryan wrote: > Hello, > > Please review the fix for 6263419. It introduces a mechanism to destroy > the sensitive data associated with private keys and secret keys. It is > a component of the JEP-166 delivery. > > Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.00/ > > Implementers of JCE security providers can override the default method > implementations in the Destroyable interface to allow applications to > take advantage of this new facility. We intend to update our key > implementation classes soon. > > Thanks. From sean.mullan at oracle.com Tue Jan 22 13:22:17 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jan 2013 16:22:17 -0500 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <50FED8E2.8020509@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <50FDDAE5.5030707@oracle.com> <50FEBD48.5020307@oracle.com> <50FEC34B.8020607@oracle.com> <50FED8E2.8020509@oracle.com> Message-ID: <50FF0309.5070605@oracle.com> Final set of comments in this webrev: PKCS12KeyStore.java [214] Minor comment, but I think it would be cleaner to create separate SecretKeyEntry and PrivateKeyEntry classes. [224, 235-238, 519, 533-536] For the attributes, I think it would be cleaner (and faster) to pass Collections.emptySet() instead of null, and then replace lines 235-238 and 533-536 with: entry.attributes = attributes; [518] You should destroy the PasswordProtection object before returning to the caller (probably with a try-finally) as they don't have a way to clear the password that has been cloned by the PasswordProtection ctor. [634-678] Why doesn't this method also support SecretKeys like the other engineSetKeyEntry method? [801-806] You should probably add a TODO comment that this should be first checking the security property, and if not set then falling back to "PBEWithSHA1AndDESede". Shouldn't we fallback to something stronger (SHA256/AES?) though? [910] what if this is a SecretKey? Should you still decrement this? [1484-1522] Why don't you just write out the bytes from the PKCS12Attribute.getEncoded() method rather than parsing and converting the Strings for the OID and value? [2216 -] It seems it would be better to create the PKCS12Attributes with the byte[] ctor, as that retains the full encoding information, and you could return arbitrary attributes we don't recognize. Also, the String ctor will cause it to be re-encoded again, when we already have the encoding. --Sean On 01/22/2013 01:22 PM, Sean Mullan wrote: > More comments ... > > PKCS12Attribute.java: > > [213-215] You can replace this with Arrays.hashCode(byte[]). > > --Sean > > On 01/22/2013 11:50 AM, Sean Mullan wrote: >> More comments: >> >> KeyStore.java >> >> [551, 670, 753] Needs to make a copy (clone) according to javadoc, so >> should be: >> >> this.attributes = Collections.unmodifiableSet(new HashSet<>(attributes)); >> >> --Sean >> >> On 01/22/2013 11:24 AM, Sean Mullan wrote: >>> Comments so far, will send more as I review more: >>> >>> AlgorithmId.java >>> >>> * Update copyright >>> >>> KeyStore.java >>> >>> [296] I think you want to say: >>> >>> If none was set then null is returned. >>> >>> As I understand it, if none is set, then the KeyStore provider will use >>> a default algorithm as specified by the Security property. This needs to >>> be made clearer in the javadoc, as it reads it says it returns the value >>> of this property, which is not possible since this class doesn't know >>> what keystore type is being used at this point. >>> >>> [304] specify that null can be returned - >>> >>> @return the algorithm name, or null if none was set >>> >>> --Sean >>> >>> >>> On 01/21/2013 07:18 PM, Vincent Ryan wrote: >>>> >>>> Updated webrev to include java.security.PKCS12Attribute: >>>> http://cr.openjdk.java.net/~vinnie/8005408/webrev.01/ >>>> >>>> >>>> >>>> On 21/01/2013 15:18, Vincent Ryan wrote: >>>>> Hello, >>>>> >>>>> Please review the fix for 8005408. It adds support for associating >>>>> attributes with keystore entries. >>>>> It is yet another component of the JEP-166 delivery. >>>>> >>>>> This new API permits several enhancements to the PKCS12 keystore >>>>> implementation: the storage of >>>>> trusted certificates, storage of secret keys and support for entry >>>>> metadata. Currently, only the >>>>> PKCS12 keystore takes advantage of these new KeyStore APIs. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ >>>>> >>>>> >>>>> For storing trusted certificates in PKCS12 a new SafeBag attribute >>>>> (with >>>>> a familiar syntax) is introduced >>>>> to indicate a trust usage: >>>>> >>>>> |trustedKeyUsage ATTRIBUTE ::= {| >>>>> |||WITH SYNTAX ExtKeyUsageSyntax| >>>>> |||ID id-at-trustedKeyUsage -- object identifier from an Oracle arc| >>>>> |}| >>>>> |-- from RFC ||5832||, Section ||4.2||.||1.12| >>>>> |||ExtKeyUsageSyntax ::= SEQUENCE SIZE (||1||..MAX) OF KeyPurposeId| >>>>> |||KeyPurposeId ::= OBJECT IDENTIFIER| >>>>> |||anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage ||0| >>>>> |}| >>>>> >>>>> Note that this approach does not preclude the storage of a Trust >>>>> Anchor >>>>> List (as defined in RFC 5914) >>>>> which was proposed earlier on this list. >>>>> >>>>> >>>>> There is one omission from the webrev above: the >>>>> java.security.PKCS12Attribute class needs some >>>>> additional changes and will be posted shortly. >>>>> >>>>> Again, JEP-166 is on a tight schedule for M6 so your early comments >>>>> are >>>>> appreciated. >>>>> >>>>> Thanks. >>>> >>> >> > From sean.mullan at oracle.com Tue Jan 22 13:30:33 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 22 Jan 2013 16:30:33 -0500 Subject: [8] Code review request for 6263419: No way to clean the memory for a java.security.Key In-Reply-To: <50FF01D3.5000406@oracle.com> References: <50F82F2B.5050608@oracle.com> <50FF01D3.5000406@oracle.com> Message-ID: <50FF04F9.9060605@oracle.com> I don't think you should add the @since 1.8 tags on the Destroyable methods, since they are not new, you are just adding a default implementation. As an aside, we should file an RFE to add a default method for SecretKey.getFormat that returns "RAW" (since this is what should always be returned). --Sean On 01/22/2013 04:17 PM, Vincent Ryan wrote: > Last call on this. And an updated webrev containing a minor javadoc > change to the Implementer's Note in PrivateKey and SecretKey. > > Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.01/ > > Thanks. > > > On 17/01/2013 17:04, Vincent Ryan wrote: >> Hello, >> >> Please review the fix for 6263419. It introduces a mechanism to destroy >> the sensitive data associated with private keys and secret keys. It is >> a component of the JEP-166 delivery. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.00/ >> >> Implementers of JCE security providers can override the default method >> implementations in the Destroyable interface to allow applications to >> take advantage of this new facility. We intend to update our key >> implementation classes soon. >> >> Thanks. > From vincent.x.ryan at oracle.com Tue Jan 22 13:52:07 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Jan 2013 21:52:07 +0000 Subject: [8] Code review request for 6263419: No way to clean the memory for a java.security.Key In-Reply-To: <50FF04F9.9060605@oracle.com> References: <50F82F2B.5050608@oracle.com> <50FF01D3.5000406@oracle.com> <50FF04F9.9060605@oracle.com> Message-ID: <50FF0A07.2060900@oracle.com> On 22/01/2013 21:30, Sean Mullan wrote: > I don't think you should add the @since 1.8 tags on the Destroyable > methods, since they are not new, you are just adding a default > implementation. Removed tags. > > As an aside, we should file an RFE to add a default method for > SecretKey.getFormat that returns "RAW" (since this is what should always > be returned). > Filed. > --Sean > > > On 01/22/2013 04:17 PM, Vincent Ryan wrote: >> Last call on this. And an updated webrev containing a minor javadoc >> change to the Implementer's Note in PrivateKey and SecretKey. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.01/ >> >> Thanks. >> >> >> On 17/01/2013 17:04, Vincent Ryan wrote: >>> Hello, >>> >>> Please review the fix for 6263419. It introduces a mechanism to destroy >>> the sensitive data associated with private keys and secret keys. It is >>> a component of the JEP-166 delivery. >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.00/ >>> >>> Implementers of JCE security providers can override the default method >>> implementations in the Destroyable interface to allow applications to >>> take advantage of this new facility. We intend to update our key >>> implementation classes soon. >>> >>> Thanks. >> > From vincent.x.ryan at oracle.com Tue Jan 22 14:40:33 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Jan 2013 22:40:33 +0000 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <658CC975-9E75-453B-9747-303B61ADAC61@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <50FDDAE5.5030707@oracle.com> <50FEBD48.5020307@oracle.com> <658CC975-9E75-453B-9747-303B61ADAC61@oracle.com> Message-ID: <50FF1561.3060801@oracle.com> On 22/01/2013 17:05, Vincent Ryan wrote: > I've made those changes. Thanks. > > > On 22 Jan 2013, at 16:24, Sean Mullan wrote: : >> >> KeyStore.java >> >> [296] I think you want to say: >> >> If none was set then null is returned. >> >> As I understand it, if none is set, then the KeyStore provider will use a default algorithm as specified by the Security property. This needs to be made clearer in the javadoc, as it reads it says it returns the value of this property, which is not possible since this class doesn't know what keystore type is being used at this point. >> > > That's right. I want to add that behaviour but I need to think about it further. I've clarified the spec for the KeyStore.getProtectionAlgorithm method: /** * Gets the name of the protection algorithm. * If none was set then the keystore provider will use its default * protection algorithm. The name of the default protection algorithm * for a given keystore type is set using the * {@code 'keystore..keyProtectionAlgorithm'} Security property. * For example, the * {@code keystore.PKCS12.keyProtectionAlgorithm} property stores the * name of the default key protection algorithm used for PKCS12 * keystores. * * @return the algorithm name, or {@code null} if none was set * * @since 1.8 */ public String getProtectionAlgorithm() { return protectionAlgorithm; } > > > >> [304] specify that null can be returned - >> >> @return the algorithm name, or null if none was set >> >> --Sean From vincent.x.ryan at oracle.com Tue Jan 22 15:18:02 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Tue, 22 Jan 2013 23:18:02 +0000 Subject: [8] Code review request for 8006591: Protect keystore entries using stronger PBE algorithms In-Reply-To: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> References: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> Message-ID: <50FF1E2A.8090309@oracle.com> Last call and an updated webrev that includes the review comments: Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.01/ On 18/01/2013 19:53, Vincent Ryan wrote: > Hello, > > Please review the fix for 8006591. It introduces a mechanism to enable > stronger PBE algorithms to be specified when encrypting a keystore entry. > This allows developers to make use of the new PBE algorithms delivered in > JEP-121. Note however that PKCS12 is currently the only keystore that > supports this new feature. > > It is a component of the JEP-166 delivery. > > Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.00/ > > Thanks. From vincent.x.ryan at oracle.com Tue Jan 22 15:41:13 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 22 Jan 2013 23:41:13 +0000 Subject: hg: jdk8/tl/jdk: 6263419: No way to clean the memory for a java.security.Key Message-ID: <20130122234135.62D744748F@hg.openjdk.java.net> Changeset: 8ee6d45348ba Author: vinnie Date: 2013-01-22 23:32 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ee6d45348ba 6263419: No way to clean the memory for a java.security.Key Reviewed-by: mullan ! src/share/classes/java/security/PrivateKey.java ! src/share/classes/javax/crypto/SecretKey.java ! src/share/classes/javax/security/auth/Destroyable.java + test/javax/security/auth/Destroyable/KeyDestructionTest.java From stuart.marks at oracle.com Tue Jan 22 18:33:32 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 23 Jan 2013 02:33:32 +0000 Subject: hg: jdk8/tl/jdk: 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running Message-ID: <20130123023343.64B0D47496@hg.openjdk.java.net> Changeset: c18f28312c49 Author: smarks Date: 2013-01-22 18:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c18f28312c49 8005646: TEST_BUG: java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup leaves process running Reviewed-by: mchung ! test/java/rmi/activation/ActivationSystem/unregisterGroup/ActivateMe.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java ! test/java/rmi/activation/ActivationSystem/unregisterGroup/rmid.security.policy From jonathan.gibbons at oracle.com Tue Jan 22 18:43:47 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Jan 2013 02:43:47 +0000 Subject: hg: jdk8/tl/langtools: 8006723: sjavac test fails to compile on clean build Message-ID: <20130123024349.A433C47497@hg.openjdk.java.net> Changeset: 8943b4213f59 Author: jjg Date: 2013-01-22 18:43 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8943b4213f59 8006723: sjavac test fails to compile on clean build Reviewed-by: ksrini ! test/tools/sjavac/SJavac.java + test/tools/sjavac/SJavacWrapper.java From jonathan.gibbons at oracle.com Tue Jan 22 19:07:23 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Jan 2013 03:07:23 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130123030731.0EB3747498@hg.openjdk.java.net> Changeset: f5b70712e0d5 Author: jjg Date: 2013-01-22 19:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f5b70712e0d5 8006728: temporarily workaround jtreg problems for doclint tests in othervm Reviewed-by: jjh + test/tools/doclint/html/AAA.java + test/tools/doclint/tidy/AAA.java + test/tools/doclint/tool/AAA.java Changeset: 385828dd5604 Author: jjg Date: 2013-01-22 19:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/385828dd5604 Merge From xueming.shen at oracle.com Tue Jan 22 20:54:43 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 23 Jan 2013 04:54:43 +0000 Subject: hg: jdk8/tl/jdk: 8003680: JSR 310 Date/Time API Message-ID: <20130123045504.5A781474A3@hg.openjdk.java.net> Changeset: 919afffa70b0 Author: sherman Date: 2013-01-22 20:59 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/919afffa70b0 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, richard.warburton at gmail.com, misterm at gmail.com ! make/docs/CORE_PKGS.gmk ! make/java/Makefile + make/java/time/Makefile ! make/jprt.properties ! make/sun/Makefile + make/sun/tzdb/Makefile ! make/tools/Makefile + make/tools/src/build/tools/tzdb/ChronoField.java + make/tools/src/build/tools/tzdb/DateTimeException.java + make/tools/src/build/tools/tzdb/LocalDate.java + make/tools/src/build/tools/tzdb/LocalDateTime.java + make/tools/src/build/tools/tzdb/LocalTime.java + make/tools/src/build/tools/tzdb/TimeDefinition.java + make/tools/src/build/tools/tzdb/TzdbZoneRulesCompiler.java + make/tools/src/build/tools/tzdb/Utils.java + make/tools/src/build/tools/tzdb/ZoneOffset.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransition.java + make/tools/src/build/tools/tzdb/ZoneOffsetTransitionRule.java + make/tools/src/build/tools/tzdb/ZoneRules.java + make/tools/src/build/tools/tzdb/ZoneRulesBuilder.java + make/tools/tzdb/Makefile ! makefiles/CreateJars.gmk + makefiles/GendataTZDB.gmk ! makefiles/GenerateData.gmk ! makefiles/Tools.gmk + src/share/classes/java/time/Clock.java + src/share/classes/java/time/DateTimeException.java + src/share/classes/java/time/DayOfWeek.java + src/share/classes/java/time/Duration.java + src/share/classes/java/time/Instant.java + src/share/classes/java/time/LocalDate.java + src/share/classes/java/time/LocalDateTime.java + src/share/classes/java/time/LocalTime.java + src/share/classes/java/time/Month.java + src/share/classes/java/time/Period.java + src/share/classes/java/time/PeriodParser.java + src/share/classes/java/time/Ser.java + src/share/classes/java/time/ZoneId.java + src/share/classes/java/time/ZoneOffset.java + src/share/classes/java/time/ZoneRegion.java + src/share/classes/java/time/ZonedDateTime.java + src/share/classes/java/time/calendar/ChronoDateImpl.java + src/share/classes/java/time/calendar/HijrahChrono.java + src/share/classes/java/time/calendar/HijrahDate.java + src/share/classes/java/time/calendar/HijrahDeviationReader.java + src/share/classes/java/time/calendar/HijrahEra.java + src/share/classes/java/time/calendar/JapaneseChrono.java + src/share/classes/java/time/calendar/JapaneseDate.java + src/share/classes/java/time/calendar/JapaneseEra.java + src/share/classes/java/time/calendar/MinguoChrono.java + src/share/classes/java/time/calendar/MinguoDate.java + src/share/classes/java/time/calendar/MinguoEra.java + src/share/classes/java/time/calendar/Ser.java + src/share/classes/java/time/calendar/ThaiBuddhistChrono.java + src/share/classes/java/time/calendar/ThaiBuddhistDate.java + src/share/classes/java/time/calendar/ThaiBuddhistEra.java + src/share/classes/java/time/calendar/package-info.java + src/share/classes/java/time/format/DateTimeBuilder.java + src/share/classes/java/time/format/DateTimeFormatStyleProvider.java + src/share/classes/java/time/format/DateTimeFormatSymbols.java + src/share/classes/java/time/format/DateTimeFormatter.java + src/share/classes/java/time/format/DateTimeFormatterBuilder.java + src/share/classes/java/time/format/DateTimeFormatters.java + src/share/classes/java/time/format/DateTimeParseContext.java + src/share/classes/java/time/format/DateTimeParseException.java + src/share/classes/java/time/format/DateTimePrintContext.java + src/share/classes/java/time/format/DateTimePrintException.java + src/share/classes/java/time/format/DateTimeTextProvider.java + src/share/classes/java/time/format/FormatStyle.java + src/share/classes/java/time/format/SignStyle.java + src/share/classes/java/time/format/TextStyle.java + src/share/classes/java/time/format/package-info.java + src/share/classes/java/time/overview.html + src/share/classes/java/time/package-info.java + src/share/classes/java/time/temporal/Adjusters.java + src/share/classes/java/time/temporal/Chrono.java + src/share/classes/java/time/temporal/ChronoField.java + src/share/classes/java/time/temporal/ChronoLocalDate.java + src/share/classes/java/time/temporal/ChronoLocalDateTime.java + src/share/classes/java/time/temporal/ChronoLocalDateTimeImpl.java + src/share/classes/java/time/temporal/ChronoUnit.java + src/share/classes/java/time/temporal/ChronoZonedDateTime.java + src/share/classes/java/time/temporal/ChronoZonedDateTimeImpl.java + src/share/classes/java/time/temporal/Era.java + src/share/classes/java/time/temporal/ISOChrono.java + src/share/classes/java/time/temporal/ISOEra.java + src/share/classes/java/time/temporal/ISOFields.java + src/share/classes/java/time/temporal/JulianFields.java + src/share/classes/java/time/temporal/MonthDay.java + src/share/classes/java/time/temporal/OffsetDate.java + src/share/classes/java/time/temporal/OffsetDateTime.java + src/share/classes/java/time/temporal/OffsetTime.java + src/share/classes/java/time/temporal/Queries.java + src/share/classes/java/time/temporal/Ser.java + src/share/classes/java/time/temporal/SimplePeriod.java + src/share/classes/java/time/temporal/Temporal.java + src/share/classes/java/time/temporal/TemporalAccessor.java + src/share/classes/java/time/temporal/TemporalAdder.java + src/share/classes/java/time/temporal/TemporalAdjuster.java + src/share/classes/java/time/temporal/TemporalField.java + src/share/classes/java/time/temporal/TemporalQuery.java + src/share/classes/java/time/temporal/TemporalSubtractor.java + src/share/classes/java/time/temporal/TemporalUnit.java + src/share/classes/java/time/temporal/ValueRange.java + src/share/classes/java/time/temporal/WeekFields.java + src/share/classes/java/time/temporal/Year.java + src/share/classes/java/time/temporal/YearMonth.java + src/share/classes/java/time/temporal/package-info.java + src/share/classes/java/time/zone/Ser.java + src/share/classes/java/time/zone/TzdbZoneRulesProvider.java + src/share/classes/java/time/zone/ZoneOffsetTransition.java + src/share/classes/java/time/zone/ZoneOffsetTransitionRule.java + src/share/classes/java/time/zone/ZoneRules.java + src/share/classes/java/time/zone/ZoneRulesException.java + src/share/classes/java/time/zone/ZoneRulesProvider.java + src/share/classes/java/time/zone/package-info.java ! src/share/classes/java/util/Formatter.java ! test/Makefile + test/java/time/META-INF/services/java.time.temporal.Chrono + test/java/time/TEST.properties + test/java/time/tck/java/time/AbstractDateTimeTest.java + test/java/time/tck/java/time/AbstractTCKTest.java + test/java/time/tck/java/time/TCKClock.java + test/java/time/tck/java/time/TCKClock_Fixed.java + test/java/time/tck/java/time/TCKClock_Offset.java + test/java/time/tck/java/time/TCKClock_System.java + test/java/time/tck/java/time/TCKClock_Tick.java + test/java/time/tck/java/time/TCKDayOfWeek.java + test/java/time/tck/java/time/TCKDuration.java + test/java/time/tck/java/time/TCKInstant.java + test/java/time/tck/java/time/TCKLocalDate.java + test/java/time/tck/java/time/TCKLocalDateTime.java + test/java/time/tck/java/time/TCKLocalTime.java + test/java/time/tck/java/time/TCKMonth.java + test/java/time/tck/java/time/TCKZoneId.java + test/java/time/tck/java/time/TCKZoneOffset.java + test/java/time/tck/java/time/TCKZonedDateTime.java + test/java/time/tck/java/time/calendar/CopticChrono.java + test/java/time/tck/java/time/calendar/CopticDate.java + test/java/time/tck/java/time/calendar/CopticEra.java + test/java/time/tck/java/time/calendar/TestChronoLocalDate.java + test/java/time/tck/java/time/calendar/TestChronoLocalDateTime.java + test/java/time/tck/java/time/calendar/TestHijrahChrono.java + test/java/time/tck/java/time/calendar/TestJapaneseChrono.java + test/java/time/tck/java/time/calendar/TestMinguoChrono.java + test/java/time/tck/java/time/calendar/TestServiceLoader.java + test/java/time/tck/java/time/calendar/TestThaiBuddhistChrono.java + test/java/time/tck/java/time/format/TCKDateTimeFormatSymbols.java + test/java/time/tck/java/time/format/TCKDateTimeFormatter.java + test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java + test/java/time/tck/java/time/format/TCKDateTimeFormatters.java + test/java/time/tck/java/time/format/TCKDateTimePrintException.java + test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java + test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java + test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java + test/java/time/tck/java/time/temporal/TCKDateTimeAdjusters.java + test/java/time/tck/java/time/temporal/TCKISOFields.java + test/java/time/tck/java/time/temporal/TCKJulianFields.java + test/java/time/tck/java/time/temporal/TCKMonthDay.java + test/java/time/tck/java/time/temporal/TCKOffsetDate.java + test/java/time/tck/java/time/temporal/TCKOffsetDateTime.java + test/java/time/tck/java/time/temporal/TCKOffsetTime.java + test/java/time/tck/java/time/temporal/TCKSimplePeriod.java + test/java/time/tck/java/time/temporal/TCKWeekFields.java + test/java/time/tck/java/time/temporal/TCKYear.java + test/java/time/tck/java/time/temporal/TCKYearMonth.java + test/java/time/tck/java/time/temporal/TestChrono.java + test/java/time/tck/java/time/temporal/TestChronoLocalDate.java + test/java/time/tck/java/time/temporal/TestChronoLocalDateTime.java + test/java/time/tck/java/time/temporal/TestChronoZonedDateTime.java + test/java/time/tck/java/time/temporal/TestISOChrono.java + test/java/time/tck/java/time/zone/TCKFixedZoneRules.java + test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java + test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java + test/java/time/tck/java/time/zone/TCKZoneRules.java + test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java + test/java/time/test/java/time/AbstractTest.java + test/java/time/test/java/time/MockSimplePeriod.java + test/java/time/test/java/time/TestClock_Fixed.java + test/java/time/test/java/time/TestClock_Offset.java + test/java/time/test/java/time/TestClock_System.java + test/java/time/test/java/time/TestClock_Tick.java + test/java/time/test/java/time/TestDuration.java + test/java/time/test/java/time/TestInstant.java + test/java/time/test/java/time/TestLocalDate.java + test/java/time/test/java/time/TestLocalDateTime.java + test/java/time/test/java/time/TestLocalTime.java + test/java/time/test/java/time/TestPeriod.java + test/java/time/test/java/time/TestPeriodParser.java + test/java/time/test/java/time/TestZoneId.java + test/java/time/test/java/time/TestZoneOffset.java + test/java/time/test/java/time/TestZonedDateTime.java + test/java/time/test/java/time/format/AbstractTestPrinterParser.java + test/java/time/test/java/time/format/MockIOExceptionAppendable.java + test/java/time/test/java/time/format/TestCharLiteralParser.java + test/java/time/test/java/time/format/TestCharLiteralPrinter.java + test/java/time/test/java/time/format/TestDateTimeFormatSymbols.java + test/java/time/test/java/time/format/TestDateTimeFormatter.java + test/java/time/test/java/time/format/TestDateTimeFormatters.java + test/java/time/test/java/time/format/TestDateTimePrintException.java + test/java/time/test/java/time/format/TestDateTimeTextProvider.java + test/java/time/test/java/time/format/TestFractionPrinterParser.java + test/java/time/test/java/time/format/TestNumberParser.java + test/java/time/test/java/time/format/TestNumberPrinter.java + test/java/time/test/java/time/format/TestPadParserDecorator.java + test/java/time/test/java/time/format/TestPadPrinterDecorator.java + test/java/time/test/java/time/format/TestReducedParser.java + test/java/time/test/java/time/format/TestReducedPrinter.java + test/java/time/test/java/time/format/TestSettingsParser.java + test/java/time/test/java/time/format/TestStringLiteralParser.java + test/java/time/test/java/time/format/TestStringLiteralPrinter.java + test/java/time/test/java/time/format/TestTextParser.java + test/java/time/test/java/time/format/TestTextPrinter.java + test/java/time/test/java/time/format/TestZoneIdParser.java + test/java/time/test/java/time/format/TestZoneOffsetParser.java + test/java/time/test/java/time/format/TestZoneOffsetPrinter.java + test/java/time/test/java/time/format/TestZoneTextPrinterParser.java + test/java/time/test/java/time/temporal/MockFieldNoValue.java + test/java/time/test/java/time/temporal/MockFieldValue.java + test/java/time/test/java/time/temporal/TestChronoUnit.java + test/java/time/test/java/time/temporal/TestDateTimeAdjusters.java + test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java + test/java/time/test/java/time/temporal/TestDateTimeValueRange.java + test/java/time/test/java/time/temporal/TestISOChronoImpl.java + test/java/time/test/java/time/temporal/TestJapaneseChronoImpl.java + test/java/time/test/java/time/temporal/TestMonthDay.java + test/java/time/test/java/time/temporal/TestOffsetDate.java + test/java/time/test/java/time/temporal/TestOffsetDateTime.java + test/java/time/test/java/time/temporal/TestOffsetDateTime_instants.java + test/java/time/test/java/time/temporal/TestOffsetTime.java + test/java/time/test/java/time/temporal/TestThaiBuddhistChronoImpl.java + test/java/time/test/java/time/temporal/TestYear.java + test/java/time/test/java/time/temporal/TestYearMonth.java + test/java/time/test/java/time/zone/TestFixedZoneRules.java + test/java/time/test/java/util/TestFormatter.java From xueming.shen at oracle.com Tue Jan 22 20:57:27 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 23 Jan 2013 04:57:27 +0000 Subject: hg: jdk8/tl: 8003680: JSR 310 Date/Time API Message-ID: <20130123045727.7D1AD474A4@hg.openjdk.java.net> Changeset: 8209c91b751d Author: sherman Date: 2013-01-22 21:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8209c91b751d 8003680: JSR 310 Date/Time API Summary: Integration of JSR310 Date/Time API for M6 Reviewed-by: alanb, naoto, dholmes Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com, richard.warburton at gmail.com, misterm at gmail.com ! common/makefiles/javadoc/CORE_PKGS.gmk ! make/jprt.properties ! test/Makefile From vincent.x.ryan at oracle.com Wed Jan 23 01:50:00 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 23 Jan 2013 09:50:00 +0000 Subject: hg: jdk8/tl/jdk: 8006741: javadoc cleanup for 6263419 Message-ID: <20130123095040.D74E1474C5@hg.openjdk.java.net> Changeset: 71691b9d45ab Author: vinnie Date: 2013-01-23 09:49 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/71691b9d45ab 8006741: javadoc cleanup for 6263419 Reviewed-by: alanb ! src/share/classes/java/security/PrivateKey.java ! src/share/classes/javax/crypto/SecretKey.java From vincent.x.ryan at oracle.com Wed Jan 23 01:56:01 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 23 Jan 2013 09:56:01 +0000 Subject: [8] 8006741: javadoc cleanup for 6263419 Message-ID: FYI this is a minor correction to javadoc tag: Webrev: http://cr.openjdk.java.net/~vinnie/8006741/webrev.00/ From Alan.Bateman at oracle.com Wed Jan 23 02:13:01 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2013 10:13:01 +0000 Subject: RFR(XS) 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac In-Reply-To: <50FEAA7F.8040106@oracle.com> References: <50FEAA7F.8040106@oracle.com> Message-ID: <50FFB7AD.4030409@oracle.com> On 22/01/2013 15:04, Chris Hegarty wrote: > These tests started failing recently on some mac machines. They appear > to hang and timeout. > > FAILED: > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh > FAILED: > sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.sh > > > Webrev: > http://cr.openjdk.java.net/~chegar/8006669/webrev.00/webrev/ > : This looks fine to me. -Alan. From chris.hegarty at oracle.com Wed Jan 23 06:47:31 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 23 Jan 2013 14:47:31 +0000 Subject: hg: jdk8/tl/jdk: 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac Message-ID: <20130123144822.C9D6A474CB@hg.openjdk.java.net> Changeset: bf2a14ebb6e9 Author: chegar Date: 2013-01-23 14:45 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf2a14ebb6e9 8006669: sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails on mac Reviewed-by: alanb ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.java ! test/sun/security/ssl/sun/net/www/protocol/https/HttpsURLConnection/PostThruProxyWithAuth.java From maurizio.cimadamore at oracle.com Wed Jan 23 07:08:44 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 23 Jan 2013 15:08:44 +0000 Subject: hg: jdk8/tl/langtools: 8006692: jdk/test/java/util/Collections/BigBinarySearch.java fails to compile Message-ID: <20130123150849.81DF2474CD@hg.openjdk.java.net> Changeset: 97bd5e7151bc Author: mcimadamore Date: 2013-01-23 15:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/97bd5e7151bc 8006692: jdk/test/java/util/Collections/BigBinarySearch.java fails to compile Summary: Missing boxing cause spurious inference failure Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/inference/8006692/T8006692.java From alan.bateman at oracle.com Wed Jan 23 07:14:46 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 23 Jan 2013 15:14:46 +0000 Subject: hg: jdk8/tl/jdk: 8006764: FunctionalInterface missing from rt.jar (old build) Message-ID: <20130123151511.AFF7C474CE@hg.openjdk.java.net> Changeset: 53064bbaeec5 Author: alanb Date: 2013-01-23 15:12 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53064bbaeec5 8006764: FunctionalInterface missing from rt.jar (old build) Reviewed-by: lancea, forax ! make/java/java/FILES_java.gmk From vincent.x.ryan at oracle.com Wed Jan 23 08:18:11 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 23 Jan 2013 16:18:11 +0000 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <50FF0309.5070605@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <50FDDAE5.5030707@oracle.com> <50FEBD48.5020307@oracle.com> <50FEC34B.8020607@oracle.com> <50FED8E2.8020509@oracle.com> <50FF0309.5070605@oracle.com> Message-ID: <5AC2D7A2-56E4-4BF0-B49A-B1EF6F28D827@oracle.com> Thanks for those comments Sean. On 22 Jan 2013, at 21:22, Sean Mullan wrote: > Final set of comments in this webrev: > > PKCS12KeyStore.java > > [214] Minor comment, but I think it would be cleaner to create separate SecretKeyEntry and PrivateKeyEntry classes. > I did consider that originally; it's worth doing. > [224, 235-238, 519, 533-536] > > For the attributes, I think it would be cleaner (and faster) to pass Collections.emptySet() instead of null, and then replace lines 235-238 and 533-536 with: > > entry.attributes = attributes; Done. > > [518] You should destroy the PasswordProtection object before returning to the caller (probably with a try-finally) as they don't have a way to clear the password that has been cloned by the PasswordProtection ctor. > Done. > [634-678] Why doesn't this method also support SecretKeys like the other engineSetKeyEntry method? > I cannot determine whether the encoded key is a SecretKey or a PrivateKey so only PrivateKey is supported. > [801-806] You should probably add a TODO comment that this should be first checking the security property, and if not set then falling back to "PBEWithSHA1AndDESede". Shouldn't we fallback to something stronger (SHA256/AES?) though? I've added code to check the security property > > [910] what if this is a SecretKey? Should you still decrement this? > Corrected. > [1484-1522] Why don't you just write out the bytes from the PKCS12Attribute.getEncoded() method rather than parsing and converting the Strings for the OID and value? > Right. This code had not been updated to use PKCS12Attribute. > [2216 -] It seems it would be better to create the PKCS12Attributes with the byte[] ctor, as that retains the full encoding information, and you could return arbitrary attributes we don't recognize. Also, the String ctor will cause it to be re-encoded again, when we already have the encoding. > Same as above. > --Sean > > On 01/22/2013 01:22 PM, Sean Mullan wrote: >> More comments ... >> >> PKCS12Attribute.java: >> >> [213-215] You can replace this with Arrays.hashCode(byte[]). >> >> --Sean >> >> On 01/22/2013 11:50 AM, Sean Mullan wrote: >>> More comments: >>> >>> KeyStore.java >>> >>> [551, 670, 753] Needs to make a copy (clone) according to javadoc, so >>> should be: >>> >>> this.attributes = Collections.unmodifiableSet(new HashSet<>(attributes)); >>> >>> --Sean >>> >>> On 01/22/2013 11:24 AM, Sean Mullan wrote: >>>> Comments so far, will send more as I review more: >>>> >>>> AlgorithmId.java >>>> >>>> * Update copyright >>>> >>>> KeyStore.java >>>> >>>> [296] I think you want to say: >>>> >>>> If none was set then null is returned. >>>> >>>> As I understand it, if none is set, then the KeyStore provider will use >>>> a default algorithm as specified by the Security property. This needs to >>>> be made clearer in the javadoc, as it reads it says it returns the value >>>> of this property, which is not possible since this class doesn't know >>>> what keystore type is being used at this point. >>>> >>>> [304] specify that null can be returned - >>>> >>>> @return the algorithm name, or null if none was set >>>> >>>> --Sean >>>> >>>> >>>> On 01/21/2013 07:18 PM, Vincent Ryan wrote: >>>>> >>>>> Updated webrev to include java.security.PKCS12Attribute: >>>>> http://cr.openjdk.java.net/~vinnie/8005408/webrev.01/ >>>>> >>>>> >>>>> >>>>> On 21/01/2013 15:18, Vincent Ryan wrote: >>>>>> Hello, >>>>>> >>>>>> Please review the fix for 8005408. It adds support for associating >>>>>> attributes with keystore entries. >>>>>> It is yet another component of the JEP-166 delivery. >>>>>> >>>>>> This new API permits several enhancements to the PKCS12 keystore >>>>>> implementation: the storage of >>>>>> trusted certificates, storage of secret keys and support for entry >>>>>> metadata. Currently, only the >>>>>> PKCS12 keystore takes advantage of these new KeyStore APIs. >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ >>>>>> >>>>>> >>>>>> For storing trusted certificates in PKCS12 a new SafeBag attribute >>>>>> (with >>>>>> a familiar syntax) is introduced >>>>>> to indicate a trust usage: >>>>>> >>>>>> |trustedKeyUsage ATTRIBUTE ::= {| >>>>>> |||WITH SYNTAX ExtKeyUsageSyntax| >>>>>> |||ID id-at-trustedKeyUsage -- object identifier from an Oracle arc| >>>>>> |}| >>>>>> |-- from RFC ||5832||, Section ||4.2||.||1.12| >>>>>> |||ExtKeyUsageSyntax ::= SEQUENCE SIZE (||1||..MAX) OF KeyPurposeId| >>>>>> |||KeyPurposeId ::= OBJECT IDENTIFIER| >>>>>> |||anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage ||0| >>>>>> |}| >>>>>> >>>>>> Note that this approach does not preclude the storage of a Trust >>>>>> Anchor >>>>>> List (as defined in RFC 5914) >>>>>> which was proposed earlier on this list. >>>>>> >>>>>> >>>>>> There is one omission from the webrev above: the >>>>>> java.security.PKCS12Attribute class needs some >>>>>> additional changes and will be posted shortly. >>>>>> >>>>>> Again, JEP-166 is on a tight schedule for M6 so your early comments >>>>>> are >>>>>> appreciated. >>>>>> >>>>>> Thanks. >>>>> >>>> >>> >> > From sean.mullan at oracle.com Wed Jan 23 08:40:53 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 Jan 2013 11:40:53 -0500 Subject: [8] Code review request for 8006591: Protect keystore entries using stronger PBE algorithms In-Reply-To: <50FF1E2A.8090309@oracle.com> References: <14830960-D7FB-4EF7-B012-C5150498D1C6@oracle.com> <50FF1E2A.8090309@oracle.com> Message-ID: <51001295.8090906@oracle.com> Just one comment: 1. In PasswordProtection.getAlgorithm(), I'd recommend adding the following sentence: "If this security property is not set, an implementation-specific algorithm will be used." --Sean On 01/22/2013 06:18 PM, Vincent Ryan wrote: > Last call and an updated webrev that includes the review comments: > > Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.01/ > > > On 18/01/2013 19:53, Vincent Ryan wrote: >> Hello, >> >> Please review the fix for 8006591. It introduces a mechanism to enable >> stronger PBE algorithms to be specified when encrypting a keystore entry. >> This allows developers to make use of the new PBE algorithms delivered in >> JEP-121. Note however that PKCS12 is currently the only keystore that >> supports this new feature. >> >> It is a component of the JEP-166 delivery. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8006591/webrev.00/ >> >> Thanks. > From mstjohns at comcast.net Wed Jan 23 09:42:06 2013 From: mstjohns at comcast.net (Michael StJohns) Date: Wed, 23 Jan 2013 12:42:06 -0500 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> Message-ID: <20130123174159.78F1C6D53@mail.openjdk.java.net> In KeyStore.java - Attribute should probably be abstract rather than interface - mainly because you need to define equals properly to honor the Set contract for an attribute. E.g. the equals is only against the "name" - not the encoded name/value. This can be overridden later. In PKCS12Attribute - line 194 - a simple compare against the OID value of type is probably where you want to go here. Otherwise you can have multiple Attributes with the same type, but different values. There's something wrong with your definition of the trusted key attribute - I think. See below. At 10:18 AM 1/21/2013, Vincent Ryan wrote: >Hello, > >Please review the fix for 8005408. It adds support for associating attributes with keystore entries. >It is yet another component of the JEP-166 delivery. > >This new API permits several enhancements to the PKCS12 keystore implementation: the storage of >trusted certificates, storage of secret keys and support for entry metadata. Currently, only the >PKCS12 keystore takes advantage of these new KeyStore APIs. > >Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ > > >For storing trusted certificates in PKCS12 a new SafeBag attribute (with a familiar syntax) is introduced >to indicate a trust usage: > >trustedKeyUsage ATTRIBUTE ::= { > WITH SYNTAX ExtKeyUsageSyntax > ID id-at-trustedKeyUsage -- object identifier from an Oracle arc >} > >-- from RFC 5832, Section 4.2.1.12 > ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId > KeyPurposeId ::= OBJECT IDENTIFIER > anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } What I think you want as an encoding is SEQUENCE { id-at-trustedCert, SET of { BOOLEAN DEFAULT TRUE } } Or basically the oid with an empty set under it. Don't use ExtKeyUsage as the syntax. Its probably incorrect for what you're trying to accomplish. TrustedCert :: BOOLEAN DEFAULT TRUE trustedCertAttribute ATTRIBUTE ::= { ID id-at-trustedCert, WITH SYNTAX TrustedCert } Alternately, use a syntax of NULL. Try to get a real OID allocation for id-at-trustedCert before this goes final. >Note that this approach does not preclude the storage of a Trust Anchor List (as defined in RFC 5914) >which was proposed earlier on this list. > > >There is one omission from the webrev above: the java.security.PKCS12Attribute class needs some >additional changes and will be posted shortly. > >Again, JEP-166 is on a tight schedule for M6 so your early comments are appreciated. > >Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130123/c0211acb/attachment.html From rob.mckenna at oracle.com Wed Jan 23 10:00:35 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Wed, 23 Jan 2013 18:00:35 +0000 Subject: hg: jdk8/tl/jdk: 8004729: Add java.lang.reflect.Parameter and related changes for parameter reflection Message-ID: <20130123180114.08DA3474D4@hg.openjdk.java.net> Changeset: c9eb1d3ef37f Author: robm Date: 2013-01-23 17:54 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c9eb1d3ef37f 8004729: Add java.lang.reflect.Parameter and related changes for parameter reflection Reviewed-by: darcy, forax, psandoz, dholmes, tbell ! make/java/java/Exportedfiles.gmk ! make/java/java/FILES_c.gmk ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/Modifier.java + src/share/classes/java/lang/reflect/Parameter.java ! src/share/javavm/export/jvm.h + src/share/native/java/lang/reflect/Executable.c + test/java/lang/reflect/Parameter/WithParameters.java + test/java/lang/reflect/Parameter/WithoutParameters.java From xueming.shen at oracle.com Wed Jan 23 10:26:36 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 23 Jan 2013 18:26:36 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130123182710.1873D474D5@hg.openjdk.java.net> Changeset: e0552f13f4a2 Author: sherman Date: 2013-01-23 10:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0552f13f4a2 8006773: test/java/util/zip/ZipFile/FinalizeZipFile.java failing intermittently Summary: fixed the test case Reviewed-by: alanb ! test/java/util/zip/ZipFile/FinalizeZipFile.java Changeset: 87f5569effdd Author: sherman Date: 2013-01-23 10:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87f5569effdd Merge From vincent.x.ryan at oracle.com Wed Jan 23 10:42:52 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 23 Jan 2013 18:42:52 +0000 Subject: [8] Code review request for 8005408: KeyStore API enhancements In-Reply-To: <201301231742.r0NHg00H026408@aserp1060.oracle.com> References: <67153B41-AF83-4A1A-A238-2782D0904792@oracle.com> <201301231742.r0NHg00H026408@aserp1060.oracle.com> Message-ID: Thanks for your comments Michael. Your suggestions involve API changes that I cannot accommodate in time for Milestone 6. I will address these issues following M6 and have filed the following bug report to track that task: 8006796: Address additional review comments for 8005408 BTW the current syntax for the trustedKeyUsage attribute is designed to enable certs to be marked as trusted for limited purposes. Your suggestion delivers a simpler syntax but loses this feature. On 23 Jan 2013, at 17:42, Michael StJohns wrote: > In KeyStore.java - > > Attribute should probably be abstract rather than interface - mainly because you need to define equals properly to honor the Set contract for an attribute. E.g. the equals is only against the "name" - not the encoded name/value. This can be overridden later. > > In PKCS12Attribute - line 194 - a simple compare against the OID value of type is probably where you want to go here. Otherwise you can have multiple Attributes with the same type, but different values. > > > There's something wrong with your definition of the trusted key attribute - I think. See below. > > > > At 10:18 AM 1/21/2013, Vincent Ryan wrote: >> Hello, >> >> Please review the fix for 8005408. It adds support for associating attributes with keystore entries. >> It is yet another component of the JEP-166 delivery. >> >> This new API permits several enhancements to the PKCS12 keystore implementation: the storage of >> trusted certificates, storage of secret keys and support for entry metadata. Currently, only the >> PKCS12 keystore takes advantage of these new KeyStore APIs. >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8005408/webrev.00/ >> >> >> For storing trusted certificates in PKCS12 a new SafeBag attribute (with a familiar syntax) is introduced >> to indicate a trust usage: >> >> trustedKeyUsage ATTRIBUTE ::= { >> WITH SYNTAX ExtKeyUsageSyntax >> ID id-at-trustedKeyUsage -- object identifier from an Oracle arc >> } >> >> -- from RFC 5832, Section 4.2.1.12 >> ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId >> KeyPurposeId ::= OBJECT IDENTIFIER >> anyExtendedKeyUsage OBJECT IDENTIFIER ::= { id-ce-extKeyUsage 0 } > > > What I think you want as an encoding is > > SEQUENCE { > id-at-trustedCert, > SET of { > BOOLEAN DEFAULT TRUE > } > } > > Or basically the oid with an empty set under it. Don't use ExtKeyUsage as the syntax. Its probably incorrect for what you're trying to accomplish. > > TrustedCert :: BOOLEAN DEFAULT TRUE > > trustedCertAttribute ATTRIBUTE ::= { > ID id-at-trustedCert, > WITH SYNTAX TrustedCert > } > > Alternately, use a syntax of NULL. > > Try to get a real OID allocation for id-at-trustedCert before this goes final. > > > >> Note that this approach does not preclude the storage of a Trust Anchor List (as defined in RFC 5914) >> which was proposed earlier on this list. >> >> >> There is one omission from the webrev above: the java.security.PKCS12Attribute class needs some >> additional changes and will be posted shortly. >> >> Again, JEP-166 is on a tight schedule for M6 so your early comments are appreciated. >> >> Thanks. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130123/146f891a/attachment.html From vicente.romero at oracle.com Wed Jan 23 13:00:05 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 23 Jan 2013 21:00:05 +0000 Subject: hg: jdk8/tl/langtools: 8006694: temporarily workaround combo tests are causing time out in several platforms Message-ID: <20130123210011.5DE04474E4@hg.openjdk.java.net> Changeset: 5c956be64b9e Author: vromero Date: 2013-01-23 20:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/5c956be64b9e 8006694: temporarily workaround combo tests are causing time out in several platforms Reviewed-by: jjg Contributed-by: maurizio.cimadamore at oracle.com ! test/Makefile ! test/tools/javac/Diagnostics/6769027/T6769027.java ! test/tools/javac/T7093325.java ! test/tools/javac/cast/intersection/IntersectionTypeCastTest.java ! test/tools/javac/defaultMethods/super/TestDefaultSuperCall.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/generics/diamond/7046778/DiamondAndInnerClassTest.java ! test/tools/javac/generics/rawOverride/7062745/GenericOverrideTest.java ! test/tools/javac/lambda/FunctionalInterfaceConversionTest.java ! test/tools/javac/lambda/LambdaParserTest.java ! test/tools/javac/lambda/MethodReferenceParserTest.java ! test/tools/javac/lambda/TestInvokeDynamic.java ! test/tools/javac/lambda/mostSpecific/StructuralMostSpecificTest.java ! test/tools/javac/lambda/typeInference/combo/TypeInferenceComboTest.java ! test/tools/javac/lambdaShapes/org/openjdk/tests/vm/FDSeparateCompilationTest.java ! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java ! test/tools/javac/multicatch/7030606/DisjunctiveTypeWellFormednessTest.java ! test/tools/javac/varargs/7042566/T7042566.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java From vincent.x.ryan at oracle.com Wed Jan 23 13:27:34 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 23 Jan 2013 21:27:34 +0000 Subject: hg: jdk8/tl/jdk: 8006591: Protect keystore entries using stronger PBE algorithms Message-ID: <20130123212752.E5816474E5@hg.openjdk.java.net> Changeset: 0c86df653029 Author: vinnie Date: 2013-01-23 21:25 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c86df653029 8006591: Protect keystore entries using stronger PBE algorithms Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java + test/java/security/KeyStore/PBETest.java From jonathan.gibbons at oracle.com Wed Jan 23 13:28:05 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 23 Jan 2013 21:28:05 +0000 Subject: hg: jdk8/tl/langtools: 8006775: JSR 308: Compiler changes in JDK8 Message-ID: <20130123212807.D5A39474E6@hg.openjdk.java.net> Changeset: 71f35e4b93a5 Author: jjg Date: 2013-01-23 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/71f35e4b93a5 8006775: JSR 308: Compiler changes in JDK8 Reviewed-by: jjg Contributed-by: mernst at cs.washington.edu, wmdietl at cs.washington.edu, mpapi at csail.mit.edu, mahmood at notnoop.com + src/share/classes/com/sun/javadoc/AnnotatedType.java ! src/share/classes/com/sun/javadoc/ExecutableMemberDoc.java ! src/share/classes/com/sun/javadoc/Type.java ! src/share/classes/com/sun/javadoc/TypeVariable.java + src/share/classes/com/sun/source/tree/AnnotatedTypeTree.java ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/Tree.java ! src/share/classes/com/sun/source/tree/TreeVisitor.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/source/util/SimpleTreeVisitor.java ! src/share/classes/com/sun/source/util/TaskEvent.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/classfile/Attribute.java ! src/share/classes/com/sun/tools/classfile/ClassWriter.java + src/share/classes/com/sun/tools/classfile/RuntimeInvisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/RuntimeVisibleTypeAnnotations_attribute.java + src/share/classes/com/sun/tools/classfile/TypeAnnotation.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractExecutableMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/LinkInfoImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/links/LinkInfo.java ! src/share/classes/com/sun/tools/javac/code/Annotations.java ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Lint.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Source.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/TargetType.java ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java + src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/ConstFold.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Lower.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/comp/TransTypes.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/jvm/Code.java ! src/share/classes/com/sun/tools/javac/jvm/Gen.java ! src/share/classes/com/sun/tools/javac/jvm/JNIWriter.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/model/JavacTypes.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/parser/Scanner.java ! src/share/classes/com/sun/tools/javac/parser/UnicodeReader.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_ja.properties ! src/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! src/share/classes/com/sun/tools/javac/tree/TreeCopier.java ! src/share/classes/com/sun/tools/javac/tree/TreeInfo.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javac/tree/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/TreeTranslator.java ! src/share/classes/com/sun/tools/javac/util/JCDiagnostic.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javadoc/AbstractTypeImpl.java + src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/PrimitiveType.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java ! src/share/classes/com/sun/tools/javap/AnnotationWriter.java ! src/share/classes/com/sun/tools/javap/AttributeWriter.java ! src/share/classes/com/sun/tools/javap/CodeWriter.java ! src/share/classes/com/sun/tools/javap/InstructionDetailWriter.java + src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java ! src/share/classes/javax/lang/model/SourceVersion.java + src/share/classes/javax/lang/model/type/AnnotatedType.java ! src/share/classes/javax/lang/model/type/ExecutableType.java ! src/share/classes/javax/lang/model/type/TypeKind.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/Types.java + test/com/sun/javadoc/testAnnotationOptional/TestAnnotationOptional.java + test/com/sun/javadoc/testAnnotationOptional/pkg/AnnotationOptional.java + test/com/sun/javadoc/typeAnnotations/smoke/TestSmoke.java + test/com/sun/javadoc/typeAnnotations/smoke/pkg/TargetTypes.java ! test/tools/javac/7129225/TestImportStar.java ! test/tools/javac/7129225/TestImportStar.ref ! test/tools/javac/T6873845.java + test/tools/javac/T6985181.java ! test/tools/javac/annotations/6881115/T6881115.java ! test/tools/javac/annotations/6881115/T6881115.out + test/tools/javac/annotations/typeAnnotations/6967002/T6967002.java + test/tools/javac/annotations/typeAnnotations/6967002/T6967002.out + test/tools/javac/annotations/typeAnnotations/InnerClass.java + test/tools/javac/annotations/typeAnnotations/MultipleTargets.java + test/tools/javac/annotations/typeAnnotations/TargetTypes.java + test/tools/javac/annotations/typeAnnotations/TypeParameterTarget.java + test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java + test/tools/javac/annotations/typeAnnotations/TypeUseTarget.java + test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java + test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java + test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java + test/tools/javac/annotations/typeAnnotations/attribution/Scopes.java + test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java + test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java + test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java + test/tools/javac/annotations/typeAnnotations/classfile/DeadCode.java + test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java + test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java + test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.java + test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion.out + test/tools/javac/annotations/typeAnnotations/failures/AnnotationVersion7.out + test/tools/javac/annotations/typeAnnotations/failures/BadCast.java + test/tools/javac/annotations/typeAnnotations/failures/BadCast.out + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.java + test/tools/javac/annotations/typeAnnotations/failures/CantAnnotateStaticClass.out + test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.java + test/tools/javac/annotations/typeAnnotations/failures/IncompleteArray.out + test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.java + test/tools/javac/annotations/typeAnnotations/failures/IncompleteVararg.out + test/tools/javac/annotations/typeAnnotations/failures/IndexArray.java + test/tools/javac/annotations/typeAnnotations/failures/IndexArray.out + test/tools/javac/annotations/typeAnnotations/failures/LintCast.java + test/tools/javac/annotations/typeAnnotations/failures/LintCast.out + test/tools/javac/annotations/typeAnnotations/failures/OldArray.java + test/tools/javac/annotations/typeAnnotations/failures/Scopes.java + test/tools/javac/annotations/typeAnnotations/failures/Scopes.out + test/tools/javac/annotations/typeAnnotations/failures/StaticFields.java + test/tools/javac/annotations/typeAnnotations/failures/StaticFields.out + test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.java + test/tools/javac/annotations/typeAnnotations/failures/StaticMethods.out + test/tools/javac/annotations/typeAnnotations/failures/TypeAndField.java + test/tools/javac/annotations/typeAnnotations/failures/VoidGenericMethod.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/arrays/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/innertypeparams/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/newarray/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/BrokenAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/parambounds/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/Nesting.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/StaticThings.out + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.java + test/tools/javac/annotations/typeAnnotations/failures/common/receiver/WrongType.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/rest/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeArgs/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/typeparams/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/DuplicateTypeAnnotation.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/InvalidLocation.out + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.java + test/tools/javac/annotations/typeAnnotations/failures/common/wildcards/MissingAnnotationValue.out + test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.java + test/tools/javac/annotations/typeAnnotations/failures/target/Constructor.out + test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java + test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.out + test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.java + test/tools/javac/annotations/typeAnnotations/failures/target/IncompleteArray.out + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.java + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeParameter.out + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.java + test/tools/javac/annotations/typeAnnotations/failures/target/NotTypeUse.out + test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.java + test/tools/javac/annotations/typeAnnotations/failures/target/VoidMethod.out + test/tools/javac/annotations/typeAnnotations/newlocations/BasicTest.java + test/tools/javac/annotations/typeAnnotations/newlocations/ClassExtends.java + test/tools/javac/annotations/typeAnnotations/newlocations/ClassParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/ConstructorTypeArgs.java + test/tools/javac/annotations/typeAnnotations/newlocations/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Expressions.java + test/tools/javac/annotations/typeAnnotations/newlocations/Fields.java + test/tools/javac/annotations/typeAnnotations/newlocations/LocalVariables.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodReturnType.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeArgs.java + test/tools/javac/annotations/typeAnnotations/newlocations/MethodTypeParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/MultiCatch.java + test/tools/javac/annotations/typeAnnotations/newlocations/NestedTypes.java + test/tools/javac/annotations/typeAnnotations/newlocations/Parameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Receivers.java + test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java + test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.out + test/tools/javac/annotations/typeAnnotations/newlocations/ResourceVariables.java + test/tools/javac/annotations/typeAnnotations/newlocations/Throws.java + test/tools/javac/annotations/typeAnnotations/newlocations/TopLevelBlocks.java + test/tools/javac/annotations/typeAnnotations/newlocations/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/newlocations/TypeParameters.java + test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java + test/tools/javac/annotations/typeAnnotations/newlocations/Wildcards.java + test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java + test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java + test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java + test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java + test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java ! test/tools/javac/api/EndPositions.java ! test/tools/javac/diags/CheckResourceKeys.java ! test/tools/javac/diags/examples.not-yet.txt + test/tools/javac/diags/examples/CantAnnotateNestedType.java + test/tools/javac/diags/examples/CantAnnotateStaticClass.java + test/tools/javac/diags/examples/IncorrectReceiverType.java + test/tools/javac/diags/examples/NoAnnotationsOnDotClass.java + test/tools/javac/diags/examples/ThisAsIdentifier.java + test/tools/javac/diags/examples/TypeAnnotationsNotSupported.java ! test/tools/javac/failover/CheckAttributedTree.java ! test/tools/javac/processing/6994946/SemanticErrorTest.2.out ! test/tools/javac/processing/model/element/TestAnonClassNames.java ! test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.java + test/tools/javac/processing/model/element/TestMissingElement/TestMissingElement.ref ! test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.java + test/tools/javac/processing/model/util/directSupersOfErr/DirectSupersOfErr.ref ! test/tools/javac/tree/TreeKindTest.java ! test/tools/javac/tree/TreePosTest.java + test/tools/javac/treeannotests/AnnoTreeTests.java ! test/tools/javac/treeannotests/TestProcessor.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.out + test/tools/javap/typeAnnotations/JSR175Annotations.java + test/tools/javap/typeAnnotations/NewArray.java + test/tools/javap/typeAnnotations/Presence.java + test/tools/javap/typeAnnotations/PresenceInner.java + test/tools/javap/typeAnnotations/T6855990.java + test/tools/javap/typeAnnotations/TypeCasts.java + test/tools/javap/typeAnnotations/Visibility.java + test/tools/javap/typeAnnotations/Wildcards.java From alexey.utkin at oracle.com Wed Jan 23 03:10:35 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Wed, 23 Jan 2013 11:10:35 +0000 Subject: hg: jdk8/tl/jdk: 6519127: user.home property not set correctly Message-ID: <20130123111048.B7CBD474C6@hg.openjdk.java.net> Changeset: 01b36b400145 Author: uta Date: 2013-01-23 15:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/01b36b400145 6519127: user.home property not set correctly Summary: Registry-based approach was changed to SHGetKnownFolderPath/SHGetFolderPathW Reviewed-by: alanb, anthony ! src/windows/native/java/lang/java_props_md.c From vincent.x.ryan at oracle.com Wed Jan 23 15:14:41 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Wed, 23 Jan 2013 23:14:41 +0000 Subject: hg: jdk8/tl/jdk: 8005408: KeyStore API enhancements Message-ID: <20130123231505.DF6E7474F6@hg.openjdk.java.net> Changeset: 1da93663f8f3 Author: vinnie Date: 2013-01-23 23:13 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1da93663f8f3 8005408: KeyStore API enhancements Reviewed-by: mullan ! src/share/classes/java/security/KeyStore.java + src/share/classes/java/security/PKCS12Attribute.java ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! src/share/classes/sun/security/x509/AlgorithmId.java + test/sun/security/pkcs12/StorePasswordTest.java + test/sun/security/pkcs12/StoreSecretKeyTest.java + test/sun/security/pkcs12/StoreTrustedCertTest.java + test/sun/security/pkcs12/trusted.pem From sean.mullan at oracle.com Wed Jan 23 17:42:52 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Wed, 23 Jan 2013 20:42:52 -0500 Subject: URGENT Code Review Request for JDK-8006813: Compilation error in PKCS12KeyStore.java Message-ID: <5100919C.6080809@oracle.com> Valerie, can you please review the following fix: http://cr.openjdk.java.net/~mullan/webrevs/8006813/webrev.00/ Thanks, Sean From valerie.peng at oracle.com Wed Jan 23 17:45:29 2013 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 23 Jan 2013 17:45:29 -0800 Subject: URGENT Code Review Request for JDK-8006813: Compilation error in PKCS12KeyStore.java In-Reply-To: <5100919C.6080809@oracle.com> References: <5100919C.6080809@oracle.com> Message-ID: <51009239.6010004@oracle.com> Change looks good. Thanks, Valerie On 01/23/13 17:42, Sean Mullan wrote: > Valerie, can you please review the following fix: > > http://cr.openjdk.java.net/~mullan/webrevs/8006813/webrev.00/ > > Thanks, > Sean From sean.mullan at oracle.com Wed Jan 23 17:47:52 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Thu, 24 Jan 2013 01:47:52 +0000 Subject: hg: jdk8/tl/jdk: 8006813: Compilation error in PKCS12KeyStore.java Message-ID: <20130124014816.49EFF474FE@hg.openjdk.java.net> Changeset: 89f37f7188df Author: mullan Date: 2013-01-23 20:46 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/89f37f7188df 8006813: Compilation error in PKCS12KeyStore.java Reviewed-by: valeriep ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From joe.darcy at oracle.com Wed Jan 23 20:11:18 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 24 Jan 2013 04:11:18 +0000 Subject: hg: jdk8/tl/langtools: 8006264: Add explanation of why default methods cannot be used in JDK 8 javax.lang.model Message-ID: <20130124041124.3C31447505@hg.openjdk.java.net> Changeset: 09f65aad4759 Author: darcy Date: 2013-01-23 20:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/09f65aad4759 8006264: Add explanation of why default methods cannot be used in JDK 8 javax.lang.model Reviewed-by: jjg ! src/share/classes/javax/lang/model/element/AnnotationValueVisitor.java ! src/share/classes/javax/lang/model/element/ElementVisitor.java ! src/share/classes/javax/lang/model/type/TypeVisitor.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractElementVisitor8.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor6.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor7.java ! src/share/classes/javax/lang/model/util/AbstractTypeVisitor8.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor6.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor7.java ! src/share/classes/javax/lang/model/util/ElementKindVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleElementVisitor8.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor8.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor6.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor8.java From alan.bateman at oracle.com Thu Jan 24 01:49:07 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 24 Jan 2013 09:49:07 +0000 Subject: hg: jdk8/tl/jdk: 8006524: JSR-3: Allows java.beans to be optional Message-ID: <20130124094930.1C5AC4750C@hg.openjdk.java.net> Changeset: b68ac92d0b2a Author: alanb Date: 2013-01-24 09:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b68ac92d0b2a 8006524: JSR-3: Allows java.beans to be optional Reviewed-by: dfuchs, mchung ! src/share/classes/javax/management/MXBean.java ! src/share/classes/javax/management/monitor/package.html From vincent.x.ryan at oracle.com Thu Jan 24 07:58:12 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 24 Jan 2013 15:58:12 +0000 Subject: [8] code review for 8006855: PKCS12 test failures due to unsupported algorithm Message-ID: <03A40F78-E7DC-4D90-880B-D29728C9A335@oracle.com> Please review this fix to correct failing tests: Webrev: http://cr.openjdk.java.net/~vinnie/8006855/webrev.00/ Thanks. From sean.mullan at oracle.com Thu Jan 24 08:33:15 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Jan 2013 11:33:15 -0500 Subject: [8] code review for 8006855: PKCS12 test failures due to unsupported algorithm In-Reply-To: <03A40F78-E7DC-4D90-880B-D29728C9A335@oracle.com> References: <03A40F78-E7DC-4D90-880B-D29728C9A335@oracle.com> Message-ID: <5101624B.60307@oracle.com> Looks ok. Since these are workarounds and not fixes for the tests failures, can you open a new bug to track them? --Sean On 01/24/2013 10:58 AM, Vincent Ryan wrote: > Please review this fix to correct failing tests: > > Webrev: http://cr.openjdk.java.net/~vinnie/8006855/webrev.00/ > > Thanks. > From vincent.x.ryan at oracle.com Thu Jan 24 08:45:31 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 24 Jan 2013 16:45:31 +0000 Subject: [8] code review for 8006855: PKCS12 test failures due to unsupported algorithm In-Reply-To: <5101624B.60307@oracle.com> References: <03A40F78-E7DC-4D90-880B-D29728C9A335@oracle.com> <5101624B.60307@oracle.com> Message-ID: <41306DB9-8382-4FB3-8808-BBEA021BE452@oracle.com> Sure. I just wanted to avoid the nightly failures until I get time to investigate these further. Thanks. On 24 Jan 2013, at 16:33, Sean Mullan wrote: > Looks ok. Since these are workarounds and not fixes for the tests failures, can you open a new bug to track them? > > --Sean > > On 01/24/2013 10:58 AM, Vincent Ryan wrote: >> Please review this fix to correct failing tests: >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8006855/webrev.00/ >> >> Thanks. >> > From vincent.x.ryan at oracle.com Thu Jan 24 08:45:00 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 24 Jan 2013 16:45:00 +0000 Subject: hg: jdk8/tl/jdk: 8006855: PKCS12 test failures due to unsupported algorithm Message-ID: <20130124164544.CB4414751C@hg.openjdk.java.net> Changeset: 943af87e0269 Author: vinnie Date: 2013-01-24 16:44 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/943af87e0269 8006855: PKCS12 test failures due to unsupported algorithm Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java ! test/java/security/KeyStore/PBETest.java ! test/sun/security/pkcs12/StoreSecretKeyTest.java From kumar.x.srinivasan at oracle.com Thu Jan 24 09:38:08 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 24 Jan 2013 17:38:08 +0000 Subject: hg: jdk8/tl/jdk: 8006850: [pack200] disable pack200 tests until JSR-308 is implemented Message-ID: <20130124173834.B2D4447525@hg.openjdk.java.net> Changeset: 1fd613016ad9 Author: ksrini Date: 2013-01-24 09:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1fd613016ad9 8006850: [pack200] disable pack200 tests until JSR-308 is implemented Reviewed-by: alanb ! test/ProblemList.txt From vincent.x.ryan at oracle.com Thu Jan 24 10:04:51 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 24 Jan 2013 18:04:51 +0000 Subject: [8] 8006863: javadoc cleanup for 8005408 Message-ID: FYI this is another minor correction to javadoc tag: Webrev: http://cr.openjdk.java.net/~vinnie/8006863/webrev.00/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130124/74f69c8f/attachment.html From sean.mullan at oracle.com Thu Jan 24 10:21:33 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Jan 2013 13:21:33 -0500 Subject: [8] 8006863: javadoc cleanup for 8005408 In-Reply-To: References: Message-ID: <51017BAD.10809@oracle.com> Looks fine. --Sean On 01/24/2013 01:04 PM, Vincent Ryan wrote: > FYI this is another minor correction to javadoc tag: > > Webrev: http://cr.openjdk.java.net/~vinnie/8006863/webrev.00/ From vincent.x.ryan at oracle.com Thu Jan 24 10:21:58 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 24 Jan 2013 18:21:58 +0000 Subject: hg: jdk8/tl/jdk: 8006863: javadoc cleanup for 8005408 Message-ID: <20130124182221.A5E4747527@hg.openjdk.java.net> Changeset: b3f0e0c79bcc Author: vinnie Date: 2013-01-24 18:21 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b3f0e0c79bcc 8006863: javadoc cleanup for 8005408 Reviewed-by: alanb ! src/share/classes/java/security/PKCS12Attribute.java From jason.uh at oracle.com Thu Jan 24 12:52:59 2013 From: jason.uh at oracle.com (Jason Uh) Date: Thu, 24 Jan 2013 12:52:59 -0800 Subject: [8] Request for review: 8006853: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout < 0 Message-ID: <51019F2B.9080605@oracle.com> If the com.sun.security.ocsp.timeout property is set to a negative value, then it should be ignored and the default timeout (15 seconds) should be used. A bug in the code sets it to 15000 seconds. This change fixes that. webrev: http://cr.openjdk.java.net/~juh/8006853/webrev.00/ Thanks, Jason From sean.mullan at oracle.com Thu Jan 24 13:12:56 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 24 Jan 2013 16:12:56 -0500 Subject: [8] Request for review: 8006853: OCSP timeout set to wrong value if com.sun.security.ocsp.timeout < 0 In-Reply-To: <51019F2B.9080605@oracle.com> References: <51019F2B.9080605@oracle.com> Message-ID: <5101A3D8.9070600@oracle.com> Looks good. --Sean On 01/24/2013 03:52 PM, Jason Uh wrote: > If the com.sun.security.ocsp.timeout property is set to a negative > value, then it should be ignored and the default timeout (15 seconds) > should be used. A bug in the code sets it to 15000 seconds. This change > fixes that. > > webrev: http://cr.openjdk.java.net/~juh/8006853/webrev.00/ > > Thanks, > Jason From joe.darcy at oracle.com Thu Jan 24 16:54:27 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 25 Jan 2013 00:54:27 +0000 Subject: hg: jdk8/tl/jdk: 8006895: Clarify that FunctionalInferface is only informative Message-ID: <20130125005448.4AEDD4753C@hg.openjdk.java.net> Changeset: 4d3c05cc21d5 Author: darcy Date: 2013-01-24 16:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4d3c05cc21d5 8006895: Clarify that FunctionalInferface is only informative Reviewed-by: briangoetz ! src/share/classes/java/lang/FunctionalInterface.java From weijun.wang at oracle.com Thu Jan 24 23:08:45 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 25 Jan 2013 15:08:45 +0800 Subject: Core review request: 8001104: Unbound SASL service: the GSSAPI/krb5 mech Message-ID: <51022F7D.7010103@oracle.com> Hi All Please review this code change webrev: http://cr.openjdk.java.net/~weijun/8001104/webrev.01/ bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001104 This is the final part of unbound kerberos server, now on all three layers of using kerberos you don't need to specify a server name, i.e. In SASL: Sasl.createServer("GSSAPI", "protocol", null, ...) In JGSS: gssManager.createContext(null) or gssManager.createCredential(null, ...) And in JAAS login config file server { com.sun.security.auth.module.Krb5LoginModule required principal=* useKeyTab=true; }; Thanks Max From luchsh at linux.vnet.ibm.com Fri Jan 25 01:09:13 2013 From: luchsh at linux.vnet.ibm.com (luchsh at linux.vnet.ibm.com) Date: Fri, 25 Jan 2013 09:09:13 +0000 Subject: hg: jdk8/tl/jdk: 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() Message-ID: <20130125090934.E627047555@hg.openjdk.java.net> Changeset: 4c9fcb5cbc07 Author: dingxmin Date: 2013-01-25 17:00 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4c9fcb5cbc07 7183373: URLClassloader.close() does not close JAR files whose resources have been loaded via getResource() Reviewed-by: chegar ! src/share/classes/sun/misc/URLClassPath.java + test/sun/misc/URLClassPath/JarLoaderTest.java From alan.bateman at oracle.com Fri Jan 25 05:11:51 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Fri, 25 Jan 2013 13:11:51 +0000 Subject: hg: jdk8/tl/jdk: 8006565: java.lang.instrument specification should make it clear that -javaagent is optional Message-ID: <20130125131214.C95A14755B@hg.openjdk.java.net> Changeset: 4a4b97f7f83b Author: alanb Date: 2013-01-25 13:09 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a4b97f7f83b 8006565: java.lang.instrument specification should make it clear that -javaagent is optional Reviewed-by: sla, dcubed, mchung ! src/share/classes/java/lang/instrument/package.html From vincent.x.ryan at oracle.com Fri Jan 25 05:47:55 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 25 Jan 2013 13:47:55 +0000 Subject: [8] code review for 8006946: PKCS12 test failure due to incorrect alias name Message-ID: <883D1AC2-06FD-4B8C-A84A-47BF2BE27934@oracle.com> Please review this fix to correct a failing PKCS12 test: Webrev: http://cr.openjdk.java.net/~vinnie/8006946/webrev.00/ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130125/1479acbd/attachment.html From sean.mullan at oracle.com Fri Jan 25 07:21:50 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Jan 2013 10:21:50 -0500 Subject: [8] code review for 8006946: PKCS12 test failure due to incorrect alias name In-Reply-To: <883D1AC2-06FD-4B8C-A84A-47BF2BE27934@oracle.com> References: <883D1AC2-06FD-4B8C-A84A-47BF2BE27934@oracle.com> Message-ID: <5102A30E.8060806@oracle.com> Looks fine. Don't forget to add the appropriate noreg label to the bug and add what specific test is failing. --Sean On 01/25/2013 08:47 AM, Vincent Ryan wrote: > Please review this fix to correct a failing PKCS12 test: > > Webrev: http://cr.openjdk.java.net/~vinnie/8006946/webrev.00/ > > Thanks. From vincent.x.ryan at oracle.com Fri Jan 25 07:37:03 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 25 Jan 2013 15:37:03 +0000 Subject: [8] code review for 8006951: Avoid storing duplicate PKCS12 attributes Message-ID: Please review this fix to correct a failing PKCS12 test: Webrev: http://cr.openjdk.java.net/~vinnie/8006951/webrev.00/ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130125/204f6527/attachment.html From vincent.x.ryan at oracle.com Fri Jan 25 08:11:07 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 25 Jan 2013 16:11:07 +0000 Subject: [8] code review for 8006946: PKCS12 test failure due to incorrect alias name In-Reply-To: <5102A30E.8060806@oracle.com> References: <883D1AC2-06FD-4B8C-A84A-47BF2BE27934@oracle.com> <5102A30E.8060806@oracle.com> Message-ID: Thanks. On 25 Jan 2013, at 15:21, Sean Mullan wrote: > Looks fine. Don't forget to add the appropriate noreg label to the bug and add what specific test is failing. > > --Sean > > On 01/25/2013 08:47 AM, Vincent Ryan wrote: >> Please review this fix to correct a failing PKCS12 test: >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8006946/webrev.00/ >> >> Thanks. > From vincent.x.ryan at oracle.com Fri Jan 25 08:20:56 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 25 Jan 2013 16:20:56 +0000 Subject: hg: jdk8/tl/jdk: 8006946: PKCS12 test failure due to incorrect alias name Message-ID: <20130125162133.27CF94755F@hg.openjdk.java.net> Changeset: c6ea84a629db Author: vinnie Date: 2013-01-25 16:19 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c6ea84a629db 8006946: PKCS12 test failure due to incorrect alias name Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From sean.mullan at oracle.com Fri Jan 25 08:41:42 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Jan 2013 11:41:42 -0500 Subject: [8] code review for 8006951: Avoid storing duplicate PKCS12 attributes In-Reply-To: References: Message-ID: <5102B5C6.50905@oracle.com> Can you explain a bit more what use-case is causing this failure? I don't quite understand why you are ignoring the attributes that are already in the KeyStore.Entry. --Sean On 01/25/2013 10:37 AM, Vincent Ryan wrote: > Please review this fix to correct a failing PKCS12 test: > > Webrev: http://cr.openjdk.java.net/~vinnie/8006951/webrev.00/ > > Thanks. From vincent.x.ryan at oracle.com Fri Jan 25 09:05:03 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 25 Jan 2013 17:05:03 +0000 Subject: [8] code review for 8006951: Avoid storing duplicate PKCS12 attributes In-Reply-To: <5102B5C6.50905@oracle.com> References: <5102B5C6.50905@oracle.com> Message-ID: <12C968D3-C0B7-48A9-83F5-7FE1EEE451D9@oracle.com> Sure. Three safeBag attributes require special handling by the PKCS12 keystore: friendlyName, localKeyId and trustedKeyUsage. The friendlyName is used as the keystore entry alias, localKeyId is used to match private keys to their associated certificates, and trustedKeyUsage, to identify trusted certificates. When loading a PKCS12 keystore these 3 attributes are added to the collection of entry attributes. When storing a PKCS12 keystore these 3 attributes should be removed from the collection of entry attributes because they are handled separately. The fix prevents these 3 attributes from being duplicated when storing a PKCS12 keystore. On 25 Jan 2013, at 16:41, Sean Mullan wrote: > Can you explain a bit more what use-case is causing this failure? I don't quite understand why you are ignoring the attributes that are already in the KeyStore.Entry. > > --Sean > > On 01/25/2013 10:37 AM, Vincent Ryan wrote: >> Please review this fix to correct a failing PKCS12 test: >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8006951/webrev.00/ >> >> Thanks. > From sean.mullan at oracle.com Fri Jan 25 09:20:24 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Jan 2013 12:20:24 -0500 Subject: [8] code review for 8006951: Avoid storing duplicate PKCS12 attributes In-Reply-To: <12C968D3-C0B7-48A9-83F5-7FE1EEE451D9@oracle.com> References: <5102B5C6.50905@oracle.com> <12C968D3-C0B7-48A9-83F5-7FE1EEE451D9@oracle.com> Message-ID: <5102BED8.2000500@oracle.com> On 01/25/2013 12:05 PM, Vincent Ryan wrote: > Sure. Three safeBag attributes require special handling by the PKCS12 keystore: friendlyName, > localKeyId and trustedKeyUsage. The friendlyName is used as the keystore entry alias, localKeyId > is used to match private keys to their associated certificates, and trustedKeyUsage, to identify > trusted certificates. > > When loading a PKCS12 keystore these 3 attributes are added to the collection of entry attributes. > When storing a PKCS12 keystore these 3 attributes should be removed from the collection of > entry attributes because they are handled separately. Can the 3 attributes change at all since you have loaded them? > The fix prevents these 3 attributes from being duplicated when storing a PKCS12 keystore. Ok, I am ok with the fix then. I think a better fix when you have more time is to separate the logic of storing an existing entry that already has these 3 attributes from a brand new entry where you want to add these 3 new attributes. --Sean > > > > On 25 Jan 2013, at 16:41, Sean Mullan wrote: > >> Can you explain a bit more what use-case is causing this failure? I don't quite understand why you are ignoring the attributes that are already in the KeyStore.Entry. >> >> --Sean >> >> On 01/25/2013 10:37 AM, Vincent Ryan wrote: >>> Please review this fix to correct a failing PKCS12 test: >>> >>> Webrev: http://cr.openjdk.java.net/~vinnie/8006951/webrev.00/ >>> >>> Thanks. >> > From mstjohns at comcast.net Fri Jan 25 09:42:15 2013 From: mstjohns at comcast.net (Michael StJohns) Date: Fri, 25 Jan 2013 12:42:15 -0500 Subject: [8] code review for 8006946: PKCS12 test failure due to incorrect alias name In-Reply-To: <883D1AC2-06FD-4B8C-A84A-47BF2BE27934@oracle.com> References: <883D1AC2-06FD-4B8C-A84A-47BF2BE27934@oracle.com> Message-ID: <20130125174203.F3CCF6999@mail.openjdk.java.net> At 08:47 AM 1/25/2013, Vincent Ryan wrote: >Please review this fix to correct a failing PKCS12 test: > >Webrev: http://cr.openjdk.java.net/~vinnie/8006946/webrev.00/ > >Thanks. This first is not a comment on the change - but a "why can't java do ...." type of comment.... >+ // skip friendlyName, localKeyId and trustedKeyUsage >+ if (CORE_ATTRIBUTES[0].equals(attributeName) || >+ CORE_ATTRIBUTES[1].equals(attributeName) || >+ CORE_ATTRIBUTES[2].equals(attributeName)) { >+ continue; >+ } > We allow arrays to be implicitly treated as collections only in the for () construct. For the above, it would be really nice if you could just do: if (CORE_ATTRIBUTES.contains(attributeName)) {} For your version, it would be increase supportability if instead of: >+ private static final String[] CORE_ATTRIBUTES = { >+ "1.2.840.113549.1.9.20", >+ "1.2.840.113549.1.9.21", >+ "2.16.840.1.113894.746875.1.1" >+ }; >+ you did private static final String idAtPkcs9FriendlyName = "1.2.840.113549.1.9.20"; etc... and did "idAtPkcs9FriendlyName.equals(attributeName)" I can't see any reason why this is in an array as it's not referenced anywhere else in the code. Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/security-dev/attachments/20130125/c28cb4d0/attachment.html From vincent.x.ryan at oracle.com Fri Jan 25 09:51:33 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 25 Jan 2013 17:51:33 +0000 Subject: hg: jdk8/tl/jdk: 8006951: Avoid storing duplicate PKCS12 attributes Message-ID: <20130125175154.6083347570@hg.openjdk.java.net> Changeset: 117491dd58c2 Author: vinnie Date: 2013-01-25 17:47 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/117491dd58c2 8006951: Avoid storing duplicate PKCS12 attributes Reviewed-by: mullan ! src/share/classes/sun/security/pkcs12/PKCS12KeyStore.java From vincent.x.ryan at oracle.com Fri Jan 25 09:59:38 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 25 Jan 2013 17:59:38 +0000 Subject: [8] code review for 8006951: Avoid storing duplicate PKCS12 attributes In-Reply-To: <5102BED8.2000500@oracle.com> References: <5102B5C6.50905@oracle.com> <12C968D3-C0B7-48A9-83F5-7FE1EEE451D9@oracle.com> <5102BED8.2000500@oracle.com> Message-ID: <5102C80A.4060901@oracle.com> On 25/01/2013 17:20, Sean Mullan wrote: > On 01/25/2013 12:05 PM, Vincent Ryan wrote: >> Sure. Three safeBag attributes require special handling by the PKCS12 >> keystore: friendlyName, >> localKeyId and trustedKeyUsage. The friendlyName is used as the >> keystore entry alias, localKeyId >> is used to match private keys to their associated certificates, and >> trustedKeyUsage, to identify >> trusted certificates. >> >> When loading a PKCS12 keystore these 3 attributes are added to the >> collection of entry attributes. >> When storing a PKCS12 keystore these 3 attributes should be removed >> from the collection of >> entry attributes because they are handled separately. > > Can the 3 attributes change at all since you have loaded them? Good point. I'll have to address that issue later. > >> The fix prevents these 3 attributes from being duplicated when storing >> a PKCS12 keystore. > > Ok, I am ok with the fix then. I think a better fix when you have more > time is to separate the logic of storing an existing entry that already > has these 3 attributes from a brand new entry where you want to add > these 3 new attributes. Right. I wanted to change as little code as possible at this stage in M6. > > --Sean > >> >> >> >> On 25 Jan 2013, at 16:41, Sean Mullan wrote: >> >>> Can you explain a bit more what use-case is causing this failure? I >>> don't quite understand why you are ignoring the attributes that are >>> already in the KeyStore.Entry. >>> >>> --Sean >>> >>> On 01/25/2013 10:37 AM, Vincent Ryan wrote: >>>> Please review this fix to correct a failing PKCS12 test: >>>> >>>> Webrev: http://cr.openjdk.java.net/~vinnie/8006951/webrev.00/ >>>> >>>> Thanks. >>> >> > From vincent.x.ryan at oracle.com Fri Jan 25 10:10:10 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Fri, 25 Jan 2013 18:10:10 +0000 Subject: [8] code review for 8006946: PKCS12 test failure due to incorrect alias name In-Reply-To: <201301251742.r0PHg5Lq016346@userp1020.oracle.com> References: <883D1AC2-06FD-4B8C-A84A-47BF2BE27934@oracle.com> <201301251742.r0PHg5Lq016346@userp1020.oracle.com> Message-ID: <5102CA82.2010701@oracle.com> Thanks Mike. A 'contains' feature on arrays would certainly be useful since arrays are quite convenient to statically initialize. Yes I could have defined separate OID strings. They are already defined in integer array form. I will have to re-visit this code following M6. On 25/01/2013 17:42, Michael StJohns wrote: > At 08:47 AM 1/25/2013, Vincent Ryan wrote: >> Please review this fix to correct a failing PKCS12 test: >> >> Webrev: http://cr.openjdk.java.net/~vinnie/8006946/webrev.00/ >> >> Thanks. > > This first is not a comment on the change - but a "why can't java do > ...." type of comment.... > > >> + >> // skip friendlyName, localKeyId and trustedKeyUsage >> + >> if (CORE_ATTRIBUTES[0].equals(attributeName) || >> + >> CORE_ATTRIBUTES[1].equals(attributeName) || >> + >> CORE_ATTRIBUTES[2].equals(attributeName)) { >> + >> continue; >> + >> } >> > > > We allow arrays to be implicitly treated as collections only in the for > () construct. For the above, it would be really nice if you could just do: > > if (CORE_ATTRIBUTES.contains(attributeName)) {} > > > For your version, it would be increase supportability if instead of: > > >> + private static final String[] CORE_ATTRIBUTES = >> { >> + >> "1.2.840.113549.1.9.20", >> + >> "1.2.840.113549.1.9.21", >> + >> "2.16.840.1.113894.746875.1.1" >> + }; >> + > > > you did > > private static final String idAtPkcs9FriendlyName = "1.2.840.113549.1.9.20"; > > etc... and did "idAtPkcs9FriendlyName.equals(attributeName)" > > I can't see any reason why this is in an array as it's not referenced > anywhere else in the code. > > Mike > > From kurchi.subhra.hazra at oracle.com Fri Jan 25 11:44:38 2013 From: kurchi.subhra.hazra at oracle.com (kurchi.subhra.hazra at oracle.com) Date: Fri, 25 Jan 2013 19:44:38 +0000 Subject: hg: jdk8/tl/jdk: 7017962: Obsolete link is used in URL class level spec Message-ID: <20130125194502.E68CD47578@hg.openjdk.java.net> Changeset: 77bde15bc6a9 Author: khazra Date: 2013-01-25 11:52 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77bde15bc6a9 7017962: Obsolete link is used in URL class level spec Summary: Change the link to an archived document Reviewed-by: chegar, mduigou ! src/share/classes/java/net/URL.java From mike.duigou at oracle.com Fri Jan 25 20:33:53 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Sat, 26 Jan 2013 04:33:53 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130126043437.BAFC04758E@hg.openjdk.java.net> Changeset: 4209b3936a7f Author: mduigou Date: 2013-01-25 16:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4209b3936a7f 8005632: Extend java.util.Logger to use Supplier for messages Reviewed-by: briangoetz, mduigou Contributed-by: henry.jen at oracle.com ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/LoggerSupplierAPIsTest.java Changeset: 1d918647332e Author: mduigou Date: 2013-01-25 16:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d918647332e 8004201: Add static utility methods to primitives to be used for redution operations. Reviewed-by: darcy, mduigou, briangoetz, dholmes Contributed-by: akhil.arora at oracle.com ! src/share/classes/java/lang/Boolean.java ! src/share/classes/java/lang/Double.java ! src/share/classes/java/lang/Float.java ! src/share/classes/java/lang/Integer.java ! src/share/classes/java/lang/Long.java + test/java/lang/PrimitiveSumMinMaxTest.java Changeset: 86a5b435c928 Author: jgish Date: 2013-01-22 11:14 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/86a5b435c928 4247235: (spec str) StringBuffer.insert(int, char[]) specification is inconsistent Summary: Add blanket null-handling statement to StringBuilder and StringBuffer Reviewed-by: mduigou ! src/share/classes/java/lang/AbstractStringBuilder.java ! src/share/classes/java/lang/String.java ! src/share/classes/java/lang/StringBuffer.java ! src/share/classes/java/lang/StringBuilder.java From alan.bateman at oracle.com Sat Jan 26 09:00:28 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 26 Jan 2013 17:00:28 +0000 Subject: hg: jdk8/tl/jdk: 8006503: JVM_PrintStackTrace is not used in JDK Message-ID: <20130126170117.3D2F647594@hg.openjdk.java.net> Changeset: e96577d82cbb Author: alanb Date: 2013-01-26 16:57 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e96577d82cbb 8006503: JVM_PrintStackTrace is not used in JDK Reviewed-by: alanb, darcy Contributed-by: eric.mccorkle at oracle.com ! src/share/javavm/export/jvm.h From vicente.romero at oracle.com Mon Jan 28 00:55:35 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 28 Jan 2013 08:55:35 +0000 Subject: hg: jdk8/tl/langtools: 8006944: javac, combo tests should print out the number of threads used Message-ID: <20130128085542.628DD475B4@hg.openjdk.java.net> Changeset: cbcd9b484759 Author: vromero Date: 2013-01-27 19:38 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cbcd9b484759 8006944: javac, combo tests should print out the number of threads used Reviewed-by: mcimadamore ! test/tools/javac/lib/JavacTestingAbstractThreadedTest.java From weijun.wang at oracle.com Mon Jan 28 01:03:17 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 28 Jan 2013 17:03:17 +0800 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <50FD4FE2.5090805@oracle.com> References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> <50FD4EE8.4090107@oracle.com> <50FD4FE2.5090805@oracle.com> Message-ID: <51063ED5.7050904@oracle.com> Your opinion? I still like to keep my changes. http://cr.openjdk.java.net/~weijun/8006564/webrev.00/ -Max On 01/21/2013 10:25 PM, Weijun Wang wrote: > Oh, did I mention jdk8 and jdk7 are using the same format? > > In fact, I don't think it's "too tied to impl", you can see that my fake > jdk6-style class is quite clean itself so it's just a reimpl of the jdk6 > serialization interface. I was more concerned about using the > -Xbootclasspath option, which many people (including you) had said will > be unusable after module. > > -Max > > On 01/21/2013 10:21 PM, Alan Bateman wrote: >> On 21/01/2013 14:19, Wang Weijun wrote: >>> I've thought about that, but it means there is no way to check forward-compatibility. (Am I using the correct word? Deserialize jdk7 format with jdk6). >>> >>> Max >> Right, but this is a test in the jdk8 forest and so it should only be >> testing jdk8. >> >> -Alan >> From Alan.Bateman at oracle.com Tue Jan 29 01:59:31 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Jan 2013 09:59:31 +0000 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <51063ED5.7050904@oracle.com> References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> <50FD4EE8.4090107@oracle.com> <50FD4FE2.5090805@oracle.com> <51063ED5.7050904@oracle.com> Message-ID: <51079D83.7040904@oracle.com> On 28/01/2013 09:03, Weijun Wang wrote: > Your opinion? I still like to keep my changes. > > http://cr.openjdk.java.net/~weijun/8006564/webrev.00/ > > -Max > I don't like it because it hacks the JDK under test with -Xbootclasspath/p. -Alan. From weijun.wang at oracle.com Tue Jan 29 02:21:48 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 29 Jan 2013 18:21:48 +0800 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <51079D83.7040904@oracle.com> References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> <50FD4EE8.4090107@oracle.com> <50FD4FE2.5090805@oracle.com> <51063ED5.7050904@oracle.com> <51079D83.7040904@oracle.com> Message-ID: <5107A2BC.30400@oracle.com> I cannot think of a better way to simulate jdk6 behavior without calling jdk6. Without this hack, the forward compatibility check part cannot be tested. Maybe I can add this part to the jdk6 repo? Thanks Max On 01/29/2013 05:59 PM, Alan Bateman wrote: > On 28/01/2013 09:03, Weijun Wang wrote: >> Your opinion? I still like to keep my changes. >> >> http://cr.openjdk.java.net/~weijun/8006564/webrev.00/ >> >> -Max >> > I don't like it because it hacks the JDK under test with -Xbootclasspath/p. > > -Alan. > From Alan.Bateman at oracle.com Tue Jan 29 02:27:53 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 29 Jan 2013 10:27:53 +0000 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <5107A2BC.30400@oracle.com> References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> <50FD4EE8.4090107@oracle.com> <50FD4FE2.5090805@oracle.com> <51063ED5.7050904@oracle.com> <51079D83.7040904@oracle.com> <5107A2BC.30400@oracle.com> Message-ID: <5107A429.3070004@oracle.com> On 29/01/2013 10:21, Weijun Wang wrote: > I cannot think of a better way to simulate jdk6 behavior without calling > jdk6. > > Without this hack, the forward compatibility check part cannot be > tested. Maybe I can add this part to the jdk6 repo? > I think the type of interop that you attempting to test here is more appropriate for other test suites. For the jdk repo, then I think it should be fine to check in the bytes streams (in source rather than binary format) and just check that they can be de-serialized in jdk8 (you can go the other way too by testing the serialized stream that jdk8 generated). -Alan. From joel.franck at oracle.com Tue Jan 29 01:38:02 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Tue, 29 Jan 2013 09:38:02 +0000 Subject: hg: jdk8/tl/jdk: 8004698: Implement Core Reflection for Type Annotations Message-ID: <20130129093814.3EF4A4763E@hg.openjdk.java.net> Changeset: a343d280bd8c Author: jfranck Date: 2013-01-29 10:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a343d280bd8c 8004698: Implement Core Reflection for Type Annotations Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java + src/share/classes/java/lang/reflect/AnnotatedArrayType.java + src/share/classes/java/lang/reflect/AnnotatedParameterizedType.java + src/share/classes/java/lang/reflect/AnnotatedType.java + src/share/classes/java/lang/reflect/AnnotatedTypeVariable.java + src/share/classes/java/lang/reflect/AnnotatedWildcardType.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/java/lang/reflect/ReflectAccess.java ! src/share/classes/java/lang/reflect/TypeVariable.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/LangReflectAccess.java ! src/share/classes/sun/reflect/ReflectionFactory.java + src/share/classes/sun/reflect/annotation/AnnotatedTypeFactory.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java + src/share/classes/sun/reflect/annotation/TypeAnnotation.java + src/share/classes/sun/reflect/annotation/TypeAnnotationParser.java ! src/share/classes/sun/reflect/generics/reflectiveObjects/TypeVariableImpl.java ! src/share/javavm/export/jvm.h ! src/share/native/java/lang/Class.c + test/java/lang/annotation/TypeAnnotationReflection.java + test/java/lang/annotation/TypeParamAnnotation.java From jonathan.gibbons at oracle.com Wed Jan 30 09:41:27 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 30 Jan 2013 17:41:27 +0000 Subject: hg: jdk8/tl/langtools: 8007096: DocLint parsing problems with some comments Message-ID: <20130130174132.C765D476AD@hg.openjdk.java.net> Changeset: 950d8195a5a4 Author: jjg Date: 2013-01-30 09:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/950d8195a5a4 8007096: DocLint parsing problems with some comments Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/DocCommentParser.java ! src/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java + test/tools/doclint/EndWithIdentifierTest.java + test/tools/doclint/EndWithIdentifierTest.out + test/tools/doclint/UnfinishedInlineTagTest.java + test/tools/doclint/UnfinishedInlineTagTest.out From jonathan.gibbons at oracle.com Wed Jan 30 09:47:45 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 30 Jan 2013 17:47:45 +0000 Subject: hg: jdk8/tl/langtools: 8007034: debug printer for javac internals Message-ID: <20130130174748.46FE4476AE@hg.openjdk.java.net> Changeset: c924291865e5 Author: jjg Date: 2013-01-30 09:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c924291865e5 8007034: debug printer for javac internals Reviewed-by: mcimadamore + test/tools/javac/lib/DPrinter.java From jason.uh at oracle.com Wed Jan 30 18:58:00 2013 From: jason.uh at oracle.com (Jason Uh) Date: Wed, 30 Jan 2013 18:58:00 -0800 Subject: Request for review: 8002313: jdk/test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java should run in headless mode Message-ID: <5109DDB8.5080908@oracle.com> This change for jdk7u has the test test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java run in headless mode, without which the test can hang on Mac OS X. webrev: http://cr.openjdk.java.net/~juh/8002313/webrev.00/ bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002313 Thanks, Jason From weijun.wang at oracle.com Thu Jan 31 01:27:25 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 31 Jan 2013 17:27:25 +0800 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <5107A429.3070004@oracle.com> References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> <50FD4EE8.4090107@oracle.com> <50FD4FE2.5090805@oracle.com> <51063ED5.7050904@oracle.com> <51079D83.7040904@oracle.com> <5107A2BC.30400@oracle.com> <5107A429.3070004@oracle.com> Message-ID: <510A38FD.3050708@oracle.com> Here is another version of the webrev: http://cr.openjdk.java.net/~weijun/8006564/webrev.01/ This test can do 3 things: 1. Generate the byte streams in code format. 2. Run in jdk7 3. Run in jdk6 In fact, the output of 1 is included inside the test. Thanks Max On 01/29/2013 06:27 PM, Alan Bateman wrote: > On 29/01/2013 10:21, Weijun Wang wrote: >> I cannot think of a better way to simulate jdk6 behavior without calling >> jdk6. >> >> Without this hack, the forward compatibility check part cannot be >> tested. Maybe I can add this part to the jdk6 repo? >> > I think the type of interop that you attempting to test here is more > appropriate for other test suites. > > For the jdk repo, then I think it should be fine to check in the bytes > streams (in source rather than binary format) and just check that they > can be de-serialized in jdk8 (you can go the other way too by testing > the serialized stream that jdk8 generated). > > -Alan. > From weijun.wang at oracle.com Thu Jan 31 01:33:41 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Thu, 31 Jan 2013 17:33:41 +0800 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <510A38FD.3050708@oracle.com> References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> <50FD4EE8.4090107@oracle.com> <50FD4FE2.5090805@oracle.com> <51063ED5.7050904@oracle.com> <51079D83.7040904@oracle.com> <5107A2BC.30400@oracle.com> <5107A429.3070004@oracle.com> <510A38FD.3050708@oracle.com> Message-ID: <510A3A75.9080808@oracle.com> Oh, I should also remove the SerialTest.java file, it's useless now. -Max On 01/31/2013 05:27 PM, Weijun Wang wrote: > Here is another version of the webrev: > > http://cr.openjdk.java.net/~weijun/8006564/webrev.01/ > > This test can do 3 things: > > 1. Generate the byte streams in code format. > 2. Run in jdk7 > 3. Run in jdk6 > > In fact, the output of 1 is included inside the test. > > Thanks > Max > > On 01/29/2013 06:27 PM, Alan Bateman wrote: >> On 29/01/2013 10:21, Weijun Wang wrote: >>> I cannot think of a better way to simulate jdk6 behavior without calling >>> jdk6. >>> >>> Without this hack, the forward compatibility check part cannot be >>> tested. Maybe I can add this part to the jdk6 repo? >>> >> I think the type of interop that you attempting to test here is more >> appropriate for other test suites. >> >> For the jdk repo, then I think it should be fine to check in the bytes >> streams (in source rather than binary format) and just check that they >> can be de-serialized in jdk8 (you can go the other way too by testing >> the serialized stream that jdk8 generated). >> >> -Alan. >> From sean.mullan at oracle.com Thu Jan 31 10:41:48 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 31 Jan 2013 13:41:48 -0500 Subject: Request for review: 8002313: jdk/test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java should run in headless mode In-Reply-To: <5109DDB8.5080908@oracle.com> References: <5109DDB8.5080908@oracle.com> Message-ID: <510ABAEC.1090404@oracle.com> Looks good to me. --Sean On 01/30/2013 09:58 PM, Jason Uh wrote: > This change for jdk7u has the test > test/java/security/Security/ClassLoaderDeadlock/ClassLoaderDeadlock.java > run in headless mode, without which the test can hang on Mac OS X. > > webrev: http://cr.openjdk.java.net/~juh/8002313/webrev.00/ > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8002313 > > Thanks, > Jason From joel.franck at oracle.com Thu Jan 31 01:12:40 2013 From: joel.franck at oracle.com (joel.franck at oracle.com) Date: Thu, 31 Jan 2013 09:12:40 +0000 Subject: hg: jdk8/tl/jdk: 8005712: Simplify support for repeating annotations in j.l.r.AnnotatedElement; ... Message-ID: <20130131091301.331DF476D9@hg.openjdk.java.net> Changeset: 5097fe015763 Author: jfranck Date: 2013-01-31 10:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5097fe015763 8005712: Simplify support for repeating annotations in j.l.r.AnnotatedElement 8004919: AnnotationSupport uses possibly half-constructed AnnotationType instances Summary: Implements the simplified semantics for repeating annotations and removes the incorrect obtaining of an AnnotationType Reviewed-by: darcy, abuckley ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/System.java ! src/share/classes/java/lang/reflect/AnnotatedElement.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Parameter.java ! src/share/classes/sun/misc/JavaLangAccess.java ! src/share/classes/sun/reflect/annotation/AnnotationSupport.java ! test/java/lang/annotation/repeatingAnnotations/RepeatedUnitTest.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Containee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/Container.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainee.java ! test/java/lang/annotation/repeatingAnnotations/subpackage/InheritedContainer.java From david.buck at oracle.com Thu Jan 31 10:56:21 2013 From: david.buck at oracle.com (david.buck at oracle.com) Date: Thu, 31 Jan 2013 18:56:21 +0000 Subject: hg: jdk8/tl/jdk: 7042126: (alt-rt) HashMap.clone implementation should be re-examined Message-ID: <20130131185643.CC531476F4@hg.openjdk.java.net> Changeset: 3f766f58c48a Author: dbuck Date: 2013-01-31 10:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f766f58c48a 7042126: (alt-rt) HashMap.clone implementation should be re-examined Summary: Test case for cr7042126. Issue only found in OracleJDK, but test case is valid for OpenJDK as well Reviewed-by: mduigou + test/java/util/HashMap/HashMapCloneLeak.java From xueming.shen at oracle.com Thu Jan 31 11:10:30 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 31 Jan 2013 19:10:30 +0000 Subject: hg: jdk8/tl/jdk: 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed Message-ID: <20130131191041.A2BBB476F5@hg.openjdk.java.net> Changeset: 857d99bef21d Author: sherman Date: 2013-01-31 11:09 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/857d99bef21d 8005394: Base64.Decoder/Encoder.wrap(XStream) don't throw NPE for null args passed Summary: to check null for dec/enc.wrap methods Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From Alan.Bateman at oracle.com Thu Jan 31 11:31:51 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 31 Jan 2013 19:31:51 +0000 Subject: Code review request: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit In-Reply-To: <510A38FD.3050708@oracle.com> References: <50FC9F3E.60109@oracle.com> <50FD497C.3050609@oracle.com> <50FD4EE8.4090107@oracle.com> <50FD4FE2.5090805@oracle.com> <51063ED5.7050904@oracle.com> <51079D83.7040904@oracle.com> <5107A2BC.30400@oracle.com> <5107A429.3070004@oracle.com> <510A38FD.3050708@oracle.com> Message-ID: <510AC6A7.8000807@oracle.com> On 31/01/2013 09:27, Weijun Wang wrote: > Here is another version of the webrev: > > http://cr.openjdk.java.net/~weijun/8006564/webrev.01/ > > This test can do 3 things: > > 1. Generate the byte streams in code format. > 2. Run in jdk7 > 3. Run in jdk6 > > In fact, the output of 1 is included inside the test. > This looks much better. Pity it uses sun.misc.Base64Encoder but it has to run on older JDKs in order to generate the dumps so that is understandable. -Alan From joe.darcy at oracle.com Thu Jan 31 12:13:45 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Jan 2013 20:13:45 +0000 Subject: hg: jdk8/tl/jdk: 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types Message-ID: <20130131201358.B16CD476F8@hg.openjdk.java.net> Changeset: 278397f752da Author: darcy Date: 2013-01-31 12:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/278397f752da 8005832: Remove java.lang.annotation.{ContainedBy, ContainerFor} annotation types Reviewed-by: mduigou - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java ! src/share/classes/java/lang/annotation/InvalidContainerAnnotationError.java From joe.darcy at oracle.com Thu Jan 31 12:16:13 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Jan 2013 20:16:13 +0000 Subject: hg: jdk8/tl/langtools: 8007313: Remove use of {ContainerFor/ContainedBy} from langtools Message-ID: <20130131201615.A7A28476F9@hg.openjdk.java.net> Changeset: 8e4c22acebeb Author: darcy Date: 2013-01-31 12:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8e4c22acebeb 8007313: Remove use of {ContainerFor/ContainedBy} from langtools Reviewed-by: jjg ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/newlocations/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java From joe.darcy at oracle.com Thu Jan 31 12:23:22 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 31 Jan 2013 20:23:22 +0000 Subject: hg: jdk8/tl/jdk: 8007115: Refactor regression tests for java.lang.reflect.Parameter Message-ID: <20130131202335.7F191476FA@hg.openjdk.java.net> Changeset: a5f38e811ab0 Author: darcy Date: 2013-01-31 12:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a5f38e811ab0 8007115: Refactor regression tests for java.lang.reflect.Parameter Reviewed-by: emc ! test/java/lang/reflect/Parameter/WithoutParameters.java From xueming.shen at oracle.com Thu Jan 31 13:13:37 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 31 Jan 2013 21:13:37 +0000 Subject: hg: jdk8/tl/jdk: 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character; ... Message-ID: <20130131211351.72285476FF@hg.openjdk.java.net> Changeset: e5ce312a5b10 Author: sherman Date: 2013-01-31 13:13 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e5ce312a5b10 8007298: Base64.getMimeDecoder().decode() throws IAE for a single non-base64 character 8006526: Base64.Decoder.decode(String) spec contains a copy-paste mistake Summary: to ignore single non-base64 char in mime decoding Reviewed-by: alanb ! src/share/classes/java/util/Base64.java ! test/java/util/Base64/TestBase64.java From mike.duigou at oracle.com Thu Jan 31 13:27:56 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 31 Jan 2013 21:27:56 +0000 Subject: hg: jdk8/tl/jdk: 8006709: Add minimal support of MacOSX platform for NetBeans Projects Message-ID: <20130131212807.8091B47701@hg.openjdk.java.net> Changeset: cff8d7768d72 Author: mduigou Date: 2013-01-31 13:27 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cff8d7768d72 8006709: Add minimal support of MacOSX platform for NetBeans Projects Summary: Adds support for MacOSX platform and architecture detection. Other minor updates (-source/target 1.8) Reviewed-by: ohair + make/netbeans/common/architectures/arch-x86_64.properties + make/netbeans/common/architectures/name-Macosx.properties ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent ! make/netbeans/common/make.xml ! make/netbeans/common/shared.xml From lana.steuck at oracle.com Thu Jan 31 14:19:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:01 +0000 Subject: hg: jdk8/tl: 19 new changesets Message-ID: <20130131221903.1B5C147703@hg.openjdk.java.net> Changeset: 50307da0149e Author: jqzuo Date: 2012-12-31 14:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/50307da0149e 8005583: Install build(gnumake all) failed preventing RE from doing JDK8 combo builds Reviewed-by: paulk, billyh ! make/install-rules.gmk Changeset: e5664599a127 Author: cgruszka Date: 2013-01-02 14:54 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e5664599a127 Merge Changeset: 75634cbeab47 Author: cgruszka Date: 2013-01-04 13:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/75634cbeab47 Merge Changeset: 61d7e2971723 Author: cgruszka Date: 2013-01-14 14:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/61d7e2971723 Merge Changeset: f9163f9cb1da Author: cgruszka Date: 2013-01-23 08:50 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f9163f9cb1da Merge Changeset: 5a5e97f9ac0a Author: erikj Date: 2013-01-18 09:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5a5e97f9ac0a 8006520: build-infra: Fix sparkle-framework configure parameter Reviewed-by: tbell, ohair ! common/autoconf/generated-configure.sh ! common/makefiles/Jprt.gmk Changeset: edad83acbd46 Author: erikj Date: 2013-01-18 16:48 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/edad83acbd46 8003693: build-infra: bridgeBuild should allow for partial build (no hotspot) Reviewed-by: tbell ! common/makefiles/Jprt.gmk Changeset: c3bf62746a80 Author: tbell Date: 2013-01-23 13:30 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c3bf62746a80 8006797: build-infra JPRT builds need JPRT_ARCHIVE_INSTALL_BUNDLE in common/makefiles/Jprt.gmk Reviewed-by: ohair ! common/makefiles/Jprt.gmk Changeset: b43aa5bd8ca5 Author: katleman Date: 2013-01-23 15:40 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b43aa5bd8ca5 Merge Changeset: cd2fa0d0ed3d Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/cd2fa0d0ed3d Added tag jdk8-b74 for changeset b43aa5bd8ca5 ! .hgtags Changeset: 039783b67959 Author: lana Date: 2013-01-26 18:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/039783b67959 Merge Changeset: e28985c549aa Author: raginip Date: 2013-01-18 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e28985c549aa 8000839: Integrate the Java Access Bridge with Java Runtime Reviewed-by: ptbrunet, erikj ! common/bin/compare_exceptions.sh.incl Changeset: db46b1c27a93 Author: erikj Date: 2013-01-28 14:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/db46b1c27a93 Merge - common/autoconf/closed.version.numbers ! common/autoconf/generated-configure.sh - common/autoconf/version.numbers ! common/bin/compare_exceptions.sh.incl Changeset: 8baaaba2ee6b Author: lana Date: 2013-01-29 20:16 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/8baaaba2ee6b Merge Changeset: 0d4b0a13adb2 Author: erikj Date: 2013-01-23 11:37 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0d4b0a13adb2 8005855: build-infra: Remove -R flag when cross compiling Reviewed-by: dholmes, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/libraries.m4 Changeset: ea6379d4624f Author: erikj Date: 2013-01-23 11:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ea6379d4624f 8006663: build-infra: Compare two arbitrary zip/jar files with compare.sh Reviewed-by: tbell ! common/bin/compare.sh Changeset: 0d46733cfffb Author: erikj Date: 2013-01-23 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/0d46733cfffb 8006658: build-infra: Make MILESTONE behave the same as JDK_BUILD_NUMBER Reviewed-by: ohrstrom, dholmes, tbell ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 9e5847257731 Author: erikj Date: 2013-01-24 09:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/9e5847257731 Merge Changeset: 2a713921952c Author: katleman Date: 2013-01-30 13:39 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/rev/2a713921952c Merge ! common/autoconf/generated-configure.sh From lana.steuck at oracle.com Thu Jan 31 14:19:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:01 +0000 Subject: hg: jdk8/tl/corba: Added tag jdk8-b74 for changeset 2132845cf5f7 Message-ID: <20130131221903.DEC9E47704@hg.openjdk.java.net> Changeset: d4e68ce17795 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d4e68ce17795 Added tag jdk8-b74 for changeset 2132845cf5f7 ! .hgtags From lana.steuck at oracle.com Thu Jan 31 14:19:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:01 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b74 for changeset 12db3c5a3393 Message-ID: <20130131221908.1192047705@hg.openjdk.java.net> Changeset: 966bf9f3c41a Author: katleman Date: 2013-01-24 16:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/966bf9f3c41a Added tag jdk8-b74 for changeset 12db3c5a3393 ! .hgtags From lana.steuck at oracle.com Thu Jan 31 14:19:03 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:03 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130131221912.452ED47706@hg.openjdk.java.net> Changeset: 69bc57b1ebdd Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/69bc57b1ebdd Added tag jdk8-b74 for changeset 2087e24a4357 ! .hgtags Changeset: ff0b73a6b3f6 Author: lana Date: 2013-01-26 18:25 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/ff0b73a6b3f6 Merge From lana.steuck at oracle.com Thu Jan 31 14:19:23 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:23 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130131221935.EA3DD47707@hg.openjdk.java.net> Changeset: 54e4ba223319 Author: katleman Date: 2013-01-24 16:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/54e4ba223319 Added tag jdk8-b74 for changeset 56c97aff46bb ! .hgtags Changeset: c2e11e2ec4a3 Author: lana Date: 2013-01-26 19:24 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c2e11e2ec4a3 Merge - test/tools/javac/annotations/repeatingAnnotations/MissingContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/MissingContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/UseWrongContainerFor.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainedBy.java - test/tools/javac/annotations/repeatingAnnotations/WrongContainerFor.java - test/tools/javac/diags/examples/ContainedByDocumentedMismatch.java - test/tools/javac/diags/examples/ContainedByInheritedMismatch.java - test/tools/javac/diags/examples/ContainedByNoValue.java - test/tools/javac/diags/examples/ContainedByNonDefault.java - test/tools/javac/diags/examples/ContainedByRetentionMismatch.java - test/tools/javac/diags/examples/ContainedByTargetMismatch.java - test/tools/javac/diags/examples/ContainedByWrongValueType.java - test/tools/javac/diags/examples/InferredDoNotConformToLower.java - test/tools/javac/diags/examples/NoUniqueMaximalInstance.java - test/tools/javac/diags/examples/WrongContainedBy.java - test/tools/javac/diags/examples/WrongContainerFor.java - test/tools/javac/lambda/MethodReference26.out - test/tools/javac/lambda/TargetType06.out - test/tools/javac/lambda/TargetType11.out - test/tools/javac/lambda/TargetType45.out - test/tools/javac/lambda/VoidCompatibility.out - test/tools/javac/typeAnnotations/newlocations/BasicTest.java - test/tools/javac/typeAnnotations/newlocations/BasicTest.out Changeset: b7cb3d7ade25 Author: lana Date: 2013-01-31 10:23 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b7cb3d7ade25 Merge Changeset: 7b269e916e06 Author: lana Date: 2013-01-31 14:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7b269e916e06 Merge From lana.steuck at oracle.com Thu Jan 31 14:19:39 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:19:39 +0000 Subject: hg: jdk8/tl/hotspot: 65 new changesets Message-ID: <20130131222145.0B04947708@hg.openjdk.java.net> Changeset: 89fc17e8d808 Author: katleman Date: 2013-01-24 16:48 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/89fc17e8d808 Added tag jdk8-b74 for changeset 1a3e54283c54 ! .hgtags Changeset: d58b7b43031b Author: amurillo Date: 2013-01-11 02:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d58b7b43031b 8006034: new hotspot build - hs25-b16 Reviewed-by: jcoomes ! make/hotspot_version Changeset: adc176e95bf2 Author: acorn Date: 2013-01-09 11:39 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/adc176e95bf2 8005689: InterfaceAccessFlagsTest failures in Lambda-JDK tests Summary: Fix verifier for new interface access flags Reviewed-by: acorn, kvn Contributed-by: bharadwaj.yadavalli at oracle.com ! src/share/vm/classfile/classFileParser.cpp Changeset: dd7248d3e151 Author: zgu Date: 2013-01-09 14:46 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dd7248d3e151 7152671: RFE: Windows decoder should add some std dirs to the symbol search path Summary: Added JRE/JDK bin directories to decoder's symbol search path Reviewed-by: dcubed, sla ! src/os/windows/vm/decoder_windows.cpp ! src/os/windows/vm/decoder_windows.hpp Changeset: 97ee8abd6ab2 Author: zgu Date: 2013-01-09 12:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/97ee8abd6ab2 Merge Changeset: aefb345d3f5e Author: acorn Date: 2013-01-10 17:38 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/aefb345d3f5e 7199207: NPG: Crash in PlaceholderTable::verify after StackOverflow Summary: Reduce scope of placeholder table entries to improve cleanup Reviewed-by: dholmes, coleenp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/utilities/exceptions.hpp Changeset: 91bf7da5c609 Author: mikael Date: 2013-01-10 17:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/91bf7da5c609 8004747: Remove last_entry from VM_STRUCT macros Summary: Instead of passing in last_entry to all the VM_ macros just expand it in the main vmStructs.cpp file. Reviewed-by: dholmes, sspitsyn, minqi ! src/cpu/sparc/vm/vmStructs_sparc.hpp ! src/cpu/x86/vm/vmStructs_x86.hpp ! src/cpu/zero/vm/vmStructs_zero.hpp ! src/os_cpu/bsd_x86/vm/vmStructs_bsd_x86.hpp ! src/os_cpu/bsd_zero/vm/vmStructs_bsd_zero.hpp ! src/os_cpu/linux_sparc/vm/vmStructs_linux_sparc.hpp ! src/os_cpu/linux_x86/vm/vmStructs_linux_x86.hpp ! src/os_cpu/linux_zero/vm/vmStructs_linux_zero.hpp ! src/os_cpu/solaris_sparc/vm/vmStructs_solaris_sparc.hpp ! src/os_cpu/solaris_x86/vm/vmStructs_solaris_x86.hpp ! src/os_cpu/windows_x86/vm/vmStructs_windows_x86.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: c1c8479222cd Author: dholmes Date: 2013-01-10 21:00 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c1c8479222cd 8005921: Memory leaks in vmStructs.cpp Reviewed-by: dholmes, mikael, rasbold Contributed-by: Jeremy Manson ! src/share/vm/runtime/vmStructs.cpp Changeset: e0cf9af8978e Author: zgu Date: 2013-01-11 12:30 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0cf9af8978e 8005936: PrintNMTStatistics doesn't work for normal JVM exit Summary: Moved NMT shutdown code to JVM exit handler to ensure NMT statistics is printed when PrintNMTStatistics is enabled Reviewed-by: acorn, dholmes, coleenp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/thread.cpp Changeset: 90a92d5bca17 Author: zgu Date: 2013-01-11 09:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/90a92d5bca17 Merge Changeset: 4a916f2ce331 Author: jwilhelm Date: 2013-01-14 15:17 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4a916f2ce331 8003985: Support @Contended Annotation - JEP 142 Summary: HotSpot changes to support @Contended annotation. Reviewed-by: coleenp, kvn, jrose Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/cpu/sparc/vm/vm_version_sparc.cpp ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/fieldInfo.hpp ! src/share/vm/oops/fieldStreams.hpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vmStructs.cpp Changeset: f9eb431c3efe Author: coleenp Date: 2013-01-14 11:01 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9eb431c3efe 8006005: Fix constant pool index validation and alignment trap for method parameter reflection Summary: This patch addresses an alignment trap due to the storage format of method parameters data in constMethod. It also adds code to validate constant pool indexes for method parameters data. Reviewed-by: jrose, dholmes Contributed-by: eric.mccorkle at oracle.com ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/constMethod.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/reflection.cpp Changeset: 5b6a231e5a86 Author: coleenp Date: 2013-01-14 08:37 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b6a231e5a86 Merge ! src/share/vm/classfile/classFileParser.cpp Changeset: fe1472c87a27 Author: mikael Date: 2013-01-14 11:00 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fe1472c87a27 8005592: ClassLoaderDataGraph::_unloading incorrectly defined as nonstatic in vmStructs Summary: Added assertion to catch problem earlier and removed the unused field Reviewed-by: dholmes, acorn ! src/share/vm/runtime/vmStructs.cpp Changeset: c793367610c1 Author: coleenp Date: 2013-01-15 17:05 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c793367610c1 8005467: CDS size information is incorrect and unfriendly Summary: Changed words to bytes, and added usage percentage information Reviewed-by: coleenp, twisti Contributed-by: ioi.lam at oracle.com ! src/share/vm/memory/metaspaceShared.cpp Changeset: 92d4b5d8dde4 Author: acorn Date: 2013-01-16 18:23 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/92d4b5d8dde4 Merge ! src/cpu/x86/vm/vm_version_x86.cpp ! src/share/vm/runtime/globals.hpp Changeset: 337e1dd9d902 Author: jiangli Date: 2013-01-11 16:55 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/337e1dd9d902 8005895: Inefficient InstanceKlass field packing wasts memory. Summary: Pack _misc_has_default_methods into the _misc_flags, move _idnum_allocated_count. Reviewed-by: coleenp, shade ! src/share/vm/oops/instanceKlass.hpp Changeset: 94fa3c4e7643 Author: vladidan Date: 2013-01-14 13:44 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/94fa3c4e7643 8005639: Move InlineSynchronizedMethods flag from develop to product Summary: Move InlineSynchronizedMethods flag from develop to product Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/c1/c1_globals.hpp Changeset: 9deda4d8e126 Author: vladidan Date: 2013-01-14 13:52 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9deda4d8e126 8005204: Code Cache Reduction: command line options implementation Summary: Adding more detailed output on CodeCache usage Reviewed-by: kvn, vladidan Contributed-by: Alexander Harlap ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 212c5b9c38e7 Author: dlong Date: 2013-01-17 01:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/212c5b9c38e7 Merge ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/java.cpp Changeset: a3f92e6c0274 Author: twisti Date: 2013-01-11 14:07 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a3f92e6c0274 8006031: LibraryCallKit::inline_array_copyOf disabled unintentionally with 7172640 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: f9bda35f4226 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9bda35f4226 8005816: Shark: fix volatile float field access Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkBlock.cpp Changeset: c566b81b3323 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c566b81b3323 8005817: Shark: implement deoptimization support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/cpu/zero/vm/frame_zero.cpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/sharkFrame_zero.hpp ! src/share/vm/shark/sharkInvariants.hpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: c095a7f289aa Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c095a7f289aa 8005818: Shark: fix OSR for non-empty incoming stack Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/shark/sharkCompiler.cpp ! src/share/vm/shark/sharkFunction.cpp ! src/share/vm/shark/sharkInvariants.hpp Changeset: 606eada1bf86 Author: twisti Date: 2013-01-11 16:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/606eada1bf86 8005820: Shark: enable JSR292 support Reviewed-by: twisti Contributed-by: Roman Kennke ! src/share/vm/compiler/abstractCompiler.hpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/shark/sharkBlock.cpp ! src/share/vm/shark/sharkCompiler.hpp ! src/share/vm/shark/sharkConstant.cpp ! src/share/vm/shark/sharkInliner.cpp ! src/share/vm/shark/sharkTopLevelBlock.cpp Changeset: 6d1f5516534e Author: twisti Date: 2013-01-11 20:01 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6d1f5516534e 8006127: remove printing code added with 8006031 Reviewed-by: kvn ! src/share/vm/opto/library_call.cpp Changeset: d92fa52a5d03 Author: vlivanov Date: 2013-01-14 08:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d92fa52a5d03 8006095: C1: SIGSEGV w/ -XX:+LogCompilation Summary: avoid printing inlining decision when compilation fails Reviewed-by: kvn, roland ! src/share/vm/c1/c1_GraphBuilder.cpp Changeset: f1de9dbc914e Author: twisti Date: 2013-01-15 12:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f1de9dbc914e 8006109: test/java/util/AbstractSequentialList/AddAll.java fails: assert(rtype == ctype) failed: mismatched return types Reviewed-by: kvn ! src/share/vm/ci/ciType.cpp ! src/share/vm/ci/ciType.hpp ! src/share/vm/opto/doCall.cpp Changeset: 5b8548391bf3 Author: kvn Date: 2013-01-15 14:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5b8548391bf3 8005821: C2: -XX:+PrintIntrinsics is broken Summary: Check all print inlining flags when processing inlining list. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! src/share/vm/opto/compile.cpp Changeset: bf623b2d5508 Author: kvn Date: 2013-01-16 14:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf623b2d5508 8006204: please JTREGify test/compiler/7190310/Test7190310.java Summary: Add proper jtreg annotations in the preceding comment, including an explicit timeout. Reviewed-by: kvn, twisti Contributed-by: david.r.chase at oracle.com ! test/compiler/7190310/Test7190310.java Changeset: eab4f9ed602c Author: kvn Date: 2013-01-17 18:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/eab4f9ed602c Merge ! src/share/vm/compiler/compileBroker.cpp Changeset: 689e1218d7fe Author: brutisso Date: 2013-01-14 09:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/689e1218d7fe 8004018: Remove old initialization flags Reviewed-by: dholmes, stefank Contributed-by: erik.helin at oracle.com ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: a30e7b564541 Author: brutisso Date: 2013-01-14 21:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a30e7b564541 8005972: ParNew should not update the tenuring threshold when promotion failed has occurred Reviewed-by: ysr, johnc, jwilhelm ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/defNewGeneration.hpp Changeset: ed6154d7d259 Author: stefank Date: 2013-01-15 13:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed6154d7d259 8005590: java_lang_Class injected field resolved_constructor appears unused Reviewed-by: coleenp, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ff0a7943fd29 Author: stefank Date: 2013-01-15 10:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ff0a7943fd29 8005994: Method annotations are allocated unnecessarily during class file parsing Summary: Also reviewed by: vitalyd at gmail.com Reviewed-by: coleenp, acorn ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/prims/jvm.cpp Changeset: 4967eb4f67a9 Author: johnc Date: 2013-01-15 12:32 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4967eb4f67a9 8001425: G1: Change the default values for certain G1 specific flags Summary: Changes to default and ergonomic flag values recommended by performance team. Changes were also reviewed by Monica Beckwith . Reviewed-by: brutisso, huntch ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 2dce7c34c564 Author: stefank Date: 2013-01-17 11:39 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2dce7c34c564 8006513: Null pointer in DefaultMethods::generate_default_methods when merging annotations Reviewed-by: brutisso, jfranck ! src/share/vm/classfile/defaultMethods.cpp Changeset: 59a58e20dc60 Author: jmasa Date: 2013-01-17 19:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/59a58e20dc60 8006537: Assert when dumping archive with default methods Reviewed-by: coleenp ! src/share/vm/classfile/classLoaderData.cpp ! src/share/vm/memory/metadataFactory.hpp Changeset: f422634e5828 Author: brutisso Date: 2013-01-18 11:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f422634e5828 Merge ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: 70c89bd6b895 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/70c89bd6b895 Merge Changeset: 2b878edabfc0 Author: amurillo Date: 2013-01-18 05:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2b878edabfc0 Added tag hs25-b16 for changeset 70c89bd6b895 ! .hgtags Changeset: 46e60405583b Author: amurillo Date: 2013-01-18 05:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46e60405583b 8006511: new hotspot build - hs25-b17 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e94ed1591b42 Author: sla Date: 2013-01-16 16:30 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e94ed1591b42 8006403: Regression: jstack failed due to the FieldInfo regression in SA Reviewed-by: sla, dholmes Contributed-by: Aleksey Shipilev ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! src/share/vm/runtime/vmStructs.cpp Changeset: 557bda927cc2 Author: sla Date: 2013-01-18 14:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/557bda927cc2 Merge ! src/share/vm/runtime/vmStructs.cpp Changeset: 617b18aadb33 Author: sla Date: 2013-01-18 19:13 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/617b18aadb33 Merge Changeset: 203f64878aab Author: hseigel Date: 2013-01-17 10:25 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/203f64878aab 7102489: RFE: cleanup jlong typedef on __APPLE__and _LLP64 systems. Summary: Define jlong as long on all LP64 platforms and add JLONG_FORMAT macro. Reviewed-by: dholmes, coleenp, mikael, kvn ! src/cpu/x86/vm/jni_x86.h ! src/os/bsd/vm/os_bsd.inline.hpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/posix/launcher/java_md.c ! src/os/posix/launcher/java_md.h ! src/os/solaris/vm/os_solaris.inline.hpp ! src/os/windows/launcher/java_md.c ! src/os/windows/launcher/java_md.h ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.inline.hpp ! src/share/tools/launcher/java.c ! src/share/tools/launcher/java.h ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/ci/ciReplay.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/runtime/aprofiler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/perfData.cpp ! src/share/vm/runtime/virtualspace.cpp ! src/share/vm/services/diagnosticArgument.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp Changeset: b14da2e6f2dc Author: coleenp Date: 2013-01-17 13:40 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b14da2e6f2dc 7174978: NPG: Fix bactrace builder for class redefinition Summary: Remove Method* from backtrace but save version so redefine classes doesn't give inaccurate line numbers. Removed old Merlin API with duplicate code. Reviewed-by: dholmes, sspitsyn ! make/bsd/makefiles/mapfile-vers-debug ! make/bsd/makefiles/mapfile-vers-product ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! make/solaris/makefiles/mapfile-vers ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: b5f6465019f6 Author: coleenp Date: 2013-01-17 22:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b5f6465019f6 8006548: version wrong in new constantPool code Summary: fix increment problem with saved_version Reviewed-by: dholmes ! src/share/vm/oops/constantPool.hpp Changeset: c07c102cbad7 Author: brutisso Date: 2013-01-21 09:00 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c07c102cbad7 8006431: os::Bsd::initialize_system_info() sets _physical_memory too large Summary: Use HW_MEMSIZE instead of HW_USERMEM to get a 64 bit value of the physical memory on the machine. Also reviewed by vitalyd at gmail.com. Reviewed-by: sla, dholmes, dlong, mikael ! src/os/bsd/vm/os_bsd.cpp Changeset: c73c3f2c5b3b Author: acorn Date: 2013-01-21 16:11 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c73c3f2c5b3b Merge ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/services/diagnosticArgument.cpp Changeset: f3184f32ce0b Author: dcubed Date: 2013-01-22 05:55 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f3184f32ce0b 6444286: Possible naked oop related to biased locking revocation safepoint in jni_exit() Summary: Add missing Handle. Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/synchronizer.cpp Changeset: 22ba8c8ce6a6 Author: dcubed Date: 2013-01-22 05:56 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22ba8c8ce6a6 8004902: correctness fixes motivated by contended locking work (6607129) Summary: misc correctness fixes Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: dave.dice at oracle.com ! src/os/bsd/vm/os_bsd.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/objectMonitor.inline.hpp Changeset: 5ce621176715 Author: dcubed Date: 2013-01-22 05:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ce621176715 8004903: VMThread::execute() calls Thread::check_for_valid_safepoint_state() on concurrent VM ops Summary: check_for_valid_safepoint_state() only applies to blocking VM ops Reviewed-by: acorn, dholmes, dice, sspitsyn Contributed-by: karen.kinnear at oracle.com ! src/share/vm/runtime/vmThread.cpp Changeset: edd23b35b1a5 Author: zgu Date: 2013-01-22 14:27 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/edd23b35b1a5 6871190: Don't terminate JVM if it is running in a non-interactive session Summary: Don't handle CTRL_LOGOFF_EVENT event when the process is running in a non-interactive session Reviewed-by: ctornqvi, acorn ! src/os/windows/vm/os_windows.cpp Changeset: 2ef7061f13b4 Author: zgu Date: 2013-01-22 11:54 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2ef7061f13b4 Merge ! src/os/windows/vm/os_windows.cpp Changeset: 7df93f7c14a5 Author: brutisso Date: 2013-01-16 12:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7df93f7c14a5 8006242: G1: WorkerDataArray::verify() too strict for double calculations Summary: Also reviewed by vitalyd at gmail.com. Reviewed-by: johnc, mgerdin ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp ! src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp Changeset: bf8c2b2c8cfa Author: mgerdin Date: 2013-01-22 13:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bf8c2b2c8cfa 8004147: test/Makefile jtreg_tests target does not work with cygwin Reviewed-by: ctornqvi, brutisso ! test/Makefile Changeset: d754ef7b9352 Author: jmasa Date: 2013-01-24 06:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d754ef7b9352 Merge Changeset: a7114d3d712e Author: kvn Date: 2013-01-22 11:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a7114d3d712e 8005055: pass outputStream to more opto debug routines Summary: pass the output stream to node->dump() and everything reachable from there Reviewed-by: kvn Contributed-by: goetz.lindenmaier at sap.com ! src/share/vm/compiler/oopMap.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/optoreg.hpp ! src/share/vm/opto/regalloc.cpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp Changeset: b30b3c2a0cf2 Author: kvn Date: 2013-01-22 15:34 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b30b3c2a0cf2 6896617: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() on x86 Summary: Use SSE4.2 and AVX2 instructions for encodeArray intrinsic. Reviewed-by: roland ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/formssel.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp + test/compiler/6896617/Test6896617.java Changeset: 522c328b8b77 Author: kvn Date: 2013-01-23 15:11 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/522c328b8b77 8003878: compiler/7196199 test failed on OS X since 8b54, jdk7u12b01 Summary: Limit vectors size to 16 bytes on BSD until the problem is fixed Reviewed-by: twisti ! src/cpu/x86/vm/vm_version_x86.cpp Changeset: 22ead76da3f4 Author: kmo Date: 2013-01-24 02:03 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22ead76da3f4 8006758: LinkResolver assertion (caused by @Contended changes) Summary: treat anonymous classes as privileged code to restore the special handling for @Compiled during class file parsing Reviewed-by: jrose, coleenp, kvn, dholmes ! src/share/vm/classfile/classFileParser.cpp Changeset: 274a29bf5682 Author: kmo Date: 2013-01-24 09:06 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/274a29bf5682 Merge Changeset: b4391649e91e Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b4391649e91e Merge ! .hgtags Changeset: 6778d0b16593 Author: amurillo Date: 2013-01-25 02:36 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6778d0b16593 Added tag hs25-b17 for changeset b4391649e91e ! .hgtags From lana.steuck at oracle.com Thu Jan 31 14:21:22 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Thu, 31 Jan 2013 22:21:22 +0000 Subject: hg: jdk8/tl/jdk: 40 new changesets Message-ID: <20130131222907.A772647709@hg.openjdk.java.net> Changeset: 6d849e883c40 Author: yhuang Date: 2013-01-13 18:45 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d849e883c40 7114053: [sq] Inproper tanslation for iso lanugage of Albanian Reviewed-by: naoto ! src/share/classes/sun/util/resources/sq/LocaleNames_sq.properties ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 2de23975ee10 Author: yhuang Date: 2013-01-15 19:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2de23975ee10 Merge Changeset: 68fc838d5e89 Author: yhuang Date: 2013-01-16 19:05 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68fc838d5e89 Merge Changeset: 595baf3cc781 Author: yhuang Date: 2013-01-16 23:08 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/595baf3cc781 Merge Changeset: 478d8354285a Author: erikj Date: 2013-01-18 16:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/478d8354285a 8006567: jre/lib/applet missing from Mac JDK installation Reviewed-by: tbell ! makefiles/Bundles.gmk Changeset: 92d8880d5406 Author: erikj Date: 2013-01-21 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92d8880d5406 8006583: build-infra: Remove /javax/swing/SwingBeanInfoBase.java from src.zip Reviewed-by: tbell ! makefiles/GensrcSwing.gmk Changeset: a9839ed93340 Author: erikj Date: 2013-01-21 11:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a9839ed93340 Merge Changeset: 506bf3d23f06 Author: erikj Date: 2013-01-21 14:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/506bf3d23f06 8006579: build-infra: In jvm.cfg, alias -server to -client when no server jvm is built. Reviewed-by: tbell ! makefiles/CopyFiles.gmk Changeset: 57d5d9544628 Author: erikj Date: 2013-01-22 09:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57d5d9544628 8004151: build-infra: Generating X11 wrapper offset file is not cross compilable Reviewed-by: dholmes, ohrstrom ! makefiles/GensrcX11Wrappers.gmk + src/solaris/classes/sun/awt/X11/generator/sizes.32 + src/solaris/classes/sun/awt/X11/generator/sizes.64 Changeset: ef592aceb40e Author: katleman Date: 2013-01-24 16:49 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ef592aceb40e Added tag jdk8-b74 for changeset 57d5d9544628 ! .hgtags Changeset: 57561ea851d2 Author: lana Date: 2013-01-26 19:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/57561ea851d2 Merge - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java ! test/sun/text/resources/LocaleData ! test/sun/text/resources/LocaleDataTest.java Changeset: 4faaaf5027a5 Author: alexsch Date: 2013-01-14 08:32 -0500 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4faaaf5027a5 7166409: bug4331515.java fail with NullPointerException on ubuntu10.04-x86 for JDK8 Reviewed-by: serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java Changeset: 9c6ca265b4a1 Author: alexsch Date: 2013-01-15 12:49 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9c6ca265b4a1 8003978: closed/javax/swing/JRootPane/bug4670486.java fails since jdk7u12b01 on macosx Reviewed-by: serb, leonidr ! src/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java ! src/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java ! src/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java ! src/share/classes/sun/swing/SwingUtilities2.java ! test/java/awt/KeyboardFocusmanager/TypeAhead/SubMenuShowTest/SubMenuShowTest.java Changeset: 1b886bd5e5bf Author: serb Date: 2013-01-15 21:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1b886bd5e5bf 7124525: [macosx] No animation on certain Swing components in Aqua LaF Reviewed-by: alexsch, swingler ! src/macosx/classes/com/apple/laf/AquaPainter.java ! src/macosx/classes/com/apple/laf/ImageCache.java Changeset: 7ea1372be2fe Author: mcherkas Date: 2013-01-16 17:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ea1372be2fe 8005492: Reduce number of warnings in sun/awt/* classes Reviewed-by: art, anthony ! src/share/classes/java/awt/Button.java ! src/share/classes/java/awt/Checkbox.java ! src/share/classes/java/awt/Choice.java ! src/share/classes/java/awt/Component.java ! src/share/classes/java/awt/Container.java ! src/share/classes/java/awt/Dialog.java ! src/share/classes/java/awt/Frame.java ! src/share/classes/java/awt/KeyboardFocusManager.java ! src/share/classes/java/awt/Scrollbar.java ! src/share/classes/java/awt/TextArea.java ! src/share/classes/java/awt/TextComponent.java ! src/share/classes/java/awt/TextField.java ! src/share/classes/java/awt/Toolkit.java ! src/share/classes/java/awt/Window.java ! src/share/classes/sun/awt/image/SurfaceManager.java Changeset: 23f9955ae34a Author: lana Date: 2013-01-16 15:57 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23f9955ae34a Merge Changeset: 47243a4efb8b Author: kshefov Date: 2013-01-17 15:08 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/47243a4efb8b 7124209: [macosx] SpringLayout issue. BASELINE is not in the range: [NORTH, SOUTH] Reviewed-by: serb, alexsch + test/javax/swing/SpringLayout/4726194/bug4726194.java Changeset: 035f87fc9f74 Author: anthony Date: 2013-01-18 14:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/035f87fc9f74 8005465: [macosx] Evaluate if checking for the -XstartOnFirstThread is still needed in awt.m Summary: Allow one to start AWT on the main thread w/o exceptions Reviewed-by: art, serb ! src/macosx/native/sun/awt/awt.m Changeset: 5309fed435b5 Author: serb Date: 2013-01-18 18:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5309fed435b5 7179050: [macosx] Make LWAWT be able to run on AppKit thread Summary: Removed irrelevant assertions from the LWAWT native methods Reviewed-by: serb, anthony Contributed-by: petr.pchelko at oracle.com ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTSurfaceLayers.m ! src/macosx/native/sun/awt/AWTView.m ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/ApplicationDelegate.m ! src/macosx/native/sun/awt/CClipboard.m ! src/macosx/native/sun/awt/CCursorManager.m ! src/macosx/native/sun/awt/CDesktopPeer.m ! src/macosx/native/sun/awt/CDragSourceContextPeer.m ! src/macosx/native/sun/awt/CImage.m ! src/macosx/native/sun/awt/CInputMethod.m ! src/macosx/native/sun/awt/CMenu.m ! src/macosx/native/sun/awt/CMenuComponent.m ! src/macosx/native/sun/awt/CMenuItem.m ! src/macosx/native/sun/awt/CPopupMenu.m ! src/macosx/native/sun/awt/CTrayIcon.m ! src/macosx/native/sun/awt/CWrapper.m ! src/macosx/native/sun/awt/JavaComponentAccessibility.m ! src/macosx/native/sun/awt/LWCToolkit.m ! src/macosx/native/sun/awt/awt.m ! src/macosx/native/sun/osxapp/ThreadUtilities.h ! src/macosx/native/sun/osxapp/ThreadUtilities.m Changeset: 112c08b41ca2 Author: alitvinov Date: 2013-01-18 18:34 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/112c08b41ca2 8006417: JComboBox.showPopup(), hidePopup() fails in JRE 1.7 on OS X Reviewed-by: art, serb ! src/macosx/classes/sun/lwawt/LWToolkit.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java + test/javax/swing/JComboBox/ShowPopupAfterHidePopupTest/ShowPopupAfterHidePopupTest.java Changeset: b4131358120a Author: raginip Date: 2013-01-18 11:33 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4131358120a 8000839: Integrate the Java Access Bridge with Java Runtime Reviewed-by: ptbrunet, erikj ! make/Makefile + make/bridge/AccessBridgeJava/Makefile + make/bridge/JAWTAccessBridge/Files_cpp.gmk + make/bridge/JAWTAccessBridge/Makefile + make/bridge/Jabswitch/Makefile + make/bridge/Jaccess/Makefile + make/bridge/JavaAccessBridge/Files_cpp.gmk + make/bridge/JavaAccessBridge/Makefile + make/bridge/Makefile + make/bridge/WindowsAccessBridge/Files_cpp.gmk + make/bridge/WindowsAccessBridge/Makefile ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk ! makefiles/GensrcMisc.gmk Changeset: f55d869052dd Author: alexsch Date: 2013-01-21 17:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f55d869052dd 8004298: NPE in WindowsTreeUI.ensureRowsAreVisible Reviewed-by: serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsTreeUI.java + test/javax/swing/JTree/8004298/bug8004298.java Changeset: dd7e1cc4253c Author: alexp Date: 2013-01-24 15:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd7e1cc4253c 7147078: [macosx] Echo char set in TextField doesn't prevent word jumping Reviewed-by: art ! src/macosx/classes/com/apple/laf/AquaKeyBindings.java ! src/macosx/classes/com/apple/laf/AquaLookAndFeel.java ! src/macosx/classes/sun/lwawt/LWTextFieldPeer.java Changeset: 04d2005fa178 Author: alexp Date: 2013-01-24 15:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/04d2005fa178 7132793: [macosx] setWheelScrollEnabled action reversed Reviewed-by: serb, art ! src/macosx/classes/sun/lwawt/LWComponentPeer.java ! src/macosx/classes/sun/lwawt/LWScrollPanePeer.java Changeset: 40a45a72a120 Author: serb Date: 2013-01-24 15:55 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40a45a72a120 8005997: [macosx] Printer Dialog opens an additional title bar Reviewed-by: anthony, art Contributed-by: petr.pchelko at oracle.com ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: fab11b21ee6e Author: kizune Date: 2013-01-24 16:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fab11b21ee6e 7143768: [macosx] Unexpected NullPointerException and java.io.IOException during DnD Reviewed-by: alexp ! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java Changeset: 7dd1896b37c8 Author: malenkov Date: 2013-01-24 17:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7dd1896b37c8 6817933: Setting the background of an HTML Widget changes the native Windows JFileChooser Reviewed-by: alexsch ! src/share/classes/sun/swing/WindowsPlacesBar.java + test/javax/swing/JFileChooser/6817933/Test6817933.java Changeset: f8526b99b825 Author: serb Date: 2013-01-24 17:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8526b99b825 8003173: [macosx] Fullscreen on Mac leaves an empty rectangle Reviewed-by: anthony, alexsch ! src/macosx/classes/sun/awt/CGraphicsDevice.java ! src/macosx/classes/sun/lwawt/LWWindowPeer.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformView.java ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java + test/java/awt/FullScreen/FullScreenInsets/FullScreenInsets.java Changeset: 32721a1a8da8 Author: malenkov Date: 2013-01-24 17:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/32721a1a8da8 8005138: test/java/beans/Introspector/TestTypeResolver.java fails Reviewed-by: alexsch ! test/java/beans/Introspector/TestTypeResolver.java Changeset: 7cda96a78260 Author: malenkov Date: 2013-01-24 18:06 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7cda96a78260 8003400: JTree scrolling problem when using large model in WindowsLookAndFeel Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/basic/BasicTreeUI.java + test/javax/swing/JTree/8003400/Test8003400.java Changeset: e616c28c5120 Author: erikj Date: 2013-01-28 14:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e616c28c5120 Merge - make/tools/swing-beans/beaninfo/BeanInfoUtils.java - make/tools/swing-beans/beaninfo/SwingBeanInfoBase.java ! makefiles/CompileJavaClasses.gmk ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! makefiles/CopyFiles.gmk ! makefiles/CreateJars.gmk - src/share/demo/jfc/CodePointIM/CodePointInputMethod.java - src/share/demo/jfc/CodePointIM/CodePointInputMethodDescriptor.java Changeset: a1a55db02f34 Author: lana Date: 2013-01-29 20:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a1a55db02f34 Merge ! makefiles/CreateJars.gmk Changeset: 9d5c43050210 Author: dl Date: 2013-01-11 16:50 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9d5c43050210 8006123: Support @Contended Annotation - JEP 142 (jdk part) Summary: jdk changes for 8003895. Reviewed-by: darcy, jrose, coleenp, dholmes, kvn Contributed-by: Aleksey Shipilev + src/share/classes/sun/misc/Contended.java Changeset: 739351a0a7a1 Author: kvn Date: 2013-01-23 11:47 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/739351a0a7a1 8006799: Optimize sun.nio.cs.ISO_8859_1$Encode.encodeArrayLoop() (jdk part of 6896617) Summary: Move hot loop in ISO_8859_1$Encode.encodeArrayLoop() into separate method encodeISOArray() to be replaced by JVM JIT compiler with optimized intrinsic code. Reviewed-by: alanb, sherman ! src/share/classes/sun/nio/cs/ISO_8859_1.java Changeset: e9d00d30fcca Author: amurillo Date: 2013-01-25 03:02 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9d00d30fcca Merge Changeset: ac286bf65242 Author: amurillo Date: 2013-01-30 10:18 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ac286bf65242 Merge - test/java/rmi/activation/ActivationSystem/unregisterGroup/CallbackInterface.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/Callback_Stub.java - test/java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup_Stub.java Changeset: 3c499051a5df Author: erikj Date: 2013-01-29 16:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3c499051a5df 8006873: SWAT-b74 msvcr100.dll does not have the permission for all Reviewed-by: alanb, tbell ! makefiles/CopyFiles.gmk Changeset: 4a67fdb752b7 Author: katleman Date: 2013-01-30 13:04 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4a67fdb752b7 Merge ! makefiles/CopyFiles.gmk Changeset: 771551bc9e02 Author: lana Date: 2013-01-31 10:22 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/771551bc9e02 Merge Changeset: e822b4d50a5b Author: lana Date: 2013-01-31 14:10 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e822b4d50a5b Merge - src/share/classes/java/lang/annotation/ContainedBy.java - src/share/classes/java/lang/annotation/ContainerFor.java From mandy.chung at oracle.com Thu Jan 31 14:33:24 2013 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Thu, 31 Jan 2013 22:33:24 +0000 Subject: hg: jdk8/tl/jdk: 6355704: (fmt) %f formatting of BigDecimals is incorrect Message-ID: <20130131223335.B07F14770A@hg.openjdk.java.net> Changeset: a09a37cff333 Author: mchung Date: 2013-01-31 14:29 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a09a37cff333 6355704: (fmt) %f formatting of BigDecimals is incorrect Reviewed-by: darcy Contributed-by: brian.burkhalter at oracle.com ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/BasicBigDecimal.java From weijun.wang at oracle.com Thu Jan 31 15:39:59 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 31 Jan 2013 23:39:59 +0000 Subject: hg: jdk8/tl/jdk: 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit Message-ID: <20130131234019.DA1E547714@hg.openjdk.java.net> Changeset: d2495b9984fa Author: weijun Date: 2013-02-01 07:39 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d2495b9984fa 8006564: Test sun/security/util/Oid/S11N.sh fails with timeout on Linux 32-bit Reviewed-by: alanb + test/sun/security/util/Oid/S11N.java - test/sun/security/util/Oid/S11N.sh - test/sun/security/util/Oid/SerialTest.java From joe.darcy at oracle.com Thu Jan 31 18:58:28 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 01 Feb 2013 02:58:28 +0000 Subject: hg: jdk8/tl/langtools: 8007351: Malformed copyright statements in typeAnnotations test directory Message-ID: <20130201025835.C022847725@hg.openjdk.java.net> Changeset: bec996065c45 Author: darcy Date: 2013-01-31 18:58 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/bec996065c45 8007351: Malformed copyright statements in typeAnnotations test directory Reviewed-by: jjg ! test/tools/javac/annotations/typeAnnotations/TargetTypes.java ! test/tools/javac/annotations/typeAnnotations/TypeProcOnly.java ! test/tools/javac/annotations/typeAnnotations/api/AnnotatedArrayOrder.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayCreationTree.java ! test/tools/javac/annotations/typeAnnotations/api/ArrayPositionConsistency.java ! test/tools/javac/annotations/typeAnnotations/classfile/ClassfileTestHelper.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest1.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java ! test/tools/javac/annotations/typeAnnotations/classfile/NewTypeArguments.java ! test/tools/javac/annotations/typeAnnotations/classfile/NoTargetAnnotations.java ! test/tools/javac/annotations/typeAnnotations/classfile/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/classfile/Wildcards.java ! test/tools/javac/annotations/typeAnnotations/failures/target/DotClass.java ! test/tools/javac/annotations/typeAnnotations/newlocations/Varargs.java ! test/tools/javac/annotations/typeAnnotations/packageanno/PackageProcessor.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/Anno.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/MyClass.java ! test/tools/javac/annotations/typeAnnotations/packageanno/mypackage/package-info.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassExtends.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ClassTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Driver.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ExceptionParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Fields.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/FromSpecification.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodParameters.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReceivers.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodReturns.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodThrows.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MethodTypeParam.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/MultiCatch.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NestedTypes.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/NewObjects.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/ReferenceInfoUtil.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/RepeatingTypeAnnotations.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeCasts.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/TypeTests.java From jonathan.gibbons at oracle.com Thu Jan 31 19:19:45 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Feb 2013 03:19:45 +0000 Subject: hg: jdk8/tl/langtools: 8007329: minor issues in impl class hierarchry for DCTree.* classes Message-ID: <20130201031952.A6EA947727@hg.openjdk.java.net> Changeset: 3ab64e4293a1 Author: jjg Date: 2013-01-31 19:19 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ab64e4293a1 8007329: minor issues in impl class hierarchry for DCTree.* classes Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/tree/DCTree.java From jonathan.gibbons at oracle.com Thu Jan 31 19:32:09 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 01 Feb 2013 03:32:09 +0000 Subject: hg: jdk8/tl/langtools: 8004353: Generated html is wrong for overview.html; content has incorrect css footer class Message-ID: <20130201033217.1C1094772D@hg.openjdk.java.net> Changeset: 3d97a9a7a82b Author: jjg Date: 2013-01-31 19:31 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3d97a9a7a82b 8004353: Generated html is wrong for overview.html; content has incorrect css footer class Reviewed-by: jjg Contributed-by: roger.riggs at oracle.com ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java From chris.hegarty at oracle.com Thu Jan 31 22:53:50 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 01 Feb 2013 06:53:50 +0000 Subject: hg: jdk8/tl/jdk: 8006395: Race in async socket close on Linux Message-ID: <20130201065420.448C84773A@hg.openjdk.java.net> Changeset: 17b643956999 Author: chegar Date: 2013-02-01 06:51 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17b643956999 8006395: Race in async socket close on Linux Reviewed-by: alanb, dsamersoff ! src/solaris/native/java/net/linux_close.c + test/java/net/Socket/asyncClose/Race.java