From vincent.x.ryan at oracle.com Thu Aug 1 11:05:44 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 1 Aug 2013 12:05:44 +0100 Subject: Code review request: 8021789: jarsigner parses alias as command line option (depending on locale) In-Reply-To: <51F8B6E4.50201@oracle.com> References: <51F8B6E4.50201@oracle.com> Message-ID: <77CD9C09-37D3-4421-8119-272DFEA28891@oracle.com> Your fix looks fine. On 31 Jul 2013, at 08:04, Weijun Wang wrote: > Hi All > > Please review the fix at > > http://cr.openjdk.java.net/~weijun/8021789/webrev.00/ > > The problem is that jarsigner uses Collator::compare to check for command line options, and if that Collator uses Collator.PRIMARY as strength it treats "-debug" and "debug" the same (in some locales?). I have no idea how people depend on other features of Collator.PRIMARY, so I move the filename/alias check to the beginning of the long if block. > > Also I fixed a small bug on empty argument. Of course, an empty argument is always useless but StringIndexOutOfBoundsException is not a friendly response. > > Thanks > Max From chris.hegarty at oracle.com Thu Aug 1 11:38:33 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 01 Aug 2013 11:38:33 +0000 Subject: hg: jdk8/tl/jdk: 8022061: More ProblemList.txt updates (7/2013) Message-ID: <20130801113906.30C9B484F7@hg.openjdk.java.net> Changeset: c49b538ef054 Author: chegar Date: 2013-08-01 12:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c49b538ef054 8022061: More ProblemList.txt updates (7/2013) Reviewed-by: alanb, psandoz ! test/ProblemList.txt From dmitry.degrave at oracle.com Thu Aug 1 12:59:17 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 01 Aug 2013 12:59:17 +0000 Subject: hg: jdk8/tl/corba: 8015987: The corba repo contains unneeded .sjava files Message-ID: <20130801125918.9222C48507@hg.openjdk.java.net> Changeset: cc11a0efb4f9 Author: aefimov Date: 2013-08-01 14:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cc11a0efb4f9 8015987: The corba repo contains unneeded .sjava files Reviewed-by: alanb, chegar, coffeys - src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava - src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava - src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava - src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava From xuelei.fan at oracle.com Thu Aug 1 13:36:42 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 01 Aug 2013 21:36:42 +0800 Subject: Code review request, 7127524 P11TlsPrfGenerator has anonymous inner class with serialVersionUID Message-ID: <51FA646A.2000807@oracle.com> Hi, Please review this simple update. webrev: http://cr.openjdk.java.net/~xuelei/7127524/webrev.00/ The purpose of this fix is to remove the unnecessary serialVersionUID definition in anonymous class. private static final SecretKey NULL_KEY = new SecretKey() { - private static final long serialVersionUID = -8090049519656411362L; // ... } An anonymous class cannot make any guarantees about serialization compatibility since has a compiler-generated, implementation-specific name that may vary uncontrollably. It is nonsensical for an anonymous class to define a serialVersionUID. No new regression test as it is a trivial update. Thanks, Xuelei From vincent.x.ryan at oracle.com Thu Aug 1 14:18:42 2013 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 1 Aug 2013 15:18:42 +0100 Subject: Code review request, 7127524 P11TlsPrfGenerator has anonymous inner class with serialVersionUID In-Reply-To: <51FA646A.2000807@oracle.com> References: <51FA646A.2000807@oracle.com> Message-ID: <7DB2EF7F-B2A6-4D9A-B823-55451BD83C43@oracle.com> Your fix looks good. On 1 Aug 2013, at 14:36, Xuelei Fan wrote: > Hi, > > Please review this simple update. > > webrev: http://cr.openjdk.java.net/~xuelei/7127524/webrev.00/ > > The purpose of this fix is to remove the unnecessary serialVersionUID > definition in anonymous class. > > private static final SecretKey NULL_KEY = new SecretKey() { > - private static final long serialVersionUID = -8090049519656411362L; > // ... > } > > An anonymous class cannot make any guarantees about serialization > compatibility since has a compiler-generated, implementation-specific > name that may vary uncontrollably. It is nonsensical for an anonymous > class to define a serialVersionUID. > > No new regression test as it is a trivial update. > > Thanks, > Xuelei From dmitry.degrave at oracle.com Thu Aug 1 14:20:44 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 01 Aug 2013 14:20:44 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130801142116.CDC4A4850C@hg.openjdk.java.net> Changeset: 36f4cf8872f3 Author: igerasim Date: 2013-07-30 21:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36f4cf8872f3 7192942: (coll) Inefficient calculation of power of two in HashMap Reviewed-by: mduigou ! src/share/classes/java/util/HashMap.java Changeset: 54329c24c2f4 Author: igerasim Date: 2013-07-29 12:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54329c24c2f4 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 Reviewed-by: alanb, chegar, martin, rriggs ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java From xuelei.fan at oracle.com Thu Aug 1 14:35:37 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 01 Aug 2013 14:35:37 +0000 Subject: hg: jdk8/tl/jdk: 7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID Message-ID: <20130801143551.326ED4850E@hg.openjdk.java.net> Changeset: d6de149b9f20 Author: xuelei Date: 2013-08-01 07:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6de149b9f20 7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java From chris.hegarty at oracle.com Thu Aug 1 15:54:13 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 01 Aug 2013 15:54:13 +0000 Subject: hg: jdk8/tl/jdk: 8022087: Fix doclint issues in j.u.Deque & Queue Message-ID: <20130801155429.B1FE048510@hg.openjdk.java.net> Changeset: cd13a4a45a37 Author: chegar Date: 2013-08-01 16:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd13a4a45a37 8022087: Fix doclint issues in j.u.Deque & Queue Reviewed-by: chegar, darcy Contributed-by: Doug Lea
! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/Queue.java From sean.mullan at oracle.com Thu Aug 1 16:48:38 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 01 Aug 2013 12:48:38 -0400 Subject: [8] Request for review: 8016848: javax_security/auth/login tests fail in compact 1 and 2 profiles Message-ID: <51FA9166.7010809@oracle.com> Hello, Could you please review my fix for 8016848: webrev: http://cr.openjdk.java.net/~mullan/webrevs/8016848/webrev.00/ bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016848 This is a bug because javax.security.auth.login.Configuration.getConfiguration() throws a ClassCastException when run with the compact1 or compact2 profiles. This is because the default Configuration object that is returned is not in the compact1 profile. The default Configuration is specified by the "login.configuration.provider" security property (in the Java security properties file). This property is currently set to com.sun.security.auth.login.ConfigFile which is not in the compact1 or compact2 profiles The fix is to change the default value of the "login.configuration.provider" security property to sun.security.provider.ConfigFile, which will be a new class that is essentially a copy of com.sun.security.auth.login.ConfigFile. However, because it is in the sun.security.provider package, it will be in all profiles. We will not remove the com.sun.security.auth.login.ConfigFile class as there may be some applications directly using it. noreg-jck as there is an existing JCK test for this. Thanks, Sean From paul.sandoz at oracle.com Thu Aug 1 21:07:32 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 01 Aug 2013 21:07:32 +0000 Subject: hg: jdk8/tl/jdk: 8020016: Numerous splitereator impls do not throw NPE for null Consumers Message-ID: <20130801210757.ADA8748544@hg.openjdk.java.net> Changeset: 0be7839d4599 Author: psandoz Date: 2013-08-01 15:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0be7839d4599 8020016: Numerous splitereator impls do not throw NPE for null Consumers Reviewed-by: mduigou, alanb, henryjen ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java From bradford.wetmore at oracle.com Fri Aug 2 00:45:33 2013 From: bradford.wetmore at oracle.com (Brad Wetmore) Date: Thu, 01 Aug 2013 17:45:33 -0700 Subject: Code review request, 8013809 deadlock in SSLSocketImpl between between write and close In-Reply-To: <51F0EBC2.3050908@Oracle.COM> References: <51F0EBC2.3050908@Oracle.COM> Message-ID: <51FB012D.3060101@oracle.com> On 7/25/2013 2:11 AM, Xuelei Fan wrote: > Hi Brad, > > Are you available to review this fix? > > Webrev: http://cr.openjdk.java.net/~xuelei/8013809/webrev.00/ > > No new regression test, hard to reproduce the issue. Your immediate fix looks good, however, IIRC, the reason for having getConnectionState() was to provide synchronized access (and syncing on the SSLSocketImpl object) to the connectionState variable before the Java "volatile" semantics were cleaned up in JDK 1.5. Now that you've made this change, does it make sense to get rid of getConnectionState(). What do you think? I hate race conditions! ;) Brad From xuelei.fan at oracle.com Fri Aug 2 01:12:50 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 02 Aug 2013 09:12:50 +0800 Subject: Code review request, 8013809 deadlock in SSLSocketImpl between between write and close In-Reply-To: <51FB012D.3060101@oracle.com> References: <51F0EBC2.3050908@Oracle.COM> <51FB012D.3060101@oracle.com> Message-ID: <51FB0792.8080705@oracle.com> On 8/2/2013 8:45 AM, Brad Wetmore wrote: > > > On 7/25/2013 2:11 AM, Xuelei Fan wrote: >> Hi Brad, >> >> Are you available to review this fix? >> >> Webrev: http://cr.openjdk.java.net/~xuelei/8013809/webrev.00/ >> >> No new regression test, hard to reproduce the issue. > > Your immediate fix looks good, however, IIRC, the reason for having > getConnectionState() was to provide synchronized access (and syncing on > the SSLSocketImpl object) to the connectionState variable before the > Java "volatile" semantics were cleaned up in JDK 1.5. > I think there is a lot of different of a "volatile" object and a synchronized block. A volatile object is to make sure the change and access of the object is synchronized; but synchronized block also make sure that the full process of the change is synchronized. For example: synchronized (aLock) { // We want to change the object, but may need // to prepare something before the change, please // don't access this object while we make the preparation. ... // prepare something else. aObject = newvalue; } > Now that you've made this change, does it make sense to get rid of > getConnectionState(). What do you think? > I was hesitated to remove the getConnectionState(). When we change the value of connectionState, "this" object is locked. If the value change does not completed, other thread cannot access the state. If we remove this synchronization, the behavior would be changed significantly. The reason that we can make the change in isClosed() implementation is that "APP_CLOSED" is the final state of the life-cycle of connection, therefore we don't care too much whether there is another thread is doing the closing or not. It looks like a little tricky. Xuelei > I hate race conditions! ;) > > Brad > > From weijun.wang at oracle.com Fri Aug 2 01:17:36 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 02 Aug 2013 01:17:36 +0000 Subject: hg: jdk8/tl/jdk: 8021789: jarsigner parses alias as command line option (depending on locale) Message-ID: <20130802011827.507EE48551@hg.openjdk.java.net> Changeset: 29f153e11683 Author: weijun Date: 2013-08-02 08:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29f153e11683 8021789: jarsigner parses alias as command line option (depending on locale) Reviewed-by: vinnie ! src/share/classes/sun/security/tools/jarsigner/Main.java + test/sun/security/tools/jarsigner/collator.sh From alexey.utkin at oracle.com Fri Aug 2 09:20:40 2013 From: alexey.utkin at oracle.com (alexey.utkin at oracle.com) Date: Fri, 02 Aug 2013 09:20:40 +0000 Subject: hg: jdk8/tl/jdk: 8020191: System.getProperty("os.name") returns "Windows NT (unknown)" on Windows 8.1 Message-ID: <20130802092154.E615B48565@hg.openjdk.java.net> Changeset: 40221b09812f Author: uta Date: 2013-08-02 13:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/40221b09812f 8020191: System.getProperty("os.name") returns "Windows NT (unknown)" on Windows 8.1 Reviewed-by: alanb, khazra, chegar ! src/windows/native/java/lang/java_props_md.c ! src/windows/resource/java.manifest From chris.hegarty at oracle.com Fri Aug 2 10:25:17 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 02 Aug 2013 10:25:17 +0000 Subject: hg: jdk8/tl/jdk: 8022121: Remove superfluous @test tag from SpliteratorTraversingAndSplittingTest Message-ID: <20130802102548.A0C5D48569@hg.openjdk.java.net> Changeset: 60c275e56a69 Author: chegar Date: 2013-08-02 11:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60c275e56a69 8022121: Remove superfluous @test tag from SpliteratorTraversingAndSplittingTest Reviewed-by: psandoz ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java From chris.hegarty at oracle.com Fri Aug 2 13:30:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 02 Aug 2013 13:30:49 +0000 Subject: hg: jdk8/tl/jdk: 8020291: j.u.c.CompletionStage; ... Message-ID: <20130802133116.5F3184856D@hg.openjdk.java.net> Changeset: 6ec910ff3ea1 Author: chegar Date: 2013-08-02 14:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ec910ff3ea1 8020291: j.u.c.CompletionStage 8020435: CompletableFuture/Basic.java fails on single core machine Reviewed-by: chegar, psandoz Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/CompletableFuture.java + src/share/classes/java/util/concurrent/CompletionStage.java ! test/ProblemList.txt ! test/java/util/concurrent/CompletableFuture/Basic.java From sean.mullan at oracle.com Fri Aug 2 13:39:43 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 02 Aug 2013 13:39:43 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130802134021.928284856E@hg.openjdk.java.net> Changeset: 42b786f2fb99 Author: mullan Date: 2013-08-02 08:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42b786f2fb99 8001319: Add SecurityPermission "insertProvider" target name Reviewed-by: vinnie ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/SecurityPermission.java + test/java/security/Security/AddProvider.java + test/java/security/Security/AddProvider.policy.1 + test/java/security/Security/AddProvider.policy.2 + test/java/security/Security/AddProvider.policy.3 Changeset: 7bbc6c2351d7 Author: mullan Date: 2013-08-02 08:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bbc6c2351d7 Merge - src/share/classes/java/net/package.html - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 0a778e487a73 Author: mullan Date: 2013-08-02 09:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a778e487a73 Merge From joe.darcy at oracle.com Fri Aug 2 21:19:21 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 02 Aug 2013 21:19:21 +0000 Subject: hg: jdk8/tl/jdk: 6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion Message-ID: <20130802212009.363134859F@hg.openjdk.java.net> Changeset: 33617583c545 Author: bpb Date: 2013-07-31 10:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33617583c545 6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion Summary: Update specification to match implementation. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicDouble.java From naoto.sato at oracle.com Fri Aug 2 22:45:52 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 02 Aug 2013 22:45:52 +0000 Subject: hg: jdk8/tl/jdk: 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Message-ID: <20130802224616.147DA485A2@hg.openjdk.java.net> Changeset: 883cc296ec89 Author: bchristi Date: 2013-08-02 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/883cc296ec89 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Summary: On Mac, default to UTF-8 if no environmental hints are available Reviewed-by: naoto, ddehaven ! src/solaris/native/java/lang/java_props_md.c + test/java/lang/System/MacEncoding/ExpectedEncoding.java + test/java/lang/System/MacEncoding/MacJNUEncoding.sh + test/java/lang/System/MacEncoding/TestFileEncoding.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh From alan.bateman at oracle.com Sun Aug 4 02:14:50 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 04 Aug 2013 02:14:50 +0000 Subject: hg: jdk8/tl/jdk: 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect Message-ID: <20130804021551.9BF2A485B9@hg.openjdk.java.net> Changeset: dd1040690e31 Author: bpb Date: 2013-08-02 11:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd1040690e31 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect Summary: Fail test if errors; fix test values; port BigDecimal version to BigInteger Reviewed-by: smarks, alanb Contributed-by: Brian Burkhalter ! test/java/math/BigDecimal/CompareToTests.java ! test/java/math/BigInteger/CompareToTests.java From weijun.wang at oracle.com Mon Aug 5 01:28:17 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 05 Aug 2013 09:28:17 +0800 Subject: Code review request: 8021788: JarInputStream doesn't provide certificates for some file under META-INF Message-ID: <51FEFFB1.2040506@oracle.com> Please take a look at http://cr.openjdk.java.net/~weijun/8021788/webrev.00/ The problem is that the method treats no META-INF entry as normal. If we can be sure that MANIFEST.MF and signature-related files are always at the beginning, we can safely treat an entry normal when we have done with those. Thanks Max From joe.darcy at oracle.com Mon Aug 5 14:50:31 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 05 Aug 2013 14:50:31 +0000 Subject: hg: jdk8/tl/jdk: 8022190: Fix varargs lint warnings in the JDK Message-ID: <20130805145121.77CAF485DA@hg.openjdk.java.net> Changeset: 80da091343af Author: darcy Date: 2013-08-05 07:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80da091343af 8022190: Fix varargs lint warnings in the JDK Reviewed-by: alanb, lancea, alexsch ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/swing/AccumulativeRunnable.java From sundararajan.athijegannathan at oracle.com Mon Aug 5 16:02:20 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Mon, 05 Aug 2013 16:02:20 +0000 Subject: hg: jdk8/tl/jdk: 8016531: jconsole-plugin script demo does not work with nashorn Message-ID: <20130805160233.DF480485DE@hg.openjdk.java.net> Changeset: 87367a1c7f76 Author: sundar Date: 2013-08-05 21:31 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/87367a1c7f76 8016531: jconsole-plugin script demo does not work with nashorn Reviewed-by: lagergren, hannesw Contributed-by: rieberandreas at gmail.com ! src/share/demo/scripting/jconsole-plugin/src/com/sun/demo/scripting/jconsole/ScriptShellPanel.java ! src/share/demo/scripting/jconsole-plugin/src/resources/jconsole.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/invoke.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jstack.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/jtop.js ! src/share/demo/scripting/jconsole-plugin/src/scripts/sysprops.js ! src/share/sample/scripting/scriptpad/README.txt ! src/share/sample/scripting/scriptpad/src/resources/conc.js ! src/share/sample/scripting/scriptpad/src/resources/mm.js From tom.hawtin at oracle.com Mon Aug 5 16:16:47 2013 From: tom.hawtin at oracle.com (Tom Hawtin) Date: Mon, 05 Aug 2013 09:16:47 -0700 Subject: Code review request, 7127524 P11TlsPrfGenerator has anonymous inner class with serialVersionUID In-Reply-To: <51FA646A.2000807@oracle.com> References: <51FA646A.2000807@oracle.com> Message-ID: <51FFCFEF.5010102@oracle.com> On 01/08/2013 06:36, Xuelei Fan wrote: > An anonymous class cannot make any guarantees about serialization > compatibility since has a compiler-generated, implementation-specific > name that may vary uncontrollably. It is nonsensical for an anonymous > class to define a serialVersionUID. Although it can't give guarantees about serialisation, that doesn't mean that it doesn't. We probably don't want to upset anything relying upon it. Having said that, in this case it doesn't seem to be reasonably accessible. Shame there isn't a good way of marking a class non-serialisable. Tom From mhall at mhcomputing.net Mon Aug 5 18:33:57 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Mon, 5 Aug 2013 11:33:57 -0700 Subject: IOE causes failure in com.sun.deploy.security.RevocationChecker.checkOCSP from 7u25 and up Message-ID: <20130805183357.GA31258@mhcomputing.net> We have a customer that is seeing the following exception in JDK7u25 after revocation checking was enabled by default: java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big. at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source) at com.sun.deploy.security.RevocationChecker.check(Unknown Source) at com.sun.deploy.security.TrustDecider.checkRevocationStatus(Unknown Source) at com.sun.deploy.security.TrustDecider.getValidationState(Unknown Source) at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source) Caused by: java.security.cert.CertPathValidatorException: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big. at sun.security.provider.certpath.OCSP.check(Unknown Source) at sun.security.provider.certpath.OCSP.check(Unknown Source) at sun.security.provider.certpath.OCSP.check(Unknown Source) ... 35 more Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big. at sun.security.util.DerInputStream.getLength(Unknown Source) at sun.security.util.DerValue.init(Unknown Source) at sun.security.util.DerValue.(Unknown Source) at sun.security.provider.certpath.OCSPResponse.(Unknown Source) ... 38 more However this com.sun.deploy.* code doesn't seem to be part of OpenJDK or IcedTea, so it's not possible for the community to recompile it with symbols, debug it, and find the cause. I did notice, in the code for sun.security.provider.certpath.OCSP.check which is available, I could see a way to get some logs from part of this code: private static final Debug debug = Debug.getInstance("certpath"); But I haven't had a chance to try that at the customer who found the issue. I suspect that the code reacts poorly if it sees unexpected characters in blocked OCSP sockets, but I can't tell without being able to read checkOCSP to see what it's really doing in there. Can anyone take a look? Thanks, Matthew. From sean.mullan at oracle.com Mon Aug 5 20:12:01 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 05 Aug 2013 13:12:01 -0700 Subject: IOE causes failure in com.sun.deploy.security.RevocationChecker.checkOCSP from 7u25 and up In-Reply-To: <20130805183357.GA31258@mhcomputing.net> References: <20130805183357.GA31258@mhcomputing.net> Message-ID: <52000711.3010903@oracle.com> Hi, I will need some more information in order to debug this, preferably the certificate chain - is that something you can email to me? Otherwise, you can enable the certpath debugging you mention below in the Java Contol Panel. Go to the Java tab, and add it to the Runtime Parameters of the JRE that you are using. Then email me the log file if possible. -Djava.security.debug=certpath Thanks, Sean On 08/05/2013 11:33 AM, Matthew Hall wrote: > We have a customer that is seeing the following exception in JDK7u25 after > revocation checking was enabled by default: > > java.security.cert.CertificateException: > java.security.cert.CertPathValidatorException: java.io.IOException: > DerInputStream.getLength(): lengthTag=127, too big. > at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source) > at com.sun.deploy.security.RevocationChecker.check(Unknown Source) > at com.sun.deploy.security.TrustDecider.checkRevocationStatus(Unknown Source) > at com.sun.deploy.security.TrustDecider.getValidationState(Unknown Source) > at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source) > Caused by: java.security.cert.CertPathValidatorException: java.io.IOException: > DerInputStream.getLength(): lengthTag=127, too big. > at sun.security.provider.certpath.OCSP.check(Unknown Source) > at sun.security.provider.certpath.OCSP.check(Unknown Source) > at sun.security.provider.certpath.OCSP.check(Unknown Source) > ... 35 more > Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big. > at sun.security.util.DerInputStream.getLength(Unknown Source) > at sun.security.util.DerValue.init(Unknown Source) > at sun.security.util.DerValue.(Unknown Source) > at sun.security.provider.certpath.OCSPResponse.(Unknown Source) > ... 38 more > > However this com.sun.deploy.* code doesn't seem to be part of OpenJDK or > IcedTea, so it's not possible for the community to recompile it with symbols, > debug it, and find the cause. > > I did notice, in the code for sun.security.provider.certpath.OCSP.check which > is available, I could see a way to get some logs from part of this code: > > private static final Debug debug = Debug.getInstance("certpath"); > > But I haven't had a chance to try that at the customer who found the issue. > > I suspect that the code reacts poorly if it sees unexpected characters in > blocked OCSP sockets, but I can't tell without being able to read checkOCSP to > see what it's really doing in there. Can anyone take a look? > > Thanks, > Matthew. > From stuart.marks at oracle.com Mon Aug 5 20:29:01 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 05 Aug 2013 13:29:01 -0700 Subject: Code review request, 7127524 P11TlsPrfGenerator has anonymous inner class with serialVersionUID In-Reply-To: <51FFCFEF.5010102@oracle.com> References: <51FA646A.2000807@oracle.com> <51FFCFEF.5010102@oracle.com> Message-ID: <52000B0D.4010900@oracle.com> On 8/5/13 9:16 AM, Tom Hawtin wrote: > On 01/08/2013 06:36, Xuelei Fan wrote: >> An anonymous class cannot make any guarantees about serialization >> compatibility since has a compiler-generated, implementation-specific >> name that may vary uncontrollably. It is nonsensical for an anonymous >> class to define a serialVersionUID. > > Although it can't give guarantees about serialisation, that doesn't mean that > it doesn't. We probably don't want to upset anything relying upon it. Having > said that, in this case it doesn't seem to be reasonably accessible. Shame > there isn't a good way of marking a class non-serialisable. The history of this bug is that the only reason that the serialVersionUID was added in the first place was to get rid of a javac serialization "lint" warning. I think javac is overzealous in issuing a warning in cases such as this, and I've filed a bug on this. [1] Good point about there not being a good way to make a class non-serializable. s'marks [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7152104 From mhall at mhcomputing.net Mon Aug 5 20:34:28 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Mon, 5 Aug 2013 13:34:28 -0700 Subject: IOE causes failure in com.sun.deploy.security.RevocationChecker.checkOCSP from 7u25 and up In-Reply-To: <52000711.3010903@oracle.com> References: <20130805183357.GA31258@mhcomputing.net> <52000711.3010903@oracle.com> Message-ID: <20130805203428.GB31773@mhcomputing.net> Sean, Thanks for agreeing to assist us. I'm working with my team to acquire the debug log, and some permission from our customer to provide the packet capture we were given, as soon as possible. One thing I didn't explain so well in my email... for us the problem happened when a firewall blocked the OCSP traffic. I suspect this might have caused the PEM / DER decoding logic to raise the IOE. Matthew. On Mon, Aug 05, 2013 at 01:12:01PM -0700, Sean Mullan wrote: > Hi, > > I will need some more information in order to debug this, preferably > the certificate chain - is that something you can email to me? > > Otherwise, you can enable the certpath debugging you mention below > in the Java Contol Panel. Go to the Java tab, and add it to the > Runtime Parameters of the JRE that you are using. Then email me the > log file if possible. > > -Djava.security.debug=certpath > > Thanks, > Sean > > On 08/05/2013 11:33 AM, Matthew Hall wrote: > >We have a customer that is seeing the following exception in JDK7u25 after > >revocation checking was enabled by default: > > > >java.security.cert.CertificateException: > >java.security.cert.CertPathValidatorException: java.io.IOException: > >DerInputStream.getLength(): lengthTag=127, too big. > > at com.sun.deploy.security.RevocationChecker.checkOCSP(Unknown Source) > > at com.sun.deploy.security.RevocationChecker.check(Unknown Source) > > at com.sun.deploy.security.TrustDecider.checkRevocationStatus(Unknown Source) > > at com.sun.deploy.security.TrustDecider.getValidationState(Unknown Source) > > at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source) > >Caused by: java.security.cert.CertPathValidatorException: java.io.IOException: > >DerInputStream.getLength(): lengthTag=127, too big. > > at sun.security.provider.certpath.OCSP.check(Unknown Source) > > at sun.security.provider.certpath.OCSP.check(Unknown Source) > > at sun.security.provider.certpath.OCSP.check(Unknown Source) > > ... 35 more > >Caused by: java.io.IOException: DerInputStream.getLength(): lengthTag=127, too big. > > at sun.security.util.DerInputStream.getLength(Unknown Source) > > at sun.security.util.DerValue.init(Unknown Source) > > at sun.security.util.DerValue.(Unknown Source) > > at sun.security.provider.certpath.OCSPResponse.(Unknown Source) > > ... 38 more > > > >However this com.sun.deploy.* code doesn't seem to be part of OpenJDK or > >IcedTea, so it's not possible for the community to recompile it with symbols, > >debug it, and find the cause. > > > >I did notice, in the code for sun.security.provider.certpath.OCSP.check which > >is available, I could see a way to get some logs from part of this code: > > > >private static final Debug debug = Debug.getInstance("certpath"); > > > >But I haven't had a chance to try that at the customer who found the issue. > > > >I suspect that the code reacts poorly if it sees unexpected characters in > >blocked OCSP sockets, but I can't tell without being able to read checkOCSP to > >see what it's really doing in there. Can anyone take a look? > > > >Thanks, > >Matthew. > > > From sean.mullan at oracle.com Mon Aug 5 23:13:02 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Mon, 05 Aug 2013 16:13:02 -0700 Subject: [8] Request for review: 8022120 : JCK test api/javax_xml/crypto/dsig/TransformService/index_ParamMethods fails Message-ID: <5200317E.7050106@oracle.com> Hello, Could you please review my fix for 8022120: webrev: http://cr.openjdk.java.net/~mullan/webrevs/8022120/webrev.00/ bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022120 This is a JCK failure/regression caused by the fix for 8011547. The TransformService API specifies that a NullPointerException should be thrown if the parent parameter passed to the init or marshalParams method is null. Thanks, Sean From xuelei.fan at oracle.com Tue Aug 6 00:37:01 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 06 Aug 2013 08:37:01 +0800 Subject: [8] Request for review: 8022120 : JCK test api/javax_xml/crypto/dsig/TransformService/index_ParamMethods fails In-Reply-To: <5200317E.7050106@oracle.com> References: <5200317E.7050106@oracle.com> Message-ID: <5200452D.5090107@oracle.com> Looks fine to me. Xuelei On 8/6/2013 7:13 AM, Sean Mullan wrote: > Hello, > > Could you please review my fix for 8022120: > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8022120/webrev.00/ > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8022120 > > This is a JCK failure/regression caused by the fix for 8011547. The > TransformService API specifies that a NullPointerException should be > thrown if the parent parameter passed to the init or marshalParams > method is null. > > Thanks, > Sean From xuelei.fan at oracle.com Tue Aug 6 01:53:49 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 06 Aug 2013 09:53:49 +0800 Subject: There should be a way to reorder the JSSE ciphers Message-ID: <5200572D.7050602@oracle.com> Hi, We are thinking about to support cipher suites preference in JSSE by defining new methods in javax.net.ssl.SSLParameters. ---------------------------------------------------- + /** + * Sets whether the cipher suites preference should be honored. + * + * @param on whether local cipher suites order in + * {@code #getCipherSuites} + * should be honored during SSL/TLS handshaking. + */ + public final void setUseCipherSuitesOrder(boolean on); + /** + * Returns whether the cipher suites preference should be honored. + * + * @return whether local cipher suites order in + {@code #getCipherSuites} + * should be honored during SSL/TLS handshaking. + */ + public final boolean getUseCipherSuitesOrder(); ---------------------------------------------------- By default, Oracle JSSE provider still honors the client's preference. The behavior can be changed by calling SSLParameters.setUseCipherSuitesOrder(true) in server side. We have had the cipher suites preference ordering in client side for many years, but we never said how to actually do it in specification and JSSE Reference Guide. With this update, the client side can enforce to honor cipher suite preference with the new method, SSLParameters.setUseCipherSuitesOrder(true). Other providers should also comply with this specification. Any feedback are welcome. Thanks, Xuelei From stuart.marks at oracle.com Tue Aug 6 02:08:25 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 06 Aug 2013 02:08:25 +0000 Subject: hg: jdk8/tl/jdk: 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address Message-ID: <20130806020849.73652485F5@hg.openjdk.java.net> Changeset: 31759750ff63 Author: smarks Date: 2013-08-05 19:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31759750ff63 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address Reviewed-by: rgallard, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java From bernd-2013 at eckenfels.net Tue Aug 6 02:41:11 2013 From: bernd-2013 at eckenfels.net (Bernd Eckenfels) Date: Tue, 06 Aug 2013 04:41:11 +0200 Subject: hg: jdk8/tl/jdk: 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address In-Reply-To: <20130806020849.73652485F5@hg.openjdk.java.net> References: <20130806020849.73652485F5@hg.openjdk.java.net> Message-ID: Hello, > ! src/share/classes/java/rmi/server/RMISocketFactory.java I think setting the rmi server name to localhost is a dangerous recommendation. It might happen that it resolves to a IPv4 or IPv6 only address on a dual socket host. And InetAddress.getLoopbackAddress() might pick the preferred family different from that. So it is better to use the literal returned by that function. (or remove this from javadoc). Bernd From xuelei.fan at oracle.com Tue Aug 6 02:54:43 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 06 Aug 2013 10:54:43 +0800 Subject: Code review request, 8013809 deadlock in SSLSocketImpl between between write and close In-Reply-To: <51FB0792.8080705@oracle.com> References: <51F0EBC2.3050908@Oracle.COM> <51FB012D.3060101@oracle.com> <51FB0792.8080705@oracle.com> Message-ID: <52006573.3060408@oracle.com> If no objections, I will push the changeset, and request to back the fix. Thanks, Xuelei On 8/2/2013 9:12 AM, Xuelei Fan wrote: > On 8/2/2013 8:45 AM, Brad Wetmore wrote: >> >> >> On 7/25/2013 2:11 AM, Xuelei Fan wrote: >>> Hi Brad, >>> >>> Are you available to review this fix? >>> >>> Webrev: http://cr.openjdk.java.net/~xuelei/8013809/webrev.00/ >>> >>> No new regression test, hard to reproduce the issue. >> >> Your immediate fix looks good, however, IIRC, the reason for having >> getConnectionState() was to provide synchronized access (and syncing on >> the SSLSocketImpl object) to the connectionState variable before the >> Java "volatile" semantics were cleaned up in JDK 1.5. >> > I think there is a lot of different of a "volatile" object and a > synchronized block. A volatile object is to make sure the change and > access of the object is synchronized; but synchronized block also make > sure that the full process of the change is synchronized. For example: > > synchronized (aLock) { > // We want to change the object, but may need > // to prepare something before the change, please > // don't access this object while we make the preparation. > > ... // prepare something else. > > aObject = newvalue; > } > >> Now that you've made this change, does it make sense to get rid of >> getConnectionState(). What do you think? >> > I was hesitated to remove the getConnectionState(). When we change the > value of connectionState, "this" object is locked. If the value change > does not completed, other thread cannot access the state. If we remove > this synchronization, the behavior would be changed significantly. > > The reason that we can make the change in isClosed() implementation is > that "APP_CLOSED" is the final state of the life-cycle of connection, > therefore we don't care too much whether there is another thread is > doing the closing or not. It looks like a little tricky. > > Xuelei > >> I hate race conditions! ;) >> >> Brad >> >> > From xuelei.fan at oracle.com Tue Aug 6 08:57:01 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 06 Aug 2013 16:57:01 +0800 Subject: [8] Request for review: 8016848: javax_security/auth/login tests fail in compact 1 and 2 profiles In-Reply-To: <51FA9166.7010809@oracle.com> References: <51FA9166.7010809@oracle.com> Message-ID: <5200BA5D.4010606@oracle.com> The fix looks fine. BTW, I think the relationship between javax.security.auth.login.Configuration and javax.security.auth.login.ConfigurationSpi is not that instinctive in the implementation. For example, the impl of Configuration.getAppConfigurationEntry() should be able to use the impl of ConfigurationSpi.engineGetAppConfigurationEntry(). And the provider should only need to extend ConfigurationSpi rather than the Configuration class. It would be nice to re-factoring the code if no other concerns. Xuelei On 8/2/2013 12:48 AM, Sean Mullan wrote: > Hello, > > Could you please review my fix for 8016848: > > webrev: http://cr.openjdk.java.net/~mullan/webrevs/8016848/webrev.00/ > > bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8016848 > > This is a bug because > javax.security.auth.login.Configuration.getConfiguration() throws a > ClassCastException when run with the compact1 or compact2 profiles. > > This is because the default Configuration object that is returned is not > in the compact1 profile. The default Configuration is specified by the > "login.configuration.provider" security property (in the Java security > properties file). This property is currently set to > com.sun.security.auth.login.ConfigFile which is not in the compact1 or > compact2 profiles > > The fix is to change the default value of the > "login.configuration.provider" security property to > sun.security.provider.ConfigFile, which will be a new class that is > essentially a copy of com.sun.security.auth.login.ConfigFile. However, > because it is in the sun.security.provider package, it will be in all > profiles. We will not remove the com.sun.security.auth.login.ConfigFile > class as there may be some applications directly using it. > > noreg-jck as there is an existing JCK test for this. > > Thanks, > Sean From sundararajan.athijegannathan at oracle.com Tue Aug 6 09:03:35 2013 From: sundararajan.athijegannathan at oracle.com (sundararajan.athijegannathan at oracle.com) Date: Tue, 06 Aug 2013 09:03:35 +0000 Subject: hg: jdk8/tl/nashorn: 2 new changesets Message-ID: <20130806090338.AC2B7485FB@hg.openjdk.java.net> Changeset: 0ad00ae4fec6 Author: hannesw Date: 2013-08-01 12:23 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/0ad00ae4fec6 8020132: Big object literal with numerical keys exceeds method size Reviewed-by: lagergren, sundar ! src/jdk/nashorn/internal/codegen/CodeGenerator.java ! src/jdk/nashorn/internal/codegen/FieldObjectCreator.java ! src/jdk/nashorn/internal/codegen/MapCreator.java ! src/jdk/nashorn/internal/codegen/SpillObjectCreator.java ! src/jdk/nashorn/internal/objects/ArrayBufferView.java ! src/jdk/nashorn/internal/runtime/NashornLoader.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIndex.java ! src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/DeletedRangeArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/FrozenArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/IntArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/LongArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NoTypeArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/NumberArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ObjectArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java ! src/jdk/nashorn/internal/runtime/arrays/SealedArrayFilter.java ! src/jdk/nashorn/internal/runtime/arrays/SparseArrayData.java ! src/jdk/nashorn/internal/runtime/arrays/UndefinedArrayFilter.java + test/script/basic/JDK-8020132.js + test/script/basic/JDK-8020132.js.EXPECTED Changeset: bb0f3c896cb7 Author: sundar Date: 2013-08-06 13:10 +0530 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/bb0f3c896cb7 Merge From dmitry.samersoff at oracle.com Tue Aug 6 10:05:31 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Tue, 06 Aug 2013 10:05:31 +0000 Subject: hg: jdk8/tl/jdk: 8011038: sourceObj validation during desereliazation of RelationNotification should be relaxed Message-ID: <20130806100558.D1A33485FD@hg.openjdk.java.net> Changeset: fce446b29577 Author: dsamersoff Date: 2013-08-06 14:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fce446b29577 8011038: sourceObj validation during desereliazation of RelationNotification should be relaxed Summary: sourceObj could be set to null by setSource() relax a validation of deserialized object. Reviewed-by: sjiang, skoivu, dfuchs ! src/share/classes/javax/management/relation/RelationNotification.java From chris.hegarty at oracle.com Tue Aug 6 10:20:26 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 06 Aug 2013 11:20:26 +0100 Subject: Code review request: 8021788: JarInputStream doesn't provide certificates for some file under META-INF In-Reply-To: <51FEFFB1.2040506@oracle.com> References: <51FEFFB1.2040506@oracle.com> Message-ID: <5200CDEA.2010200@oracle.com> This looks ok to me Max, but I think it would be good to get a second review on this too. -Chris. On 05/08/2013 02:28, Weijun Wang wrote: > Please take a look at > > http://cr.openjdk.java.net/~weijun/8021788/webrev.00/ > > The problem is that the method treats no META-INF entry as normal. If we > can be sure that MANIFEST.MF and signature-related files are always at > the beginning, we can safely treat an entry normal when we have done > with those. > > Thanks > Max From xuelei.fan at oracle.com Tue Aug 6 11:44:57 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 06 Aug 2013 19:44:57 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot Message-ID: <5200E1B9.7070002@oracle.com> Hi, Please review the bug fix to strict the illegal input checking in IDN. webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ Here is two test cases, which are expected to get IAE. Case 1: String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.StringBuffer.charAt(StringBuffer.java:204) at java.net.IDN.toASCIIInternal(IDN.java:279) at java.net.IDN.toASCII(IDN.java:118) Case 2: String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); Thanks, Xuelei From vicente.romero at oracle.com Tue Aug 6 14:18:15 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 06 Aug 2013 14:18:15 +0000 Subject: hg: jdk8/tl/langtools: 8022186: javac generates dead code if a try with an empty body has a finalizer Message-ID: <20130806141821.C84924860B@hg.openjdk.java.net> Changeset: 99b60bcf3862 Author: vromero Date: 2013-08-06 15:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/99b60bcf3862 8022186: javac generates dead code if a try with an empty body has a finalizer Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T8022186/DeadCodeGeneratedForEmptyTryTest.java From chris.hegarty at oracle.com Tue Aug 6 14:35:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 06 Aug 2013 14:35:49 +0000 Subject: hg: jdk8/tl/jdk: 8022344: Additional debug info for test/java/net/NetworkInterface/IndexTest.java Message-ID: <20130806143616.38D8B4860E@hg.openjdk.java.net> Changeset: 6773af0dda02 Author: chegar Date: 2013-08-06 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6773af0dda02 8022344: Additional debug info for test/java/net/NetworkInterface/IndexTest.java Reviewed-by: michaelm, alanb ! test/java/net/NetworkInterface/IndexTest.java From weijun.wang at oracle.com Tue Aug 6 15:08:33 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 06 Aug 2013 23:08:33 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5200E1B9.7070002@oracle.com> References: <5200E1B9.7070002@oracle.com> Message-ID: <52011171.7090808@oracle.com> I am not sure if IDN.java is the correct place to change. At least I've seen trailing dots in DNS entries. So maybe it's not so illegal. --Max On 8/6/13 7:44 PM, Xuelei Fan wrote: > Hi, > > Please review the bug fix to strict the illegal input checking in IDN. > > webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ > > Here is two test cases, which are expected to get IAE. > > Case 1: > String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); > Exception in thread "main" java.lang.StringIndexOutOfBoundsException: > String index out of range: 0 > at java.lang.StringBuffer.charAt(StringBuffer.java:204) > at java.net.IDN.toASCIIInternal(IDN.java:279) > at java.net.IDN.toASCII(IDN.java:118) > > Case 2: > String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); > > Thanks, > Xuelei > From Xuelei.Fan at Oracle.Com Tue Aug 6 15:25:31 2013 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 6 Aug 2013 23:25:31 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52011171.7090808@oracle.com> References: <5200E1B9.7070002@oracle.com> <52011171.7090808@oracle.com> Message-ID: On Aug 6, 2013, at 23:08, Weijun Wang wrote: > I am not sure if IDN.java is the correct place to change. At least I've seen trailing dots in DNS entries. So maybe it's not so illegal. > Per RFC 1034, a domain name cannot end with dot. I will check other related specifications. What's the case you saw with trailing dots? Thanks, Xuelei > --Max > > On 8/6/13 7:44 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the bug fix to strict the illegal input checking in IDN. >> >> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >> >> Here is two test cases, which are expected to get IAE. >> >> Case 1: >> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >> String index out of range: 0 >> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >> at java.net.IDN.toASCIIInternal(IDN.java:279) >> at java.net.IDN.toASCII(IDN.java:118) >> >> Case 2: >> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >> >> Thanks, >> Xuelei >> From sean.mullan at oracle.com Tue Aug 6 15:56:29 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 06 Aug 2013 15:56:29 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130806155652.F28CB48610@hg.openjdk.java.net> Changeset: 1f4af3e0447e Author: mullan Date: 2013-08-06 08:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f4af3e0447e 8022120: JCK test api/javax_xml/crypto/dsig/TransformService/index_ParamMethods fails Summary: TransformService.init and marshalParams must throw NullPointerException when parent parameter is null Reviewed-by: xuelei ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java + test/javax/xml/crypto/dsig/TransformService/NullParent.java Changeset: ba634b53f53a Author: mullan Date: 2013-08-06 08:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba634b53f53a Merge From mhall at mhcomputing.net Tue Aug 6 16:06:16 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 06 Aug 2013 09:06:16 -0700 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52011171.7090808@oracle.com> References: <5200E1B9.7070002@oracle.com> <52011171.7090808@oracle.com> Message-ID: <056269b4-7ea6-4077-a189-ce40ce332dfb@email.android.com> Trailing dots are allowed in plain DNS (thus almost surely in IDN), and the single dot represents the root zone. So you have to be careful making this sort of change to check the DNS RFCs first. Matthew. -- Sent from my mobile device. Weijun Wang wrote: >I am not sure if IDN.java is the correct place to change. At least I've > >seen trailing dots in DNS entries. So maybe it's not so illegal. > >--Max > >On 8/6/13 7:44 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the bug fix to strict the illegal input checking in >IDN. >> >> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >> >> Here is two test cases, which are expected to get IAE. >> >> Case 1: >> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >> String index out of range: 0 >> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >> at java.net.IDN.toASCIIInternal(IDN.java:279) >> at java.net.IDN.toASCII(IDN.java:118) >> >> Case 2: >> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >> >> Thanks, >> Xuelei >> From mhall at mhcomputing.net Tue Aug 6 16:09:07 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 06 Aug 2013 09:09:07 -0700 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <056269b4-7ea6-4077-a189-ce40ce332dfb@email.android.com> References: <5200E1B9.7070002@oracle.com> <52011171.7090808@oracle.com> <056269b4-7ea6-4077-a189-ce40ce332dfb@email.android.com> Message-ID: <7ea06d02-2224-44fb-af21-dc3af48fb603@email.android.com> Take a look here for more clarity: http://en.wikipedia.org/wiki/Fully_qualified_domain_name -- Sent from my mobile device. Matthew Hall wrote: >Trailing dots are allowed in plain DNS (thus almost surely in IDN), and >the single dot represents the root zone. So you have to be careful >making this sort of change to check the DNS RFCs first. > >Matthew. From dmitry.samersoff at oracle.com Tue Aug 6 16:43:15 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 06 Aug 2013 20:43:15 +0400 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5200E1B9.7070002@oracle.com> References: <5200E1B9.7070002@oracle.com> Message-ID: <520127A3.3060405@oracle.com> Xuelei, . (dot) is perfectly valid domain name and it means root domain so com. is valid domain name as well. It thinks to me that in context of methods your change we should ignore trailing dots, rather than throw exception. -Dmitry On 2013-08-06 15:44, Xuelei Fan wrote: > Hi, > > Please review the bug fix to strict the illegal input checking in IDN. > > webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ > > Here is two test cases, which are expected to get IAE. > > Case 1: > String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); > Exception in thread "main" java.lang.StringIndexOutOfBoundsException: > String index out of range: 0 > at java.lang.StringBuffer.charAt(StringBuffer.java:204) > at java.net.IDN.toASCIIInternal(IDN.java:279) > at java.net.IDN.toASCII(IDN.java:118) > > Case 2: > String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); > > Thanks, > Xuelei > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From sean.mullan at oracle.com Tue Aug 6 17:21:37 2013 From: sean.mullan at oracle.com (Sean Mullan) Date: Tue, 06 Aug 2013 10:21:37 -0700 Subject: There should be a way to reorder the JSSE ciphers In-Reply-To: <5200572D.7050602@oracle.com> References: <5200572D.7050602@oracle.com> Message-ID: <520130A1.8020605@oracle.com> It might be useful to add a more general method to set boolean options like this. For example: public final void setOptions(Set