From joe.darcy at oracle.com Tue Feb 1 03:07:21 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 01 Feb 2011 03:07:21 +0000 Subject: hg: jdk7/tl/langtools: 7014734: Project Coin: Allow optional trailing semicolon to terminate resources list in try-with-resources Message-ID: <20110201030726.335F9472E8@hg.openjdk.java.net> Changeset: 2ab47c4cd618 Author: darcy Date: 2011-01-31 19:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2ab47c4cd618 7014734: Project Coin: Allow optional trailing semicolon to terminate resources list in try-with-resources Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/TryWithResources/BadTwrSyntax.java ! test/tools/javac/TryWithResources/BadTwrSyntax.out - test/tools/javac/diags/examples/TryResourceTrailingSemi.java From joe.darcy at oracle.com Tue Feb 1 08:29:44 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 01 Feb 2011 08:29:44 +0000 Subject: hg: jdk7/tl/jdk: 7015827: Fix HTML validation issues in java.math package Message-ID: <20110201082958.24FA5472F6@hg.openjdk.java.net> Changeset: f110edeb4428 Author: darcy Date: 2011-02-01 00:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f110edeb4428 7015827: Fix HTML validation issues in java.math package Reviewed-by: mduigou ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/RoundingMode.java From xuelei.fan at oracle.com Tue Feb 1 12:46:21 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 01 Feb 2011 12:46:21 +0000 Subject: hg: jdk7/tl/jdk: 7011497: new CertPathValidatorException.BasicReason enum constant for constrained algorithm Message-ID: <20110201124641.2C24047301@hg.openjdk.java.net> Changeset: d4bc38aa7594 Author: xuelei Date: 2011-02-01 04:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d4bc38aa7594 7011497: new CertPathValidatorException.BasicReason enum constant for constrained algorithm Summary: add new BasicReason and improve trust anchor searching method during cert path validation Reviewed-by: mullan ! src/share/classes/java/security/cert/CertPathValidatorException.java + src/share/classes/sun/security/provider/certpath/AdaptableX509CertSelector.java ! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java ! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java ! src/share/classes/sun/security/provider/certpath/ForwardBuilder.java ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java ! src/share/classes/sun/security/validator/SimpleValidator.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorEndEntity.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorIntermediate.java ! test/sun/security/provider/certpath/DisabledAlgorithms/CPValidatorTrustAnchor.java From sundararajan.a at sun.com Tue Feb 1 15:31:45 2011 From: sundararajan.a at sun.com (sundararajan.a at sun.com) Date: Tue, 01 Feb 2011 15:31:45 +0000 Subject: hg: jdk7/tl/jdk: 7015908: 3 javax.script tests fail with openjdk build Message-ID: <20110201153203.DDD2847309@hg.openjdk.java.net> Changeset: 21d7cd823247 Author: sundar Date: 2011-02-01 21:00 +0530 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/21d7cd823247 7015908: 3 javax.script tests fail with openjdk build Reviewed-by: alanb ! test/javax/script/CauseExceptionTest.java ! test/javax/script/StringWriterPrintTest.java ! test/javax/script/UnescapedBracketRegExTest.java From joe.darcy at oracle.com Tue Feb 1 18:11:28 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 01 Feb 2011 18:11:28 +0000 Subject: hg: jdk7/tl/langtools: 6961571: Update visitors to support ARM's ElementKind.RESOURCE_VARIABLE Message-ID: <20110201181131.9D3E547311@hg.openjdk.java.net> Changeset: cad51b6eb7a6 Author: darcy Date: 2011-02-01 10:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/cad51b6eb7a6 6961571: Update visitors to support ARM's ElementKind.RESOURCE_VARIABLE Reviewed-by: jjg + src/share/classes/javax/lang/model/type/DisjunctiveType.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/AbstractTypeVisitor7.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/ElementScanner6.java ! src/share/classes/javax/lang/model/util/ElementScanner7.java ! src/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor7.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/SimpleTypeVisitor6.java ! src/share/classes/javax/lang/model/util/SimpleTypeVisitor7.java ! src/share/classes/javax/lang/model/util/TypeKindVisitor7.java ! src/share/classes/javax/lang/model/util/Types.java ! test/tools/javac/processing/model/element/TestResourceVariable.java From xueming.shen at oracle.com Tue Feb 1 22:21:43 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 01 Feb 2011 22:21:43 +0000 Subject: hg: jdk7/tl/jdk: 7015391: (zipfs) Update zip provider for 1/2011 changes; ... Message-ID: <20110201222159.A22E847322@hg.openjdk.java.net> Changeset: 312dc0abb960 Author: sherman Date: 2011-02-01 14:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/312dc0abb960 7015391: (zipfs) Update zip provider for 1/2011 changes 7014948: (zipfs) ZipFileSystem.newFileSystem(Path...) should not throw FileSystemAlreadyExistsException 7015139: (zipfs) ZipPath.delete() should throw DirectoryNotEmptyException when handling "real, non-empty" dir Summary: zip filesystem provider update Reviewed-by: alanb ! make/mkdemo/Makefile ! src/share/demo/nio/zipfs/Demo.java ! src/share/demo/nio/zipfs/README.txt ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileAttributeView.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileStore.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java - src/share/demo/zipfs ! test/demo/zipfs/Basic.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh From dmytro_sheyko at hotmail.com Wed Feb 2 09:34:48 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Wed, 2 Feb 2011 16:34:48 +0700 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: References: Message-ID: Hi, Any updates on it? I don't want to be overly importunate, but the quite trivial fix was available year ago. Maybe I do something wrong, so please suggest what I should do to have this bug fixed. Thanks, Dmytro From: dmytro_sheyko at hotmail.com To: serviceability-dev at openjdk.java.net Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value Date: Fri, 28 Jan 2011 15:05:45 +0700 Hi, I would like to find sponsor and discuss fix for bug#6853676 OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 The idea is to use GlobalMemoryStatusEx instead of GlobalMemoryStatus. patch is available here: https://bugs.openjdk.java.net/show_bug.cgi?id=100077 Thanks, Dmytro -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Holmes at oracle.com Wed Feb 2 09:47:07 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 02 Feb 2011 19:47:07 +1000 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: References: Message-ID: <4D49281B.3020809@oracle.com> Dmytro, It looks like this was actually fixed under 6840305 back in July 2009: http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 This CR was not updated however. Does the problem still exist? David Holmes Dmytro Sheyko said the following on 02/02/11 19:34: > Hi, > > Any updates on it? > > I don't want to be overly importunate, but the quite trivial fix was > available year ago. > Maybe I do something wrong, so please suggest what I should do to have > this bug fixed. > > Thanks, > Dmytro > > ------------------------------------------------------------------------ > From: dmytro_sheyko at hotmail.com > To: serviceability-dev at openjdk.java.net > Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has > incorrect value > Date: Fri, 28 Jan 2011 15:05:45 +0700 > > Hi, > > I would like to find sponsor and discuss fix for bug#6853676 > OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6853676 > > The idea is to use GlobalMemoryStatusEx instead of GlobalMemoryStatus. > > patch is available here: > https://bugs.openjdk.java.net/show_bug.cgi?id=100077 > > Thanks, > Dmytro > From Alan.Bateman at oracle.com Wed Feb 2 10:05:34 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Feb 2011 10:05:34 +0000 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: <4D49281B.3020809@oracle.com> References: <4D49281B.3020809@oracle.com> Message-ID: <4D492C6E.4060308@oracle.com> David Holmes wrote: > Dmytro, > > It looks like this was actually fixed under 6840305 back in July 2009: > > http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 > > This CR was not updated however. > > Does the problem still exist? > > David Holmes I think this is separate and 6853676 is about com.sun.management.OperatingSystemMXBean. The code for that is in jdk repo in src/windows/native/com/sun/management. It should be using GlobalMemoryStatusEx rather than GlobalMemoryStatus. Dmytro - to your question, serviceability-dev is the right place to bring it. -Alan From David.Holmes at oracle.com Wed Feb 2 10:09:59 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 02 Feb 2011 20:09:59 +1000 Subject: 6853676: OperatingSystemMXBean.TotalPhysicalMemorySize has incorrect value In-Reply-To: <4D492C6E.4060308@oracle.com> References: <4D49281B.3020809@oracle.com> <4D492C6E.4060308@oracle.com> Message-ID: <4D492D77.5070209@oracle.com> Alan Bateman said the following on 02/02/11 20:05: > David Holmes wrote: >> It looks like this was actually fixed under 6840305 back in July 2009: >> >> http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/8c79517a9300 >> >> This CR was not updated however. >> >> Does the problem still exist? >> >> David Holmes > I think this is separate and 6853676 is about > com.sun.management.OperatingSystemMXBean. The code for that is in jdk > repo in src/windows/native/com/sun/management. It should be using > GlobalMemoryStatusEx rather than GlobalMemoryStatus. Thanks Alan, the comments in 6853676 led me astray. As a P4 it looks like this has just slipped through the cracks. David > Dmytro - to your question, serviceability-dev is the right place to > bring it. > > -Alan From aph at redhat.com Wed Feb 2 16:16:38 2011 From: aph at redhat.com (Andrew Haley) Date: Wed, 02 Feb 2011 16:16:38 +0000 Subject: Fix for JDK Double.parseDouble infinite loop Message-ID: <4D498366.6050805@redhat.com> The post on http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ describes a (on first sight) trivial bug when parsing strings into Java Double objects. Runtime (java app hang): class runhang { public static void main(String[] args) { System.out.println("Test:"); double d = Double.parseDouble("2.2250738585072012e-308"); System.out.println("Value: " + d); } } DevTime (javac hang): class compilehang { public static void main(String[] args) { double d = 2.2250738585072012e-308; System.out.println("Value: " + d); } } The problem is that the estimation of halfUlp is too small in the case where the larger alternative is normal and the smaller is denormal. In this case, the first estimate for 2.22507385850720120e-308 is 2.225073858507200889...e-308, an error of -3.109754e-324 and the second is 2.225073858507201383...e-308, an error of 1.830902e-324 so the second should be chosen. Unfortunately, in the second case the calculated halfUlp is 2^-1076, which is wrong because the next lower number will be denormal. Because denormals don't have the implied 1 bit, they are less accurate than normals, so the next lower number will have the same precision as this number, not twice the precision. Therefore, the estimated halfUlp is too large: it must be 2^-1075. So, I think this may be the correct fix: --- /local/openjdk/jdk6/jdk/src/share/classes/sun/misc/FloatingDecimal.java 2011-02-01 15:28:10.550913741 +0000 +++ /local/icedtea6/openjdk/jdk/src/share/classes/sun/misc/FloatingDecimal.java2011-02-02 12:07:22.292913754 +0000 @@ -1549,7 +1548,7 @@ if ( (cmpResult = bigB.cmp( bigD ) ) > 0 ){ overvalue = true; // our candidate is too big. diff = bigB.sub( bigD ); - if ( (bigIntNBits == 1) && (bigIntExp > -expBias) ){ + if ( (bigIntNBits == 1) && (bigIntExp-1 > -expBias) ){ // candidate is a normalized exact power of 2 and // is too big. We will be subtracting. // For our purposes, ulp is the ulp of the Andrew. From brian.goetz at oracle.com Wed Feb 2 18:48:04 2011 From: brian.goetz at oracle.com (brian.goetz at oracle.com) Date: Wed, 02 Feb 2011 18:48:04 +0000 Subject: hg: jdk7/tl/jdk: 7012540: java.util.Objects.nonNull() incorrectly named Message-ID: <20110202184820.B39CD4735C@hg.openjdk.java.net> Changeset: 25462d7eee24 Author: briangoetz Date: 2011-02-02 13:13 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/25462d7eee24 7012540: java.util.Objects.nonNull() incorrectly named Reviewed-by: darcy, weijun ! src/share/classes/java/io/PrintStream.java ! src/share/classes/java/io/PrintWriter.java ! src/share/classes/java/lang/StackTraceElement.java ! src/share/classes/java/nio/file/DirectoryIteratorException.java ! src/share/classes/java/nio/file/FileTreeWalker.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/java/nio/file/SimpleFileVisitor.java ! src/share/classes/java/util/Formatter.java ! src/share/classes/java/util/Objects.java ! src/share/classes/java/util/Scanner.java ! src/share/classes/sun/security/krb5/KrbAsRep.java ! test/java/util/Objects/BasicObjectsTest.java From Alan.Bateman at oracle.com Wed Feb 2 20:02:09 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 02 Feb 2011 20:02:09 +0000 Subject: Fix for JDK Double.parseDouble infinite loop In-Reply-To: <4D498366.6050805@redhat.com> References: <4D498366.6050805@redhat.com> Message-ID: <4D49B841.80101@oracle.com> Andrew Haley wrote: > The post on > http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ > > > describes a (on first sight) trivial bug when parsing strings into > Java Double objects. Thanks for the analysis and patch. We also have a fix from Dmitry Nadezhin that he posted here some time ago (but fell through the cracks for some reason). I expect this issue will be fixed soon. -Alan From mark at klomp.org Wed Feb 2 20:30:40 2011 From: mark at klomp.org (Mark Wielaard) Date: Wed, 02 Feb 2011 21:30:40 +0100 Subject: Fix for JDK Double.parseDouble infinite loop In-Reply-To: <4D49B841.80101@oracle.com> References: <4D498366.6050805@redhat.com> <4D49B841.80101@oracle.com> Message-ID: <1296678640.30817.65.camel@springer.wildebeest.org> On Wed, 2011-02-02 at 20:02 +0000, Alan Bateman wrote: > Andrew Haley wrote: > > The post on > > http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ > > > > describes a (on first sight) trivial bug when parsing strings into > > Java Double objects. > Thanks for the analysis and patch. We also have a fix from Dmitry > Nadezhin that he posted here some time ago (but fell through the cracks > for some reason). I expect this issue will be fixed soon. Wow, I did some digging to find this. And it was reported back in 2001 (!): http://bugs.sun.com/view_bug.do?bug_id=4421494 There is even a suggested fix in the report. Dmitry Nadezhin posted about it on the list in 2009: http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003153.html If people are looking into floating point issues now, it might be good to also take a look at the other issues he mentioned in 2010 when he proposed a Math subproject for OpenJDK: http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-January/003556.html Cheers, Mark From mike.duigou at oracle.com Wed Feb 2 22:38:11 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Wed, 2 Feb 2011 14:38:11 -0800 Subject: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient In-Reply-To: References: Message-ID: <175B5A20-658C-47EE-AE68-888D5FE23E49@oracle.com> After thinking about it for a few days and talking the issue over with Alan Bateman I suspect that Josh's fix would be rejected by CCC on the same grounds as CR #4902078--a ConcurrentModificationException would be thrown where previously none was thrown. This case is also probably less ambiguous than 4902078 as currently CME is never thrown by EnumSet iterators. Neil's fix though might be acceptable in that improves the behaviour of the class and avoids corruption of the object state which can currently result from concurrent removes(). My preference, given a time machine, would be for consistency with the other iterators which throw CME. Lacking that, I believe that adding CME to EnumSet iterator() will be rejected over compatibility concerns. On Jan 27 2011, at 03:44 , Neil Richards wrote: > On 26 January 2011 01:57, Joshua Bloch wrote: >> I have serious reservations about this. It would be the first time (to my >> knowledge) that we deliberately swept a concurrent modification under the >> rug. If we go to the effort of detecting it (which you're doing), the least >> we should do is to report it. > > I see that the current API Javadoc for EnumSet currently says this > about the behaviour of its iterator: > > " > The iterator returned by the iterator method traverses the elements in > their natural order (the order in which the enum constants are > declared). > The returned iterator is weakly consistent: it will never throw > ConcurrentModificationException and it may or may not show the effects > of any modifications to the set that occur while the iteration is in > progress. > " > > The change I suggest improves the resilience of the behaviour of the > EnumSet implementations within the confines of the behaviour mandated > by the existing API Javadoc. > > The additional modification that you suggest would necessitate a > change in the documented behaviour here, albeit to something more akin > to other Iterator implementations. > > I can see validity in the argument on both sides of this, but, given > the way things are currently documented in the API and the ability > (with the change) for the EnumSet Iterator impls to handle things in > naturally graceful manner (ie. without corrupting the set), I think I > still lean towards abiding by the constraints of the current > documentation and so not throwing a ConcurrentModificationException. > (I could probably be swayed if the consensus lay the other way, however.) > >> There was a much >> more serious case where we failed to throw a CME that we should have thrown, >> and the CCC (an internal review body within Sun, and now Oracle) ruled that >> it represented an unacceptable compatibility violation. >> If we're going to make this change to EnumSet, then we must reopen 4902078 >> and fix that too. > > Thanks for the pointer - it seems to be an interesting problem, and > one which I have not hitherto contemplated or explored. > > Being generally an advocate of the philosophy of "making the word a > better place, fixing one bug at a time", I don't see a solution to > 4902078 as being *inextricably* linked with the one I'm trying to > address in EnumSet here - though they're obviously in the same area of > SDK function. > >> P.S. There is a much more serious problem with EnumMap that we might want >> to fix. > I believe that the problem to which you refer is reported in 6312706, > "(coll) Map entrySet iterators should return different entries on each > call to next()". I have re-opened 6312706 (I closed it) with this clarification and added both of you to the interest list. Mike From gnu_andrew at member.fsf.org Wed Feb 2 22:43:56 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Wed, 2 Feb 2011 22:43:56 +0000 Subject: Fix for JDK Double.parseDouble infinite loop In-Reply-To: <1296678640.30817.65.camel@springer.wildebeest.org> References: <4D498366.6050805@redhat.com> <4D49B841.80101@oracle.com> <1296678640.30817.65.camel@springer.wildebeest.org> Message-ID: On 2 February 2011 20:30, Mark Wielaard wrote: > On Wed, 2011-02-02 at 20:02 +0000, Alan Bateman wrote: >> Andrew Haley wrote: >> > The post on >> > http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ >> > >> > describes a (on first sight) trivial bug when parsing strings into >> > Java Double objects. >> Thanks for the analysis and patch. We also have a fix from Dmitry >> Nadezhin that he posted here some time ago (but fell through the cracks >> for some reason). I expect this issue will be fixed soon. > > Wow, I did some digging to find this. And it was reported back in 2001 > (!): http://bugs.sun.com/view_bug.do?bug_id=4421494 > There is even a suggested fix in the report. > > Dmitry Nadezhin posted about it on the list in 2009: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-November/003153.html > > If people are looking into floating point issues now, it might be good > to also take a look at the other issues he mentioned in 2010 when he > proposed a Math subproject for OpenJDK: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-January/003556.html > > Cheers, > > Mark > > We should look at at least getting these into IcedTea. Sadly, the archiver seems to have scrubbed the patches but I may have them in my inbox somewhere. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From maurizio.cimadamore at oracle.com Thu Feb 3 09:41:02 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Thu, 03 Feb 2011 09:41:02 +0000 Subject: hg: jdk7/tl/langtools: 4 new changesets Message-ID: <20110203094112.5590247384@hg.openjdk.java.net> Changeset: 899f7c3d9426 Author: mcimadamore Date: 2011-02-03 09:35 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/899f7c3d9426 6594914: @SuppressWarnings("deprecation") does not not work for the type of a variable Summary: Lint warnings generated during MemberEnter might ignore @SuppressWarnings annotations Reviewed-by: jjg + src/share/classes/com/sun/tools/javac/code/DeferredLintHandler.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/MemberEnter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java + test/tools/javac/warnings/6594914/DeprecatedClass.java + test/tools/javac/warnings/6594914/T6594914a.java + test/tools/javac/warnings/6594914/T6594914a.out + test/tools/javac/warnings/6594914/T6594914b.java + test/tools/javac/warnings/6594914/T6594914b.out Changeset: 875262e89b52 Author: mcimadamore Date: 2011-02-03 09:36 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/875262e89b52 5017953: spurious cascaded diagnostics when name not found Summary: when an operator is applied to one or more erroneous operands, spurious diagnostics are generated Reviewed-by: jjg ! 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/Resolve.java + test/tools/javac/5017953/T5017953.java + test/tools/javac/5017953/T5017953.out ! test/tools/javac/6491592/T6491592.out Changeset: 03cf47d4de15 Author: mcimadamore Date: 2011-02-03 09:37 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/03cf47d4de15 6969184: poor error recovery after symbol not found Summary: generic type-well formedness check should ignore erroneous symbols Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/6969184/T6969184.java + test/tools/javac/generics/6969184/T6969184.out Changeset: afe226180744 Author: mcimadamore Date: 2011-02-03 09:38 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/afe226180744 7014715: javac returns different error code for certain failure(s) Summary: javac silently crashes when emitting certain kinds of resolution diagnostics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! test/tools/javac/AnonStaticMember_2.java + test/tools/javac/AnonStaticMember_2.out ! test/tools/javac/InterfaceInInner.java + test/tools/javac/InterfaceInInner.out ! test/tools/javac/QualifiedNew.java + test/tools/javac/QualifiedNew.out ! test/tools/javac/T6247324.out ! test/tools/javac/generics/diamond/neg/Neg01.out ! test/tools/javac/generics/inference/6943278/T6943278.out From chris.hegarty at oracle.com Thu Feb 3 10:11:03 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 03 Feb 2011 10:11:03 +0000 Subject: hg: jdk7/tl/jdk: 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache Message-ID: <20110203101125.5662347386@hg.openjdk.java.net> Changeset: 3c86f24f7500 Author: chegar Date: 2011-02-03 10:10 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3c86f24f7500 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache Reviewed-by: michaelm ! src/share/classes/sun/net/www/http/KeepAliveCache.java ! src/share/classes/sun/net/www/http/KeepAliveStream.java From mlists at juma.me.uk Thu Feb 3 10:40:11 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 3 Feb 2011 10:40:11 +0000 (UTC) Subject: Fix for JDK Double.parseDouble infinite loop References: <4D498366.6050805@redhat.com> Message-ID: Andrew Haley writes: > The post on > http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e- 308/ Also see (filed more than a year ago): https://bugs.openjdk.java.net/show_bug.cgi?id=100119 Best, Ismael From mlists at juma.me.uk Thu Feb 3 10:54:29 2011 From: mlists at juma.me.uk (Ismael Juma) Date: Thu, 3 Feb 2011 10:54:29 +0000 (UTC) Subject: Fix for JDK Double.parseDouble infinite loop References: <4D498366.6050805@redhat.com> Message-ID: Ismael Juma writes: > Also see (filed more than a year ago): > > https://bugs.openjdk.java.net/show_bug.cgi?id=100119 Oops, some of the newer messages were not visible on my reader for some reason. Sorry for the noise. Ismael From sean.coffey at oracle.com Thu Feb 3 11:36:15 2011 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Thu, 03 Feb 2011 11:36:15 +0000 Subject: hg: jdk7/tl/jdk: 7016897: Copyright header correction : test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Message-ID: <20110203113633.DBF2A4738C@hg.openjdk.java.net> Changeset: dff9b6d18628 Author: coffeys Date: 2011-02-03 11:28 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dff9b6d18628 7016897: Copyright header correction : test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java Reviewed-by: vinnie ! test/sun/security/provider/SeedGenerator/SeedGeneratorChoice.java From chris.hegarty at oracle.com Thu Feb 3 11:59:17 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 03 Feb 2011 11:59:17 +0000 Subject: hg: jdk7/tl/jdk: 6887710: Jar index should avoid putting META-INF in the INDEX.LIST Message-ID: <20110203115935.0C1C54738E@hg.openjdk.java.net> Changeset: 0f5dc2fc81b1 Author: chegar Date: 2011-02-03 11:56 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f5dc2fc81b1 6887710: Jar index should avoid putting META-INF in the INDEX.LIST Reviewed-by: michaelm ! src/share/classes/sun/misc/JarIndex.java + test/sun/misc/JarIndex/metaInfFilenames/Basic.java + test/sun/misc/JarIndex/metaInfFilenames/jarA/META-INF/services/my.happy.land + test/sun/misc/JarIndex/metaInfFilenames/jarA/a/A.java + test/sun/misc/JarIndex/metaInfFilenames/jarA/com/message/spi/MessageService.java + test/sun/misc/JarIndex/metaInfFilenames/jarB/META-INF/JAVA2.DS + test/sun/misc/JarIndex/metaInfFilenames/jarB/META-INF/services/no.name.service + test/sun/misc/JarIndex/metaInfFilenames/jarB/b/B.java + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts.mf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts/Company-corporate.ttf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/fonts/kidpr.ttf + test/sun/misc/JarIndex/metaInfFilenames/jarC/META-INF/services/com.message.spi.MessageService + test/sun/misc/JarIndex/metaInfFilenames/jarC/my/impl/StandardMessageService.java From sonali.goel at oracle.com Thu Feb 3 12:00:10 2011 From: sonali.goel at oracle.com (sonali.goel at oracle.com) Date: Thu, 3 Feb 2011 04:00:10 -0800 (PST) Subject: Auto Reply: core-libs-dev Digest, Vol 46, Issue 3 Message-ID: <1746c9f4-1635-4aa7-8826-2ae9f4bc1598@default> This is an auto-reply. I am out of office and travelling with limited access to email. Please contact the following: Steve Sides - Rhino and JavaDoc for JDK7 Randy - Sponsor Revamp and JdkTests For urgent matters, please contact Vita.Santrucek at oracle.com From michael.x.mcmahon at oracle.com Thu Feb 3 12:57:47 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 03 Feb 2011 12:57:47 +0000 Subject: hg: jdk7/tl/jdk: 6751021: TEST_BUG: race condition in the test java/lang/Runtime/exec/Duped.java Message-ID: <20110203125756.DAD0747390@hg.openjdk.java.net> Changeset: 68e3eba12afe Author: michaelm Date: 2011-02-03 12:57 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/68e3eba12afe 6751021: TEST_BUG: race condition in the test java/lang/Runtime/exec/Duped.java Reviewed-by: alanb ! test/java/lang/Runtime/exec/Duped.java From alan.bateman at oracle.com Thu Feb 3 13:38:44 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 03 Feb 2011 13:38:44 +0000 Subject: hg: jdk7/tl/jdk: 7014794: (file) lookupPrincipalByGroupName fails to find large NIS groups Message-ID: <20110203133854.C5B2347394@hg.openjdk.java.net> Changeset: e2a182adb30f Author: alanb Date: 2011-02-03 13:37 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e2a182adb30f 7014794: (file) lookupPrincipalByGroupName fails to find large NIS groups Reviewed-by: chegar ! src/solaris/native/sun/nio/fs/UnixNativeDispatcher.c From jason_mehrens at hotmail.com Thu Feb 3 17:56:27 2011 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Thu, 3 Feb 2011 11:56:27 -0600 Subject: hg: jdk7/tl/jdk: 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache In-Reply-To: <20110203101125.5662347386@hg.openjdk.java.net> References: <20110203101125.5662347386@hg.openjdk.java.net> Message-ID: I understand why the previous code leaks but, why is a null value safe to use for the CCL? Is it because this code is part of the JDK (not ext classloader) or is it because no more class loading is done on that thread? For 3rd party libs, should the CCL be set to null or set to the classloader of the thread's target and in the case of thread subclasses the loader of the subclass thread? Thanks, Jason > From: chris.hegarty at oracle.com > To: jdk7-changes at openjdk.java.net; compiler-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; security-dev at openjdk.java.net; net-dev at openjdk.java.net > Subject: hg: jdk7/tl/jdk: 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache > Date: Thu, 3 Feb 2011 10:11:03 +0000 > > Changeset: 3c86f24f7500 > Author: chegar > Date: 2011-02-03 10:10 +0000 > URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3c86f24f7500 > > 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache > Reviewed-by: michaelm > > ! src/share/classes/sun/net/www/http/KeepAliveCache.java > ! src/share/classes/sun/net/www/http/KeepAliveStream.java > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Thu Feb 3 18:32:09 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 03 Feb 2011 18:32:09 +0000 Subject: hg: jdk7/tl/jdk: 7008595: Class loader leak caused by keepAliveTimer thread in KeepAliveCache In-Reply-To: References: <20110203101125.5662347386@hg.openjdk.java.net> Message-ID: <4D4AF4A9.8040500@oracle.com> On 02/ 3/11 05:56 PM, Jason Mehrens wrote: > I understand why the previous code leaks but, why is a null value safe > to use for the CCL? Is it because this code is part of the JDK (not ext > classloader) or is it because no more class loading is done on that These are internal JDK implementation threads that are used to control the lifetime of persistent HTTP connections. The threads will only trigger loading of sun private classes, they will never have to load any application classes, so it is safe to set the CCL to null. > thread? For 3rd party libs, should the CCL be set to null or set to the > classloader of the thread's target and in the case of thread subclasses > the loader of the subclass thread? It depends on the libs, for example java.util.ServiceLoader.load(Class service) is specified to use the current thread's context class loader. It is really up to the implemenation. -Chris. > > Thanks, > > Jason > > > > From: chris.hegarty at oracle.com > > To: jdk7-changes at openjdk.java.net; compiler-dev at openjdk.java.net; > core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; > security-dev at openjdk.java.net; net-dev at openjdk.java.net > > Subject: hg: jdk7/tl/jdk: 7008595: Class loader leak caused by > keepAliveTimer thread in KeepAliveCache > > Date: Thu, 3 Feb 2011 10:11:03 +0000 > > > > Changeset: 3c86f24f7500 > > Author: chegar > > Date: 2011-02-03 10:10 +0000 > > URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3c86f24f7500 > > > > 7008595: Class loader leak caused by keepAliveTimer thread in > KeepAliveCache > > Reviewed-by: michaelm > > > > ! src/share/classes/sun/net/www/http/KeepAliveCache.java > > ! src/share/classes/sun/net/www/http/KeepAliveStream.java > > From vincent.x.ryan at oracle.com Thu Feb 3 19:21:30 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 03 Feb 2011 19:21:30 +0000 Subject: hg: jdk7/tl/jdk: 6997561: A request for better error handling in JNDI Message-ID: <20110203192156.5869C473A3@hg.openjdk.java.net> Changeset: 515512634eb4 Author: vinnie Date: 2011-02-03 19:09 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/515512634eb4 6997561: A request for better error handling in JNDI Reviewed-by: robm ! src/share/classes/com/sun/jndi/toolkit/ctx/Continuation.java + test/com/sun/jndi/ldap/LdapName/EmptyNameSearch.java From xueming.shen at oracle.com Thu Feb 3 21:51:27 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 03 Feb 2011 21:51:27 +0000 Subject: hg: jdk7/tl/jdk: 7014645: Support perl style Unicode hex notation \x{...} Message-ID: <20110203215144.A15F1473B1@hg.openjdk.java.net> Changeset: 035ecca4379c Author: sherman Date: 2011-02-03 13:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/035ecca4379c 7014645: Support perl style Unicode hex notation \x{...} Summary: Added the construct \x{...} for Unicode hex notation support Reviewed-by: alanb, okutsu ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java From kumar.x.srinivasan at oracle.com Thu Feb 3 23:44:53 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 03 Feb 2011 23:44:53 +0000 Subject: hg: jdk7/tl/jdk: 6968053: (launcher) hide exceptions under certain launcher failures Message-ID: <20110203234511.4E38B473BC@hg.openjdk.java.net> Changeset: 3c1eca364cc7 Author: ksrini Date: 2011-02-03 15:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3c1eca364cc7 6968053: (launcher) hide exceptions under certain launcher failures Reviewed-by: mchung ! src/share/bin/java.c ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/misc/VM.java ! test/tools/launcher/Arrrghs.java From vincent.x.ryan at oracle.com Fri Feb 4 00:34:52 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 04 Feb 2011 00:34:52 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110204003523.E094C473BE@hg.openjdk.java.net> Changeset: 1b5c838b8db8 Author: vinnie Date: 2011-02-04 00:33 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1b5c838b8db8 6989705: ECC security code native code compiler warnings Reviewed-by: alanb, ohair ! src/share/native/sun/security/ec/ECC_JNI.cpp ! src/share/native/sun/security/ec/impl/ec.c ! src/share/native/sun/security/ec/impl/ec.h ! src/share/native/sun/security/ec/impl/ec2.h ! src/share/native/sun/security/ec/impl/ec2_163.c ! src/share/native/sun/security/ec/impl/ec2_193.c ! src/share/native/sun/security/ec/impl/ec2_233.c ! src/share/native/sun/security/ec/impl/ec2_aff.c ! src/share/native/sun/security/ec/impl/ec2_mont.c ! src/share/native/sun/security/ec/impl/ec_naf.c ! src/share/native/sun/security/ec/impl/ecc_impl.h ! src/share/native/sun/security/ec/impl/ecdecode.c ! src/share/native/sun/security/ec/impl/ecl-curve.h ! src/share/native/sun/security/ec/impl/ecl-exp.h ! src/share/native/sun/security/ec/impl/ecl-priv.h ! src/share/native/sun/security/ec/impl/ecl.c ! src/share/native/sun/security/ec/impl/ecl.h ! src/share/native/sun/security/ec/impl/ecl_curve.c ! src/share/native/sun/security/ec/impl/ecl_gf.c ! src/share/native/sun/security/ec/impl/ecl_mult.c ! src/share/native/sun/security/ec/impl/ecp.h ! src/share/native/sun/security/ec/impl/ecp_192.c ! src/share/native/sun/security/ec/impl/ecp_224.c ! src/share/native/sun/security/ec/impl/ecp_256.c ! src/share/native/sun/security/ec/impl/ecp_384.c ! src/share/native/sun/security/ec/impl/ecp_521.c ! src/share/native/sun/security/ec/impl/ecp_aff.c ! src/share/native/sun/security/ec/impl/ecp_jac.c ! src/share/native/sun/security/ec/impl/ecp_jm.c ! src/share/native/sun/security/ec/impl/ecp_mont.c ! src/share/native/sun/security/ec/impl/logtab.h ! src/share/native/sun/security/ec/impl/mp_gf2m-priv.h ! src/share/native/sun/security/ec/impl/mp_gf2m.c ! src/share/native/sun/security/ec/impl/mp_gf2m.h ! src/share/native/sun/security/ec/impl/mpi-config.h ! src/share/native/sun/security/ec/impl/mpi-priv.h ! src/share/native/sun/security/ec/impl/mpi.c ! src/share/native/sun/security/ec/impl/mpi.h ! src/share/native/sun/security/ec/impl/mplogic.c ! src/share/native/sun/security/ec/impl/mplogic.h ! src/share/native/sun/security/ec/impl/mpmontg.c ! src/share/native/sun/security/ec/impl/mpprime.h ! src/share/native/sun/security/ec/impl/oid.c ! src/share/native/sun/security/ec/impl/secitem.c ! src/share/native/sun/security/ec/impl/secoidt.h Changeset: fed61c2f4d14 Author: vinnie Date: 2011-02-04 00:33 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fed61c2f4d14 Merge From vincent.x.ryan at oracle.com Fri Feb 4 09:52:52 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Fri, 04 Feb 2011 09:52:52 +0000 Subject: hg: jdk7/tl/jdk: 7017176: Several JNDI tests are mssing GPL header Message-ID: <20110204095309.4145F473F9@hg.openjdk.java.net> Changeset: 78fe1b7a9a1a Author: vinnie Date: 2011-02-04 09:52 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/78fe1b7a9a1a 7017176: Several JNDI tests are mssing GPL header Reviewed-by: alanb ! test/com/sun/jndi/ldap/LdapName/Case.java ! test/com/sun/jndi/ldap/LdapName/EmptyNameSearch.java ! test/com/sun/jndi/ldap/LdapName/UnescapeTest.java ! test/com/sun/jndi/ldap/ReadTimeoutTest.java From lance.andersen at oracle.com Fri Feb 4 14:07:33 2011 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Fri, 04 Feb 2011 14:07:33 +0000 Subject: hg: jdk7/tl/jdk: 7014095: Broken link in java.sql package specification Message-ID: <20110204140756.5260747404@hg.openjdk.java.net> Changeset: 9599534b1727 Author: lancea Date: 2011-02-04 09:07 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9599534b1727 7014095: Broken link in java.sql package specification Reviewed-by: alanb ! src/share/classes/java/sql/package.html From mike.duigou at oracle.com Fri Feb 4 18:48:10 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 4 Feb 2011 10:48:10 -0800 Subject: Dual-Pivot Quicksort improvements for highly structured (nearly sorted) arrays and data with small periods In-Reply-To: References: Message-ID: <89690CEB-6855-4525-8FD8-7E5BD92F8008@oracle.com> This looks like really good work. I have a few comments and questions about this webrev. None of these comments block commit. - The @version tag contains what appears to be a value from a version control system. I thought all of these had been or were being eliminated. - I am curious how the MAX_RUN_COUNT, MAX_RUN_LENGTH and THRESHOLD values are derived. We should provide some back link to how these values were chosen at so that future maintainers can decided when it is appropriate (or not) to change the values. - Are the seven implementations generated from a template or are they hand-coded? I didn't check that there are no unexplained differences between the implementation but am curious if it would be possible that differences could arise or exist. Mike On Jan 20 2011, at 10:09 , Vladimir Iaroslavski wrote: > Hello, > > Here is improvement for sorting primitives: > http://cr.openjdk.java.net/~alanb/7013585/webrev > > Highly structured (nearly sorted) data like > 1,2,3,..,k,1,2,3,..,k,... or > 1,2,3,...,n/2,n/2,...,3,2,1 etc. > is sorted very effectively by merge sort. > > The main idea of this optimization is to check > if given array is nearly sorted and apply modified > and improved merge sort on it. Otherwise, Dual-Pivot > Quicksort is applied. > > Note that the check doesn't decrease the performance of sorting. > > Other optimization is related to random or repeated data > with small period, m <= 10. This type of data is sorted > faster by Quicksort with one pivot but with DNF (Dutch > National Flag) partition. Therefore, sorting is switched > to DNF even calculated pivots are different. > > The boost of performance with new optimizations is: > > random data: new: 135, old: 154, ratio: 87.6% > ascending: new: 3, old: 45, ratio: 6.6% > descending: new: 5, old: 48, ratio: 10.4% > organ pipes: new: 20, old: 80, ratio: 25% > period(m), m <= 10: new: 10, old: 15, ratio: 66.6% > random(m), m <= 10: new: 11, old: 16, ratio: 68.7% > equal: new: 2.5, old: 3, new: 83.3% > > On test suite suggested by Jon Bentley we see > the following performance: > > client VM: old 56%, new 43% > server VM: old 46%, new 29% > > Thank you, > Vladimir From mike.duigou at oracle.com Fri Feb 4 20:59:32 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Fri, 04 Feb 2011 20:59:32 +0000 Subject: hg: jdk7/tl/jdk: 7015783: Update JDK Netbeans projects to -source 1.7 Message-ID: <20110204205949.C7DCD4741C@hg.openjdk.java.net> Changeset: c5f953e920c6 Author: mduigou Date: 2011-02-04 12:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c5f953e920c6 7015783: Update JDK Netbeans projects to -source 1.7 Reviewed-by: darcy ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent From xueming.shen at oracle.com Fri Feb 4 21:19:58 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 04 Feb 2011 21:19:58 +0000 Subject: hg: jdk7/tl/jdk: 7005986: (zipfs) ZipPath.startsWith() fails because of the implementation of getName(index) Message-ID: <20110204212007.D37A74741D@hg.openjdk.java.net> Changeset: b8662dac7c91 Author: sherman Date: 2011-02-04 13:17 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b8662dac7c91 7005986: (zipfs) ZipPath.startsWith() fails because of the implementation of getName(index) Summary: Updated starsWith/endsWith to be consistent with default file system Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipPath.java ! test/demo/zipfs/PathOps.java ! test/demo/zipfs/basic.sh From iaroslavski at mail.ru Fri Feb 4 21:58:25 2011 From: iaroslavski at mail.ru (Vladimir Iaroslavski) Date: Sat, 05 Feb 2011 00:58:25 +0300 Subject: =?koi8-r?Q?Re[2]=3A_Dual-Pivot_Quicksort_improvements_for_highly_structured_(nearly_sorted)_arrays_and_data_with_small_periods?= In-Reply-To: <89690CEB-6855-4525-8FD8-7E5BD92F8008@oracle.com> References: <89690CEB-6855-4525-8FD8-7E5BD92F8008@oracle.com> Message-ID: Hi Mike, Thank you for review! The value of the @version tag is date plus numbers which are not from any version control system. It is just abbreviation for changes and versions from my file tree. For example, "5\7" means improvement of pivot candidates, "p" - pair insertion sort, "m" - using of merge sort. Sometimes I receive feedback or find review of Dual-Pivot Quicksort source in the internet and the version value helps me a lot to recognize which version is used. The @value tag is not shown in javadoc (as well as whole DPQ class), therefore I'd like to keep it. All tuning parameters were empirically determined. The best way to find optimal value is to run series of tests and compare sorting with different values. This series was done by me recently and INSERTION_SORT_THRESHOLD was increased. I think it makes sense to run check in each release. No templates: I take int method and adjust it for other types, but double/float methods are little bit different from int/long/short/char/byte, see comment in new version, lines 440-448 and 507-514. Note that Quicksort is not used in byte method at all, counting and insertion sort are used only. Methods for short/char use counting sort also. When I prepare final version of the class, I double check all methods. Thank you, Vladimir Fri, 4 Feb 2011 10:48:10 -0800 ?????? ?? Mike Duigou : > This looks like really good work. I have a few comments and questions about > this webrev. None of these comments block commit. > > - The @version tag contains what appears to be a value from a version control > system. I thought all of these had been or were being eliminated. > > - I am curious how the MAX_RUN_COUNT, MAX_RUN_LENGTH and THRESHOLD values are > derived. We should provide some back link to how these values were chosen at > so that future maintainers can decided when it is appropriate (or not) to > change the values. > > - Are the seven implementations generated from a template or are they > hand-coded? I didn't check that there are no unexplained differences between > the implementation but am curious if it would be possible that differences > could arise or exist. > > Mike > > On Jan 20 2011, at 10:09 , Vladimir Iaroslavski wrote: > > > Here is improvement for sorting primitives: > > http://cr.openjdk.java.net/~alanb/7013585/webrev > > ... From lana.steuck at oracle.com Sat Feb 5 05:23:23 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Feb 2011 05:23:23 +0000 Subject: hg: jdk7/tl: 12 new changesets Message-ID: <20110205052324.21C634743C@hg.openjdk.java.net> Changeset: bd70f76b0309 Author: cl Date: 2011-01-20 15:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/bd70f76b0309 Added tag jdk7-b126 for changeset b566d4909056 ! .hgtags Changeset: 6e0f4d6099bb Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/6e0f4d6099bb Added tag jdk7-b127 for changeset bd70f76b0309 ! .hgtags Changeset: 65e6601596e2 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/65e6601596e2 Merge Changeset: 61f181d43d9a Author: lana Date: 2011-01-28 10:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/61f181d43d9a Merge Changeset: 6db0e6f221bd Author: ohair Date: 2011-01-05 17:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/6db0e6f221bd 7009969: Remove SKIP_OPENJDK_BUILD from top Makefile Reviewed-by: robilad ! Makefile ! make/Defs-internal.gmk Changeset: 49c463695059 Author: ohair Date: 2011-01-10 10:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/49c463695059 Merge Changeset: 6d9bbcc0a8cb Author: ohair Date: 2011-01-13 17:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/6d9bbcc0a8cb Merge Changeset: 24900a58ab9f Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/24900a58ab9f 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! Makefile ! README-builds.html Changeset: 3a9f19cbf7f1 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/3a9f19cbf7f1 Merge Changeset: a7a4f6db294d Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/a7a4f6db294d Merge Changeset: 57d702105b23 Author: ohair Date: 2011-02-02 09:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/57d702105b23 Merge Changeset: 904d7c7c44d9 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/904d7c7c44d9 Added tag jdk7-b128 for changeset 57d702105b23 ! .hgtags From lana.steuck at oracle.com Sat Feb 5 05:23:29 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Feb 2011 05:23:29 +0000 Subject: hg: jdk7/tl/corba: 3 new changesets Message-ID: <20110205052332.9BDC84743D@hg.openjdk.java.net> Changeset: 64775e83f4df Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/64775e83f4df Added tag jdk7-b126 for changeset d7532bcd3742 ! .hgtags Changeset: 9baa8f94a11d Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/9baa8f94a11d Added tag jdk7-b127 for changeset 64775e83f4df ! .hgtags Changeset: 3ff9acc7cc06 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/3ff9acc7cc06 Added tag jdk7-b128 for changeset 9baa8f94a11d ! .hgtags From lana.steuck at oracle.com Sat Feb 5 05:27:04 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Feb 2011 05:27:04 +0000 Subject: hg: jdk7/tl/hotspot: 52 new changesets Message-ID: <20110205052837.B40534743F@hg.openjdk.java.net> Changeset: 102466e70deb Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/102466e70deb Added tag jdk7-b126 for changeset 4c851c931d00 ! .hgtags Changeset: 907c1aed0f8c Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/907c1aed0f8c Added tag jdk7-b127 for changeset 102466e70deb ! .hgtags Changeset: e4f8c88cf6f0 Author: trims Date: 2011-01-13 22:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e4f8c88cf6f0 Added tag hs20-b06 for changeset e24ab3fa6aaf ! .hgtags Changeset: 76d6282dcfe5 Author: trims Date: 2011-01-13 22:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/76d6282dcfe5 7012348: Bump the HS20 build number to 07 Summary: Update the HS20 build number to 07 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 55f868e91c3b Author: iveresov Date: 2011-01-06 16:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/55f868e91c3b 7010618: C1: array length should be treated at int on 64bit during array allocation Summary: Sign-extend the length argument during array allocation Reviewed-by: never, kvn ! src/cpu/sparc/vm/c1_LIRAssembler_sparc.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp Changeset: 0e52ef6e94d3 Author: twisti Date: 2011-01-07 03:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0e52ef6e94d3 Merge Changeset: 4fc084dac61e Author: kvn Date: 2011-01-07 10:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4fc084dac61e 7009756: volatile variables could be broken throw reflection API Summary: Use Atomic::load() and Atomic::store() to access a volatile long. Reviewed-by: iveresov, jrose, dholmes, never ! src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp ! src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp ! src/share/vm/prims/unsafe.cpp Changeset: 78e248949382 Author: kvn Date: 2011-01-07 11:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/78e248949382 6876037: CTW fails jdk7/hotspot/src/share/vm/opto/type.cpp:2055. assert(bits,"Use TypePtr for NULL") Summary: Add missing 0 value check in TypeRawPtr::add_offset(). Reviewed-by: never ! src/share/vm/opto/type.cpp Changeset: d810e9a3fc33 Author: twisti Date: 2011-01-10 00:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d810e9a3fc33 7010180: JSR 292 InvokeDynamicPrintArgs fails with: assert(_adapter == NULL) failed: init'd to NULL Reviewed-by: never ! src/cpu/sparc/vm/methodHandles_sparc.cpp ! src/cpu/x86/vm/methodHandles_x86.cpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp Changeset: 70427f06ea47 Author: twisti Date: 2011-01-10 03:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/70427f06ea47 7010913: JSR 292 ciMethodHandle does not handle MethodHandleCompiler exceptions properly Reviewed-by: kvn, never ! src/share/vm/ci/ciMethodHandle.cpp ! src/share/vm/prims/methodHandleWalk.cpp Changeset: dd031b2226de Author: iveresov Date: 2011-01-10 18:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/dd031b2226de 4930919: race condition in MDO creation at back branch locations Summary: Reuse set_method_data_for_bcp() to setup mdp after MDO creation. Reviewed-by: kvn, never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/interp_masm_sparc.hpp ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: d4fca0a6abde Author: kvn Date: 2011-01-11 20:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d4fca0a6abde 7011386: race in objArrayKlass::array_klass_impl Summary: Move _lower_dimension field initialization before _higher_dimension and add storestore barrier. Reviewed-by: dholmes, iveresov, never ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: bb8e3b66bde6 Author: twisti Date: 2011-01-13 07:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bb8e3b66bde6 Merge ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/os_cpu/linux_x86/vm/linux_x86_32.s ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il Changeset: c17b998c5926 Author: iveresov Date: 2011-01-12 18:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c17b998c5926 7011627: C1: call_RT must support targets that don't fit in wdisp30 Summary: Make both compilers emit near and far calls when necessary. Reviewed-by: never, kvn, phh ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/sparc.ad Changeset: 5ae3e3b03224 Author: twisti Date: 2011-01-13 07:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5ae3e3b03224 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp Changeset: df307487d610 Author: dholmes Date: 2011-01-09 17:16 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/df307487d610 7010665: Misplaced membar in C1 implementation of Unsafe.get/putXXX Summary: Modify membars to match regular volatile variable handling Reviewed-by: iveresov, kvn, never ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: e31d8c656c5b Author: dcubed Date: 2011-01-10 09:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e31d8c656c5b Merge ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: 7246a374a9f2 Author: kamg Date: 2011-01-10 17:14 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7246a374a9f2 6458402: 3 jvmti tests fail with CMS and +ExplicitGCInvokesConcurrent Summary: Make JvmtiGCMark safe to run non-safepoint and instrument CMS Reviewed-by: ysr, dcubed ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/vm_operations_g1.cpp ! src/share/vm/gc_implementation/parallelScavenge/vmPSOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/prims/jvmti.xml ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/jvmtiTagMap.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/jniHandles.cpp Changeset: db2b0f8c1cef Author: kamg Date: 2011-01-11 10:06 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/db2b0f8c1cef 6814943: getcpool001 catches more than one JvmtiThreadState problem Summary: Mark field volatile, use membars, and change access order to close race Reviewed-by: dcubed, dholmes ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 5577848f5923 Author: phh Date: 2011-01-11 17:33 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5577848f5923 7011463: Sparc MacroAssembler::incr_allocated_bytes() needs a RegisterOrConstant argument Summary: Replaced incr_allocated_bytes() formals var_size_in_bytes and con_size_in_bytes with a single RegisterOrConstant formal. Reviewed-by: twisti, jcoomes ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/c1_MacroAssembler_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: 0ca32cc95d7b Author: phh Date: 2011-01-11 17:50 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0ca32cc95d7b Merge Changeset: 8f8dfba37802 Author: kevinw Date: 2011-01-12 15:44 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8f8dfba37802 6994753: Implement optional hook to a Java method at VM startup. Reviewed-by: mchung, acorn ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/thread.cpp Changeset: 34d64ad817f4 Author: coleenp Date: 2011-01-12 13:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/34d64ad817f4 7009828: Fix for 6938627 breaks visualvm monitoring when -Djava.io.tmpdir is defined Summary: Change get_temp_directory() back to /tmp and %TEMP% like it always was and where the tools expect it to be. Reviewed-by: phh, dcubed, kamg, alanb ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 856ecff79cf7 Author: dcubed Date: 2011-01-13 08:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/856ecff79cf7 Merge ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/templateTable_sparc.cpp Changeset: 4947ee68d19c Author: ysr Date: 2011-01-06 23:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/4947ee68d19c 7008136: CMS: assert((HeapWord*)nextChunk <= _limit) failed: sweep invariant Summary: The recorded _sweep_limit may not necessarily remain a block boundary as the old generation expands during a concurrent cycle. Terminal actions inside the sweep closure need to be aware of this as they cross over the limit. Reviewed-by: johnc, minqi ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Changeset: 2250ee17e258 Author: tonyp Date: 2011-01-12 13:06 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2250ee17e258 7007068: G1: refine the BOT during evac failure handling Summary: During evacuation failure handling we refine the BOT to reflect the location of all the objects in the regions we scan. The changeset includes some minor cleanup: a) non-product print_on() method on the G1 BOT class, b) added more complete BOT verification during heap / region verification, c) slight modification to the BOT set up for humongous regions to be more consistent with the BOT set up during evac failure handling, and d) removed a couple of unused methods. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.cpp ! src/share/vm/gc_implementation/g1/g1BlockOffsetTable.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: b158bed62ef5 Author: tonyp Date: 2011-01-12 16:34 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b158bed62ef5 6994297: G1: do first-level slow-path allocations with a CAS Summary: First attempt to allocate out the current alloc region using a CAS instead of taking the Heap_lock (first level of G1's slow allocation path). Only if that fails and it's necessary to replace the current alloc region take the Heap_lock (that's the second level of G1's slow allocation path). Reviewed-by: johnc, brutisso, ysr ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: 2e0b0c4671e4 Author: brutisso Date: 2011-01-13 04:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2e0b0c4671e4 6941122: G1: UseLargePages does not work with G1 garbage collector Summary: Pass the value of UseLargePages instead of false as the "large" parameter when reserving the G1 heap. Reviewed-by: tonyp, johnc, phh ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: c91cc404ca46 Author: ysr Date: 2011-01-13 11:33 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c91cc404ca46 7011940: iCMS: SIGSEGV in SweepClosure::do_already_free_chunk(FreeChunk*)+0x360 Summary: Revert a (relaxed version of the) bounds-check that was incorrectly removed in the fix for 7008136. Reviewed-by: jmasa, johnc ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp Changeset: ffd725ff6943 Author: johnc Date: 2011-01-13 17:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ffd725ff6943 Merge ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 0915f9be781c Author: trims Date: 2011-01-13 22:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0915f9be781c Merge Changeset: 75efcee5ac47 Author: minqi Date: 2010-10-07 13:49 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/75efcee5ac47 6966589: hs16-b08 causes java.lang.StackOverflowError Reviewed-by: mchung, dholmes, chrisphi ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp Changeset: 85c73c0edb06 Author: kvn Date: 2011-01-18 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/85c73c0edb06 7012965: Fix failed on sparc for 7009756: volatile variables could be broken throw reflection API Summary: Use LDX/STX on v9 and LDD/STD on v8 sparc for volatile long moves. Reviewed-by: never ! src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp ! src/os_cpu/solaris_sparc/vm/solaris_sparc.il Changeset: b599a4c6c2df Author: iveresov Date: 2011-01-18 18:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b599a4c6c2df 7012766: assert(false) failed: DEBUG MESSAGE in MacroAssembler::debug32 Summary: Interpreter expects to see methodOop in rbx on method entry, which needs to be restored after call to profile_method. Reviewed-by: kvn, never ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp Changeset: 8012aa3ccede Author: never Date: 2011-01-13 22:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/8012aa3ccede 4926272: methodOopDesc::method_from_bcp is unsafe Reviewed-by: coleenp, jrose, kvn, dcubed ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/ciMethod.hpp ! src/share/vm/ci/ciMethodBlocks.cpp ! src/share/vm/ci/ciStreams.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/methodLiveness.cpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeStream.cpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/interpreter/templateInterpreter.cpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/methodDataOop.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/vframeArray.cpp Changeset: 17c778814856 Author: coleenp Date: 2011-01-14 13:47 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/17c778814856 6811367: Fix code in HeapDumper::dump_heap() to avoid buffer overrun Summary: Check buffer size before using and use dynamic buffer sizes for subsequent calls. Reviewed-by: kamg, dholmes ! src/share/vm/services/heapDumper.cpp Changeset: 633a44a9fc45 Author: dcubed Date: 2011-01-19 07:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/633a44a9fc45 Merge ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: c1a0ede55d6f Author: dcubed Date: 2011-01-19 07:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c1a0ede55d6f 7012493: 2/2 6849574/Test.java fails with Internal Error (src/share/vm/prims/jvmtiTagMap.cpp:3294) Summary: Refine assertion to work before VMThread has started. Reviewed-by: ysr, never, dholmes, acorn ! src/share/vm/prims/jvmtiTagMap.cpp Changeset: 2f33b03bd915 Author: never Date: 2011-01-19 08:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2f33b03bd915 7013008: 2/3 assert(method == NULL || check_method(method, bcp)) failed: bcp must point into method Summary: The Relocator should pass a NULL methodOop when rewriting since its resource array can never contain breakpoints. Reviewed-by: dcubed, kvn, coleenp ! src/share/vm/runtime/relocator.hpp Changeset: 9afee0b9fc1d Author: kamg Date: 2011-01-19 13:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9afee0b9fc1d 7012505: BreakpointWithFullGC.sh fails with Internal Error (src/share/vm/oops/methodOop.cpp:220) Summary: Rebuild breakpoint cache at gc_epilogue instead of during oops_do Reviewed-by: dcubed, ysr, coleenp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/jniHandles.cpp Changeset: 02b6913287da Author: dcubed Date: 2011-01-19 19:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/02b6913287da Merge Changeset: 7e37af9d69ef Author: tonyp Date: 2011-01-19 09:35 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/7e37af9d69ef 7011379: G1: overly long concurrent marking cycles Summary: This changeset introduces filtering of SATB buffers at the point when they are about to be enqueued. If this filtering clears enough entries on each buffer, the buffer can then be re-used and not enqueued. This cuts down the number of SATB buffers that need to be processed by the concurrent marking threads. Reviewed-by: johnc, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/g1/satbQueue.hpp Changeset: 182e9624aa42 Author: johnc Date: 2011-01-19 13:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/182e9624aa42 7012642: G1: JumbleGC002 test aborts with segmentation violation due to uncaught stack overflow Summary: With recent G1 allocation path changes, the value of StackShadowPages in fast debug builds of the JVM, is no longer large enough to prevent the JVM C++ code from touching the stack guard pages. Increase the value of StackShadowPages to a suitable value. Reviewed-by: ysr, tonyp, coleenp ! src/cpu/x86/vm/globals_x86.hpp Changeset: cb913d743d09 Author: johnc Date: 2011-01-19 13:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/cb913d743d09 Merge Changeset: 0fa27f37d4d4 Author: tonyp Date: 2011-01-19 19:30 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0fa27f37d4d4 6977804: G1: remove the zero-filling thread Summary: This changeset removes the zero-filling thread from G1 and collapses the two free region lists we had before (the "free" and "unclean" lists) into one. The new free list uses the new heap region sets / lists abstractions that we'll ultimately use it to keep track of all regions in the heap. A heap region set was also introduced for the humongous regions. Finally, this change increases the concurrency between the thread that completes freeing regions (after a cleanup pause) and the rest of the system (before we'd have to wait for said thread to complete before allocating a new region). The changest also includes a lot of refactoring and code simplification. Reviewed-by: jcoomes, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.cpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.hpp + src/share/vm/gc_implementation/g1/heapRegionSet.cpp + src/share/vm/gc_implementation/g1/heapRegionSet.hpp + src/share/vm/gc_implementation/g1/heapRegionSet.inline.hpp + src/share/vm/gc_implementation/g1/heapRegionSets.cpp + src/share/vm/gc_implementation/g1/heapRegionSets.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 377371490991 Author: johnc Date: 2011-01-20 13:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/377371490991 Merge - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp Changeset: 5668ad215b80 Author: trims Date: 2011-01-20 17:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5668ad215b80 Merge ! .hgtags Changeset: 98bf1c6bb73a Author: trims Date: 2011-01-20 18:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/98bf1c6bb73a Merge Changeset: 85330eaa15ee Author: iveresov Date: 2011-01-21 00:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/85330eaa15ee 7013812: C1: deopt blob too far from patching stub Summary: Use long jumps to get from patching stubs to deopt blob Reviewed-by: kvn, never ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: d535bf4c1235 Author: trims Date: 2011-01-21 02:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d535bf4c1235 Merge Changeset: 9a5762f44859 Author: trims Date: 2011-02-01 18:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9a5762f44859 Merge ! .hgtags - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp Changeset: 6ecdca5709df Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6ecdca5709df Added tag jdk7-b128 for changeset 9a5762f44859 ! .hgtags From lana.steuck at oracle.com Sat Feb 5 05:29:42 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Feb 2011 05:29:42 +0000 Subject: hg: jdk7/tl/jaxp: 3 new changesets Message-ID: <20110205052942.3A19847440@hg.openjdk.java.net> Changeset: c532d6dbc8d1 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/c532d6dbc8d1 Added tag jdk7-b126 for changeset 2fde639439c1 ! .hgtags Changeset: a42c6132c746 Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/a42c6132c746 Added tag jdk7-b127 for changeset c532d6dbc8d1 ! .hgtags Changeset: f5b60c5a310f Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/f5b60c5a310f Added tag jdk7-b128 for changeset a42c6132c746 ! .hgtags From lana.steuck at oracle.com Sat Feb 5 05:29:47 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Feb 2011 05:29:47 +0000 Subject: hg: jdk7/tl/jaxws: 3 new changesets Message-ID: <20110205052947.B08A147441@hg.openjdk.java.net> Changeset: ef19f173578c Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/ef19f173578c Added tag jdk7-b126 for changeset 6d772c5119d5 ! .hgtags Changeset: 88d74afc5593 Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/88d74afc5593 Added tag jdk7-b127 for changeset ef19f173578c ! .hgtags Changeset: 0f7b39ad9024 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/0f7b39ad9024 Added tag jdk7-b128 for changeset 88d74afc5593 ! .hgtags From lana.steuck at oracle.com Sat Feb 5 05:32:21 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Feb 2011 05:32:21 +0000 Subject: hg: jdk7/tl/jdk: 55 new changesets Message-ID: <20110205054128.5F66747442@hg.openjdk.java.net> Changeset: 29e09de1d0b4 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29e09de1d0b4 Added tag jdk7-b126 for changeset 8361ef97a0f9 ! .hgtags Changeset: 66c86ca4079a Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/66c86ca4079a Added tag jdk7-b127 for changeset 29e09de1d0b4 ! .hgtags Changeset: 63f5c7704faa Author: prr Date: 2011-01-12 15:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/63f5c7704faa 6958221: java.awt.Font.getFamily() leads to JVM crash on Linux on JDK7 for "custom" fonts Reviewed-by: igor, jgodinez ! make/sun/awt/mapfile-mawt-vers ! make/sun/awt/mapfile-vers-linux ! make/sun/headless/mapfile-vers ! make/sun/xawt/mapfile-vers ! src/solaris/classes/sun/awt/X11FontManager.java ! src/solaris/classes/sun/awt/motif/MToolkit.java ! src/solaris/native/sun/awt/fontpath.c + test/java/awt/FontClass/X11FontPathCrashTest.java Changeset: 5aae8b3162d0 Author: prr Date: 2011-01-13 10:36 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5aae8b3162d0 7001056: JDK 7 fails on to build on Solaris 10 update 9 - updated Xrender header files Reviewed-by: igor, jgodinez ! make/sun/xawt/Makefile ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 76b8fa7fd229 Author: prr Date: 2011-01-13 12:08 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/76b8fa7fd229 7012269: mapfile for headless awt needs getFontPathNative defined Reviewed-by: igor ! make/sun/headless/mapfile-vers Changeset: 9f3f38c150b5 Author: prr Date: 2011-01-13 14:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9f3f38c150b5 6917884: NPE in sun.font.FcFontConfiguration.getPlatformFontNames Reviewed-by: igor, jgodinez ! src/solaris/classes/sun/font/FontConfigManager.java Changeset: 987aeabbfda3 Author: prr Date: 2011-01-14 11:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/987aeabbfda3 6951086: Excessive Local References in sun.font.SunLayoutEngine.nativeLayout Reviewed-by: igor, jgodinez ! src/share/native/sun/font/FontInstanceAdapter.cpp Changeset: 646c3cf1ba37 Author: prr Date: 2011-01-14 11:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/646c3cf1ba37 6989370: Windows platform fonts may be incorrectly marked as ineligible for the native rasteriser Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java Changeset: 5cb6bb816a34 Author: prr Date: 2011-01-14 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5cb6bb816a34 6925760: Scaled graphics can cause overlapped LCD mode strings on Windows for pixel size > 48 Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java + test/java/awt/FontClass/LCDScale.java Changeset: 8b33567d68b0 Author: jgodinez Date: 2011-01-14 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b33567d68b0 6939417: ArrayIndexOutOfBoundsException in Win 7 on selected printers Reviewed-by: igor, prr ! src/windows/classes/sun/print/Win32PrintService.java ! test/javax/print/DialogMargins.java Changeset: c2fcb5530ba5 Author: prr Date: 2011-01-14 15:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2fcb5530ba5 6930980: Disable TrueType hinting for fonts known not to hint well Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/FileFontStrike.java ! src/share/classes/sun/font/FontScaler.java ! src/share/classes/sun/font/FreetypeFontScaler.java ! src/share/classes/sun/font/NullFontScaler.java Changeset: 0bec5d506120 Author: dlila Date: 2011-01-19 09:44 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0bec5d506120 4724552: CubicCurve2D.contains(Rectangle2D) returns true when only partially contained. Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: c8a10bfd2fcb Author: dlila Date: 2011-01-19 11:31 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c8a10bfd2fcb 4493128: CubicCurve2D intersects method fails Summary: Now using subdivision code in sun.awt.geom.Curve. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java Changeset: 00cc1c09c6dd Author: prr Date: 2011-01-19 09:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/00cc1c09c6dd 6951501: EUDC character is not displayed on Swing Reviewed-by: igor, jgodinez ! src/windows/classes/sun/awt/Win32FontManager.java ! src/windows/native/sun/windows/awt_Win32GraphicsEnv.cpp Changeset: e58e9e32399a Author: prr Date: 2011-01-19 17:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e58e9e32399a 6983037: closed/java/awt/font/FontNames/Type1Fonts.java failed due to missed font Reviewed-by: igor ! src/share/classes/sun/font/SunFontManager.java ! src/solaris/classes/sun/awt/X11FontManager.java Changeset: fe1b5c15afab Author: prr Date: 2011-01-19 17:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fe1b5c15afab 7013109: windows application manifest problems 6820955: Update application manifests with new Windows 7 dpiAware section Reviewed-by: ohair, art ! make/common/Defs-windows.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! src/windows/resource/java.manifest Changeset: aa1825b1b69d Author: lana Date: 2011-01-19 19:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aa1825b1b69d Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: 0044e8e16a30 Author: prr Date: 2011-01-20 10:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0044e8e16a30 6980204: closed/java/awt/font/LogicalFonts/MappingTest.java fails Reviewed-by: jgodinez ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java Changeset: b1c41e0321a2 Author: prr Date: 2011-01-20 13:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b1c41e0321a2 7013646: remove obsolete fontconfig files for linux and solaris Reviewed-by: igor, jgodinez ! make/sun/awt/Makefile - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties ! src/solaris/classes/sun/awt/motif/MFontConfiguration.java ! src/solaris/classes/sun/font/FcFontConfiguration.java Changeset: b8f08482aca1 Author: prr Date: 2011-01-21 07:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b8f08482aca1 6892493: potential memory leaks in 2D font code indentified by parfait. Reviewed-by: bae, igor ! src/solaris/native/sun/awt/fontpath.c Changeset: c17e5a95aba7 Author: prr Date: 2011-01-21 08:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c17e5a95aba7 6892138: Windows GDI platform font lookup apis affect start-up for small UI apps Reviewed-by: igor, jgodinez ! src/share/classes/sun/font/SunFontManager.java ! src/windows/classes/sun/awt/Win32FontManager.java + test/java/awt/font/FontNames/LocaleFamilyNames.java Changeset: ade796b84e71 Author: bae Date: 2011-01-24 15:14 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ade796b84e71 7002766: Java2d: Changes to correct c/c++ language issues for use of parfait Reviewed-by: jgodinez, prr ! src/share/native/sun/awt/image/jpeg/jmorecfg.h ! src/share/native/sun/java2d/cmm/lcms/LCMS.c Changeset: 63a2e8e00a7b Author: bae Date: 2011-01-24 15:37 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/63a2e8e00a7b 6999620: [parfait] potential buffer overruns in 2d and awt Reviewed-by: jgodinez, prr ! src/windows/native/sun/java2d/d3d/D3DGraphicsDevice.cpp ! src/windows/native/sun/windows/awt_Toolkit.cpp Changeset: 74d020ed7f5b Author: lana Date: 2011-01-24 13:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/74d020ed7f5b Merge - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties Changeset: 5d4723944cbd Author: dcherepanov Date: 2011-01-20 14:27 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5d4723944cbd 7011446: ./windows/classes/sun/awt/windows/WToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/windows/classes/sun/awt/windows/WToolkit.java Changeset: 1bb32dc775c8 Author: dcherepanov Date: 2011-01-20 14:28 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1bb32dc775c8 7011443: ./share/classes/sun/awt/SunToolkit.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/awt/SunToolkit.java Changeset: 4cd8718d4548 Author: dcherepanov Date: 2011-01-20 14:29 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4cd8718d4548 7011442: AppletClassLoader.java needs to avoid spurious wakeup Reviewed-by: anthony ! src/share/classes/sun/applet/AppletClassLoader.java Changeset: 4c9a9871830f Author: lana Date: 2011-01-20 10:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4c9a9871830f Merge - test/javax/script/E4XErrorTest.java - test/sun/security/krb5/auto/basic.sh Changeset: f6b73a9b3895 Author: lana Date: 2011-01-24 13:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f6b73a9b3895 Merge Changeset: 63972a313ca4 Author: rupashka Date: 2011-01-11 12:51 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/63972a313ca4 6589952: Swing: dead links in API documentation Reviewed-by: alexp ! src/share/classes/javax/swing/AbstractButton.java ! src/share/classes/javax/swing/JEditorPane.java ! src/share/classes/javax/swing/SizeSequence.java ! src/share/classes/javax/swing/TransferHandler.java ! src/share/classes/javax/swing/event/InternalFrameAdapter.java ! src/share/classes/javax/swing/event/InternalFrameListener.java ! src/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html ! src/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html ! src/share/classes/javax/swing/text/AsyncBoxView.java ! src/share/classes/javax/swing/text/DefaultCaret.java ! src/share/classes/javax/swing/text/TableView.java ! src/share/classes/javax/swing/text/View.java ! src/share/classes/javax/swing/text/html/HTMLEditorKit.java ! src/share/classes/javax/swing/text/html/ParagraphView.java ! src/share/classes/javax/swing/text/html/StyleSheet.java Changeset: 2a966dd275fc Author: rupashka Date: 2011-01-13 20:12 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2a966dd275fc 6990651: Regression: NPE when refreshing applet since 6u22-b01 Reviewed-by: peterz ! src/share/classes/javax/swing/text/html/parser/ParserDelegator.java + test/javax/swing/JLabel/7004134/bug7004134.java + test/javax/swing/text/html/parser/Parser/6990651/bug6990651.java Changeset: 5787add5b679 Author: rupashka Date: 2011-01-17 19:14 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5787add5b679 6342301: Bad interaction between setting the ui and file filters in JFileChooser Reviewed-by: alexp ! src/share/classes/javax/swing/JFileChooser.java + test/javax/swing/JFileChooser/6342301/bug6342301.java Changeset: ca3bafeffd3b Author: rupashka Date: 2011-01-19 17:01 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ca3bafeffd3b 6246816: SwingSet2 should be rewritten Reviewed-by: peterz ! make/common/Demo.gmk ! make/mkdemo/jfc/Makefile + make/mkdemo/jfc/SwingSet3/Makefile Changeset: e93106dc798b Author: lana Date: 2011-01-19 21:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e93106dc798b Merge - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.html - test/java/awt/Insets/WindowWithWarningTest/WindowWithWarningTest.java - test/javax/script/E4XErrorTest.java - test/javax/swing/SwingWorker/6480289/bug6480289.java - test/sun/security/krb5/auto/basic.sh Changeset: b45ea2c3bd6d Author: rupashka Date: 2011-01-24 18:04 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b45ea2c3bd6d 6735293: javax.swing.text.NavigationFilter.getNextVisualPositionFrom() not always throws BadLocationException Reviewed-by: peterz ! src/share/classes/javax/swing/text/View.java + test/javax/swing/text/NavigationFilter/6735293/bug6735293.java Changeset: 1f3ecbfa0c29 Author: lana Date: 2011-01-24 13:21 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f3ecbfa0c29 Merge Changeset: 1f977c82b733 Author: lana Date: 2011-01-24 13:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f977c82b733 Merge ! make/common/Defs-windows.gmk - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 47cfd89c3227 Author: lana Date: 2011-01-28 10:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/47cfd89c3227 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 006c683ead1a Author: ohair Date: 2011-01-05 14:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/006c683ead1a 6975326: Problem in install/make/rebase/Makefile, grep on empty pattern 6413588: Add 'ldd -r' and 'dump -Lv' checks to all .so files delivered in the JDK 7000995: Add check in makefiles to verify that msvcp100.dll is NOT used Reviewed-by: mduigou ! make/com/sun/java/pack/Makefile ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Program.gmk ! make/common/Release.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-linux.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile Changeset: 9576644931b2 Author: ohair Date: 2011-01-07 21:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9576644931b2 6980024: Rebranding jre7/jdk7 License, Copyright, Readme 6912291: Third party license agreement should be present in all bundles Reviewed-by: katleman ! make/common/Modules.gmk ! make/common/Release.gmk ! make/common/shared/Defs-control.gmk Changeset: 8c3c6ac6fcdb Author: ohair Date: 2011-01-10 09:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8c3c6ac6fcdb Merge Changeset: 658559ca4526 Author: ohair Date: 2011-01-10 17:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/658559ca4526 7011382: Fix use of VS100COMNTOOLS when installed in non-default or non-space path Reviewed-by: prr ! make/common/shared/Defs-windows.gmk Changeset: fd6319676bd3 Author: ohair Date: 2011-01-10 17:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fd6319676bd3 Merge Changeset: 713d20f796c0 Author: ohair Date: 2011-01-10 18:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/713d20f796c0 6989472: Provide simple jdk identification information in the install image Reviewed-by: alanb ! make/common/Release.gmk ! make/common/shared/Defs-versions.gmk Changeset: 523386cfb731 Author: ohair Date: 2011-01-10 22:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/523386cfb731 Merge Changeset: 83cef4633684 Author: ohair Date: 2011-01-13 17:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/83cef4633684 Merge Changeset: 4241588a12c3 Author: ohair Date: 2011-01-13 13:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4241588a12c3 7008047: remove sanity check of msival tool from JDK tree Reviewed-by: billyh ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk Changeset: 81e66ce6f501 Author: ohair Date: 2011-01-13 23:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/81e66ce6f501 Merge Changeset: 0c29bbd10e19 Author: ohair Date: 2011-01-14 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0c29bbd10e19 6950375: Remove msvcrt.dll from the Windows JRE bundles Reviewed-by: prr ! make/Makefile ! make/common/Defs-windows.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! make/java/redist/Makefile ! make/jdk_generic_profile.sh ! src/share/demo/jvmti/index.html Changeset: 329f49ab5c4c Author: ohair Date: 2011-01-16 12:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/329f49ab5c4c Merge Changeset: 688f415db098 Author: ohair Date: 2011-01-26 16:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/688f415db098 Merge Changeset: aecb8f0eb83b Author: ohair Date: 2011-01-27 18:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/aecb8f0eb83b Merge Changeset: f08682e23279 Author: ohair Date: 2011-02-02 09:39 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f08682e23279 Merge ! make/common/Defs-windows.gmk ! make/common/Demo.gmk ! make/common/Library.gmk ! make/common/Modules.gmk ! make/common/Program.gmk ! make/common/Release.gmk Changeset: 07c68a15ec79 Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07c68a15ec79 Added tag jdk7-b128 for changeset f08682e23279 ! .hgtags Changeset: a775b8d3fed0 Author: lana Date: 2011-02-04 17:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a775b8d3fed0 Merge - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties From lana.steuck at oracle.com Sat Feb 5 05:44:26 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Sat, 05 Feb 2011 05:44:26 +0000 Subject: hg: jdk7/tl/langtools: 6 new changesets Message-ID: <20110205054439.BF14347443@hg.openjdk.java.net> Changeset: 1e6094c33187 Author: cl Date: 2011-01-20 15:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1e6094c33187 Added tag jdk7-b126 for changeset 438a8ad60f7a ! .hgtags Changeset: d79e283c7d9b Author: cl Date: 2011-01-27 17:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d79e283c7d9b Added tag jdk7-b127 for changeset 1e6094c33187 ! .hgtags Changeset: 2314f2b07ae7 Author: lana Date: 2011-01-24 13:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2314f2b07ae7 Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.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/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: d7225b476a5d Author: lana Date: 2011-01-28 10:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/d7225b476a5d Merge - src/share/classes/com/sun/tools/classfile/ExtendedAnnotation.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/javac/code/TypeAnnotations.java - src/share/classes/com/sun/tools/javap/TypeAnnotationWriter.java - test/tools/javac/diags/examples/EnumConstRequired.java - test/tools/javac/diags/examples/TypeParameterOnPolymorphicSignature.java - test/tools/javac/meth/InvokeDynTrans.out - test/tools/javac/meth/InvokeMHTrans.java - test/tools/javac/meth/InvokeMHTrans.out Changeset: 1383d1ee8b5d Author: cl Date: 2011-02-03 17:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/1383d1ee8b5d Added tag jdk7-b128 for changeset d7225b476a5d ! .hgtags Changeset: 9e6a09375d37 Author: lana Date: 2011-02-04 17:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9e6a09375d37 Merge From vincent.x.ryan at oracle.com Mon Feb 7 09:27:51 2011 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Mon, 07 Feb 2011 09:27:51 +0000 Subject: hg: jdk7/tl/jdk: 7017486: Need synchronized access when flushing the LDAP request queue Message-ID: <20110207092812.20C26474AC@hg.openjdk.java.net> Changeset: b0bd638036bd Author: vinnie Date: 2011-02-07 09:11 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b0bd638036bd 7017486: Need synchronized access when flushing the LDAP request queue Reviewed-by: alanb ! src/share/classes/com/sun/jndi/ldap/Connection.java From alan.bateman at oracle.com Mon Feb 7 14:03:42 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 07 Feb 2011 14:03:42 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110207140412.05C26474B7@hg.openjdk.java.net> Changeset: f34dcfeecc8d Author: alanb Date: 2011-02-07 13:53 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f34dcfeecc8d 7012823: TEST_BUG: java/nio/MappedByteBuffer tests leave file mappingsthat prevent clean-up (win) Reviewed-by: forax ! test/java/nio/MappedByteBuffer/Force.java ! test/java/nio/MappedByteBuffer/ZeroMap.java Changeset: 32f1c5f67aae Author: alanb Date: 2011-02-07 13:55 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/32f1c5f67aae 7003155: (fs) Paths.get() does not handle escaped octets correctly Reviewed-by: sherman ! src/solaris/classes/sun/nio/fs/UnixUriUtils.java ! test/java/nio/file/Path/UriImportExport.java From chris.hegarty at oracle.com Mon Feb 7 14:09:30 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 07 Feb 2011 14:09:30 +0000 Subject: hg: jdk7/tl/jdk: 7016898: PlainSocketImpl.fd is null on Windows Message-ID: <20110207140940.7EB5F474B8@hg.openjdk.java.net> Changeset: 94bcd9aa2119 Author: chegar Date: 2011-02-07 14:08 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/94bcd9aa2119 7016898: PlainSocketImpl.fd is null on Windows Reviewed-by: alanb ! src/windows/classes/java/net/PlainSocketImpl.java From alan.bateman at oracle.com Mon Feb 7 18:02:56 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 07 Feb 2011 18:02:56 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110207180324.28E61474C4@hg.openjdk.java.net> Changeset: f9f321a7502c Author: alanb Date: 2011-02-07 18:01 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f9f321a7502c 7017454: Residual warnings in sun/nio/** and java/io native code (win64) Reviewed-by: chegar ! src/share/native/java/io/io_util.c ! src/windows/native/java/io/WinNTFileSystem_md.c ! src/windows/native/java/io/canonicalize_md.c ! src/windows/native/java/io/io_util_md.c ! src/windows/native/sun/nio/ch/Iocp.c ! src/windows/native/sun/nio/fs/RegistryFileTypeDetector.c ! src/windows/native/sun/nio/fs/WindowsNativeDispatcher.c Changeset: 08e1914d5852 Author: alanb Date: 2011-02-07 18:02 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/08e1914d5852 Merge From maurizio.cimadamore at oracle.com Mon Feb 7 18:11:57 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 07 Feb 2011 18:11:57 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20110207181202.C97C3474C6@hg.openjdk.java.net> Changeset: 3aa269645199 Author: mcimadamore Date: 2011-02-07 18:09 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3aa269645199 7017414: before the move of JSR 292 to package java.lang.invoke, javac must recognize the new package Summary: added support for future 292 package (support for old location 'java.dyn' will be removed in followup changeset) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Flags.java ! src/share/classes/com/sun/tools/javac/code/Symtab.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/util/Names.java Changeset: 96d4226bdd60 Author: mcimadamore Date: 2011-02-07 18:10 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/96d4226bdd60 7007615: java_util/generics/phase2/NameClashTest02 fails since jdk7/pit/b123. Summary: override clash algorithm is not implemented correctly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! 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/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Enter.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/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/diags/examples/NameClashSameErasureNoHide.java ! test/tools/javac/diags/examples/NameClashSameErasureNoOverride.java + test/tools/javac/diags/examples/NameClashSameErasureNoOverride1.java ! test/tools/javac/generics/5009937/T5009937.out ! test/tools/javac/generics/6182950/T6182950b.out ! test/tools/javac/generics/6476118/T6476118a.out ! test/tools/javac/generics/6476118/T6476118b.out ! test/tools/javac/generics/6476118/T6476118c.java ! test/tools/javac/generics/6476118/T6476118c.out ! test/tools/javac/generics/6985719/T6985719e.out ! test/tools/javac/generics/6985719/T6985719f.out ! test/tools/javac/generics/6985719/T6985719g.out ! test/tools/javac/generics/6985719/T6985719h.out + test/tools/javac/generics/7007615/T7007615.java + test/tools/javac/generics/7007615/T7007615.out + test/tools/javac/generics/7007615/acc1/AccessibilityCheck01.java + test/tools/javac/generics/7007615/acc1/p1/C.java + test/tools/javac/generics/7007615/acc1/p1/D.java + test/tools/javac/generics/7007615/acc1/p2/E.java + test/tools/javac/generics/7007615/acc2/AccessibilityCheck02.java + test/tools/javac/generics/7007615/acc2/AccessibilityCheck02.out + test/tools/javac/generics/7007615/acc2/p1/C.java + test/tools/javac/generics/7007615/acc2/p1/D.java + test/tools/javac/generics/7007615/acc2/p2/E.java ! test/tools/javac/scope/HashCollisionTest.java ! test/tools/javac/scope/StarImportTest.java From jonathan.gibbons at oracle.com Mon Feb 7 19:42:41 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 07 Feb 2011 19:42:41 +0000 Subject: hg: jdk7/tl/langtools: 7017675: typo in JavacParser for allowUnderscoresInLiterals Message-ID: <20110207194243.8B4D1474CC@hg.openjdk.java.net> Changeset: 56b77a38618c Author: jjg Date: 2011-02-07 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/56b77a38618c 7017675: typo in JavacParser for allowUnderscoresInLiterals Reviewed-by: dlsmith Contributed-by: peter.b.kessler at oracle.com ! src/share/classes/com/sun/tools/javac/parser/Scanner.java From mark at klomp.org Mon Feb 7 21:48:21 2011 From: mark at klomp.org (Mark Wielaard) Date: Mon, 7 Feb 2011 22:48:21 +0100 (CET) Subject: Fix for JDK Double.parseDouble infinite loop In-Reply-To: <4D498366.6050805@redhat.com> References: <4D498366.6050805@redhat.com> Message-ID: <36297.80.101.103.228.1297115301.squirrel@gnu.wildebeest.org> On Wed, February 2, 2011 17:16, Andrew Haley wrote: > The post on > http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ This is hitting more and more media. e.g. http://www.channelregister.co.uk/2011/02/07/java_denial_of_service_bug/ Since it seems to be a pretty serious security/denial of service attack maybe we could at least get the fix into IcedTea6 and warn the various distros they should apply it asap for their users? Cheers, Mark From gnu_andrew at member.fsf.org Mon Feb 7 22:23:22 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Mon, 7 Feb 2011 22:23:22 +0000 Subject: Fix for JDK Double.parseDouble infinite loop In-Reply-To: <36297.80.101.103.228.1297115301.squirrel@gnu.wildebeest.org> References: <4D498366.6050805@redhat.com> <36297.80.101.103.228.1297115301.squirrel@gnu.wildebeest.org> Message-ID: On 7 February 2011 21:48, Mark Wielaard wrote: > On Wed, February 2, 2011 17:16, Andrew Haley wrote: >> The post on >> http://www.exploringbinary.com/java-hangs-when-converting-2-2250738585072012e-308/ > > This is hitting more and more media. e.g. > http://www.channelregister.co.uk/2011/02/07/java_denial_of_service_bug/ > > Since it seems to be a pretty serious security/denial of service attack > maybe we could at least get the fix into IcedTea6 and warn the various > distros they should apply it asap for their users? > > Cheers, > > Mark > > I'll add it tomorrow. I expect new IcedTea6 releases soon to coincide with the Oracle SSR; see http://www.oracle.com/technetwork/topics/security/alerts-086861.html -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From dmytro_sheyko at hotmail.com Tue Feb 8 09:24:55 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Tue, 8 Feb 2011 16:24:55 +0700 Subject: Some issues on identifying user.name on Windows Message-ID: Hi, I noticed following code openjdk-7-ea-src-b127-27_jan_2011\jdk\src\windows\native\java\lang\java_props_md.c /* * User name * We try to avoid calling GetUserName as it turns out to * be surprisingly expensive on NT. It pulls in an extra * 100 K of footprint. */ { WCHAR *uname = _wgetenv(L"USERNAME"); if (uname != NULL && wcslen(uname) > 0) { sprops.user_name = _wcsdup(uname); } else { WCHAR buf[100]; int buflen = sizeof(buf); sprops.user_name = GetUserNameW(buf, &buflen) ? _wcsdup(buf) : L"unknown"; } } In my opinion there are some issues in it. 1. We identify buffer length in bytes but GetUserNameW expects size in wchars. This can lead to buffer overflow. 2. In normal cases user name is allocated in heap (_wcsdup does this), but in problematic case user_name points to the static string "unknown". This can lead to problems once we decide to free memory. 3. Solaris and Linux return "?" in problematic case, but Windows returns "unknown". This seems inconsistent. I believe that Windows should also return "?" in order to make it consistent with Linux and Solaris and to let know whether username is definitely unknown. It's impossible to create user with name "?" because it has a forbidden character. On the other hand it is possible have user with name "unknown" literally, so if java says that user name is "unknown" we can't definitely know whether user is really unknown or he has such a name. I propose following code instead: /* * User name * We try to avoid calling GetUserName as it turns out to * be surprisingly expensive on NT. It pulls in an extra * 100 K of footprint. */ { WCHAR *uname = _wgetenv(L"USERNAME"); if (uname != NULL && wcslen(uname) > 0) { sprops.user_name = _wcsdup(uname); } else { sprops.user_name = IdentifyUserName(); } } static LPWSTR IdentifyUserName() { DWORD buflen = 0; GetUserNameW(0, &buflen); // identify buffer length if (GetLastError() == ERROR_INSUFFICIENT_BUFFER) { // 'buflen' receives the required buffer size in WCHARs, including the terminating null character. LPWSTR result = (LPWSTR) malloc(buflen * sizeof(WCHAR)); if (result) { if (GetUserNameW(result, &buflen)) { return result; } else { free(result); } } } return _wcsdup(L"?"); // allocate username in heap, use impossible username } Regards, Dmytro -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Tue Feb 8 13:30:19 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 08 Feb 2011 13:30:19 +0000 Subject: Some issues on identifying user.name on Windows In-Reply-To: References: Message-ID: <4D51456B.2040708@oracle.com> Dmytro Sheyko wrote: > Hi, > > I noticed following code > > openjdk-7-ea-src-b127-27_jan_2011\jdk\src\windows\native\java\lang\java_props_md.c > > /* > * User name > * We try to avoid calling GetUserName as it turns out to > * be surprisingly expensive on NT. It pulls in an extra > * 100 K of footprint. > */ > { > WCHAR *uname = _wgetenv(L"USERNAME"); > if (uname != NULL && wcslen(uname) > 0) { > sprops.user_name = _wcsdup(uname); > } else { > WCHAR buf[100]; > int buflen = sizeof(buf); > sprops.user_name = > GetUserNameW(buf, &buflen) ? _wcsdup(buf) : L"unknown"; > } > } Dmytro - I agree this code should be fixed. On the buffer size, my guess is that it's rare to have a 50+ character username and so it probably hasn't been an issue. I think the issue of what to do when the username cannot be determined is a good question and should be re-examined. Defaulting to "?" or "unknown" is problematic as some applications need to use the value of the user.name propety in file names or as a key. We've had a few reports of problems on Linux where user.name is defaulting to "?". In the examples that I looked at it was because the 32-bit JDK was being used on a 64-bit system and the 32-bit libnss_ldap wasn't installed. Minimally we need to make these types of issues easier to diagnose, and perhaps look at the implications of having the startup fail if the username cannot be determined. In the your patch you propose to standardize on "?" if the username cannot be determined and I just wonder if there are any genuine conditions where it might fail on Windows and whether is there might be any existing code depending on "unknown" (I hope not). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.bateman at oracle.com Tue Feb 8 15:58:31 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 08 Feb 2011 15:58:31 +0000 Subject: hg: jdk7/tl/jdk: 7013585: Dual-pivot quicksort improvements for highly structured (nearly sorted) and data with small periods Message-ID: <20110208155841.597DD474FE@hg.openjdk.java.net> Changeset: 947ce00ed7a2 Author: alanb Date: 2011-02-08 15:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/947ce00ed7a2 7013585: Dual-pivot quicksort improvements for highly structured (nearly sorted) and data with small periods Reviewed-by: mduigou, alanb Contributed-by: vladimir.yaroslavskiy at oracle.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java From alan.bateman at oracle.com Tue Feb 8 21:04:25 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 08 Feb 2011 21:04:25 +0000 Subject: hg: jdk7/tl/jdk: 4421494: infinite loop while parsing double literal Message-ID: <20110208210435.4B3C847512@hg.openjdk.java.net> Changeset: 82c8c54ac1d5 Author: alanb Date: 2011-02-08 19:31 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/82c8c54ac1d5 4421494: infinite loop while parsing double literal Reviewed-by: darcy, alanb Contributed-by: dmitry.nadezhin at oracle.com ! src/share/classes/sun/misc/FloatingDecimal.java ! test/java/lang/Double/ParseDouble.java From xueming.shen at oracle.com Tue Feb 8 21:33:19 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 08 Feb 2011 21:33:19 +0000 Subject: hg: jdk7/tl/jdk: 7017840: (zipfs) test/demo/zipfs/basic.sh needs to be updated due to 7013420 Message-ID: <20110208213328.F14C547516@hg.openjdk.java.net> Changeset: 6661a1dfa369 Author: sherman Date: 2011-02-08 13:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6661a1dfa369 7017840: (zipfs) test/demo/zipfs/basic.sh needs to be updated due to 7013420 Summary: updated try-with-resourcse usage in test/demo code Reviewed-by: alanb ! src/share/demo/nio/zipfs/Demo.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh From dmytro_sheyko at hotmail.com Wed Feb 9 10:25:51 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Wed, 9 Feb 2011 17:25:51 +0700 Subject: Some issues on identifying user.name on Windows In-Reply-To: <4D51456B.2040708@oracle.com> References: , <4D51456B.2040708@oracle.com> Message-ID: Hi, Maybe it makes sense to use environment variables on Linux (and Solaris) as well in order to minimize failure of "user.name" and "user.home" detection, doesn't it? As for Windows, many Win32 functions fail when system is shutting down, and GetUserName shouldn't be an exception. But I don't know other conditions till now. I believe that JVM shouldn't stop working if user name can't be determined because many applications do not need to know it at all. Actually system properties don't seems very reliable source for those applications that DO need user name. One can easily cheat them by setting env var USERNAME (on Windows) or just passing -Duser.name in command line explicitly. I think this kind of application needs separate API that provides true system information and better diagnostics in problematic cases. As for default value for "user.name" I changed my mind. I think we shouldn't place "user.name" to system properties at all if user name cannot be determined. (Of course, documenting this behavior well in System.getProperties() javadoc) It would be easier to handle quite rare problematic cases with following code String username = System.getProperty("user.name", fallbackUsernameValue); than with String username = System.getProperty("user.name"); if (username.equals("?") || username.equals("unknown")) { username = fallbackUsernameValue; } Regards, Dmytro Date: Tue, 8 Feb 2011 13:30:19 +0000 From: Alan.Bateman at oracle.com To: dmytro_sheyko at hotmail.com CC: core-libs-dev at openjdk.java.net Subject: Re: Some issues on identifying user.name on Windows Message body Dmytro Sheyko wrote: Hi, I noticed following code openjdk-7-ea-src-b127-27_jan_2011\jdk\src\windows\native\java\lang\java_props_md.c /* * User name * We try to avoid calling GetUserName as it turns out to * be surprisingly expensive on NT. It pulls in an extra * 100 K of footprint. */ { WCHAR *uname = _wgetenv(L"USERNAME"); if (uname != NULL && wcslen(uname) > 0) { sprops.user_name = _wcsdup(uname); } else { WCHAR buf[100]; int buflen = sizeof(buf); sprops.user_name = GetUserNameW(buf, &buflen) ? _wcsdup(buf) : L"unknown"; } } Dmytro - I agree this code should be fixed. On the buffer size, my guess is that it's rare to have a 50+ character username and so it probably hasn't been an issue. I think the issue of what to do when the username cannot be determined is a good question and should be re-examined. Defaulting to "?" or "unknown" is problematic as some applications need to use the value of the user.name propety in file names or as a key. We've had a few reports of problems on Linux where user.name is defaulting to "?". In the examples that I looked at it was because the 32-bit JDK was being used on a 64-bit system and the 32-bit libnss_ldap wasn't installed. Minimally we need to make these types of issues easier to diagnose, and perhaps look at the implications of having the startup fail if the username cannot be determined. In the your patch you propose to standardize on "?" if the username cannot be determined and I just wonder if there are any genuine conditions where it might fail on Windows and whether is there might be any existing code depending on "unknown" (I hope not). -Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Feb 9 10:38:55 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 09 Feb 2011 10:38:55 +0000 Subject: hg: jdk7/tl/jdk: 7013961: Threads attached via JNI attach prevent daemon ThreadGroups from being destroyed Message-ID: <20110209103904.F109E4753B@hg.openjdk.java.net> Changeset: cd9a302f2806 Author: chegar Date: 2011-02-09 09:53 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cd9a302f2806 7013961: Threads attached via JNI attach prevent daemon ThreadGroups from being destroyed Reviewed-by: dholmes ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/lang/ThreadGroup.java From Alan.Bateman at oracle.com Wed Feb 9 12:50:04 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Feb 2011 12:50:04 +0000 Subject: Some issues on identifying user.name on Windows In-Reply-To: References: , <4D51456B.2040708@oracle.com> Message-ID: <4D528D7C.4030603@oracle.com> Dmytro Sheyko wrote: > Hi, > > Maybe it makes sense to use environment variables on Linux (and > Solaris) as well in order to minimize failure of "user.name" and > "user.home" detection, doesn't it? Yes, I think this makes sense. Typically USER and LOGNAME are set (we might just need to think about the sudo case). > > As for Windows, many Win32 functions fail when system is shutting > down, and GetUserName shouldn't be an exception. But I don't know > other conditions till now. > > I believe that JVM shouldn't stop working if user name can't be > determined because many applications do not need to know it at all. The counter argument is that applications that do require it could fail in unpredictable ways. I've seen a couple of cases but never Windows. Another suggestion is to emit a warning, something that might be feasible for debug/fastdebug builds (probably not product because messages coming from the runtime can cause other problems, and can confuse tests). Minimally we need something to make it easier to diagnose. > Actually system properties don't seems very reliable source for those > applications that DO need user name. One can easily cheat them by > setting env var USERNAME (on Windows) > or just passing -Duser.name in command line explicitly. I think this > kind of application needs separate API that provides true system > information and better diagnostics > in problematic cases. > > As for default value for "user.name" I changed my mind. I think we > shouldn't place "user.name" to system properties at all if user name > cannot be determined. > (Of course, documenting this behavior well in System.getProperties() > javadoc) I don't think this is an option because it would break existing code that assumes user.name is set. > It would be easier to handle quite rare problematic cases with > following code > > String username = System.getProperty("user.name", > fallbackUsernameValue); > > than with > > String username = System.getProperty("user.name"); > if (username.equals("?") || username.equals("unknown")) { > username = fallbackUsernameValue; > } We don't document "?" or "unknown" but it would not surprise me to find code like this. Anyway back to your original patch, what would you think about modifying it so that it throws an exception if GetUserNameW fails rather than defaulting to "unknown"? You mentioned the "Windows is shutting down" case (and you may be right on that) but I can't think of any others except period insufficient resources in which case we'll probably keel over anyway. We can separate this from the Solaris/Linux changes as that is the most likely places where it might fail and default to "?" today. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil.richards at ngmr.net Wed Feb 9 13:23:23 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Wed, 9 Feb 2011 13:23:23 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: References: <4D2473E9.4010600@oracle.com> <4D2AFCAD.2000304@oracle.com> Message-ID: Hi Alan, Mike, Please find attached one more webrev zip, with updated license text and now based off jdk7-b128. Let me know if this is now good to be committed, or if there's anything else I need to do, Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.6927486.3.zip Type: application/zip Size: 116133 bytes Desc: not available URL: From Alan.Bateman at oracle.com Wed Feb 9 14:13:18 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 09 Feb 2011 14:13:18 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: References: <4D2473E9.4010600@oracle.com> <4D2AFCAD.2000304@oracle.com> Message-ID: <4D52A0FE.7010009@oracle.com> Neil Richards wrote: > Hi Alan, Mike, > Please find attached one more webrev zip, with updated license text > and now based off jdk7-b128. > > Let me know if this is now good to be committed, or if there's > anything else I need to do, > Thanks, > Neil > Thanks for perceiving with this. The only thing that looks a bit strange (to me anyway) is that the GPL header is in the same comment block as the IBM notice. I just checked other examples in the repository and the convention seems to be to put them in separate comment blocks. -Alan. From Alan.Bateman at ORACLE.COM Wed Feb 9 16:13:42 2011 From: Alan.Bateman at ORACLE.COM (Alan Bateman) Date: Wed, 09 Feb 2011 16:13:42 +0000 Subject: Dual-Pivot Quicksort improvements for highly structured (nearly sorted) arrays and data with small periods In-Reply-To: References: <89690CEB-6855-4525-8FD8-7E5BD92F8008@oracle.com> Message-ID: <4D52BD36.2080202@oracle.com> This one was pushed yesterday but it turns out to have an issue in the code that checks if the array is nearly sorted. This can lead to an ArrayIndexOutOfBoundsException that isn't caught by the existing tests. Vladimir has a fix and we need to extend the sorting test to ensure that it hits all the new code. Should have jdk7/tl fixed shortly. -Alan. From alan.bateman at oracle.com Wed Feb 9 16:31:05 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 09 Feb 2011 16:31:05 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110209163124.439C447553@hg.openjdk.java.net> Changeset: 6a274c4d3e00 Author: alanb Date: 2011-02-09 15:59 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6a274c4d3e00 7018258: Dual-pivot updates in 7013585 can fail with ArrayIndexOutOfBoundsException Reviewed-by: alanb Contributed-by: vladimir.yaroslavskiy at oracle.com ! src/share/classes/java/util/DualPivotQuicksort.java ! test/java/util/Arrays/Sorting.java Changeset: 37563c09305d Author: alanb Date: 2011-02-09 16:30 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/37563c09305d Merge From jonathan.gibbons at oracle.com Wed Feb 9 22:05:20 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Feb 2011 22:05:20 +0000 Subject: hg: jdk7/tl/langtools: 7016750: tools/javac/nio/CompileTest failing in nightly test Message-ID: <20110209220522.4755547569@hg.openjdk.java.net> Changeset: c6cb387190ee Author: jjg Date: 2011-02-09 14:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c6cb387190ee 7016750: tools/javac/nio/CompileTest failing in nightly test Reviewed-by: mcimadamore ! test/tools/javac/nio/compileTest/CompileTest.java From jonathan.gibbons at oracle.com Wed Feb 9 22:11:03 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 09 Feb 2011 22:11:03 +0000 Subject: hg: jdk7/tl/langtools: 7010792: remove bad debugging method from javac Message-ID: <20110209221105.0A6B44756B@hg.openjdk.java.net> Changeset: 3ce4e1a07e92 Author: jjg Date: 2011-02-09 14:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3ce4e1a07e92 7010792: remove bad debugging method from javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/parser/Scanner.java From jonathan.gibbons at oracle.com Thu Feb 10 02:26:35 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Feb 2011 02:26:35 +0000 Subject: hg: jdk7/tl/langtools: 7018447: langtools launcher template fails if tools run from their own directory Message-ID: <20110210022637.BF9244757D@hg.openjdk.java.net> Changeset: bfa59f3e84bd Author: jjg Date: 2011-02-09 18:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bfa59f3e84bd 7018447: langtools launcher template fails if tools run from their own directory Reviewed-by: jjg Contributed-by: daniel.smith at oracle.com ! src/share/bin/launcher.sh-template From David.Holmes at oracle.com Thu Feb 10 07:08:45 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 10 Feb 2011 17:08:45 +1000 Subject: Deprecating puzzling APIs In-Reply-To: References: Message-ID: <4D538EFD.6000801@oracle.com> Not a topic for the discuss list (which I've bcc'ed), so moved to core-libs David Holmes Behrang Saeedzadeh said the following on 02/10/11 16:49: > In particular, I am referring to Integer.getInteger, > Boolean.getBoolean, etc. series of methods. These methods are API > smells, confusing to new users, and can lead to all sorts of bugs. > Shouldn't we start deprecating these methods? > > Cheers, > Behrang Saeedzadeh > http://www.behrang.org From jonathan.gibbons at oracle.com Thu Feb 10 22:25:01 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Feb 2011 22:25:01 +0000 Subject: hg: jdk7/tl/langtools: 7018098: CacheFSInfo persists too long Message-ID: <20110210222503.799B9475BB@hg.openjdk.java.net> Changeset: a19b1f4f23c9 Author: jjg Date: 2011-02-10 14:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a19b1f4f23c9 7018098: CacheFSInfo persists too long Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/file/T7018098.java From jonathan.gibbons at oracle.com Thu Feb 10 22:27:45 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Feb 2011 22:27:45 +0000 Subject: hg: jdk7/tl/langtools: 7018452: langtools not buildable on Mac Message-ID: <20110210222747.64495475BC@hg.openjdk.java.net> Changeset: 747a7601b6d6 Author: jjg Date: 2011-02-10 14:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/747a7601b6d6 7018452: langtools not buildable on Mac Reviewed-by: ohair ! make/build.xml From jonathan.gibbons at oracle.com Thu Feb 10 23:05:55 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 10 Feb 2011 23:05:55 +0000 Subject: hg: jdk7/tl/langtools: 6485027: javac incorrectly handles relative paths in manifest classpath Message-ID: <20110210230556.F04E2475BF@hg.openjdk.java.net> Changeset: e0c16199b2e0 Author: jjg Date: 2011-02-10 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/e0c16199b2e0 6485027: javac incorrectly handles relative paths in manifest classpath Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/file/Paths.java ! test/tools/javac/Paths/Class-Path.sh + test/tools/javac/Paths/Class-Path2.sh ! test/tools/javac/Paths/Diagnostics.sh From sundararajan.a at sun.com Fri Feb 11 05:09:20 2011 From: sundararajan.a at sun.com (sundararajan.a at sun.com) Date: Fri, 11 Feb 2011 05:09:20 +0000 Subject: hg: jdk7/tl/jdk: 6604827: JavaDoc for ScriptEngineFactory.getMethodCallSyntax contains an error. Message-ID: <20110211050930.478A647645@hg.openjdk.java.net> Changeset: cfd397d86474 Author: sundar Date: 2011-02-11 10:38 +0530 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cfd397d86474 6604827: JavaDoc for ScriptEngineFactory.getMethodCallSyntax contains an error. Reviewed-by: mchung ! src/share/classes/javax/script/ScriptEngineFactory.java From dmytro_sheyko at hotmail.com Fri Feb 11 09:13:12 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Fri, 11 Feb 2011 16:13:12 +0700 Subject: Some issues on identifying user.name on Windows In-Reply-To: <4D528D7C.4030603@oracle.com> References: , <4D51456B.2040708@oracle.com> , <4D528D7C.4030603@oracle.com> Message-ID: Hi Alan, I am still convinced that inability to get user name is not a good reason to terminate execution (with exception or fatal error). I am afraid that this could break existing programs that perform well when user name is not known. They can be even unconscious that they work in such strange conditions. Looking at code near I can see that there is not consistent approach. Solaris/Linux part fails with exception if current directory is not known, while Windows part is optimistic about this. Maybe the best approach is somewhere between these extreme ones. Just an idea: what about to put diagnostic message just in system property? So it may look something like user.name="?: GetUserName failed, GetLastError=1115: A system shutdown is in progress." This way we provide better diagnostics than if we report plain "unknown" and at the same time we let application ignore failure if it is not relevant for it. By the way, getting current directory on Windows is also slippery. In code we inform GetCurrentDirectory that our buffer is twice longer than we actually reserved. /* Current directory */ { WCHAR buf[MAX_PATH]; GetCurrentDirectoryW(sizeof(buf), buf); sprops.user_dir = _wcsdup(buf); } Again, this can be not an issue since it's not easy to create directory longer than MAX_PATH. Regards, Dmytro Date: Wed, 9 Feb 2011 12:50:04 +0000 From: Alan.Bateman at oracle.com To: dmytro_sheyko at hotmail.com CC: core-libs-dev at openjdk.java.net Subject: Re: Some issues on identifying user.name on Windows Dmytro Sheyko wrote: Hi, Maybe it makes sense to use environment variables on Linux (and Solaris) as well in order to minimize failure of "user.name" and "user.home" detection, doesn't it? Yes, I think this makes sense. Typically USER and LOGNAME are set (we might just need to think about the sudo case). As for Windows, many Win32 functions fail when system is shutting down, and GetUserName shouldn't be an exception. But I don't know other conditions till now. I believe that JVM shouldn't stop working if user name can't be determined because many applications do not need to know it at all. The counter argument is that applications that do require it could fail in unpredictable ways. I've seen a couple of cases but never Windows. Another suggestion is to emit a warning, something that might be feasible for debug/fastdebug builds (probably not product because messages coming from the runtime can cause other problems, and can confuse tests). Minimally we need something to make it easier to diagnose. Actually system properties don't seems very reliable source for those applications that DO need user name. One can easily cheat them by setting env var USERNAME (on Windows) or just passing -Duser.name in command line explicitly. I think this kind of application needs separate API that provides true system information and better diagnostics in problematic cases. As for default value for "user.name" I changed my mind. I think we shouldn't place "user.name" to system properties at all if user name cannot be determined. (Of course, documenting this behavior well in System.getProperties() javadoc) I don't think this is an option because it would break existing code that assumes user.name is set. It would be easier to handle quite rare problematic cases with following code String username = System.getProperty("user.name", fallbackUsernameValue); than with String username = System.getProperty("user.name"); if (username.equals("?") || username.equals("unknown")) { username = fallbackUsernameValue; } We don't document "?" or "unknown" but it would not surprise me to find code like this. Anyway back to your original patch, what would you think about modifying it so that it throws an exception if GetUserNameW fails rather than defaulting to "unknown"? You mentioned the "Windows is shutting down" case (and you may be right on that) but I can't think of any others except period insufficient resources in which case we'll probably keel over anyway. We can separate this from the Solaris/Linux changes as that is the most likely places where it might fail and default to "?" today. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kelly.ohair at oracle.com Fri Feb 11 10:26:18 2011 From: kelly.ohair at oracle.com (kelly.ohair at oracle.com) Date: Fri, 11 Feb 2011 10:26:18 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20110211102648.824A747657@hg.openjdk.java.net> Changeset: 7bb09178ffc7 Author: ohair Date: 2011-02-10 20:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/7bb09178ffc7 7012644: Regression: jdk/make/common/shared/Defs-windows.gmk has problems on cygwin 7018835: Debug build issues in jdk makefiles Reviewed-by: ksrini ! make/common/shared/Defs-windows.gmk ! make/common/shared/Defs.gmk ! make/common/shared/Platform.gmk Changeset: 05a0271173a6 Author: ohair Date: 2011-02-10 20:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/05a0271173a6 Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 1dc0c3021d13 Author: ohair Date: 2011-02-11 01:45 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1dc0c3021d13 Merge From neil.richards at ngmr.net Fri Feb 11 11:46:46 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 11 Feb 2011 11:46:46 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: References: <4D2473E9.4010600@oracle.com> <4D2AFCAD.2000304@oracle.com> Message-ID: Hi Alan, Mike, Please find attached a further webrev zip file with the IBM copyright split out into its own little comment block, as requested. Hope this helps, Cheers, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.6927486.4.zip Type: application/zip Size: 116100 bytes Desc: not available URL: From Alan.Bateman at oracle.com Fri Feb 11 12:05:39 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Feb 2011 12:05:39 +0000 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: References: <4D2473E9.4010600@oracle.com> <4D2AFCAD.2000304@oracle.com> Message-ID: <4D552613.7040309@oracle.com> Neil Richards wrote: > Hi Alan, Mike, > Please find attached a further webrev zip file with the IBM copyright > split out into its own little comment block, as requested. > Good to see this finally resolved. Thumbs up from me. Mike has offered to push this so I'll leave it to him. Also I assume this means the related fix to j.u.Vector can be brought to the finish line too, right? -Alan. From neil.richards at ngmr.net Fri Feb 11 13:03:04 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 11 Feb 2011 13:03:04 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <55CEEFF2-5A74-40D9-B82D-558ED326D8E3@roundroom.net> References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <4D2B75F4.20309@oracle.com> <61A4144A-0302-466D-A676-586EC6D6AB62@roundroom.net> <55CEEFF2-5A74-40D9-B82D-558ED326D8E3@roundroom.net> Message-ID: Hi Peter, Using putFields/writeFields was the only way I found of properly addressing the problem in Vector serialization. The fix has not impacted performance significantly in places where it has been used in anger. (I'd naturally be interested in any further improvements in this area.) All, please find attached an updated webrev zip file, which makes 'data' final (thanks for the suggestion, Peter), and also sorts out the licensing text. Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.6934356.5.zip Type: application/zip Size: 117434 bytes Desc: not available URL: From forax at univ-mlv.fr Fri Feb 11 13:14:30 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 11 Feb 2011 14:14:30 +0100 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <4D2B75F4.20309@oracle.com> <61A4144A-0302-466D-A676-586EC6D6AB62@roundroom.net> <55CEEFF2-5A74-40D9-B82D-558ED326D8E3@roundroom.net> Message-ID: <4D553636.8060302@univ-mlv.fr> You could use elementData.clone() instead of System.arraycopy R?mi On 02/11/2011 02:03 PM, Neil Richards wrote: > Hi Peter, > Using putFields/writeFields was the only way I found of properly > addressing the problem in Vector serialization. > > The fix has not impacted performance significantly in places where it > has been used in anger. > (I'd naturally be interested in any further improvements in this area.) > > All, please find attached an updated webrev zip file, which makes > 'data' final (thanks for the suggestion, Peter), and also sorts out > the licensing text. > > Thanks, > Neil > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From neil.richards at ngmr.net Fri Feb 11 13:42:45 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 11 Feb 2011 13:42:45 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: <4D553636.8060302@univ-mlv.fr> References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <4D2B75F4.20309@oracle.com> <61A4144A-0302-466D-A676-586EC6D6AB62@roundroom.net> <55CEEFF2-5A74-40D9-B82D-558ED326D8E3@roundroom.net> <4D553636.8060302@univ-mlv.fr> Message-ID: On 11 February 2011 13:14, R?mi Forax wrote: > You could use elementData.clone() instead of System.arraycopy > > R?mi Good idea - thanks for the suggestion! Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.6934356.6.zip Type: application/zip Size: 117153 bytes Desc: not available URL: From neil.richards at ngmr.net Fri Feb 11 13:59:29 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 11 Feb 2011 13:59:29 +0000 Subject: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient In-Reply-To: <175B5A20-658C-47EE-AE68-888D5FE23E49@oracle.com> References: <175B5A20-658C-47EE-AE68-888D5FE23E49@oracle.com> Message-ID: Please find an updated webrev zip file with corrected license text and references to the RFE number, 7014637, in the testcases. Thanks, Neil -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From forax at univ-mlv.fr Fri Feb 11 13:59:26 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Fri, 11 Feb 2011 14:59:26 +0100 Subject: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient In-Reply-To: References: <175B5A20-658C-47EE-AE68-888D5FE23E49@oracle.com> Message-ID: <4D5540BE.1000100@univ-mlv.fr> On 02/11/2011 02:59 PM, Neil Richards wrote: > Please find where :) > an updated webrev zip file with corrected license text and > references to the RFE number, 7014637, in the testcases. > > Thanks, > Neil R?mi From neil.richards at ngmr.net Fri Feb 11 14:02:08 2011 From: neil.richards at ngmr.net (Neil Richards) Date: Fri, 11 Feb 2011 14:02:08 +0000 Subject: Making java.util.Iterator.remove() for the iterators for EnumSet more resilient In-Reply-To: References: <175B5A20-658C-47EE-AE68-888D5FE23E49@oracle.com> Message-ID: Umm, let me try that one again, attaching the webrev zip file this time (doh!) On 11 February 2011 13:59, Neil Richards wrote: > Please find an updated webrev zip file with corrected license text and > references to the RFE number, 7014637, in the testcases. > > Thanks, > Neil > -- Unless stated above: IBM email: neil_richards at uk.ibm.com IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- A non-text attachment was scrubbed... Name: webrev.7014637.1.zip Type: application/zip Size: 92932 bytes Desc: not available URL: From mike.duigou at oracle.com Fri Feb 11 16:38:37 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 11 Feb 2011 08:38:37 -0800 Subject: Review request for 6927486: Deadlock in legacy Hashtable writeObject() In-Reply-To: <4D552613.7040309@oracle.com> References: <4D2473E9.4010600@oracle.com> <4D2AFCAD.2000304@oracle.com> <4D552613.7040309@oracle.com> Message-ID: <2AC993D0-EBC4-48ED-85AB-261320BA7588@oracle.com> Everything looks resolved to me as well. I will push this webrev over the weekend or on Monday. Thank you for your patience in working through the pedantic details. Hopefully this will make the process smoother for all future commits and we won't have to revisit any of these issues. Mike On Feb 11 2011, at 04:05 , Alan Bateman wrote: > Neil Richards wrote: >> Hi Alan, Mike, >> Please find attached a further webrev zip file with the IBM copyright >> split out into its own little comment block, as requested. >> > Good to see this finally resolved. Thumbs up from me. Mike has offered to push this so I'll leave it to him. Also I assume this means the related fix to j.u.Vector can be brought to the finish line too, right? > > -Alan. From Alan.Bateman at oracle.com Fri Feb 11 16:42:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 11 Feb 2011 16:42:49 +0000 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <4D2B75F4.20309@oracle.com> <61A4144A-0302-466D-A676-586EC6D6AB62@roundroom.net> <55CEEFF2-5A74-40D9-B82D-558ED326D8E3@roundroom.net> <4D553636.8060302@univ-mlv.fr> Message-ID: <4D556709.6060905@oracle.com> Neil Richards wrote: > : > Good idea - thanks for the suggestion! > Neil > Yes, a good suggestion, and updated webrev looks good to me. -Alan From xueming.shen at oracle.com Fri Feb 11 20:23:18 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 11 Feb 2011 20:23:18 +0000 Subject: hg: jdk7/tl/jdk: 7007596: (zipfs) FileSystems.newFileSystem(FileRef...) always employs zipfs regardless the real Path type. Message-ID: <20110211202340.2E9EB4767D@hg.openjdk.java.net> Changeset: 8711aedb08f2 Author: sherman Date: 2011-02-11 12:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8711aedb08f2 7007596: (zipfs) FileSystems.newFileSystem(FileRef...) always employs zipfs regardless the real Path type. Summary: updated newFileSystem() to throw UOE exception for non-zip/jar file Reviewed-by: alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystemProvider.java ! test/demo/zipfs/ZipFSTester.java ! test/demo/zipfs/basic.sh From weijun.wang at oracle.com Fri Feb 11 22:44:48 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 11 Feb 2011 22:44:48 +0000 Subject: hg: jdk7/tl/jdk: 6742654: Code insertion/replacement attacks against signed jars; ... Message-ID: <20110211224458.C25EC47687@hg.openjdk.java.net> Changeset: 8860e17db3bd Author: weijun Date: 2011-02-12 05:09 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8860e17db3bd 6742654: Code insertion/replacement attacks against signed jars 6911041: JCK api/signaturetest tests fails for Mixed Code PIT builds (b91) for all trains 6921823: JarVerifier csdomain field not initialized 6921839: Update trusted.libraries list Reviewed-by: dgu ! make/java/security/Makefile ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JarVerifier.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java ! src/share/classes/sun/misc/JarIndex.java ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java From weijun.wang at oracle.com Fri Feb 11 23:31:24 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 11 Feb 2011 23:31:24 +0000 Subject: hg: jdk7/tl/jdk: 7016698: test sun/security/krb5/runNameEquals.sh failed on Ubuntu Message-ID: <20110211233153.7BFAA4768F@hg.openjdk.java.net> Changeset: de923c0ec3c4 Author: weijun Date: 2011-02-12 07:30 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/de923c0ec3c4 7016698: test sun/security/krb5/runNameEquals.sh failed on Ubuntu Reviewed-by: valeriep ! src/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java From xueming.shen at oracle.com Sat Feb 12 01:10:21 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Sat, 12 Feb 2011 01:10:21 +0000 Subject: hg: jdk7/tl/jdk: 6996192: Console.readPassword race: input echo off must be prior to writing prompt Message-ID: <20110212011032.5AC6147697@hg.openjdk.java.net> Changeset: 21a1e86dedc2 Author: sherman Date: 2011-02-11 17:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/21a1e86dedc2 6996192: Console.readPassword race: input echo off must be prior to writing prompt Summary: To turn off echo before prompt Reviewed-by: alanb ! src/share/classes/java/io/Console.java From jonathan.gibbons at oracle.com Sat Feb 12 01:10:48 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 12 Feb 2011 01:10:48 +0000 Subject: hg: jdk7/tl/langtools: 6505047: javax.lang.model.element.Element.getEnclosingElement() doesn't return null for type parameter Message-ID: <20110212011055.DB63A47698@hg.openjdk.java.net> Changeset: bfeed79c70aa Author: jjg Date: 2011-02-11 17:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bfeed79c70aa 6505047: javax.lang.model.element.Element.getEnclosingElement() doesn't return null for type parameter Reviewed-by: darcy + test/tools/javac/processing/model/element/TestTypeParameter.java From chris.hegarty at oracle.com Mon Feb 14 16:28:04 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 14 Feb 2011 16:28:04 +0000 Subject: Code Review 6562203: Thread doesn't terminate immediately if it was stopped before start Message-ID: <4D595814.2000202@oracle.com> David, Since your changes for CR 6566340 "Restore use of stillborn flag to signify a thread that was stopped before it started", are now promoted in hs21.0-b01, I would like to proceed with this clean up in the libraries. Basically reverse out the changes that were made by CR 4519200, in JDK6. Stop before start will now be correctly handled solely by the VM. Also, some minor changes to an existing StopBeforeStart regression test. http://cr.openjdk.java.net/~chegar/6562203/webrev.00/webrev/ Thanks, -Chris. From daniel.daugherty at oracle.com Mon Feb 14 17:33:03 2011 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Mon, 14 Feb 2011 17:33:03 +0000 Subject: hg: jdk7/tl/jdk: 6637230: 2/3 jps doesn't work for application waiting for direct attach Message-ID: <20110214173327.6025447729@hg.openjdk.java.net> Changeset: b04e86b3e27e Author: dcubed Date: 2011-02-14 09:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b04e86b3e27e 6637230: 2/3 jps doesn't work for application waiting for direct attach Summary: Properly handle exceptions thrown when querying a monitored VM. Reviewed-by: dsamersoff, swamyv ! src/share/classes/sun/tools/jps/Jps.java From dmytro_sheyko at hotmail.com Mon Feb 14 17:49:53 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Tue, 15 Feb 2011 00:49:53 +0700 Subject: sun.cpu.isalist Message-ID: Hi, I can see that such system property as "sun.cpu.isalist" is not set on Linux, but it is set on Solaris and Windows. What is the purpose of this property and shouldn't it be set on Linux as well? Thanks, Dmytro -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon Feb 14 17:48:17 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 14 Feb 2011 17:48:17 +0000 Subject: Code Review 6562203: Thread doesn't terminate immediately if it was stopped before start In-Reply-To: <4D595814.2000202@oracle.com> References: <4D595814.2000202@oracle.com> Message-ID: <4D596AE1.7080703@oracle.com> Chris Hegarty wrote: > David, > > Since your changes for CR 6566340 "Restore use of stillborn flag to > signify a thread that was stopped before it started", are now promoted > in hs21.0-b01, I would like to proceed with this clean up in the > libraries. Basically reverse out the changes that were made by CR > 4519200, in JDK6. Stop before start will now be correctly handled > solely by the VM. > > Also, some minor changes to an existing StopBeforeStart regression test. > > http://cr.openjdk.java.net/~chegar/6562203/webrev.00/webrev/ > > Thanks, > -Chris. Not your doing, but it looks like stop(null) could resume a suspended thread before throwing NPE. Do I read this correctly? Just wondering if that should be ex-examined while you are in the stop method. -Alan. From alan.bateman at oracle.com Mon Feb 14 18:31:57 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 14 Feb 2011 18:31:57 +0000 Subject: hg: jdk7/tl/jdk: 7016704: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with new version of find (lnx) Message-ID: <20110214183208.D198F4772C@hg.openjdk.java.net> Changeset: fefc740bff52 Author: alanb Date: 2011-02-14 18:30 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/fefc740bff52 7016704: TEST_BUG: java/nio/file/Files/walk_file_tree.sh fails with new version of find (lnx) Reviewed-by: forax ! test/java/nio/file/Files/walkFileTree/PrintFileTree.java From mike.duigou at oracle.com Mon Feb 14 18:48:59 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 14 Feb 2011 18:48:59 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110214184918.AB7FE4772D@hg.openjdk.java.net> Changeset: 28037efa90a3 Author: mduigou Date: 2011-02-14 10:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/28037efa90a3 6934356: Vector.writeObject() serialization may deadlock Summary: No longer synchronize on self while writing other objects. Reviewed-by: alanb, forax, mduigou, peterjones Contributed-by: Neil Richards ! src/share/classes/java/util/Vector.java + test/java/util/Vector/SerializationDeadlock.java + test/java/util/Vector/SimpleSerialization.java Changeset: 2633daa325ed Author: mduigou Date: 2011-02-14 10:48 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/2633daa325ed Merge From mike.duigou at oracle.com Mon Feb 14 18:52:40 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 14 Feb 2011 10:52:40 -0800 Subject: Sunbug 6934356: Vector.writeObject() synchronization risks serialization deadlock In-Reply-To: References: <4D0A0D96.7050302@oracle.com> <4D2AF3DE.5060104@oracle.com> <4D2B75F4.20309@oracle.com> <61A4144A-0302-466D-A676-586EC6D6AB62@roundroom.net> <55CEEFF2-5A74-40D9-B82D-558ED326D8E3@roundroom.net> <4D553636.8060302@univ-mlv.fr> Message-ID: I have pushed this webrev to the openjdk tl workspace. It should be in the master workspace (and thereby to all child workspaces) within the next week. Thank you for your patience in working through all the details to get this first issue completed. Mike On Feb 11 2011, at 05:42 , Neil Richards wrote: > On 11 February 2011 13:14, R?mi Forax wrote: >> You could use elementData.clone() instead of System.arraycopy >> >> R?mi > > Good idea - thanks for the suggestion! > Neil > > -- > Unless stated above: > IBM email: neil_richards at uk.ibm.com > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > From mike.duigou at oracle.com Mon Feb 14 19:00:20 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 14 Feb 2011 19:00:20 +0000 Subject: hg: jdk7/tl/jdk: 6927486: Hashtable writeObject() may deadlock Message-ID: <20110214190030.5E0D74772F@hg.openjdk.java.net> Changeset: 338c5b815ff2 Author: mduigou Date: 2011-02-14 11:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/338c5b815ff2 6927486: Hashtable writeObject() may deadlock Summary: Do not synchronize on self while writing hash table elements Reviewed-by: alanb, mduigou Contributed-by: Neil Richards ! src/share/classes/java/util/Hashtable.java + test/java/util/Hashtable/SerializationDeadlock.java + test/java/util/Hashtable/SimpleSerialization.java From gnu_andrew at member.fsf.org Mon Feb 14 20:23:20 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Mon, 14 Feb 2011 20:23:20 +0000 Subject: sun.cpu.isalist In-Reply-To: References: Message-ID: 2011/2/14 Dmytro Sheyko : > Hi, > > I can see that such system property as "sun.cpu.isalist" is not set on > Linux, but it is set on Solaris and Windows. > What is the purpose of this property and shouldn't it be set on Linux as > well? > > Thanks, > Dmytro > > On Solaris, it includes the results of a call to sysinfo(SA_ISALIST, list, sizeof(list)): http://www.opensolarisforum.org/man/man2/sysinfo.html SI_ISALIST Copy into the array pointed to by buf the names of the variant instruction set architectures executable on the current system. The names are space-separated and are ordered in the sense of best performance. That is, earlier-named instruction sets might contain more instructions than later-named instruction sets; a program that is compiled for an earlier-named instruction set will most likely run faster on this machine than the same program compiled for a later-named instruction set. Programs compiled for an instruction set that does not appear in the list will most likely experience performance degradation or not run at all on this machine. The instruction set names known to the system are listed in isal- ist(5); these names might not match predefined names or compiler options in the C language compilation system. This command is obsolete and might be removed in a future release. See getisax(2) and the Linker and Libraries Guide for a better way to handle instruction set extensions. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From xuelei.fan at oracle.com Mon Feb 14 21:32:03 2011 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 14 Feb 2011 21:32:03 +0000 Subject: hg: jdk7/tl/jdk: 7018897: CertPath validation cannot handle self-signed cert with bad KeyUsage Message-ID: <20110214213214.09B734773D@hg.openjdk.java.net> Changeset: 44c99f30f9df Author: xuelei Date: 2011-02-14 13:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/44c99f30f9df 7018897: CertPath validation cannot handle self-signed cert with bad KeyUsage Summary: Remove KeyUsage checking for trust anchors Reviewed-by: mullan ! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java From jonathan.gibbons at oracle.com Mon Feb 14 22:28:09 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 14 Feb 2011 22:28:09 +0000 Subject: hg: jdk7/tl/langtools: 7008433: Minor copyright changes Message-ID: <20110214222811.D964547741@hg.openjdk.java.net> Changeset: ef6c66215a93 Author: jjg Date: 2011-02-14 14:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/ef6c66215a93 7008433: Minor copyright changes Reviewed-by: jjg Contributed-by: kelly.ohair at oracle.com ! test/tools/javac/4917091/Test255.java ! test/tools/javac/4917091/Test256a.java ! test/tools/javac/4917091/Test256b.java From David.Holmes at oracle.com Tue Feb 15 00:53:19 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 15 Feb 2011 10:53:19 +1000 Subject: Code Review 6562203: Thread doesn't terminate immediately if it was stopped before start In-Reply-To: <4D596AE1.7080703@oracle.com> References: <4D595814.2000202@oracle.com> <4D596AE1.7080703@oracle.com> Message-ID: <4D59CE7F.9000400@oracle.com> HI Chris, Alan, Alan Bateman said the following on 02/15/11 03:48: > Chris Hegarty wrote: >> Since your changes for CR 6566340 "Restore use of stillborn flag to >> signify a thread that was stopped before it started", are now promoted >> in hs21.0-b01, I would like to proceed with this clean up in the >> libraries. Basically reverse out the changes that were made by CR >> 4519200, in JDK6. Stop before start will now be correctly handled >> solely by the VM. >> >> Also, some minor changes to an existing StopBeforeStart regression test. >> >> http://cr.openjdk.java.net/~chegar/6562203/webrev.00/webrev/ >> > Not your doing, but it looks like stop(null) could resume a suspended > thread before throwing NPE. Do I read this correctly? Just wondering if > that should be ex-examined while you are in the stop method. It doesn't pay to look too closely at this code :) Yes the old and current code might resume a thread and then not actually stop it due to the throwable being null. We should probably put in an explicit null check. That said the resume() is bogus anyway: 1. There's nothing in the spec that says that a thread that was suspended which is then stopped should immediately resume so that it can throw the exception. Seems to me it should throw only after being explicitly resumed. 2. As there's no synchronization between stop/suspend/resume the thread could be suspended as soon as you've resumed it. That aside the code changes look code. Thanks. Let's hope we've finally laid this one to rest! David From David.Holmes at oracle.com Tue Feb 15 01:12:48 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 15 Feb 2011 11:12:48 +1000 Subject: sun.cpu.isalist In-Reply-To: References: Message-ID: <4D59D310.2020800@oracle.com> Dmytro Sheyko said the following on 02/15/11 03:49: > I can see that such system property as "sun.cpu.isalist" is not set on > Linux, but it is set on Solaris and Windows. > What is the purpose of this property and shouldn't it be set on Linux as > well? I don't see the property actually being used anywhere these days. No idea what it may have been used for other than printing the property for information (there's a Java2D demo that does that). Is there an API on Linux that will provide the information? Both Solaris and Windows have a "sys info" call that can provide this information. But Linux sysinfo is something different. David From david.lloyd at redhat.com Tue Feb 15 02:44:23 2011 From: david.lloyd at redhat.com (David M. Lloyd) Date: Mon, 14 Feb 2011 20:44:23 -0600 Subject: sun.cpu.isalist In-Reply-To: <4D59D310.2020800@oracle.com> References: <4D59D310.2020800@oracle.com> Message-ID: <4D59E887.1090302@redhat.com> On 02/14/2011 07:12 PM, David Holmes wrote: > Dmytro Sheyko said the following on 02/15/11 03:49: >> I can see that such system property as "sun.cpu.isalist" is not set on >> Linux, but it is set on Solaris and Windows. >> What is the purpose of this property and shouldn't it be set on Linux >> as well? > > I don't see the property actually being used anywhere these days. No > idea what it may have been used for other than printing the property for > information (there's a Java2D demo that does that). > > Is there an API on Linux that will provide the information? Both Solaris > and Windows have a "sys info" call that can provide this information. > But Linux sysinfo is something different. /proc/cpuinfo has a flags field, maybe that's similar enough? -- - DML From weijun.wang at oracle.com Tue Feb 15 04:12:33 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 15 Feb 2011 04:12:33 +0000 Subject: hg: jdk7/tl/jdk: 7018928: test failure: sun/security/krb5/auto/SSL.java Message-ID: <20110215041259.60C0447752@hg.openjdk.java.net> Changeset: 9024288330c4 Author: weijun Date: 2011-02-15 12:11 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9024288330c4 7018928: test failure: sun/security/krb5/auto/SSL.java Reviewed-by: valeriep ! test/sun/security/krb5/auto/BadKdc1.java ! test/sun/security/krb5/auto/BadKdc2.java ! test/sun/security/krb5/auto/BadKdc3.java ! test/sun/security/krb5/auto/BadKdc4.java ! test/sun/security/krb5/auto/CleanState.java ! test/sun/security/krb5/auto/CrossRealm.java ! test/sun/security/krb5/auto/HttpNegotiateServer.java ! test/sun/security/krb5/auto/IgnoreChannelBinding.java ! test/sun/security/krb5/auto/KerberosHashEqualsTest.java ! test/sun/security/krb5/auto/LifeTimeInSeconds.java ! test/sun/security/krb5/auto/LoginModuleOptions.java ! test/sun/security/krb5/auto/MaxRetries.java ! test/sun/security/krb5/auto/MoreKvno.java ! test/sun/security/krb5/auto/NewSalt.java ! test/sun/security/krb5/auto/NonMutualSpnego.java ! test/sun/security/krb5/auto/SSL.java ! test/sun/security/krb5/auto/SpnegoReqFlags.java ! test/sun/security/krb5/auto/Test5653.java From Alan.Bateman at oracle.com Tue Feb 15 10:00:09 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Feb 2011 10:00:09 +0000 Subject: sun.cpu.isalist In-Reply-To: <4D59D310.2020800@oracle.com> References: <4D59D310.2020800@oracle.com> Message-ID: <4D5A4EA9.2040404@oracle.com> David Holmes wrote: > : > I don't see the property actually being used anywhere these days. No > idea what it may have been used for other than printing the property > for information (there's a Java2D demo that does that). > > Is there an API on Linux that will provide the information? Both > Solaris and Windows have a "sys info" call that can provide this > information. But Linux sysinfo is something different. I checked the pre-OpenJDK history and it seems to have been added in 1999 without explanation. I can only guess that it was something added for some Solaris service. It doesn't appear to have ever been documented and I doubt it is used. -Alan From Alan.Bateman at oracle.com Tue Feb 15 10:05:34 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Feb 2011 10:05:34 +0000 Subject: Code Review 6562203: Thread doesn't terminate immediately if it was stopped before start In-Reply-To: <4D59CE7F.9000400@oracle.com> References: <4D595814.2000202@oracle.com> <4D596AE1.7080703@oracle.com> <4D59CE7F.9000400@oracle.com> Message-ID: <4D5A4FEE.90602@oracle.com> David Holmes wrote: > : > > That aside the code changes look code. > > Thanks. Let's hope we've finally laid this one to rest! I agree, it's great to have this long running saga put to rest. The changes look fine to me too. -Alan From spoole at linux.vnet.ibm.com Tue Feb 15 10:24:30 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Tue, 15 Feb 2011 10:24:30 +0000 Subject: Zlib level in JDK7 Message-ID: <1297765470.8797.7.camel@jazzette> Hi all, JDK7 is using zlib 1.2.3 (which was added to JDK7 back in 2009.) Zlib's latest version is 1.2.5 - is there any expectation to move to 1.2.5 in JDK7? It seems a real shame to ship JDK7 with a version of zlib that is so out of date. More than happy to help contribute towards making this happen. I would like to know if its already on someone's radar though or to understand why this is a mad idea :-) Cheers Steve From David.Holmes at oracle.com Tue Feb 15 10:32:40 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 15 Feb 2011 20:32:40 +1000 Subject: Code Review 6562203: Thread doesn't terminate immediately if it was stopped before start In-Reply-To: <4D59CE7F.9000400@oracle.com> References: <4D595814.2000202@oracle.com> <4D596AE1.7080703@oracle.com> <4D59CE7F.9000400@oracle.com> Message-ID: <4D5A5648.3040509@oracle.com> I must correct myself: David Holmes said the following on 02/15/11 10:53: > That said the resume() is bogus anyway: > > 1. There's nothing in the spec that says that a thread that was > suspended which is then stopped should immediately resume so that it can > throw the exception. Seems to me it should throw only after being > explicitly resumed. Actually there is, or at least there was in the original spec for Thread.stop in the Java Language Specification first edition. But there's a number of things defined in the THread API in JLS 1ed that never actually made it into the Thread class. To implement this without a race the VM would have to be responsible for doing the resume(), and it's interesting to note that the VM does perform an interrupt on the target thread so that is woken from a sleep (or wait) again as per the original JLS 1e spec. David ------ > 2. As there's no synchronization between stop/suspend/resume the thread > could be suspended as soon as you've resumed it. > > > That aside the code changes look code. > > Thanks. Let's hope we've finally laid this one to rest! > > David From maurizio.cimadamore at oracle.com Tue Feb 15 12:02:15 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Tue, 15 Feb 2011 12:02:15 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20110215120221.11C1A47767@hg.openjdk.java.net> Changeset: 351027202f60 Author: mcimadamore Date: 2011-02-15 11:49 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/351027202f60 7017664: Add listeners infrastracture to javac scopes Summary: Add listeners to javac scopes, added CompoundScope and correct invalidation logic for ImplementationCache Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Scope.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/scope/7017664/CompoundScopeTest.java + test/tools/javac/scope/7017664/ImplementationCacheTest.java Changeset: fa0e4e1916f4 Author: mcimadamore Date: 2011-02-15 11:51 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/fa0e4e1916f4 7017104: improve error reporting for uncaught/undeclared exceptions from try-with-resources Summary: twr should generate better error message when uncaught exceptions are thrown by implicit call of close() method Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! test/tools/javac/TryWithResources/ResourceInterface.out ! test/tools/javac/TryWithResources/TwrFlow.out + test/tools/javac/diags/examples/UnreportedExceptionImplicitClose.java From dmytro_sheyko at hotmail.com Tue Feb 15 13:11:42 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Tue, 15 Feb 2011 20:11:42 +0700 Subject: sun.cpu.isalist In-Reply-To: <4D59E887.1090302@redhat.com> References: , <4D59D310.2020800@oracle.com>, <4D59E887.1090302@redhat.com> Message-ID: Sure, we can parse /proc/cpuinfo output on Linux in order to provide valid isalist, but it seems it's not worth doing. Maybe we can just get rid of it. > Date: Mon, 14 Feb 2011 20:44:23 -0600 > From: david.lloyd at redhat.com > To: core-libs-dev at openjdk.java.net > Subject: Re: sun.cpu.isalist > > On 02/14/2011 07:12 PM, David Holmes wrote: > > Dmytro Sheyko said the following on 02/15/11 03:49: > >> I can see that such system property as "sun.cpu.isalist" is not set on > >> Linux, but it is set on Solaris and Windows. > >> What is the purpose of this property and shouldn't it be set on Linux > >> as well? > > > > I don't see the property actually being used anywhere these days. No > > idea what it may have been used for other than printing the property for > > information (there's a Java2D demo that does that). > > > > Is there an API on Linux that will provide the information? Both Solaris > > and Windows have a "sys info" call that can provide this information. > > But Linux sysinfo is something different. > > /proc/cpuinfo has a flags field, maybe that's similar enough? > > -- > - DML -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu_andrew at member.fsf.org Tue Feb 15 13:58:46 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Tue, 15 Feb 2011 13:58:46 +0000 Subject: sun.cpu.isalist In-Reply-To: References: <4D59D310.2020800@oracle.com> <4D59E887.1090302@redhat.com> Message-ID: 2011/2/15 Dmytro Sheyko : > Sure, we can parse /proc/cpuinfo output on Linux in order to provide valid > isalist, but it seems it's not worth doing. Maybe we can just get rid of it. > > >> Date: Mon, 14 Feb 2011 20:44:23 -0600 >> From: david.lloyd at redhat.com >> To: core-libs-dev at openjdk.java.net >> Subject: Re: sun.cpu.isalist >> >> On 02/14/2011 07:12 PM, David Holmes wrote: >> > Dmytro Sheyko said the following on 02/15/11 03:49: >> >> I can see that such system property as "sun.cpu.isalist" is not set on >> >> Linux, but it is set on Solaris and Windows. >> >> What is the purpose of this property and shouldn't it be set on Linux >> >> as well? >> > >> > I don't see the property actually being used anywhere these days. No >> > idea what it may have been used for other than printing the property for >> > information (there's a Java2D demo that does that). >> > >> > Is there an API on Linux that will provide the information? Both Solaris >> > and Windows have a "sys info" call that can provide this information. >> > But Linux sysinfo is something different. >> >> /proc/cpuinfo has a flags field, maybe that's similar enough? >> >> -- >> - DML > I looked at this briefly last night. The ISA sysinfo call results can be seen on Solaris by running isainfo: $ isainfo amd64 i386 That's the results from an x86_64 box. I presume x86 would just return i386. /proc/cpuinfo's flags is quite a bit more detailed: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority so it's not the same thing. Also the output of /proc/cpuinfo is per-core, so on an 8-core box there are 8 sets of flags. The standard property os.arch will already return amd64 on a x86_64 GNU/Linux box. There may be more advantage on SPARC and I guess that's what this was originally designed for. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From Alan.Bateman at oracle.com Tue Feb 15 13:57:22 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 15 Feb 2011 13:57:22 +0000 Subject: Zlib level in JDK7 In-Reply-To: <1297765470.8797.7.camel@jazzette> References: <1297765470.8797.7.camel@jazzette> Message-ID: <4D5A8642.602@oracle.com> Steve Poole wrote: > Hi all, > > JDK7 is using zlib 1.2.3 (which was added to JDK7 back in 2009.) > > Zlib's latest version is 1.2.5 - is there any expectation to move to > 1.2.5 in JDK7? It seems a real shame to ship JDK7 with a version of > zlib that is so out of date. > > More than happy to help contribute towards making this happen. I would > like to know if its already on someone's radar though or to understand > why this is a mad idea :-) > > Cheers > > Steve > I don't think it's on anyone's radar. Sherman did the last update, bringing us up from a patched 1.1.3 to 1.2.3. The main thing with zlib updates is testing and bake time. Have you done any testing with 1.2.5? While there are some good reasons listed in the ChangeLog, I'm curious if they translate into any measurable improvement with the zip APIs. On the testing it would be interesting to check if 1.2.5 is used by any of the distros as I think (but might be wrong) that OpenJDK/IcedTea6 project have changes to use /usr/lib/libzip.so rather than the snapshot in the jdk repository and so might already have experience using the latest version. -Alan From gnu_andrew at member.fsf.org Tue Feb 15 14:07:52 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Tue, 15 Feb 2011 14:07:52 +0000 Subject: Zlib level in JDK7 In-Reply-To: <4D5A8642.602@oracle.com> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> Message-ID: On 15 February 2011 13:57, Alan Bateman wrote: > Steve Poole wrote: >> >> Hi all, >> JDK7 is using zlib 1.2.3 (which was added to JDK7 back in 2009.) >> Zlib's latest version is 1.2.5 - is there any expectation to move to >> 1.2.5 in JDK7? ? It seems a real shame to ship JDK7 with a version of >> zlib that is so out of date. >> More than happy to help contribute towards making this happen. ?I would >> like to know if its already on someone's radar though ?or to understand >> why this is a mad idea :-) >> >> Cheers >> >> Steve >> > > I don't think it's on anyone's radar. Sherman did the last update, bringing > us up from a patched 1.1.3 to 1.2.3. The main thing with zlib updates is > testing and bake time. Have you done any testing with 1.2.5? While there are > some good reasons listed in the ChangeLog, I'm curious if they translate > into any measurable improvement with the zip APIs. On the testing it would > be interesting to check if 1.2.5 is used by any of the distros as I think > (but might be wrong) that OpenJDK/IcedTea6 project have changes to use > /usr/lib/libzip.so rather than the snapshot in the jdk repository and so > might already have experience using the latest version. > > -Alan > Yes, IcedTea uses system libraries for everything bar LCMS, where local changes in OpenJDK mean we are still forced to use the in-tree version. There hasn't been any success upstreaming these changes, though I haven't looked at LCMS 2.x. So yes, that means we use the system zlib (currently 1.2.5 here), jpeg (8c) and png (1.4.5). 1.10 will also finally remove the static linking of libstdc++ and libgcc. This was done back in the early days of IcedTea as part of preparing OpenJDK for distro packaging, allowing these libraries to receive timely security updates and bug fixes. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From fweimer at bfk.de Tue Feb 15 15:40:05 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 15 Feb 2011 15:40:05 +0000 Subject: Zlib level in JDK7 In-Reply-To: (Andrew John Hughes's message of "Tue\, 15 Feb 2011 14\:07\:52 +0000") References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> Message-ID: <8262sl71d6.fsf@mid.bfk.de> * Andrew John Hughes: > So yes, that means we use the system zlib (currently 1.2.5 here), jpeg > (8c) and png (1.4.5). 1.10 will also finally remove the static > linking of libstdc++ and libgcc. This was done back in the early days > of IcedTea as part of preparing OpenJDK for distro packaging, allowing > these libraries to receive timely security updates and bug fixes. It also increases compatibility with systems which use a different zlib version. The symbols of the version in OpenJDK haven't been mangled, and the VM crashes if the wrong routines are called due to a symbol clash. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From damjan.jov at gmail.com Tue Feb 15 16:00:24 2011 From: damjan.jov at gmail.com (Damjan Jovanovic) Date: Tue, 15 Feb 2011 18:00:24 +0200 Subject: Zlib level in JDK7 In-Reply-To: <8262sl71d6.fsf@mid.bfk.de> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <8262sl71d6.fsf@mid.bfk.de> Message-ID: On Tue, Feb 15, 2011 at 5:40 PM, Florian Weimer wrote: > * Andrew John Hughes: > >> So yes, that means we use the system zlib (currently 1.2.5 here), jpeg >> (8c) and png (1.4.5). ?1.10 will also finally remove the static >> linking of libstdc++ and libgcc. ?This was done back in the early days >> of IcedTea as part of preparing OpenJDK for distro packaging, allowing >> these libraries to receive timely security updates and bug fixes. > > It also increases compatibility with systems which use a different > zlib version. ?The symbols of the version in OpenJDK haven't been > mangled, and the VM crashes if the wrong routines are called due to a > symbol clash. > Such symbol clashes are ultimately caused by the fact that ELF is probably the only binary file format left today to use the moronic idea of process-scoped symbol lookup. The JVM could work around it by using the RTLD_DEEPBIND flag to dlopen() on Linux, and by linking libraries with "-Bdirect" on Solaris. Other ELF-using operating systems (BSD?) are probably out of luck. Damjan Jovanovic From xueming.shen at oracle.com Tue Feb 15 17:17:57 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 15 Feb 2011 09:17:57 -0800 Subject: Zlib level in JDK7 In-Reply-To: <4D5A8642.602@oracle.com> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> Message-ID: <4D5AB545.2000206@oracle.com> One of the benefits of using a 5-year old version is that it has been thoroughly tested by various software for 5 years, given we actually don't have lots of tests for zlib ourself, this is very important, at least for me, when considering upgrade, especially at this late stage of the release I would be very cautious to do it. While the changelog lists a "long" list of changes from 1.2.3. to 1.2.4, most of them are in code that are not included in JDK, the only thing that might bring in some enhancement is "Faster Z_HUFFMAN_ONLY compression for images and other specialized compression", but given my experience of measuring the improvement in the past, I doubt you actually benefit from it in most of the use scenario. -Sherman On 2/15/2011 5:57 AM, Alan Bateman wrote: > Steve Poole wrote: >> Hi all, >> JDK7 is using zlib 1.2.3 (which was added to JDK7 back in 2009.) >> Zlib's latest version is 1.2.5 - is there any expectation to move to >> 1.2.5 in JDK7? It seems a real shame to ship JDK7 with a version of >> zlib that is so out of date. >> More than happy to help contribute towards making this happen. I would >> like to know if its already on someone's radar though or to understand >> why this is a mad idea :-) >> >> Cheers >> >> Steve > I don't think it's on anyone's radar. Sherman did the last update, > bringing us up from a patched 1.1.3 to 1.2.3. The main thing with zlib > updates is testing and bake time. Have you done any testing with > 1.2.5? While there are some good reasons listed in the ChangeLog, I'm > curious if they translate into any measurable improvement with the zip > APIs. On the testing it would be interesting to check if 1.2.5 is used > by any of the distros as I think (but might be wrong) that > OpenJDK/IcedTea6 project have changes to use /usr/lib/libzip.so rather > than the snapshot in the jdk repository and so might already have > experience using the latest version. > > -Alan From lana.steuck at oracle.com Tue Feb 15 19:33:14 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 15 Feb 2011 19:33:14 +0000 Subject: hg: jdk7/tl/corba: 3 new changesets Message-ID: <20110215193318.78A2D4777C@hg.openjdk.java.net> Changeset: 6a3903e5b6cc Author: ohair Date: 2011-02-03 15:05 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/6a3903e5b6cc 6944304: Potential rebranding issues in the openjdk7/corba sources Reviewed-by: alanb, mchung, darcy ! src/share/classes/com/sun/corba/se/spi/logging/data/Activation.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/IOR.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Interceptors.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Naming.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/OMG.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/ORBUtil.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/POA.mc ! src/share/classes/com/sun/corba/se/spi/logging/data/Util.mc Changeset: 66fa0fcc7792 Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/66fa0fcc7792 Merge Changeset: 4cdf9b86f550 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/4cdf9b86f550 Added tag jdk7-b129 for changeset 66fa0fcc7792 ! .hgtags From lana.steuck at oracle.com Tue Feb 15 19:33:20 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 15 Feb 2011 19:33:20 +0000 Subject: hg: jdk7/tl: 4 new changesets Message-ID: <20110215193320.752D84777D@hg.openjdk.java.net> Changeset: ce02c0d73d6a Author: ohair Date: 2011-02-03 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/ce02c0d73d6a 7014634: By default, only build the product bits with a closed jdk build (like openjdk does) Reviewed-by: katleman, cl, igor, trims ! make/Defs-internal.gmk Changeset: e2a214ec8ebc Author: ohair Date: 2011-02-04 07:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/e2a214ec8ebc Merge Changeset: a6b015b59fbc Author: ohair Date: 2011-02-08 16:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/a6b015b59fbc 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! README-builds.html Changeset: cc58c11af154 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/cc58c11af154 Added tag jdk7-b129 for changeset a6b015b59fbc ! .hgtags From lana.steuck at oracle.com Tue Feb 15 19:33:22 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 15 Feb 2011 19:33:22 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b129 for changeset f5b60c5a310f Message-ID: <20110215193322.BFB174777E@hg.openjdk.java.net> Changeset: ab107c1bc4b9 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/ab107c1bc4b9 Added tag jdk7-b129 for changeset f5b60c5a310f ! .hgtags From lana.steuck at oracle.com Tue Feb 15 19:33:25 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 15 Feb 2011 19:33:25 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b129 for changeset 0f7b39ad9024 Message-ID: <20110215193325.849454777F@hg.openjdk.java.net> Changeset: ba1fac1c2083 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/ba1fac1c2083 Added tag jdk7-b129 for changeset 0f7b39ad9024 ! .hgtags From lana.steuck at oracle.com Tue Feb 15 19:33:31 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 15 Feb 2011 19:33:31 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20110215193336.1289C47780@hg.openjdk.java.net> Changeset: 03e7fc380090 Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/03e7fc380090 Added tag jdk7-b129 for changeset 1383d1ee8b5d ! .hgtags Changeset: 846d6644bb70 Author: lana Date: 2011-02-15 08:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/846d6644bb70 Merge From lana.steuck at oracle.com Tue Feb 15 19:33:35 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 15 Feb 2011 19:33:35 +0000 Subject: hg: jdk7/tl/hotspot: 21 new changesets Message-ID: <20110215193415.4342647781@hg.openjdk.java.net> Changeset: 6aa467001334 Author: trims Date: 2011-01-25 14:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/6aa467001334 Added tag hs20-b07 for changeset d535bf4c1235 ! .hgtags Changeset: d19d8218a399 Author: trims Date: 2011-01-25 15:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d19d8218a399 7014711: Fork HS20 to HS21 - renumber Major and build numbers of JVM Summary: Update the Major and Build numbers for HS21 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ccfcb502af3f Author: dholmes Date: 2011-01-25 00:14 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ccfcb502af3f 6566340: Restore use of stillborn flag to signify a thread that was stopped before it started Summary: Restore use of stillborn flag Reviewed-by: acorn, alanb ! src/share/vm/prims/jvm.cpp ! src/share/vm/runtime/thread.cpp Changeset: 515cc1a31fd1 Author: dcubed Date: 2011-01-26 21:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/515cc1a31fd1 Merge Changeset: bb2c2878f134 Author: twisti Date: 2011-01-20 08:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bb2c2878f134 7011839: JSR 292 turn on escape analysis when using invokedynamic Summary: Currently escape analysis is turned off when EnableInvokeDynamic is true. Reviewed-by: jrose, kvn ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/runtime/arguments.cpp Changeset: a7367756024b Author: twisti Date: 2011-01-21 01:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a7367756024b Merge ! src/share/vm/ci/bcEscapeAnalyzer.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.cpp - src/share/vm/gc_implementation/g1/concurrentZFThread.hpp Changeset: 403dc4c1d7f5 Author: never Date: 2011-01-21 13:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/403dc4c1d7f5 6809483: hotspot:::method_entry are not correctly generated for "method()V" Reviewed-by: iveresov, twisti ! src/share/vm/c1/c1_Canonicalizer.cpp ! src/share/vm/c1/c1_Canonicalizer.hpp ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_InstructionPrinter.cpp ! src/share/vm/c1/c1_InstructionPrinter.hpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_ValueMap.hpp Changeset: aa4b04b68652 Author: never Date: 2011-01-21 13:03 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/aa4b04b68652 Merge ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: e4fee0bdaa85 Author: never Date: 2011-01-24 13:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e4fee0bdaa85 7008809: should report the class in ArrayStoreExceptions from compiled code Reviewed-by: iveresov, twisti ! src/cpu/sparc/vm/c1_CodeStubs_sparc.cpp ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp ! src/cpu/x86/vm/c1_CodeStubs_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/share/vm/c1/c1_CodeStubs.hpp ! src/share/vm/c1/c1_LIR.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/c1/c1_Runtime1.hpp Changeset: f966c66b5463 Author: iveresov Date: 2011-01-25 14:38 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f966c66b5463 7014247: CTW fails when compile sun/misc/AtomicLongCSImpl (REMOVED from JDK7) Summary: Use lea to compute field address in AtomicLongCSImpl::attemptUpdate() intrinsic on x86. Reviewed-by: never, kvn ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp Changeset: 635b068a7224 Author: twisti Date: 2011-01-27 08:47 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/635b068a7224 Merge ! src/cpu/sparc/vm/c1_Runtime1_sparc.cpp Changeset: 9846d99e16d3 Author: twisti Date: 2011-01-27 14:05 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9846d99e16d3 Merge Changeset: a672e43650cc Author: tonyp Date: 2011-01-21 11:30 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/a672e43650cc 7013718: G1: small fixes for two assert/guarantee failures Summary: Two small fixes to deal with a guarantee failure (the marking thread should join the SuspendibleThreadSet before calling a method that does pause prediction work so that said method is never called during a pause) and an assert failure (an assert is too strong). Reviewed-by: iveresov, johnc ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp Changeset: 97ba643ea3ed Author: tonyp Date: 2011-01-25 17:58 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/97ba643ea3ed 7014261: G1: RSet-related failures Summary: A race between the concurrent cleanup thread and the VM thread while it is processing the "expanded sparse table list" causes both threads to try to free the same sparse table entry and either causes one of the threads to fail or leaves the entry in an inconsistent state. The solution is purge all entries on the expanded list that correspond go regions that are being cleaned up. Reviewed-by: brutisso, johnc ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: 234761c55641 Author: johnc Date: 2011-01-25 10:56 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/234761c55641 6608385: G1: need to support parallel reference processing Summary: Implement support for ParallelRefProcEnabled in the reference processing that takes place at the end of G1 concurrent marking. Reviewed-by: tonyp, ysr ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 81668b1f4877 Author: johnc Date: 2011-01-26 09:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/81668b1f4877 Merge ! src/share/vm/gc_implementation/g1/concurrentMark.cpp Changeset: 27e4ea99855d Author: johnc Date: 2011-01-27 13:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/27e4ea99855d Merge ! src/share/vm/runtime/arguments.cpp Changeset: 3582bf76420e Author: coleenp Date: 2011-01-27 16:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/3582bf76420e 6990754: Use native memory and reference counting to implement SymbolTable Summary: move symbols from permgen into C heap and reference count them Reviewed-by: never, acorn, jmasa, stefank ! agent/src/share/classes/sun/jvm/hotspot/CommandProcessor.java ! agent/src/share/classes/sun/jvm/hotspot/HotSpotTypeDataBase.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeLoadConstant.java ! agent/src/share/classes/sun/jvm/hotspot/interpreter/BytecodeWithKlass.java ! agent/src/share/classes/sun/jvm/hotspot/memory/DictionaryEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/LoaderConstraintEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/PlaceholderEntry.java ! agent/src/share/classes/sun/jvm/hotspot/memory/StringTable.java ! agent/src/share/classes/sun/jvm/hotspot/memory/SymbolTable.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ConstantPool.java ! agent/src/share/classes/sun/jvm/hotspot/oops/GenerateOopMap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/InstanceKlass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Klass.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Method.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! agent/src/share/classes/sun/jvm/hotspot/oops/Symbol.java - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassWriter.java ! agent/src/share/classes/sun/jvm/hotspot/types/Field.java ! agent/src/share/classes/sun/jvm/hotspot/ui/classbrowser/HTMLGenerator.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/Hashtable.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HashtableEntry.java ! agent/src/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/os/solaris/dtrace/generateJvmOffsets.cpp ! src/os/solaris/dtrace/jhelper.d ! src/os/solaris/dtrace/libjvm_db.c ! src/os/solaris/vm/dtraceJSDT_solaris.cpp ! src/share/vm/ci/ciClassList.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciField.cpp ! src/share/vm/ci/ciInstanceKlass.cpp ! src/share/vm/ci/ciKlass.cpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/ci/ciObjArrayKlass.cpp ! src/share/vm/ci/ciObject.hpp ! src/share/vm/ci/ciObjectFactory.cpp ! src/share/vm/ci/ciObjectFactory.hpp ! src/share/vm/ci/ciSignature.cpp ! src/share/vm/ci/ciSignature.hpp ! src/share/vm/ci/ciSymbol.cpp ! src/share/vm/ci/ciSymbol.hpp - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp ! src/share/vm/ci/compilerInterface.hpp ! src/share/vm/classfile/classFileError.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/classFileParser.hpp ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/classfile/classLoader.hpp ! src/share/vm/classfile/dictionary.cpp ! src/share/vm/classfile/dictionary.hpp ! src/share/vm/classfile/javaAssertions.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/loaderConstraints.cpp ! src/share/vm/classfile/loaderConstraints.hpp ! src/share/vm/classfile/placeholders.cpp ! src/share/vm/classfile/placeholders.hpp ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/stackMapFrame.cpp ! src/share/vm/classfile/stackMapFrame.hpp ! src/share/vm/classfile/stackMapTable.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verificationType.cpp ! src/share/vm/classfile/verificationType.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/classfile/vmSymbols.cpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/code/compiledIC.cpp ! src/share/vm/code/dependencies.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/compiler/compileLog.hpp ! src/share/vm/compiler/compilerOracle.cpp ! src/share/vm/compiler/compilerOracle.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/g1MarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.cpp ! src/share/vm/gc_implementation/parallelScavenge/pcTasks.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/concurrentGCThread.cpp ! src/share/vm/gc_implementation/shared/markSweep.cpp ! src/share/vm/interpreter/bytecode.cpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeTracer.cpp ! src/share/vm/interpreter/interpreter.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/linkResolver.cpp ! src/share/vm/interpreter/linkResolver.hpp ! src/share/vm/memory/classify.cpp ! src/share/vm/memory/compactingPermGenGen.cpp ! src/share/vm/memory/compactingPermGenGen.hpp ! src/share/vm/memory/dump.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/iterator.hpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/restore.cpp ! src/share/vm/memory/serialize.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayKlass.cpp ! src/share/vm/oops/arrayKlass.hpp ! src/share/vm/oops/arrayOop.cpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/oops/instanceKlassKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/klassKlass.cpp ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/oops/klassVtable.hpp ! src/share/vm/oops/markOop.hpp ! src/share/vm/oops/methodKlass.cpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/objArrayKlass.cpp ! src/share/vm/oops/objArrayKlassKlass.cpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp + src/share/vm/oops/symbol.cpp + src/share/vm/oops/symbol.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/precompiled.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm_misc.hpp ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/prims/jvmtiClassFileReconstituter.hpp ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/methodComparator.cpp ! src/share/vm/prims/methodHandleWalk.cpp ! src/share/vm/prims/methodHandleWalk.hpp ! src/share/vm/prims/methodHandles.cpp ! src/share/vm/prims/methodHandles.hpp ! src/share/vm/prims/nativeLookup.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/fieldDescriptor.hpp ! src/share/vm/runtime/fieldType.cpp ! src/share/vm/runtime/fieldType.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/handles.hpp ! src/share/vm/runtime/interfaceSupport.cpp ! src/share/vm/runtime/interfaceSupport.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/objectMonitor.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/runtime/reflection.hpp ! src/share/vm/runtime/reflectionUtils.hpp ! src/share/vm/runtime/rframe.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp ! src/share/vm/runtime/signature.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vframe.cpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vmStructs.hpp ! src/share/vm/runtime/vm_operations.cpp ! src/share/vm/runtime/vm_operations.hpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/classLoadingService.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/management.cpp ! src/share/vm/services/management.hpp ! src/share/vm/services/memoryManager.cpp ! src/share/vm/services/memoryPool.cpp ! src/share/vm/services/memoryService.cpp ! src/share/vm/services/threadService.cpp ! src/share/vm/utilities/debug.cpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/exceptions.cpp ! src/share/vm/utilities/exceptions.hpp ! src/share/vm/utilities/hashtable.cpp ! src/share/vm/utilities/hashtable.hpp ! src/share/vm/utilities/hashtable.inline.hpp ! src/share/vm/utilities/utf8.cpp ! src/share/vm/utilities/utf8.hpp ! src/share/vm/utilities/xmlstream.cpp ! src/share/vm/utilities/xmlstream.hpp Changeset: ae4b185f2ed1 Author: trims Date: 2011-02-03 23:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/ae4b185f2ed1 Merge ! .hgtags - agent/src/share/classes/sun/jvm/hotspot/oops/SymbolKlass.java - src/share/vm/ci/ciSymbolKlass.cpp - src/share/vm/ci/ciSymbolKlass.hpp - src/share/vm/oops/symbolKlass.cpp - src/share/vm/oops/symbolKlass.hpp - src/share/vm/oops/symbolOop.cpp - src/share/vm/oops/symbolOop.hpp Changeset: 55b9f498dbce Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/55b9f498dbce Added tag jdk7-b129 for changeset ae4b185f2ed1 ! .hgtags Changeset: 14c2f31280dd Author: trims Date: 2011-02-11 14:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/14c2f31280dd Added tag hs21-b01 for changeset ae4b185f2ed1 ! .hgtags From lana.steuck at oracle.com Tue Feb 15 19:33:35 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 15 Feb 2011 19:33:35 +0000 Subject: hg: jdk7/tl/jdk: 6 new changesets Message-ID: <20110215193449.02C6F47782@hg.openjdk.java.net> Changeset: 001dcfd0be4b Author: ohair Date: 2011-02-08 16:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/001dcfd0be4b 7016976: Documentation for required ant version on JDK7 builds on Solaris 10 and Solaris 11 Reviewed-by: rinaldo ! make/common/shared/Defs-versions.gmk ! make/common/shared/Sanity.gmk Changeset: 1f056ddda771 Author: ohair Date: 2011-01-28 14:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f056ddda771 7014301: Change make 3.81 sanity check to a fatal, 3.81 is needed now Reviewed-by: alanb ! make/common/shared/Sanity.gmk Changeset: 3f77dae85c85 Author: ohair Date: 2011-02-08 13:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3f77dae85c85 Merge Changeset: 14cd5d54a8d0 Author: ohair Date: 2011-02-08 20:00 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/14cd5d54a8d0 Merge ! make/common/shared/Sanity.gmk Changeset: 326aac19a89f Author: cl Date: 2011-02-10 16:24 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/326aac19a89f Added tag jdk7-b129 for changeset 14cd5d54a8d0 ! .hgtags Changeset: b578c9ccfb01 Author: lana Date: 2011-02-15 08:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b578c9ccfb01 Merge From philip.race at oracle.com Tue Feb 15 20:23:11 2011 From: philip.race at oracle.com (Phil Race) Date: Tue, 15 Feb 2011 12:23:11 -0800 Subject: Zlib level in JDK7 In-Reply-To: References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> Message-ID: <4D5AE0AF.3070509@oracle.com> On 2/15/2011 6:07 AM, Dr Andrew John Hughes wrote: > > Yes, IcedTea uses system libraries for everything bar LCMS, where > local changes in OpenJDK mean we are still forced to use the in-tree > version. There hasn't been any success upstreaming these changes, > though I haven't looked at LCMS 2.x. LittleCMS 1.x didn't provide the support necessary to pass JCK. So we talked to the LittleCMS maintainer and he added the necessary APIs in 2.0 JDK 7 has had LittleCMS 2.0 for almost 6 months now and that is included without any code modifications, so I think it should now be possible to use a system library, although we didn't do the work to actually enable that, so its built into a JDK library which has the littlecms code and the glue code. We need to provide the ability to separate these. When we pushed LCMS 2.0, I asked for a bug to be filed to remember to do this work but I can't find it in the database. I'll ask for that to be filed if it wasn't already. NB It didn't seem super-urgent since we pulled in LCMS 2.0 relatively soon after its release we thought shipping distros weren't likely to have the library upgrade anyway, but that's probably changing. -phil. From dmytro_sheyko at hotmail.com Wed Feb 16 11:47:11 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Wed, 16 Feb 2011 18:47:11 +0700 Subject: sun.cpu.isalist In-Reply-To: <4D5A4EA9.2040404@oracle.com> References: <4D59D310.2020800@oracle.com>,<4D5A4EA9.2040404@oracle.com> Message-ID: Hi, I have tried 1.7.0-ea-b129 and 1.6.0_24-b07 on Solaris 11 and they both have shown empty "sun.cpu.isalist". At the same time isalist output is: "amd64 pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86" The code that fills "sun.cpu.isalist" on Soliaris/Linux is following #ifdef SI_ISALIST /* supported instruction sets */ { char list[258]; sysinfo(SI_ISALIST, list, sizeof(list)); sprops.cpu_isalist = strdup(list); } #else sprops.cpu_isalist = NULL; #endif and in order to use sysinfo(SI_ISALIST) API we have to include header #include However this header is not included in java_props_md.c! So, neither Solaris nor Linux fills "sun.cpu.isalist". Only Windows does. But again Windows does this slightly differently. It shows "amd64" on 64bit jre and "pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86" on 32bit. I can find only this bug report, which is likely related to the issue. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6340855 sun.cpu.isalist property is empty in jinfo It seems that this property hasn't been not filled properly so long. Is it hard drop it at all? Thanks, Dmytro > Date: Tue, 15 Feb 2011 10:00:09 +0000 > From: Alan.Bateman at oracle.comt > To: David.Holmes at oracle.com > CC: dmytro_sheyko at hotmail.com; serviceability-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: sun.cpu.isalist > > David Holmes wrote: > > : > > I don't see the property actually being used anywhere these days. No > > idea what it may have been used for other than printing the property > > for information (there's a Java2D demo that does that). > > > > Is there an API on Linux that will provide the information? Both > > Solaris and Windows have a "sys info" call that can provide this > > information. But Linux sysinfo is something different. > > I checked the pre-OpenJDK history and it seems to have been added in > 1999 without explanation. I can only guess that it was something added > for some Solaris service. It doesn't appear to have ever been documented > and I doubt it is used. > > -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From spoole at linux.vnet.ibm.com Wed Feb 16 11:55:03 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Wed, 16 Feb 2011 11:55:03 +0000 Subject: Zlib level in JDK7 In-Reply-To: <4D5AB545.2000206@oracle.com> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AB545.2000206@oracle.com> Message-ID: <1297857303.8248.10.camel@jazzette> On Tue, 2011-02-15 at 09:17 -0800, Xueming Shen wrote: > One of the benefits of using a 5-year old version is that it has been > thoroughly tested by > various software for 5 years, given we actually don't have lots of tests > for zlib ourself, this > is very important, at least for me, when considering upgrade, especially > at this late stage I can appreciate why you want to be cautious right now - but it is important that the codebase is regularly upgraded. If IcedTea have shown that 1.2.5 is "ok" then I'd say the risk is quite low. For JDK 8 it would make sense to discuss the pros and cons of relying on the system version of zlib. I can make the case either way though. > of the release I would be very cautious to do it. While the changelog > lists a "long" list of > changes from 1.2.3. to 1.2.4, most of them are in code that are not > included in JDK, So the risk is even lower then? :-) > the > only thing that might bring in some enhancement is "Faster Z_HUFFMAN_ONLY > compression for images and other specialized compression", but given my > experience > of measuring the improvement in the past, I doubt you actually benefit > from it in most of > the use scenario. > I'm not sure this is about any particular improvement - its really just about keeping current with someone else's codebase. > -Sherman > > On 2/15/2011 5:57 AM, Alan Bateman wrote: > > Steve Poole wrote: > >> Hi all, > >> JDK7 is using zlib 1.2.3 (which was added to JDK7 back in 2009.) > >> Zlib's latest version is 1.2.5 - is there any expectation to move to > >> 1.2.5 in JDK7? It seems a real shame to ship JDK7 with a version of > >> zlib that is so out of date. > >> More than happy to help contribute towards making this happen. I would > >> like to know if its already on someone's radar though or to understand > >> why this is a mad idea :-) > >> > >> Cheers > >> > >> Steve > > I don't think it's on anyone's radar. Sherman did the last update, > > bringing us up from a patched 1.1.3 to 1.2.3. The main thing with zlib > > updates is testing and bake time. Have you done any testing with > > 1.2.5? While there are some good reasons listed in the ChangeLog, I'm > > curious if they translate into any measurable improvement with the zip > > APIs. On the testing it would be interesting to check if 1.2.5 is used > > by any of the distros as I think (but might be wrong) that > > OpenJDK/IcedTea6 project have changes to use /usr/lib/libzip.so rather > > than the snapshot in the jdk repository and so might already have > > experience using the latest version. > > > > -Alan > From Alan.Bateman at oracle.com Wed Feb 16 12:33:41 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Feb 2011 12:33:41 +0000 Subject: sun.cpu.isalist In-Reply-To: References: <4D59D310.2020800@oracle.com>, <4D5A4EA9.2040404@oracle.com> Message-ID: <4D5BC425.8090101@oracle.com> Dmytro Sheyko wrote: > Hi, > > I have tried 1.7.0-ea-b129 and 1.6.0_24-b07 on Solaris 11 and they > both have shown empty "sun.cpu.isalist". > > At the same time isalist output is: "amd64 pentium_pro+mmx pentium_pro > pentium+mmx pentium i486 i386 i86" > > The code that fills "sun.cpu.isalist" on Soliaris/Linux is following > > #ifdef SI_ISALIST > /* supported instruction sets */ > { > char list[258]; > sysinfo(SI_ISALIST, list, sizeof(list)); > sprops.cpu_isalist = strdup(list); > } > #else > sprops.cpu_isalist = NULL; > #endif > > and in order to use sysinfo(SI_ISALIST) API we have to include header > > #include > > However this header is not included in java_props_md.c! > So, neither Solaris nor Linux fills "sun.cpu.isalist". Only Windows does. > But again Windows does this slightly differently. It shows > "amd64" on 64bit jre and > "pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86" on 32bit. > > I can find only this bug report, which is likely related to the issue. > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6340855 > sun.cpu.isalist property is empty in jinfo > > It seems that this property hasn't been not filled properly so long. > Is it hard drop it at all? Good sleuthing. It looks like jdk5 was the last release to compile in that code on Solaris. This does support the case for removing it. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Feb 16 12:39:27 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 16 Feb 2011 12:39:27 +0000 Subject: hg: jdk7/tl/jdk: 6562203: Thread doesn't terminate immediately if it was stopped before start Message-ID: <20110216123950.CADE8477B9@hg.openjdk.java.net> Changeset: afa89f8ab9c8 Author: chegar Date: 2011-02-16 12:38 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/afa89f8ab9c8 6562203: Thread doesn't terminate immediately if it was stopped before start Reviewed-by: dholmes, alanb ! src/share/classes/java/lang/Thread.java - test/java/lang/Thread/StopBeforeStart.java From Alan.Bateman at oracle.com Wed Feb 16 12:53:38 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Feb 2011 12:53:38 +0000 Subject: Zlib level in JDK7 In-Reply-To: <1297857303.8248.10.camel@jazzette> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AB545.2000206@oracle.com> <1297857303.8248.10.camel@jazzette> Message-ID: <4D5BC8D2.9030205@oracle.com> Steve Poole wrote: > : > I can appreciate why you want to be cautious right now - but it is > important that the codebase is regularly upgraded. If IcedTea have shown > that 1.2.5 is "ok" then I'd say the risk is quite low. > > For JDK 8 it would make sense to discuss the pros and cons of relying on > the system version of zlib. I can make the case either way though. > We should probably add a build option around this so there is the option of using the system zip library in preference to compiling the zlib copy in the repository. However, I don't think we can get away from keeping a copy in the repository as we need to be able to compile to platforms that don't have zlib. Do you have cycles to do testing with zlib 1.2.5, ideally on platforms other than Linux? (I suggest platforms other than Linux as it does appear that this version is used there and it would really help to get confirmation that all is well on other platforms too). -Alan. From mark.reinhold at oracle.com Wed Feb 16 16:13:15 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 16 Feb 2011 08:13:15 -0800 Subject: sun.cpu.isalist In-Reply-To: alan.bateman@oracle.com; Wed, 16 Feb 2011 12:33:41 GMT; <4D5BC425.8090101@oracle.com> Message-ID: <20110216161315.3669029B3@eggemoggin.niobe.net> > Date: Wed, 16 Feb 2011 12:33:41 +0000 > From: alan.bateman at oracle.com > ... > > Good sleuthing. It looks like jdk5 was the last release to compile in that code > on Solaris. This does support the case for removing it. Agreed. - Mark From xueming.shen at oracle.com Wed Feb 16 19:11:56 2011 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 16 Feb 2011 19:11:56 +0000 Subject: hg: jdk7/tl/jdk: 6999337: java.exe fails to start if some directory names in path to java binaries contain Russian characters Message-ID: <20110216191206.A4CFE477CF@hg.openjdk.java.net> Changeset: dbc74475822f Author: sherman Date: 2011-02-16 11:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbc74475822f 6999337: java.exe fails to start if some directory names in path to java binaries contain Russian characters Summary: updated to make sure the system properties are accessable by vm during initialization Reviewed-by: alanb, mchung ! src/share/classes/java/lang/System.java From stuart.marks at oracle.com Thu Feb 17 02:32:54 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 17 Feb 2011 02:32:54 +0000 Subject: hg: jdk7/tl/jdk: 7018392: update URLJarFile.java to use try-with-resources Message-ID: <20110217023328.06C0747805@hg.openjdk.java.net> Changeset: 6e33b377aa6e Author: smarks Date: 2011-02-16 18:22 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6e33b377aa6e 7018392: update URLJarFile.java to use try-with-resources Reviewed-by: alanb, chegar, hawtin ! src/share/classes/sun/net/www/protocol/jar/URLJarFile.java From spoole at linux.vnet.ibm.com Thu Feb 17 07:15:56 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Thu, 17 Feb 2011 07:15:56 +0000 Subject: Zlib level in JDK7 In-Reply-To: <4D5BC8D2.9030205@oracle.com> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AB545.2000206@oracle.com> <1297857303.8248.10.camel@jazzette> <4D5BC8D2.9030205@oracle.com> Message-ID: <1297926956.2358.4.camel@jazzette> On Wed, 2011-02-16 at 12:53 +0000, Alan Bateman wrote: > Steve Poole wrote: > > : > > I can appreciate why you want to be cautious right now - but it is > > important that the codebase is regularly upgraded. If IcedTea have shown > > that 1.2.5 is "ok" then I'd say the risk is quite low. > > > > For JDK 8 it would make sense to discuss the pros and cons of relying on > > the system version of zlib. I can make the case either way though. > > > We should probably add a build option around this so there is the option > of using the system zip library in preference to compiling the zlib copy > in the repository. However, I don't think we can get away from keeping a > copy in the repository as we need to be able to compile to platforms > that don't have zlib. > > Do you have cycles to do testing with zlib 1.2.5, ideally on platforms > other than Linux? (I suggest platforms other than Linux as it does > appear that this version is used there and it would really help to get > confirmation that all is well on other platforms too). > What sort of testing did you have in mind? You mean run the zlib tests and/or OpenJDK testcases? > -Alan. > > > From lvjing at linux.vnet.ibm.com Thu Feb 17 08:22:44 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Thu, 17 Feb 2011 16:22:44 +0800 Subject: BufferedOutputStream does not throw exception after it's closed In-Reply-To: <4D3EEC37.5050004@univ-mlv.fr> References: <4D3EE928.1030701@linux.vnet.ibm.com> <4D3EEC37.5050004@univ-mlv.fr> Message-ID: <4D5CDAD4.4040704@linux.vnet.ibm.com> ? 2011-1-25 23:28, R?mi Forax ??: > On 01/25/2011 04:15 PM, Jing LV wrote: >> Hello, > Hi, you should report it as a bug even if I think that too many programs > rely on that semantics so the spec should be updated instead of the > implementation. > >> Find a similar problem with the one in the last mail(BufferedWriter), >> this time is BufferedOutputStream, and it has a delegated output stream >> and behave the same with BufferedWriter, I believe the two problems are >> just the same - it needs to check the open status before store the >> contents even if it does not need to flush. A similar testcase can be: >> private int bufferSize = 1024; >> public void test() throws Exception { >> OutputStream out = new BufferedOutputStream(new >> ClosableByteArrayOutputStream(), bufferSize); >> out.close(); >> >> try { >> out.write(new byte[] { 7, 3, 4, 5 }); >> fail("expected already closed exception"); >> } catch (IOException expected) { >> } >> } >> >> private static class ClosableByteArrayOutputStream extends OutputStream { >> private final ByteArrayOutputStream bytesOut = new ByteArrayOutputStream(); >> >> private boolean closed = false; >> @Override >> public void close() throws IOException { >> closed = true; >> } >> >> @Override >> public void write(int oneByte) throws IOException { >> if (closed) { >> throw new IOException(); >> } >> bytesOut.write(oneByte); >> } >> } >> >> Any comments? I'd like to raise this problem on the bug-tracker system. > R?mi > > Thanks Remi. I've report this issue on the openjdk bugzilla. Any other comments on this? Can someone help to raise this issue on Sun bug system? Thanks in advance. -- Best Regards, Jimmy, Jing LV From lvjing at linux.vnet.ibm.com Thu Feb 17 08:24:23 2011 From: lvjing at linux.vnet.ibm.com (Jing LV) Date: Thu, 17 Feb 2011 16:24:23 +0800 Subject: A HashMap bug with a Proxy value? In-Reply-To: <4D36A981.5030802@linux.vnet.ibm.com> References: <4D2DCE76.4000108@linux.vnet.ibm.com>, <4D2DDA16.5070903@oracle.com> <4D2DDDDE.4090206@oracle.com>, <4D2E965C.5080403@linux.vnet.ibm.com> <4D36A981.5030802@linux.vnet.ibm.com> Message-ID: <4D5CDB37.7050809@linux.vnet.ibm.com> Hello, is there any other comments on this issue? Can someone help raise a bug on Sun's bug system? Thanks. ? 2011-1-19 17:06, Jing LV ??: > Hi, > > Thanks for information. I've raised a new bug on openjdk bug > system (https://bugs.openjdk.java.net/show_bug.cgi?id=100165) with > testcase and patch. > > ? 2011-1-14 1:46, Jason Mehrens ??: >> >> > I wonder the design for Proxy and InvocationHandler can be >> > enhanced by creating a default equals/toString/hashCode implementation >> > for Proxy correctly, not ask developers to do it again and again >> > whenever he uses Proxy. Anyway, this may be another story. >> >> See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4652876 >> >> The ProxyGenerator could safely add byte codes to >> equals/compareTo/compare that: >> 1. Handle the null case per contract: false, NPE, call handler. >> 2. Proxy == Argument: true, 0, 0 >> 3. Proxy.getClass() == Argument.getClass() && Proxy.h == >> Proxy.getClass().cast(argument).h: true,0,0 >> >> The problem is short circuit operations nor return value overrides >> are not allowed per the Proxy contract: "A method invocation on a >> proxy instance through one of its proxy interfaces will be dispatched >> to the invoke method of the instance's invocation handler...the >> result that it returns will be returned as the result of the method >> invocation on the proxy instance." >> >> I think for most equality checks, short circuit would be for the >> most part safe since most Collections all ready do such checks but, >> it requires a change to the Proxy contract which presents >> a compatibility problem. >> >> >> > I think for HashMap, it may be benefit to check "==" as well as equals >> > in containsValue() (as containsKey already do) which is a quick >> solution >> > to resolve such problems. >> >> Seems like the identity check would be a win: >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486197 >> >> Jason >> >> > -- Best Regards, Jimmy, Jing LV -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhouyx at linux.vnet.ibm.com Thu Feb 17 08:46:03 2011 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Thu, 17 Feb 2011 16:46:03 +0800 Subject: Behavior of java.io.FileOutputStream.getChannel() does not match the spec Message-ID: Hi, I find there is a mismatch between the spec and the behavior of java.io.FileOutputStream.getChannel(). The spec reads: "The initial position of the returned channel will be equal to the number of bytes written to the file so far unless this stream is in append mode, in which case it will be equal to the size of the file. " But we'll get size 0 in such situation. Here is the testcase: //Testcase import java.io.*; public class FileOutputStreamTest{ public static void main(String args[]) throws Exception{ File tmpfile = File.createTempFile("FileOutputStream", "tmp"); tmpfile.deleteOnExit(); FileOutputStream fos = new FileOutputStream(tmpfile, false); fos.write(new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); fos.close(); fos = new FileOutputStream(tmpfile, true); long size = fos.getChannel().position(); if (10 != size){ // This return value is 0, mismatching the spec System.out.println("Position Error Detected: except 10, but was " + size); } fos.close(); } } // End of the testcase Any comments? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 17 09:01:36 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Feb 2011 09:01:36 +0000 Subject: BufferedOutputStream does not throw exception after it's closed In-Reply-To: <4D5CDAD4.4040704@linux.vnet.ibm.com> References: <4D3EE928.1030701@linux.vnet.ibm.com> <4D3EEC37.5050004@univ-mlv.fr> <4D5CDAD4.4040704@linux.vnet.ibm.com> Message-ID: <4D5CE3F0.1090704@oracle.com> Jing LV wrote: > : > Thanks Remi. I've report this issue on the openjdk bugzilla. > Any other comments on this? Can someone help to raise this issue on Sun > bug system? Thanks in advance. > > It's 7015589, sorry I should have been clearer in my mail of Jan 28 [1]. -Alan. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-January/005781.html From littlee at linux.vnet.ibm.com Thu Feb 17 09:19:56 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Thu, 17 Feb 2011 17:19:56 +0800 Subject: SocketPermission's implies() interesting behavior Message-ID: <4D5CE83C.7050009@linux.vnet.ibm.com> Hi guys, I am reading the SocketPermission source code recently and find some thing strange. Below is a simple test case to describe the strange thing: SocketPermission star_All = new SocketPermission("*.java.net", "listen,accept,connect"); SocketPermission www_All = new SocketPermission("java.net", "listen,accept,connect"); System.out.println(star_All.implies(www_All)); star_All = new SocketPermission("java.net", "listen,accept,connect"); www_All = new SocketPermission("java.net", "listen,accept,connect"); System.out.println(star_All.implies(www_All)); Return is false and true. The reason is: SocketPermission treat wildcard special. If the initial string has a wildcard, the cname comes from the substring. For example, the cname of "*.java.net" is ".java.net". (Why the first dot remains?) In my initial idea, "*.java.net" should imply "java.net". Any idea about it? More interestingly, I add "localhost.localdomain" and "mytest" pointing to the "127.0.0.1" in the /etc/hosts (Ubuntu) and rewrite the test case to: SocketPermission star_All = new SocketPermission("localhost.localdomain", "listen,accept,connect"); SocketPermission www_All = new SocketPermission("mytest", "listen,accept,connect"); System.out.println(star_All.implies(www_All)); Return is true. If on a multi-host machine, is it reasonable? By the way, I am curious about the reason why SocketPermission does not use the initial string as its cname, for example: SocketPermission star_All = new SocketPermission("*.blabla.bla", "listen,accept,connect"); SocketPermission www_All = new SocketPermission("bla.blabla.bla", "listen,accept,connect"); System.out.println(star_All.implies(www_All)); In the above test case, the two permission looks similiar. If using the initial string, I expect the return should be true. But it return false, because of the UnknowHostException. Any idea about this? From dmytro_sheyko at hotmail.com Thu Feb 17 09:21:19 2011 From: dmytro_sheyko at hotmail.com (Dmytro Sheyko) Date: Thu, 17 Feb 2011 16:21:19 +0700 Subject: A HashMap bug with a Proxy value? In-Reply-To: <4D5CDB37.7050809@linux.vnet.ibm.com> References: <4D2DCE76.4000108@linux.vnet.ibm.com>,,<4D2DDA16.5070903@oracle.com> <4D2DDDDE.4090206@oracle.com>, , <4D2E965C.5080403@linux.vnet.ibm.com>, , <4D36A981.5030802@linux.vnet.ibm.com>, <4D5CDB37.7050809@linux.vnet.ibm.com> Message-ID: Hi Jing LV, As for your patch of HashMap I think we shouldn't do this. There are a lot of places in code where we assume that every object equals to itself, not only in HashMap (e.g. ArrayList.indexOf()). In you case I believe that InvocationHandler impl is broken because it written that way that violates contract of hashCode()/equals(). Regards, Dmytro Date: Thu, 17 Feb 2011 16:24:23 +0800 From: lvjing at linux.vnet.ibm.com To: core-libs-dev at openjdk.java.net Subject: Re: A HashMap bug with a Proxy value? Hello, is there any other comments on this issue? Can someone help raise a bug on Sun's bug system? Thanks. ? 2011-1-19 17:06, Jing LV ??: Message body Hi, Thanks for information. I've raised a new bug on openjdk bug system (https://bugs.openjdk.java.net/show_bug.cgi?id=100165) with testcase and patch. ? 2011-1-14 1:46, Jason Mehrens ??: > I wonder the design for Proxy and InvocationHandler can be > enhanced by creating a default equals/toString/hashCode implementation > for Proxy correctly, not ask developers to do it again and again > whenever he uses Proxy. Anyway, this may be another story. See: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4652876 The ProxyGenerator could safely add byte codes to equals/compareTo/compare that: 1. Handle the null case per contract: false, NPE, call handler. 2. Proxy == Argument: true, 0, 0 3. Proxy.getClass() == Argument.getClass() && Proxy.h == Proxy.getClass().cast(argument).h: true,0,0 The problem is short circuit operations nor return value overrides are not allowed per the Proxy contract: "A method invocation on a proxy instance through one of its proxy interfaces will be dispatched to the invoke method of the instance's invocation handler...the result that it returns will be returned as the result of the method invocation on the proxy instance." I think for most equality checks, short circuit would be for the most part safe since most Collections all ready do such checks but, it requires a change to the Proxy contract which presents a compatibility problem. > I think for HashMap, it may be benefit to check "==" as well as equals > in containsValue() (as containsKey already do) which is a quick solution > to resolve such problems. Seems like the identity check would be a win: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6486197 Jason -- Best Regards, Jimmy, Jing LV -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Thu Feb 17 09:34:31 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Feb 2011 09:34:31 +0000 Subject: Behavior of java.io.FileOutputStream.getChannel() does not match the spec In-Reply-To: References: Message-ID: <4D5CEBA7.4090002@oracle.com> Sean Chou wrote: > Hi, > I find there is a mismatch between the spec and the behavior of > java.io.FileOutputStream.getChannel(). > > The spec reads: "The initial position of the returned channel will be > equal to the number of bytes written to the file so far unless this > stream is in append mode, in which case it will be equal to the size > of the file. " > > But we'll get size 0 in such situation. Here is the testcase: > > //Testcase > import java.io.*; > > public class FileOutputStreamTest{ > public static void main(String args[]) throws Exception{ > File tmpfile = File.createTempFile("FileOutputStream", "tmp"); > tmpfile.deleteOnExit(); > FileOutputStream fos = new FileOutputStream(tmpfile, false); > fos.write(new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); > fos.close(); > > fos = new FileOutputStream(tmpfile, true); > long size = fos.getChannel().position(); > if (10 != size){ > // This return value is 0, mismatching the spec > System.out.println("Position Error Detected: except 10, > but was " + size); > } > fos.close(); > } > } > // End of the testcase > > Any comments? > This is a long standing issue, 6526860 but hasn't been high priority as it probably isn't too common to query or change the file position when opened for append. -Alan. From chris.hegarty at oracle.com Thu Feb 17 09:57:21 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 17 Feb 2011 09:57:21 +0000 Subject: hg: jdk7/tl/jdk: 7017901: OOME in java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java Message-ID: <20110217095731.A02F147816@hg.openjdk.java.net> Changeset: 15ef6cf616d6 Author: chegar Date: 2011-02-17 09:56 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/15ef6cf616d6 7017901: OOME in java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java Summary: Unbounded queues should be disabled in the test Reviewed-by: alanb ! test/java/util/concurrent/BlockingQueue/CancelledProducerConsumerLoops.java From Alan.Bateman at oracle.com Thu Feb 17 10:20:48 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Feb 2011 10:20:48 +0000 Subject: Zlib level in JDK7 In-Reply-To: <1297926956.2358.4.camel@jazzette> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AB545.2000206@oracle.com> <1297857303.8248.10.camel@jazzette> <4D5BC8D2.9030205@oracle.com> <1297926956.2358.4.camel@jazzette> Message-ID: <4D5CF680.5000100@oracle.com> Steve Poole wrote: > : > What sort of testing did you have in mind? You mean run the zlib tests > and/or OpenJDK testcases? > To be honest, I don't know. The zip tests should clearly be run but they are unlikely to stress the zip code in the same way that the IDEs, app servers, and other big applications do. If there is a compelling reason to do another zlib update in 7 then I would suggest running as many of these as you can to increase the confidence that there won't be an issues. If this is too much work then it might be better to just prepare the patch to go in once jdk8 opens for business. -Alan. From forax at univ-mlv.fr Thu Feb 17 14:42:05 2011 From: forax at univ-mlv.fr (=?ISO-8859-1?Q?R=E9mi_Forax?=) Date: Thu, 17 Feb 2011 15:42:05 +0100 Subject: Behavior of java.io.FileOutputStream.getChannel() does not match the spec In-Reply-To: <4D5CEBA7.4090002@oracle.com> References: <4D5CEBA7.4090002@oracle.com> Message-ID: <4D5D33BD.7040501@univ-mlv.fr> On 02/17/2011 10:34 AM, Alan Bateman wrote: > Sean Chou wrote: >> Hi, >> I find there is a mismatch between the spec and the behavior of >> java.io.FileOutputStream.getChannel(). >> >> The spec reads: "The initial position of the returned channel will be >> equal to the number of bytes written to the file so far unless this >> stream is in append mode, in which case it will be equal to the size >> of the file. " >> >> But we'll get size 0 in such situation. Here is the testcase: >> >> //Testcase >> import java.io.*; >> >> public class FileOutputStreamTest{ >> public static void main(String args[]) throws Exception{ >> File tmpfile = File.createTempFile("FileOutputStream", "tmp"); >> tmpfile.deleteOnExit(); >> FileOutputStream fos = new FileOutputStream(tmpfile, false); >> fos.write(new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); >> fos.close(); >> >> fos = new FileOutputStream(tmpfile, true); >> long size = fos.getChannel().position(); >> if (10 != size){ >> // This return value is 0, mismatching the spec >> System.out.println("Position Error Detected: except >> 10, but was " + size); >> } >> fos.close(); >> } >> } >> // End of the testcase >> >> Any comments? >> > This is a long standing issue, 6526860 but hasn't been high priority > as it probably isn't too common to query or change the file position > when opened for append. > > -Alan. Anyway, it's a good idea to fix it :) R?mi From alan.bateman at oracle.com Thu Feb 17 20:55:10 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 17 Feb 2011 20:55:10 +0000 Subject: hg: jdk7/tl/jdk: 2 new changesets Message-ID: <20110217205530.8CC9447830@hg.openjdk.java.net> Changeset: 302877469037 Author: alanb Date: 2011-02-17 20:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/302877469037 6526860: (fc) FileChannel.position returns 0 when FileOutputStream opened in append mode Reviewed-by: forax ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/solaris/classes/sun/nio/fs/UnixChannelFactory.java ! test/java/nio/channels/FileChannel/Position.java Changeset: a5861eb81f3c Author: alanb Date: 2011-02-17 20:53 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a5861eb81f3c Merge From zhouyx at linux.vnet.ibm.com Fri Feb 18 04:24:33 2011 From: zhouyx at linux.vnet.ibm.com (Sean Chou) Date: Fri, 18 Feb 2011 12:24:33 +0800 Subject: Behavior of java.io.FileOutputStream.getChannel() does not match the spec In-Reply-To: <4D5CEBA7.4090002@oracle.com> References: <4D5CEBA7.4090002@oracle.com> Message-ID: Oh, I should have done a little more investigation. Is there a plan to fix it? I can provide a patch if it is needed. 2011/2/17 Alan Bateman > Sean Chou wrote: > >> Hi, >> I find there is a mismatch between the spec and the behavior of >> java.io.FileOutputStream.getChannel(). >> >> The spec reads: "The initial position of the returned channel will be >> equal to the number of bytes written to the file so far unless this >> stream is in append mode, in which case it will be equal to the size >> of the file. " >> >> But we'll get size 0 in such situation. Here is the testcase: >> >> //Testcase >> import java.io.*; >> >> public class FileOutputStreamTest{ >> public static void main(String args[]) throws Exception{ >> File tmpfile = File.createTempFile("FileOutputStream", "tmp"); >> tmpfile.deleteOnExit(); >> FileOutputStream fos = new FileOutputStream(tmpfile, false); >> fos.write(new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); >> fos.close(); >> >> fos = new FileOutputStream(tmpfile, true); >> long size = fos.getChannel().position(); >> if (10 != size){ >> // This return value is 0, mismatching the spec >> System.out.println("Position Error Detected: except 10, but >> was " + size); >> } >> fos.close(); >> } >> } >> // End of the testcase >> >> Any comments? >> >> This is a long standing issue, 6526860 but hasn't been high priority as > it probably isn't too common to query or change the file position when > opened for append. > > -Alan. > -- Best Regards, Sean Chou From coveringzyx at gmail.com Fri Feb 18 04:48:35 2011 From: coveringzyx at gmail.com (Yixun Zhou) Date: Fri, 18 Feb 2011 12:48:35 +0800 Subject: Behavior of java.io.FileOutputStream.getChannel() does not match the spec In-Reply-To: References: <4D5CEBA7.4090002@oracle.com> Message-ID: I missed the mail about the fix given by Alan, please just ignore the previous mail. 2011/2/18 Sean Chou > > Oh, I should have done a little more investigation. > > Is there a plan to fix it? I can provide a patch if it is needed. > > 2011/2/17 Alan Bateman > > Sean Chou wrote: >> >>> Hi, >>> I find there is a mismatch between the spec and the behavior of >>> java.io.FileOutputStream.getChannel(). >>> >>> The spec reads: "The initial position of the returned channel will be >>> equal to the number of bytes written to the file so far unless this >>> stream is in append mode, in which case it will be equal to the size >>> of the file. " >>> >>> But we'll get size 0 in such situation. Here is the testcase: >>> >>> //Testcase >>> import java.io.*; >>> >>> public class FileOutputStreamTest{ >>> public static void main(String args[]) throws Exception{ >>> File tmpfile = File.createTempFile("FileOutputStream", "tmp"); >>> tmpfile.deleteOnExit(); >>> FileOutputStream fos = new FileOutputStream(tmpfile, false); >>> fos.write(new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); >>> fos.close(); >>> >>> fos = new FileOutputStream(tmpfile, true); >>> long size = fos.getChannel().position(); >>> if (10 != size){ >>> // This return value is 0, mismatching the spec >>> System.out.println("Position Error Detected: except 10, but >>> was " + size); >>> } >>> fos.close(); >>> } >>> } >>> // End of the testcase >>> >>> Any comments? >>> >>> This is a long standing issue, 6526860 but hasn't been high priority as >> it probably isn't too common to query or change the file position when >> opened for append. >> >> -Alan. >> > > > > -- > Best Regards, > Sean Chou > > -- Best Regards, Yixun Zhou From sundararajan.a at sun.com Fri Feb 18 06:38:09 2011 From: sundararajan.a at sun.com (sundararajan.a at sun.com) Date: Fri, 18 Feb 2011 06:38:09 +0000 Subject: hg: jdk7/tl/jdk: 7018459: javax.script code comments have issues with HTML4 validation and Accessibility compliance Message-ID: <20110218063819.464BA4784F@hg.openjdk.java.net> Changeset: dd143033cef1 Author: sundar Date: 2011-02-18 12:07 +0530 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd143033cef1 7018459: javax.script code comments have issues with HTML4 validation and Accessibility compliance Reviewed-by: jjh ! src/share/classes/javax/script/ScriptEngineFactory.java From maurizio.cimadamore at oracle.com Fri Feb 18 12:29:45 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 18 Feb 2011 12:29:45 +0000 Subject: hg: jdk7/tl/langtools: 7020043: Project Coin: diamond allowed on non-generic type Message-ID: <20110218122950.335984785D@hg.openjdk.java.net> Changeset: 4ce95dc0b908 Author: mcimadamore Date: 2011-02-18 12:28 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4ce95dc0b908 7020043: Project Coin: diamond allowed on non-generic type Summary: Diamond oerator should be disallowed on non-generic class types (i.e. String) Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties + test/tools/javac/generics/diamond/neg/Neg12.java + test/tools/javac/generics/diamond/neg/Neg12.out From Alan.Bateman at oracle.com Fri Feb 18 15:57:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Feb 2011 15:57:49 +0000 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4D5CE83C.7050009@linux.vnet.ibm.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> Message-ID: <4D5E96FD.4040700@oracle.com> Charles Lee wrote: > Hi guys, > > I am reading the SocketPermission source code recently and find some > thing strange. It might be better to bring this to the net-dev list as that is where the networking code, including SocketPermission, is maintained. -Alan. From kumar.x.srinivasan at oracle.com Fri Feb 18 16:14:32 2011 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 18 Feb 2011 16:14:32 +0000 Subject: hg: jdk7/tl/langtools: 7018859: javac turn off the Zip optimization by default Message-ID: <20110218161434.B2C5C47865@hg.openjdk.java.net> Changeset: 3d45cc94ee0f Author: ksrini Date: 2011-02-18 08:12 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3d45cc94ee0f 7018859: javac turn off the Zip optimization by default Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! test/tools/javac/4241573/T4241573.java ! test/tools/javac/6508981/TestInferBinaryName.java ! test/tools/javac/api/6411310/Test.java ! test/tools/javac/api/T6838467.java ! test/tools/javac/api/T6877206.java From maurizio.cimadamore at oracle.com Fri Feb 18 16:18:19 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 18 Feb 2011 16:18:19 +0000 Subject: hg: jdk7/tl/langtools: 7020626: diamond: add diagnostic test for diamond and non-generic classes Message-ID: <20110218161821.8D8C847867@hg.openjdk.java.net> Changeset: 51e643f41a3a Author: mcimadamore Date: 2011-02-18 16:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/51e643f41a3a 7020626: diamond: add diagnostic test for diamond and non-generic classes Summary: Fix failure in regression test CheckExamples Reviewed-by: jjg + test/tools/javac/diags/examples/DiamondNonGeneric.java From spoole at linux.vnet.ibm.com Fri Feb 18 15:20:36 2011 From: spoole at linux.vnet.ibm.com (Steve Poole) Date: Fri, 18 Feb 2011 15:20:36 +0000 Subject: Zlib level in JDK7 In-Reply-To: <4D5CF680.5000100@oracle.com> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AB545.2000206@oracle.com> <1297857303.8248.10.camel@jazzette> <4D5BC8D2.9030205@oracle.com> <1297926956.2358.4.camel@jazzette> <4D5CF680.5000100@oracle.com> Message-ID: <1298042436.18623.22.camel@jazzette> On Thu, 2011-02-17 at 10:20 +0000, Alan Bateman wrote: > Steve Poole wrote: > > : > > What sort of testing did you have in mind? You mean run the zlib tests > > and/or OpenJDK testcases? > > > To be honest, I don't know. The zip tests should clearly be run but they > are unlikely to stress the zip code in the same way that the IDEs, app > servers, and other big applications do. Running zlibs own tests is unlikely to be too helpful. I'd be quite happy to run any JDK tests you have and there are also testcases in Apache Harmony for the related Java APIs. I'm curious to understand just what level of testing is already done though? > If there is a compelling reason > to do another zlib update in 7 then I would suggest running as many of > these as you can to increase the confidence that there won't be an > issues. I think this is simply about currency. Getting fixes from other projects usually has a list of drag-alongs. So the closer you can keep to their latest production level the smaller that list is , and consequently the lower the risk is, when you need a specific fix later. > If this is too much work then it might be better to just prepare > the patch to go in once jdk8 opens for business. > Agreed - I can imagine why zlib was embedded originally but I can't see why that should continue. It seem that the right direction is to remove the embedded code and rely on the platform providing the support. > -Alan. Steve From Alan.Bateman at oracle.com Fri Feb 18 19:30:00 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 18 Feb 2011 19:30:00 +0000 Subject: Zlib level in JDK7 In-Reply-To: <1298042436.18623.22.camel@jazzette> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AB545.2000206@oracle.com> <1297857303.8248.10.camel@jazzette> <4D5BC8D2.9030205@oracle.com> <1297926956.2358.4.camel@jazzette> <4D5CF680.5000100@oracle.com> <1298042436.18623.22.camel@jazzette> Message-ID: <4D5EC8B8.80605@oracle.com> Steve Poole wrote: > : > Running zlibs own tests is unlikely to be too helpful. I'd be quite > happy to run any JDK tests you have and there are also testcases in > Apache Harmony for the related Java APIs. I'm curious to understand > just what level of testing is already done though? > I wasn't clear. I meant the zip tests in the jdk repository rather than the zlib tests. The zip tests are in test/java/util/zip and test/java/util/jar. I don't know the Apache Harmony tests but if they can be be used with OpenJDK builds then great. > : > > Agreed - I can imagine why zlib was embedded originally but I can't see > why that should continue. It seem that the right direction is to remove > the embedded code and rely on the platform providing the support. > > That would work on platforms that have zlib installed (libzip on Linux, libz on Solaris, etc.) but my guess is that we would still need to build it on at least Windows. A possible starting point is a build option that determines whether it compiles the zlib copy in the repository or not. -Alan From stuart.marks at oracle.com Fri Feb 18 20:46:50 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 18 Feb 2011 20:46:50 +0000 Subject: hg: jdk7/tl/jdk: 7018385: update javax.sql classes to use try-with-resources Message-ID: <20110218204715.93B5447878@hg.openjdk.java.net> Changeset: 5bf920749b97 Author: smarks Date: 2011-02-18 12:43 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5bf920749b97 7018385: update javax.sql classes to use try-with-resources Reviewed-by: alanb, lancea, darcy ! src/share/classes/javax/sql/rowset/serial/SerialClob.java ! src/share/classes/javax/sql/rowset/spi/SyncFactory.java From joe.darcy at oracle.com Fri Feb 18 23:55:58 2011 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 18 Feb 2011 23:55:58 +0000 Subject: hg: jdk7/tl/langtools: 7020047: Project Coin: generate null-check around try-with-resources close call Message-ID: <20110218235600.5EC3C47894@hg.openjdk.java.net> Changeset: 75e25df50873 Author: darcy Date: 2011-02-18 15:55 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/75e25df50873 7020047: Project Coin: generate null-check around try-with-resources close call Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/TryWithResources/TwrNullTests.java From pbenedict at apache.org Sat Feb 19 00:14:11 2011 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 18 Feb 2011 18:14:11 -0600 Subject: hg: jdk7/tl/langtools: 7020047: Project Coin: generate null-check around try-with-resources close call In-Reply-To: <20110218235600.5EC3C47894@hg.openjdk.java.net> References: <20110218235600.5EC3C47894@hg.openjdk.java.net> Message-ID: Joe, I like how you snuck a little tribute to Leslie Nielsen in the test: "Nothing to see here, move along" http://www.youtube.com/watch?v=5NNOrp_83RU On Fri, Feb 18, 2011 at 5:55 PM, wrote: > Changeset: 75e25df50873 > Author: darcy > Date: 2011-02-18 15:55 -0800 > URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/75e25df50873 > > 7020047: Project Coin: generate null-check around try-with-resources close > call > Reviewed-by: jjg > > ! src/share/classes/com/sun/tools/javac/comp/Lower.java > + test/tools/javac/TryWithResources/TwrNullTests.java > > From chris.hegarty at oracle.com Fri Feb 18 16:20:14 2011 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 18 Feb 2011 16:20:14 +0000 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4D5CE83C.7050009@linux.vnet.ibm.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> Message-ID: <4D5E9C3E.3090200@oracle.com> [ bcc'ing off core-libs-dev and cc'ing (more appropriate) net-dev ] Hi Charles, I'm not sure I follow you here. I would not expect '*.java.net' to imply 'java.net'. I would however expect it to imply sub domains of java.net, i.e. openjdk.java.net -Chris. On 17/02/2011 09:19, Charles Lee wrote: > Hi guys, > > I am reading the SocketPermission source code recently and find some > thing strange. Below is a simple test case to describe the strange thing: > > SocketPermission star_All = new SocketPermission("*.java.net", > "listen,accept,connect"); > SocketPermission www_All = new SocketPermission("java.net", > "listen,accept,connect"); > System.out.println(star_All.implies(www_All)); > > star_All = new SocketPermission("java.net", "listen,accept,connect"); > www_All = new SocketPermission("java.net", "listen,accept,connect"); > System.out.println(star_All.implies(www_All)); > > Return is false and true. > > The reason is: > SocketPermission treat wildcard special. If the initial string has a > wildcard, the cname comes from the substring. For example, the cname of > "*.java.net" is ".java.net". (Why the first dot remains?) > In my initial idea, "*.java.net" should imply "java.net". Any idea about > it? > > More interestingly, I add "localhost.localdomain" and "mytest" pointing > to the "127.0.0.1" in the /etc/hosts (Ubuntu) and rewrite the test case to: > > SocketPermission star_All = new > SocketPermission("localhost.localdomain", "listen,accept,connect"); > SocketPermission www_All = new SocketPermission("mytest", > "listen,accept,connect"); > System.out.println(star_All.implies(www_All)); > > Return is true. > > If on a multi-host machine, is it reasonable? > > By the way, I am curious about the reason why SocketPermission does not > use the initial string as its cname, for example: > > SocketPermission star_All = new SocketPermission("*.blabla.bla", > "listen,accept,connect"); > SocketPermission www_All = new SocketPermission("bla.blabla.bla", > "listen,accept,connect"); > System.out.println(star_All.implies(www_All)); > > In the above test case, the two permission looks similiar. If using the > initial string, I expect the return should be true. But it return false, > because of the UnknowHostException. Any idea about this? From gnu_andrew at member.fsf.org Sun Feb 20 17:39:52 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Sun, 20 Feb 2011 17:39:52 +0000 Subject: Zlib level in JDK7 In-Reply-To: <4D5AE0AF.3070509@oracle.com> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AE0AF.3070509@oracle.com> Message-ID: On 15 February 2011 20:23, Phil Race wrote: > On 2/15/2011 6:07 AM, Dr Andrew John Hughes wrote: >> >> Yes, IcedTea uses system libraries for everything bar LCMS, where >> local changes in OpenJDK mean we are still forced to use the in-tree >> version. ?There hasn't been any success upstreaming these changes, >> though I haven't looked at LCMS 2.x. > > ? LittleCMS 1.x ?didn't provide the support necessary to pass JCK. So we > talked to > ? the LittleCMS maintainer and he added the necessary APIs in 2.0 > ? JDK 7 has had LittleCMS 2.0 for almost 6 months now and that is included > without any code > ? modifications, so I think it should now be possible to use a system > library, although > ? we didn't do the work to actually enable that, so its built into a JDK > library which > ? has the littlecms code and the glue code. We need to provide the ability > to separate these. > ? When we pushed LCMS 2.0, I asked for a bug to be filed to remember to do > this work > ? but I can't find it in the database. I'll ask for that to be filed if it > wasn't already. > ? NB It didn't seem super-urgent since we pulled in LCMS 2.0 relatively soon > after its release > ? we thought shipping distros weren't likely to have the library upgrade > anyway, but that's > ? probably changing. > > -phil. > > Hi Phil, Thanks for making me aware of this. I briefly glanced at some for the release notes for LCMS 2 when it was released, and saw something that may support the missing functionality, but never had chance to look in detail. I've also not had chance to look at OpenJDK 7 recently, so it's great to hear that support has already gone in. Do you have any idea as to whether this would be safe to backport to OpenJDK 6? I presume it doesn't alter any public API. I've not seen any use of OpenJDK 7 by distros as yet. We've managed with the other libraries without in-tree support by using local patching. There's a big libraries patch in IcedTea that would be nice to integrate but it would need considerable work to do optional system linking rather than the current brute force of deleting the in-tree version and always linking. There's also no TCK for 7 yet, which is I believe what caught many of the issues with missing LCMS support before. I did a quick survey of distro support for LCMS 2. It's in Gentoo (which is what made me aware of it), but Ubuntu, Debian and Fedora all seem to still be on the 1.x series. So it doesn't seem to be changing yet. Maybe OpenJDK could be the kick they need to support it? ;-) -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From littlee at linux.vnet.ibm.com Mon Feb 21 02:27:18 2011 From: littlee at linux.vnet.ibm.com (Charles Lee) Date: Mon, 21 Feb 2011 10:27:18 +0800 Subject: SocketPermission's implies() interesting behavior In-Reply-To: <4D5E96FD.4040700@oracle.com> References: <4D5CE83C.7050009@linux.vnet.ibm.com> <4D5E96FD.4040700@oracle.com> Message-ID: <4D61CD86.9090104@linux.vnet.ibm.com> On 02/18/2011 11:57 PM, Alan Bateman wrote: > Charles Lee wrote: >> Hi guys, >> >> I am reading the SocketPermission source code recently and find some >> thing strange. > It might be better to bring this to the net-dev list as that is where > the networking code, including SocketPermission, is maintained. > > -Alan. > Thanks Alan. I will bring it to the net dev. From mike.duigou at oracle.com Mon Feb 21 18:57:06 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Mon, 21 Feb 2011 10:57:06 -0800 Subject: 7001685: Renable EnumSetBash Test Message-ID: <492829E7-ACF4-49A0-8463-C3FE2EF75A2C@oracle.com> Hi All; I need a quick review for a very minor issue. An EnumSet unit test, EnumSetBash.java, is currently disabled but the bug which caused it to be disabled seems to no longer be reproducible. It is theorized that it had been failing due to a short lived HotSpot bug. This webrev merely re-enables the test. http://cr.openjdk.java.net/~mduigou/7001685/webrev.0/ Cheers! Mike From kelly.ohair at oracle.com Mon Feb 21 20:02:03 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 21 Feb 2011 12:02:03 -0800 Subject: 7001685: Renable EnumSetBash Test In-Reply-To: <492829E7-ACF4-49A0-8463-C3FE2EF75A2C@oracle.com> References: <492829E7-ACF4-49A0-8463-C3FE2EF75A2C@oracle.com> Message-ID: Ok with me. -kto On Feb 21, 2011, at 10:57 AM, Mike Duigou wrote: > Hi All; > > I need a quick review for a very minor issue. An EnumSet unit test, > EnumSetBash.java, is currently disabled but the bug which caused it > to be disabled seems to no longer be reproducible. It is theorized > that it had been failing due to a short lived HotSpot bug. This > webrev merely re-enables the test. > > http://cr.openjdk.java.net/~mduigou/7001685/webrev.0/ > > Cheers! > > Mike From Alan.Bateman at oracle.com Mon Feb 21 20:17:30 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 21 Feb 2011 20:17:30 +0000 Subject: 7001685: Renable EnumSetBash Test In-Reply-To: <492829E7-ACF4-49A0-8463-C3FE2EF75A2C@oracle.com> References: <492829E7-ACF4-49A0-8463-C3FE2EF75A2C@oracle.com> Message-ID: <4D62C85A.5060104@oracle.com> Mike Duigou wrote: > Hi All; > > I need a quick review for a very minor issue. An EnumSet unit test, EnumSetBash.java, is currently disabled but the bug which caused it to be disabled seems to no longer be reproducible. It is theorized that it had been failing due to a short lived HotSpot bug. This webrev merely re-enables the test. > > http://cr.openjdk.java.net/~mduigou/7001685/webrev.0/ > > Cheers! > > Mike If it only failed with C2 on sparc then it probably was a HotSpot bug. Removing it from the problem list is fine with me. -Alan. From mike.duigou at oracle.com Mon Feb 21 21:37:44 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 21 Feb 2011 21:37:44 +0000 Subject: hg: jdk7/tl/jdk: 7001685: Renable EnumSetBash Test Message-ID: <20110221213753.C945447934@hg.openjdk.java.net> Changeset: 42e4205db024 Author: mduigou Date: 2011-02-21 13:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/42e4205db024 7001685: Renable EnumSetBash Test Reviewed-by: alanb, ohair, darcy ! test/ProblemList.txt From mike.duigou at oracle.com Mon Feb 21 22:53:20 2011 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 21 Feb 2011 22:53:20 +0000 Subject: hg: jdk7/tl/jdk: 7019705: Add -XX:+AggressiveOpts options to MOAT test Message-ID: <20110221225330.7BCDB47938@hg.openjdk.java.net> Changeset: d26e79640fd4 Author: mduigou Date: 2011-02-21 14:53 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d26e79640fd4 7019705: Add -XX:+AggressiveOpts options to MOAT test Reviewed-by: alanb ! test/java/util/Collection/MOAT.java From David.Holmes at oracle.com Tue Feb 22 01:44:14 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 22 Feb 2011 11:44:14 +1000 Subject: FW: [concurrency-interest] ForkJoin Improvements Message-ID: FYI David Holmes -----Original Message----- From: concurrency-interest-bounces at cs.oswego.edu [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Doug Lea Sent: Tuesday, 22 February 2011 11:21 AM To: Concurrency-interest at cs.oswego.edu Subject: [concurrency-interest] ForkJoin Improvements Another round of improvements to ForkJoin framework is now available in the usual places (see below). The main change is an overhaul to core control that better avoids creating or restarting more threads than needed. You'll probably see better overall performance too. Also, exceptions stemming from user errors are now more informative. Please try these out let us know about any problems. Pasting from http://gee.cs.oswego.edu/dl/concurrency-interest/index.html jsr166y versions * API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/ * jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166y.jar (compiled using Java6 javac). * Browsable CVS sources: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/ java7 java.util.concurrent versions * API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/docs/ * jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar * Browsable CVS sources: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/ * Browsable CVS TCK test sources: http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/tests/tck/ You may be able to use these versions now, without waiting for JDK releases, by obtaining jsr166 jar and running java using the option -Xbootclasspath/p:jsr166.jar (You may need to precede "jsr166.jar" with its full file path.) _______________________________________________ Concurrency-interest mailing list Concurrency-interest at cs.oswego.edu http://cs.oswego.edu/mailman/listinfo/concurrency-interest From stuart.marks at oracle.com Tue Feb 22 02:05:01 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 21 Feb 2011 18:05:01 -0800 Subject: review request for 7021209, use try-with-resources in lang, math, util Message-ID: <4D6319CD.1010306@oracle.com> Hi all, The following webrev changes a variety of files in java.lang, math, and util, and their corresponding tests, to use the new Java 7 try-with-resources construct. I think most of the changes should be straightforward. In a few cases (e.g., Currency.java and LocalGregorianCalendar.java) there was no close() call in the original code so the open file was always leaked. Naoto, several of the util changes look like they're in the internationalization area. I don't know if you're the right person to review them; if not, please forward or cc this to the right person. Or, should I forward this to something like i18n-dev? Webrev is here: http://cr.openjdk.java.net/~smarks/reviews/7021209/webrev.0/ Thanks! s'marks From David.Holmes at oracle.com Tue Feb 22 02:24:29 2011 From: David.Holmes at oracle.com (David Holmes) Date: Tue, 22 Feb 2011 12:24:29 +1000 Subject: review request for 7021209, use try-with-resources in lang, math, util In-Reply-To: <4D6319CD.1010306@oracle.com> References: <4D6319CD.1010306@oracle.com> Message-ID: <4D631E5D.4060802@oracle.com> Hi Stuart, I'm unclear how try-with-resources applies in different cases. For example, here in Package.java: private static Manifest loadManifest(String fn) { try (FileInputStream fis = new FileInputStream(fn); JarInputStream jis = new JarInputStream(fis, false)) { return jis.getManifest(); } catch (IOException e) { return null; } } from which code will the the explicit catch block actually catch IOException? Does this act as-if it were written: try { try (FileInputStream fis = new FileInputStream(fn); JarInputStream jis = new JarInputStream(fis, false)) { return jis.getManifest(); } } catch (IOException e) { return null; } If so it seems a bit redundant to jump through all the suppressed exception stuff only to throw away any exception and return null. David ----- Stuart Marks said the following on 02/22/11 12:05: > Hi all, > > The following webrev changes a variety of files in java.lang, math, and > util, and their corresponding tests, to use the new Java 7 > try-with-resources construct. I think most of the changes should be > straightforward. In a few cases (e.g., Currency.java and > LocalGregorianCalendar.java) there was no close() call in the original > code so the open file was always leaked. > > Naoto, several of the util changes look like they're in the > internationalization area. I don't know if you're the right person to > review them; if not, please forward or cc this to the right person. Or, > should I forward this to something like i18n-dev? > > Webrev is here: > > http://cr.openjdk.java.net/~smarks/reviews/7021209/webrev.0/ > > Thanks! > > s'marks From joe.darcy at oracle.com Tue Feb 22 03:23:40 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 21 Feb 2011 19:23:40 -0800 Subject: review request for 7021209, use try-with-resources in lang, math, util In-Reply-To: <4D631E5D.4060802@oracle.com> References: <4D6319CD.1010306@oracle.com> <4D631E5D.4060802@oracle.com> Message-ID: <4D632C3C.9040003@oracle.com> David Holmes wrote: > Hi Stuart, > > I'm unclear how try-with-resources applies in different cases. For > example, here in Package.java: > > private static Manifest loadManifest(String fn) { > try (FileInputStream fis = new FileInputStream(fn); > JarInputStream jis = new JarInputStream(fis, false)) > { > return jis.getManifest(); > } catch (IOException e) { > return null; > } > } > > from which code will the the explicit catch block actually catch > IOException? It will catch exceptions from jis.getManifest and from the compiler-generated close calls on fis and jis. > Does this act as-if it were written: > > try { > try (FileInputStream fis = new FileInputStream(fn); > JarInputStream jis = new JarInputStream(fis, false)) > { > return jis.getManifest(); > } > } catch (IOException e) { > return null; > } Yes it does. -Joe From stuart.marks at oracle.com Tue Feb 22 07:34:33 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 21 Feb 2011 23:34:33 -0800 Subject: review request for 7021209, use try-with-resources in lang, math, util In-Reply-To: <4D632C3C.9040003@oracle.com> References: <4D6319CD.1010306@oracle.com> <4D631E5D.4060802@oracle.com> <4D632C3C.9040003@oracle.com> Message-ID: <4D636709.50205@oracle.com> On 2/21/11 7:23 PM, Joe Darcy wrote: > David Holmes wrote: >> Hi Stuart, >> >> I'm unclear how try-with-resources applies in different cases. For example, >> here in Package.java: >> >> private static Manifest loadManifest(String fn) { >> try (FileInputStream fis = new FileInputStream(fn); >> JarInputStream jis = new JarInputStream(fis, false)) >> { >> return jis.getManifest(); >> } catch (IOException e) { >> return null; >> } >> } >> >> from which code will the the explicit catch block actually catch IOException? > > It will catch exceptions from jis.getManifest and from the compiler-generated > close calls on fis and jis. It will also catch exceptions from the construction of the FileInputStream and the JarInputStream. >> Does this act as-if it were written: >> >> try { >> try (FileInputStream fis = new FileInputStream(fn); >> JarInputStream jis = new JarInputStream(fis, false)) >> { >> return jis.getManifest(); >> } >> } catch (IOException e) { >> return null; >> } > > Yes it does. > > -Joe Indeed, since the second block is the initial desugaring of the first, it's clear that the catch clause will also catch exceptions thrown from the construction of the resources. David also asked: > If so it seems a bit redundant to jump through all the suppressed exception stuff only to throw away any exception and return null. True, some useless suppressed exception code will be generated. However, the logic deal with suppressed exceptions will only be executed if there is an exception thrown during construction or the jis.getManifest() call, *and* another exception is thrown from one of the close() calls on one of the resources. The primary benefit of using TWR here is to ensure that the FileInputStream gets closed properly if construction or processing of the JarInputStream fails, which the original code did not do. (There is also the benefit that the JarInputStream and the FileInputStream are both closed properly if getManifest() fails. But there is probably some redundancy here, since closing the JarInputStream will also probably close the underlying FileInputStream.) It's an interesting exercise to write out the code with proper exception handling, without using TWR, disregarding any handling of suppressed exceptions, which we clearly don't care about in this case, and also disregarding closing of the JarInputStream. Here's what I came up with: private static Manifest loadManifest1(String fn) { try { Manifest man = null; FileInputStream fis = new FileInputStream(fn); try { JarInputStream jis = new JarInputStream(fis, false); man = jis.getManifest(); jis.close(); } catch (IOException ioe1) { // ignore } finally { try { fis.close(); } catch (IOException ioe2) { // ignore } } return man; } catch (FileNotFoundException fnfe) { return null; } } Quite a mouthful, innit? Somebody could poke holes in this, but I'd guess that filling them would make it even more complex. I doubt that this could be simplified much if at all. s'marks From joe.darcy at oracle.com Tue Feb 22 07:46:17 2011 From: joe.darcy at oracle.com (Joe Darcy) Date: Mon, 21 Feb 2011 23:46:17 -0800 Subject: review request for 7021209, use try-with-resources in lang, math, util In-Reply-To: <4D6319CD.1010306@oracle.com> References: <4D6319CD.1010306@oracle.com> Message-ID: <4D6369C9.9000408@oracle.com> Looks good, -Joe Stuart Marks wrote: > Hi all, > > The following webrev changes a variety of files in java.lang, math, > and util, and their corresponding tests, to use the new Java 7 > try-with-resources construct. I think most of the changes should be > straightforward. In a few cases (e.g., Currency.java and > LocalGregorianCalendar.java) there was no close() call in the original > code so the open file was always leaked. > > Naoto, several of the util changes look like they're in the > internationalization area. I don't know if you're the right person to > review them; if not, please forward or cc this to the right person. > Or, should I forward this to something like i18n-dev? > > Webrev is here: > > http://cr.openjdk.java.net/~smarks/reviews/7021209/webrev.0/ > > Thanks! > > s'marks From Alan.Bateman at oracle.com Tue Feb 22 08:52:20 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Feb 2011 08:52:20 +0000 Subject: review request for 7021209, use try-with-resources in lang, math, util In-Reply-To: <4D6319CD.1010306@oracle.com> References: <4D6319CD.1010306@oracle.com> Message-ID: <4D637944.2000101@oracle.com> Stuart Marks wrote: > Hi all, > > The following webrev changes a variety of files in java.lang, math, > and util, and their corresponding tests, to use the new Java 7 > try-with-resources construct. I think most of the changes should be > straightforward. In a few cases (e.g., Currency.java and > LocalGregorianCalendar.java) there was no close() call in the original > code so the open file was always leaked. > > Naoto, several of the util changes look like they're in the > internationalization area. I don't know if you're the right person to > review them; if not, please forward or cc this to the right person. > Or, should I forward this to something like i18n-dev? > > Webrev is here: > > http://cr.openjdk.java.net/~smarks/reviews/7021209/webrev.0/ > > Thanks! > > s'marks Looks good to me and great to it fixing the bugs in Currency and LocalGregorianCalendar. Minor comment on test/java/util/Formatter/FailingConstructors.java is that an alternative to using try-with-resources is to just replace it with Files.write(file.toPath(), FILE_CONTENTS.getBytes()). Same thing in test/java/util/Scanner/FailingConstructors.java. -Alan. From alan.bateman at oracle.com Tue Feb 22 13:49:29 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 22 Feb 2011 13:49:29 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets Message-ID: <20110222135019.5704A47961@hg.openjdk.java.net> Changeset: dbdafe65af60 Author: alanb Date: 2011-02-21 13:54 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbdafe65af60 7020517: (fs) FileStore.equals returns true if both volumes have the same serial number Reviewed-by: chegar ! src/windows/classes/sun/nio/fs/WindowsFileStore.java ! test/java/nio/file/FileStore/Basic.java Changeset: d7cb44a4d08a Author: alanb Date: 2011-02-22 10:19 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d7cb44a4d08a Merge Changeset: 9d8a0369b906 Author: alanb Date: 2011-02-22 12:04 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d8a0369b906 7020888: (file) Miscellaneous and trivial clean-ups (typos and opportunities to use suppressed exceptions) Reviewed-by: mduigou, chegar ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/File.java ! src/share/classes/java/io/FilterOutputStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! src/share/classes/java/nio/channels/AsynchronousFileChannel.java ! src/share/classes/java/nio/channels/SocketChannel.java ! src/share/classes/java/nio/file/CopyMoveHelper.java ! src/share/classes/java/nio/file/Files.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! test/java/lang/ProcessBuilder/Basic.java From Alan.Bateman at oracle.com Tue Feb 22 14:18:22 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 22 Feb 2011 14:18:22 +0000 Subject: hg: jdk7/tl/jdk: 3 new changesets In-Reply-To: <20110222135019.5704A47961@hg.openjdk.java.net> References: <20110222135019.5704A47961@hg.openjdk.java.net> Message-ID: <4D63C5AE.1020906@oracle.com> Too many balls in the air, looks like I created the change-set for 7020888 while have another patch in my working copy. This means the change included changes to several java.io classes that should have been there. Nothing wrong with the change, they fix long standing issues that were touched on here recently, but they involve behavior changes and are not reviewed. Chris - I need anti-delta 5 files, can you review? diff --git a/src/share/classes/java/io/BufferedReader.java b/src/share/classes/java/io/BufferedReader.java --- a/src/share/classes/java/io/BufferedReader.java +++ b/src/share/classes/java/io/BufferedReader.java @@ -512,14 +512,11 @@ public class BufferedReader extends Read public void close() throws IOException { synchronized (lock) { - if (in != null) { - try { - in.close(); - } finally { - in = null; - cb = null; - } - } + if (in == null) + return; + in.close(); + in = null; + cb = null; } } } diff --git a/src/share/classes/java/io/BufferedWriter.java b/src/share/classes/java/io/BufferedWriter.java --- a/src/share/classes/java/io/BufferedWriter.java +++ b/src/share/classes/java/io/BufferedWriter.java @@ -255,16 +255,17 @@ public class BufferedWriter extends Writ } } - @SuppressWarnings("try") public void close() throws IOException { synchronized (lock) { - if (out != null) { - try (Writer w = out) { - flushBuffer(); - } finally { - out = null; - cb = null; - } + if (out == null) { + return; + } + try { + flushBuffer(); + } finally { + out.close(); + out = null; + cb = null; } } } diff --git a/src/share/classes/java/io/FilterOutputStream.java b/src/share/classes/java/io/FilterOutputStream.java --- a/src/share/classes/java/io/FilterOutputStream.java +++ b/src/share/classes/java/io/FilterOutputStream.java @@ -152,10 +152,11 @@ class FilterOutputStream extends OutputS * @see java.io.FilterOutputStream#flush() * @see java.io.FilterOutputStream#out */ - @SuppressWarnings("try") public void close() throws IOException { - try (OutputStream ostream = out) { - flush(); + try { + flush(); + } catch (IOException ignored) { } + out.close(); } } diff --git a/src/share/classes/java/io/PushbackInputStream.java b/src/share/classes/java/io/PushbackInputStream.java --- a/src/share/classes/java/io/PushbackInputStream.java +++ b/src/share/classes/java/io/PushbackInputStream.java @@ -374,13 +374,10 @@ class PushbackInputStream extends Filter * @exception IOException if an I/O error occurs. */ public synchronized void close() throws IOException { - if (in != null) { - try { - in.close(); - } finally { - in = null; - buf = null; - } - } + if (in == null) + return; + in.close(); + in = null; + buf = null; } } diff --git a/src/share/classes/java/io/PushbackReader.java b/src/share/classes/java/io/PushbackReader.java --- a/src/share/classes/java/io/PushbackReader.java +++ b/src/share/classes/java/io/PushbackReader.java @@ -245,11 +245,8 @@ public class PushbackReader extends Filt * @exception IOException If an I/O error occurs */ public void close() throws IOException { - try { - super.close(); - } finally { - buf = null; - } + super.close(); + buf = null; } /** diff --git a/test/java/lang/ProcessBuilder/Basic.java b/test/java/lang/ProcessBuilder/Basic.java --- a/test/java/lang/ProcessBuilder/Basic.java +++ b/test/java/lang/ProcessBuilder/Basic.java @@ -1762,9 +1762,9 @@ public class Basic { equal(p.exitValue(), 5); - try { p.getInputStream().close(); } catch (IOException ignore) { } - try {p.getErrorStream().close(); } catch (IOException ignore) { } - try { p.getOutputStream().close(); } catch (IOException ignore) { } + p.getInputStream().close(); + p.getErrorStream().close(); + p.getOutputStream().close(); InputStream[] streams = { p.getInputStream(), p.getErrorStream() }; for (final InputStream in : streams) { From alan.bateman at oracle.com Tue Feb 22 14:41:27 2011 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 22 Feb 2011 14:41:27 +0000 Subject: hg: jdk7/tl/jdk: 7021327: Changes for 7020888 included changes to other files in error Message-ID: <20110222144137.5BCE847965@hg.openjdk.java.net> Changeset: bac152c6491a Author: alanb Date: 2011-02-22 14:28 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bac152c6491a 7021327: Changes for 7020888 included changes to other files in error Reviewed-by: chegar ! src/share/classes/java/io/BufferedReader.java ! src/share/classes/java/io/BufferedWriter.java ! src/share/classes/java/io/FilterOutputStream.java ! src/share/classes/java/io/PushbackInputStream.java ! src/share/classes/java/io/PushbackReader.java ! test/java/lang/ProcessBuilder/Basic.java From michael.x.mcmahon at oracle.com Tue Feb 22 14:45:38 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Tue, 22 Feb 2011 14:45:38 +0000 Subject: hg: jdk7/tl/jdk: 6702400: ChunkedInputStream expecting -1 from int read, but int->char comparision is wrong Message-ID: <20110222144547.DA4EF47966@hg.openjdk.java.net> Changeset: b853414b8eef Author: michaelm Date: 2011-02-22 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b853414b8eef 6702400: ChunkedInputStream expecting -1 from int read, but int->char comparision is wrong Reviewed-by: chegar ! src/share/classes/sun/net/httpserver/ChunkedInputStream.java From philip.race at oracle.com Tue Feb 22 17:26:44 2011 From: philip.race at oracle.com (Phil Race) Date: Tue, 22 Feb 2011 09:26:44 -0800 Subject: Zlib level in JDK7 In-Reply-To: References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AE0AF.3070509@oracle.com> Message-ID: <4D63F1D4.9020305@oracle.com> On 2/20/2011 9:39 AM, Dr Andrew John Hughes wrote: > On 15 February 2011 20:23, Phil Race wrote: >> On 2/15/2011 6:07 AM, Dr Andrew John Hughes wrote: >>> Yes, IcedTea uses system libraries for everything bar LCMS, where >>> local changes in OpenJDK mean we are still forced to use the in-tree >>> version. There hasn't been any success upstreaming these changes, >>> though I haven't looked at LCMS 2.x. >> LittleCMS 1.x didn't provide the support necessary to pass JCK. So we >> talked to >> the LittleCMS maintainer and he added the necessary APIs in 2.0 >> JDK 7 has had LittleCMS 2.0 for almost 6 months now and that is included >> without any code >> modifications, so I think it should now be possible to use a system >> library, although >> we didn't do the work to actually enable that, so its built into a JDK >> library which >> has the littlecms code and the glue code. We need to provide the ability >> to separate these. >> When we pushed LCMS 2.0, I asked for a bug to be filed to remember to do >> this work >> but I can't find it in the database. I'll ask for that to be filed if it >> wasn't already. >> NB It didn't seem super-urgent since we pulled in LCMS 2.0 relatively soon >> after its release >> we thought shipping distros weren't likely to have the library upgrade >> anyway, but that's >> probably changing. >> >> -phil. >> >> > Hi Phil, > > Thanks for making me aware of this. I briefly glanced at some for the > release notes for LCMS 2 when it was released, and saw something that > may support the missing functionality, but never had chance to look in > detail. I've also not had chance to look at OpenJDK 7 recently, so > it's great to hear that support has already gone in. Do you have any > idea as to whether this would be safe to backport to OpenJDK 6? I > presume it doesn't alter any public API. It ought to be OK. If someone else wants to take on the work that is :-) > I've not seen any use of OpenJDK 7 by distros as yet. We've managed > with the other libraries without in-tree support by using local > patching. There's a big libraries patch in IcedTea that would be nice > to integrate but it would need considerable work to do optional system > linking rather than the current brute force of deleting the in-tree > version and always linking. There's also no TCK for 7 yet, which is I > believe what caught many of the issues with missing LCMS support > before. I don't know how distros would want to present/package the 7 EA builds so I'm not too surprised they aren't common. We believe LCMS 2.0 should pass JCK, but I don't know if a full JCK run has been performed against a fully open 7 build since it went in. A 6-open backport would find any problems there. > I did a quick survey of distro support for LCMS 2. It's in Gentoo > (which is what made me aware of it), but Ubuntu, Debian and Fedora all > seem to still be on the 1.x series. So it doesn't seem to be changing > yet. Maybe OpenJDK could be the kick they need to support it? ;-) yep. -phil. From assembling.signals at yandex.ru Tue Feb 22 20:00:01 2011 From: assembling.signals at yandex.ru (assembling signals) Date: Tue, 22 Feb 2011 21:00:01 +0100 Subject: java.awt.Graphics: not a candidate for AutoCloseable? Message-ID: <905501298404801@web154.yandex.ru> Hello, community! Is java.awt.Graphics not a candidate for AutoCloseable? In most cases, a Graphics object has to be dispose()'d at the end. Couldn't it be extended with close() which would be a delegate to dispose()? Best regards, Ivan G Shevchenko From philip.race at oracle.com Tue Feb 22 20:19:34 2011 From: philip.race at oracle.com (Phil Race) Date: Tue, 22 Feb 2011 12:19:34 -0800 Subject: java.awt.Graphics: not a candidate for AutoCloseable? In-Reply-To: <905501298404801@web154.yandex.ru> References: <905501298404801@web154.yandex.ru> Message-ID: <4D641A56.1040603@oracle.com> Aside from the fact that its weird, if not downright wrong to think of a Graphics instance as "closeable", Graphics instances are not used in the same way as all the stream type resources for which AutoCloseable is intended. In most cases they are provided to you in a call to paint() Releasing a Graphics via explicit call to dispose() only should be used in the relatively rare use case where you obtained it yourself to draw on an image or some other surface. And even then dispose() is not a requirement since the system does dispose of the graphics for you in a prompt way that does not require finalisation. The docs on java.awt.Graphics are extremely dated in that respect. -Phil-of-the-graphics-team. On 2/22/2011 12:00 PM, assembling signals wrote: > Hello, community! > > Is java.awt.Graphics not a candidate for AutoCloseable? > > In most cases, a Graphics object has to be dispose()'d at the end. > Couldn't it be extended with close() which would be a delegate to dispose()? > > Best regards, > Ivan G Shevchenko From assembling.signals at yandex.ru Tue Feb 22 20:33:39 2011 From: assembling.signals at yandex.ru (assembling signals) Date: Tue, 22 Feb 2011 21:33:39 +0100 Subject: java.awt.Graphics: not a candidate for AutoCloseable? In-Reply-To: <4D641A56.1040603@oracle.com> References: <905501298404801@web154.yandex.ru> <4D641A56.1040603@oracle.com> Message-ID: <98791298406819@web146.yandex.ru> Right, I was dealing with sources, where accidentally all Graphics objects were manually created from BufferedImage objects ;) So I wasn't thinking about the more common case of paint(). 22.02.2011, 21:19, "Phil Race" : > Aside from the fact that its weird, if not downright wrong > to think of a Graphics instance as "closeable", > Graphics instances are not used in the same way as all > the stream type resources for which AutoCloseable is intended. > In most cases they are provided ?to you in a call to paint() > Releasing a Graphics via explicit call to dispose() only > should be used in the relatively rare use case where you obtained it > yourself to draw on an image or some other surface. > And even then dispose() is not a requirement since the system does > dispose of > the graphics for you in a prompt way that does not require finalisation. > The docs on java.awt.Graphics are extremely dated in that respect. > > -Phil-of-the-graphics-team. > > On 2/22/2011 12:00 PM, assembling signals wrote: > >> ?Hello, community! >> >> ?Is java.awt.Graphics not a candidate for AutoCloseable? >> >> ?In most cases, a Graphics object has to be dispose()'d at the end. >> ?Couldn't it be extended with close() which would be a delegate to dispose()? >> >> ?Best regards, >> ?Ivan G Shevchenko From naoto.sato at oracle.com Tue Feb 22 21:24:22 2011 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 22 Feb 2011 13:24:22 -0800 Subject: review request for 7021209, use try-with-resources in lang, math, util In-Reply-To: <4D6319CD.1010306@oracle.com> References: <4D6319CD.1010306@oracle.com> Message-ID: <4D642986.9000602@oracle.com> Looks good to me. Naoto (2/21/11 6:05 PM), Stuart Marks wrote: > Hi all, > > The following webrev changes a variety of files in java.lang, math, and > util, and their corresponding tests, to use the new Java 7 > try-with-resources construct. I think most of the changes should be > straightforward. In a few cases (e.g., Currency.java and > LocalGregorianCalendar.java) there was no close() call in the original > code so the open file was always leaked. > > Naoto, several of the util changes look like they're in the > internationalization area. I don't know if you're the right person to > review them; if not, please forward or cc this to the right person. Or, > should I forward this to something like i18n-dev? > > Webrev is here: > > http://cr.openjdk.java.net/~smarks/reviews/7021209/webrev.0/ > > Thanks! > > s'marks From valerie.peng at oracle.com Tue Feb 22 21:07:34 2011 From: valerie.peng at oracle.com (valerie.peng at oracle.com) Date: Tue, 22 Feb 2011 21:07:34 +0000 Subject: hg: jdk7/tl/jdk: 6604496: Support for CKM_AES_CTR (counter mode) Message-ID: <20110222210744.7EE3247977@hg.openjdk.java.net> Changeset: 75216854fb53 Author: valeriep Date: 2011-02-22 12:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/75216854fb53 6604496: Support for CKM_AES_CTR (counter mode) Summary: Enhanced SunPKCS11 provider to support AES/CTR/NoPadding transformation. Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Cipher.java ! src/share/classes/sun/security/pkcs11/SunPKCS11.java + src/share/classes/sun/security/pkcs11/wrapper/CK_AES_CTR_PARAMS.java ! src/share/classes/sun/security/pkcs11/wrapper/CK_MECHANISM.java ! src/share/classes/sun/security/pkcs11/wrapper/PKCS11Constants.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c + src/share/native/sun/security/pkcs11/wrapper/pkcs-11v2-20a3.h ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h ! test/sun/security/pkcs11/Cipher/TestSymmCiphers.java ! test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java From stuart.marks at oracle.com Tue Feb 22 23:21:01 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 22 Feb 2011 15:21:01 -0800 Subject: review request for 7021209, use try-with-resources in lang, math, util In-Reply-To: <4D637755.5010308@oracle.com> References: <4D6319CD.1010306@oracle.com> <4D637755.5010308@oracle.com> Message-ID: <4D6444DD.1000609@oracle.com> On 2/22/11 12:44 AM, Alan Bateman wrote: > Minor comment on test/java/util/Formatter/FailingConstructors.java is that an > alternative to using try-with-resources is to just replace it with > Files.write(file.toPath(), FILE_CONTENTS.getBytes()). Same thing in > test/java/util/Scanner/FailingConstructors.java. Ah, good point. It's not directly related to try-with-resources but it's good cleanup nonetheless. I'll integrate this change. Thanks. s'marks From stuart.marks at oracle.com Tue Feb 22 23:33:31 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 22 Feb 2011 23:33:31 +0000 Subject: hg: jdk7/tl/jdk: 7021209: convert lang, math, util to use try-with-resources Message-ID: <20110222233348.3498247981@hg.openjdk.java.net> Changeset: 84e339f1033b Author: smarks Date: 2011-02-22 15:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/84e339f1033b 7021209: convert lang, math, util to use try-with-resources Reviewed-by: alanb, darcy, naoto ! src/share/classes/java/lang/Package.java ! src/share/classes/java/util/Currency.java ! src/share/classes/sun/util/calendar/LocalGregorianCalendar.java ! src/solaris/classes/java/util/prefs/FileSystemPreferences.java ! test/java/lang/Character/CheckScript.java ! test/java/lang/Runtime/shutdown/ShutdownHooks.java ! test/java/lang/instrument/BootClassPath/Setup.java ! test/java/lang/instrument/ilib/Inject.java ! test/java/math/BigInteger/BigIntegerTest.java ! test/java/util/Currency/ValidateISO4217.java ! test/java/util/Formatter/FailingConstructors.java ! test/java/util/Locale/LocaleEnhanceTest.java ! test/java/util/ResourceBundle/Bug6204853.java ! test/java/util/Scanner/FailingConstructors.java From gnu_andrew at member.fsf.org Tue Feb 22 23:51:17 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Tue, 22 Feb 2011 23:51:17 +0000 Subject: Zlib level in JDK7 In-Reply-To: <4D63F1D4.9020305@oracle.com> References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AE0AF.3070509@oracle.com> <4D63F1D4.9020305@oracle.com> Message-ID: On 22 February 2011 17:26, Phil Race wrote: > On 2/20/2011 9:39 AM, Dr Andrew John Hughes wrote: >> >> On 15 February 2011 20:23, Phil Race ?wrote: >>> >>> On 2/15/2011 6:07 AM, Dr Andrew John Hughes wrote: >>>> >>>> Yes, IcedTea uses system libraries for everything bar LCMS, where >>>> local changes in OpenJDK mean we are still forced to use the in-tree >>>> version. ?There hasn't been any success upstreaming these changes, >>>> though I haven't looked at LCMS 2.x. >>> >>> ? LittleCMS 1.x ?didn't provide the support necessary to pass JCK. So we >>> talked to >>> ? the LittleCMS maintainer and he added the necessary APIs in 2.0 >>> ? JDK 7 has had LittleCMS 2.0 for almost 6 months now and that is >>> included >>> without any code >>> ? modifications, so I think it should now be possible to use a system >>> library, although >>> ? we didn't do the work to actually enable that, so its built into a JDK >>> library which >>> ? has the littlecms code and the glue code. We need to provide the >>> ability >>> to separate these. >>> ? When we pushed LCMS 2.0, I asked for a bug to be filed to remember to >>> do >>> this work >>> ? but I can't find it in the database. I'll ask for that to be filed if >>> it >>> wasn't already. >>> ? NB It didn't seem super-urgent since we pulled in LCMS 2.0 relatively >>> soon >>> after its release >>> ? we thought shipping distros weren't likely to have the library upgrade >>> anyway, but that's >>> ? probably changing. >>> >>> -phil. >>> >>> >> Hi Phil, >> >> Thanks for making me aware of this. ?I briefly glanced at some for the >> release notes for LCMS 2 when it was released, and saw something that >> may support the missing functionality, but never had chance to look in >> detail. ?I've also not had chance to look at OpenJDK 7 recently, so >> it's great to hear that support has already gone in. ?Do you have any >> idea as to whether this would be safe to backport to OpenJDK 6? ?I >> presume it doesn't alter any public API. > > It ought to be OK. If someone else wants to take on the work that is :-) > Consider it on my TODO list ;-) >> I've not seen any use of OpenJDK 7 by distros as yet. ?We've managed >> with the other libraries without in-tree support by using local >> patching. ?There's a big libraries patch in IcedTea that would be nice >> to integrate but it would need considerable work to do optional system >> linking rather than the current brute force of deleting the in-tree >> version and always linking. ?There's also no TCK for 7 yet, which is I >> believe what caught many of the issues with missing LCMS support >> before. > > I don't know how distros would want to present/package the 7 EA builds so > I'm not > too surprised they aren't common. > > We believe LCMS 2.0 should pass JCK, but I don't know if a full JCK run > has been performed against a fully open 7 build since it went in. > A 6-open backport would find any problems there. > I wasn't aware there was a JCK for 7 yet. At least, not one under the same terms as the one used for OpenJDK6. >> I did a quick survey of distro support for LCMS 2. ?It's in Gentoo >> (which is what made me aware of it), but Ubuntu, Debian and Fedora all >> seem to still be on the 1.x series. ?So it doesn't seem to be changing >> yet. ?Maybe OpenJDK could be the kick they need to support it? ;-) > > yep. > > -phil. > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From philip.race at oracle.com Wed Feb 23 00:12:58 2011 From: philip.race at oracle.com (Phil Race) Date: Tue, 22 Feb 2011 16:12:58 -0800 Subject: Zlib level in JDK7 In-Reply-To: References: <1297765470.8797.7.camel@jazzette> <4D5A8642.602@oracle.com> <4D5AE0AF.3070509@oracle.com> <4D63F1D4.9020305@oracle.com> Message-ID: <4D64510A.4010505@oracle.com> On 2/22/2011 3:51 PM, Dr Andrew John Hughes wrote: > On 22 February 2011 17:26, Phil Race wrote: > >> We believe LCMS 2.0 should pass JCK, but I don't know if a full JCK run >> has been performed against a fully open 7 build since it went in. >> A 6-open backport would find any problems there. >> > I wasn't aware there was a JCK for 7 yet. At least, not one under the same > terms as the one used for OpenJDK6. Strictly there cannot be one until the java se 7 spec is final because otherwise it doesn't know what to test, but it has to be worked on concurrently else you'd then have to wait a long time after the JDK work was done .. so that ongoing work is what I refer to. I don't think they run JDK 6 against it because it would fail straight off the bat on all the new APIs. However in this stable area I rather doubt its anything other than the existing JCK6 tests. -phil. From mike.duigou at oracle.com Wed Feb 23 00:29:18 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Tue, 22 Feb 2011 16:29:18 -0800 Subject: Review CR #6611830: UUID thread-safety and performance improvements Message-ID: Daniel Aioanei reported via Josh Bloch a data race issue with the UUID accessor and hashCode() methods. I've prepared a webrev with the suggested changes: http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ I've tested the change against the standard UUID tests and did a microbenchmark test of one method, variant(), to see what impact not caching had on performance. Since there was only negligible change in performance vs. the existing UUID implementation I am comfortable with eliminating the cache values. It would appear that a field access plus a shift is not a significant cost over a field access. Mike From rama.pulavarthi at oracle.com Wed Feb 23 00:32:10 2011 From: rama.pulavarthi at oracle.com (Rama Pulavarthi) Date: Tue, 22 Feb 2011 16:32:10 -0800 Subject: Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security Message-ID: <4D64558A.6040807@oracle.com> Hi, Need reviewer for CR 7020513: Add com.sun.xml.internal to the "package.access" property in $JAVA_HOME/lib/security/java.security Webrev is available at http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws-7020513/webrev/ thanks, Rama Pulavarthi From vitalyd at gmail.com Wed Feb 23 01:46:12 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 22 Feb 2011 20:46:12 -0500 Subject: Review CR #6611830: UUID thread-safety and performance improvements In-Reply-To: References: Message-ID: Hi Mike, Unless i missed something, seems like the race can be fixed via same mechanics as String.hashcode; ie since all of the cached values are based on least and most significant bits which are final and the long members are volatile, using lazy evaluation with use of temps should yield the same results even to racing threads, making the race benign. Vitaly On Feb 22, 2011 7:30 PM, "Mike Duigou" wrote: > Daniel Aioanei reported via Josh Bloch a data race issue with the UUID accessor and hashCode() methods. I've prepared a webrev with the suggested changes: > > http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ > > I've tested the change against the standard UUID tests and did a microbenchmark test of one method, variant(), to see what impact not caching had on performance. Since there was only negligible change in performance vs. the existing UUID implementation I am comfortable with eliminating the cache values. It would appear that a field access plus a shift is not a significant cost over a field access. > > Mike From David.Holmes at oracle.com Wed Feb 23 03:27:45 2011 From: David.Holmes at oracle.com (David Holmes) Date: Wed, 23 Feb 2011 13:27:45 +1000 Subject: Review CR #6611830: UUID thread-safety and performance improvements In-Reply-To: References: Message-ID: <4D647EB1.8000800@oracle.com> Hi Vitaly, Vitaly Davidovich said the following on 02/23/11 11:46: > Unless i missed something, seems like the race can be fixed via same > mechanics as String.hashcode; ie since all of the cached values are based on > least and most significant bits which are final and the long members are > volatile, using lazy evaluation with use of temps should yield the same > results even to racing threads, making the race benign. Are you able to see the actual bug report for this? The key point is that the -1 "uninitialized" values of the fields are not guaranteed to be seen, so if zero is seen instead the wrong calculation will be done for the variant and hashcode. The conclusion is that the simplest fix is to not bother with lazy evaluation and caching for any of these fields. David Holmes > Vitaly > On Feb 22, 2011 7:30 PM, "Mike Duigou" wrote: >> Daniel Aioanei reported via Josh Bloch a data race issue with the UUID > accessor and hashCode() methods. I've prepared a webrev with the suggested > changes: >> http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ >> >> I've tested the change against the standard UUID tests and did a > microbenchmark test of one method, variant(), to see what impact not caching > had on performance. Since there was only negligible change in performance > vs. the existing UUID implementation I am comfortable with eliminating the > cache values. It would appear that a field access plus a shift is not a > significant cost over a field access. >> Mike From brian.goetz at oracle.com Wed Feb 23 04:53:50 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 22 Feb 2011 23:53:50 -0500 Subject: Review CR #6611830: UUID thread-safety and performance improvements In-Reply-To: References: Message-ID: <4D6492DE.9000309@oracle.com> I think you have a potential visibility problem here. You use -1 as the initial value, but observing threads might see instead the default value if the initializing write is not visible, and mistakenly think that the zero default value represents a computed value. (This is different from the trick employed by String.hashCode(), which does not use an initializer. Can you get the same result using zero instead?) The key to making the String.hashCode() trick work is that, while there is definitely a data race, it is benign because the field can only ever take on one non-default value, and that value is computed deterministically from immutable state. On 2/22/2011 7:29 PM, Mike Duigou wrote: > Daniel Aioanei reported via Josh Bloch a data race issue with the UUID accessor and hashCode() methods. I've prepared a webrev with the suggested changes: > > http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ > > I've tested the change against the standard UUID tests and did a microbenchmark test of one method, variant(), to see what impact not caching had on performance. Since there was only negligible change in performance vs. the existing UUID implementation I am comfortable with eliminating the cache values. It would appear that a field access plus a shift is not a significant cost over a field access. > > Mike From Alan.Bateman at oracle.com Wed Feb 23 08:44:31 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Feb 2011 08:44:31 +0000 Subject: Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security In-Reply-To: <4D64558A.6040807@oracle.com> References: <4D64558A.6040807@oracle.com> Message-ID: <4D64C8EF.2050101@oracle.com> Rama Pulavarthi wrote: > Hi, > Need reviewer for CR 7020513: Add com.sun.xml.internal to the > "package.access" property in $JAVA_HOME/lib/security/java.security > Webrev is available at > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws-7020513/webrev/ > > thanks, > Rama Pulavarthi > > Rama - it might be better to bring this to security-dev at openjdk as that is where the security property files and XML DSIG implementation are maintained. Just on the test, it would be great if it didn't require the script as these can be problematic (looks like it will fail if run on Cygwin for example). Also looks like the dates on the tests are 2009. -Alan. From vitalyd at gmail.com Wed Feb 23 13:36:18 2011 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 23 Feb 2011 08:36:18 -0500 Subject: Review CR #6611830: UUID thread-safety and performance improvements In-Reply-To: References: <4D6492DE.9000309@oracle.com> Message-ID: resending as I just realized I replied only to Brian. On Wed, Feb 23, 2011 at 12:19 AM, Vitaly Davidovich wrote: > Hi David/Brian, > > Yes, I meant whether the "entire" string.hashcode technique can be used, > including the default zero values. I agree on the initial -1 assignment > possibly not being visible across cores, leading to incorrect results. > > David, I did not see the actual bug report -- is there a link to it? > > Cheers, > Vitaly > > On Tue, Feb 22, 2011 at 11:53 PM, Brian Goetz wrote: > >> I think you have a potential visibility problem here. You use -1 as the >> initial value, but observing threads might see instead the default value if >> the initializing write is not visible, and mistakenly think that the zero >> default value represents a computed value. (This is different from the >> trick employed by String.hashCode(), which does not use an initializer. Can >> you get the same result using zero instead?) >> >> The key to making the String.hashCode() trick work is that, while there is >> definitely a data race, it is benign because the field can only ever take on >> one non-default value, and that value is computed deterministically from >> immutable state. >> >> >> On 2/22/2011 7:29 PM, Mike Duigou wrote: >> >>> Daniel Aioanei reported via Josh Bloch a data race issue with the UUID >>> accessor and hashCode() methods. I've prepared a webrev with the suggested >>> changes: >>> >>> http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ >>> >>> I've tested the change against the standard UUID tests and did a >>> microbenchmark test of one method, variant(), to see what impact not caching >>> had on performance. Since there was only negligible change in performance >>> vs. the existing UUID implementation I am comfortable with eliminating the >>> cache values. It would appear that a field access plus a shift is not a >>> significant cost over a field access. >>> >>> Mike >>> >> > > > -- > Vitaly > 617-548-7007 (mobile) > -- Vitaly 617-548-7007 (mobile) From maurizio.cimadamore at oracle.com Wed Feb 23 14:19:26 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Wed, 23 Feb 2011 14:19:26 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20110223141930.5D602479AD@hg.openjdk.java.net> Changeset: 015dc9a63efc Author: mcimadamore Date: 2011-02-23 14:16 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/015dc9a63efc 7020657: Javac rejects a fairly common idiom with raw override and interfaces Summary: name clash should not be reported if subinterface/implementing class resolves the clash by defining common overrider Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/7020657/T7020657neg.java + test/tools/javac/generics/7020657/T7020657neg.out + test/tools/javac/generics/7020657/T7020657pos.java Changeset: 3ab7bb46c5c1 Author: mcimadamore Date: 2011-02-23 14:17 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3ab7bb46c5c1 7019631: issues in test headers in b130 Summary: fix to test headers not containing correct bug ID Reviewed-by: jjg ! test/tools/javac/AnonStaticMember_2.java ! test/tools/javac/InterfaceInInner.java ! test/tools/javac/QualifiedNew.java ! test/tools/javac/generics/6969184/T6969184.java From Alan.Bateman at oracle.com Wed Feb 23 14:03:12 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Feb 2011 14:03:12 +0000 Subject: Review CR #6611830: UUID thread-safety and performance improvements In-Reply-To: References: Message-ID: <4D6513A0.5090109@oracle.com> Mike Duigou wrote: > Daniel Aioanei reported via Josh Bloch a data race issue with the UUID accessor and hashCode() methods. I've prepared a webrev with the suggested changes: > > http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ > > I've tested the change against the standard UUID tests and did a microbenchmark test of one method, variant(), to see what impact not caching had on performance. Since there was only negligible change in performance vs. the existing UUID implementation I am comfortable with eliminating the cache values. It would appear that a field access plus a shift is not a significant cost over a field access. > > Mike This looks good to me, but I had to pause on the variant method to prove to myself that it's right - I don't know if a comment would help there. -Alan. From martin.desruisseaux at geomatys.fr Wed Feb 23 14:55:33 2011 From: martin.desruisseaux at geomatys.fr (Martin Desruisseaux) Date: Wed, 23 Feb 2011 15:55:33 +0100 Subject: java.util.Objects.requireNonNull: an opportunity for NullArgumentException? Message-ID: <4D651FE5.6010902@geomatys.fr> Hello all I apologize if this question was already debated previously. I just wonder: since JDK 7 defines an Object.requireNonNull(?) method for explicit checks of argument value, does the Project-Coin expert group has considered the addition of an explicit NullArgumentException extends NullPointerException for making clear that this exception is the result of an argument check rather than some bug hidden in the middle of a code? Some kind of NullArgumentException seems a common addition in many libraries built on top of JDK. To name just a few from a quick Google search: http://commons.apache.org/lang/api-2.3/org/apache/commons/lang/NullArgumentException.html http://www.croftsoft.com/library/code/javadoc/core/com/croftsoft/core/lang/NullArgumentException.html http://api.dpml.net/dpml/1.1.0/net/dpml/transit/NullArgumentException.html http://www.geotoolkit.org/apidocs/org/geotoolkit/util/NullArgumentException.html A blog: http://closingbraces.net/2007/02/26/nullargumentexception/ Regards, Martin From chris.hegarty at oracle.com Wed Feb 23 15:30:19 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Wed, 23 Feb 2011 15:30:19 +0000 Subject: hg: jdk7/tl/jdk: 7017493: ConcurrentLinkedDeque: Unexpected initialization order can lead to crash due to use of Unsafe Message-ID: <20110223153029.7A3B9479B0@hg.openjdk.java.net> Changeset: 892c3fc7249e Author: dl Date: 2011-02-23 14:56 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/892c3fc7249e 7017493: ConcurrentLinkedDeque: Unexpected initialization order can lead to crash due to use of Unsafe Reviewed-by: chegar ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListSet.java ! src/share/classes/java/util/concurrent/CopyOnWriteArrayList.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/Phaser.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java From brian.goetz at oracle.com Wed Feb 23 15:38:22 2011 From: brian.goetz at oracle.com (Brian Goetz) Date: Wed, 23 Feb 2011 10:38:22 -0500 Subject: Review CR #6611830: UUID thread-safety and performance improvements In-Reply-To: <4D6492DE.9000309@oracle.com> References: <4D6492DE.9000309@oracle.com> Message-ID: <4D6529EE.5010900@oracle.com> Ignore my comment -- I was reading the diffs backwards :( On 2/22/2011 11:53 PM, Brian Goetz wrote: > I think you have a potential visibility problem here. You use -1 as the > initial value, but observing threads might see instead the default value > if the initializing write is not visible, and mistakenly think that the > zero default value represents a computed value. (This is different from > the trick employed by String.hashCode(), which does not use an > initializer. Can you get the same result using zero instead?) > > The key to making the String.hashCode() trick work is that, while there > is definitely a data race, it is benign because the field can only ever > take on one non-default value, and that value is computed > deterministically from immutable state. > > On 2/22/2011 7:29 PM, Mike Duigou wrote: >> Daniel Aioanei reported via Josh Bloch a data race issue with the UUID >> accessor and hashCode() methods. I've prepared a webrev with the >> suggested changes: >> >> http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ >> >> I've tested the change against the standard UUID tests and did a >> microbenchmark test of one method, variant(), to see what impact not >> caching had on performance. Since there was only negligible change in >> performance vs. the existing UUID implementation I am comfortable with >> eliminating the cache values. It would appear that a field access plus >> a shift is not a significant cost over a field access. >> >> Mike From Rama.Pulavarthi at oracle.com Wed Feb 23 18:13:52 2011 From: Rama.Pulavarthi at oracle.com (Rama Pulavarthi) Date: Wed, 23 Feb 2011 10:13:52 -0800 Subject: Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security In-Reply-To: <4D64C8EF.2050101@oracle.com> References: <4D64558A.6040807@oracle.com> <4D64C8EF.2050101@oracle.com> Message-ID: <4D654E60.9070106@oracle.com> Hi Alan, On 2/23/11 12:44 AM, Alan Bateman wrote: > Rama Pulavarthi wrote: >> Hi, >> Need reviewer for CR 7020513: Add com.sun.xml.internal to the >> "package.access" property in $JAVA_HOME/lib/security/java.security >> Webrev is available at >> http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws-7020513/webrev/ >> >> thanks, >> Rama Pulavarthi >> > Rama - it might be better to bring this to security-dev at openjdk as > that is where the security property files and XML DSIG implementation > are maintained. > CCing security-dev. For background on this issue, this is not a new one. I am trying to port the old fixes made in jdk repo as part of earlier jax-ws integrations in to Open JDK 6. The original issue CR 6592792 was fixed in JDK 6u7 and then ported to Open JDK 6. When Open JDK 6 transistioned to Hg, it was committed as [1]. As fix for CR 6831313 :update jaxws in OpenJDK7 to 2.1 plus bug fixes from OpenJDK 6, Only the changes in jaxws sources are ported to JDK 7 [2]. But, there are other changes that are made in jdk repo required for this fix. > Just on the test, it would be great if it didn't require the script as > these can be problematic (looks like it will fail if run on Cygwin for > example). Also looks like the dates on the tests are 2009. > Just porting the fix along with tests from Open JDK 6 workspace, that's why I kept the old date. Does it need to be changed? This test was added then following the convention of other tests. I will check other tests in JDK 7 to see if it needs any update. thanks, Rama Pulavarthi [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/586feec8273d [2] http://hg.openjdk.java.net/jdk7/build/jaxws/rev/31822b475baa > -Alan. > > From lana.steuck at oracle.com Wed Feb 23 18:56:45 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 23 Feb 2011 18:56:45 +0000 Subject: hg: jdk7/tl: 9 new changesets Message-ID: <20110223185646.39839479B9@hg.openjdk.java.net> Changeset: 995077c73fbb Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/rev/995077c73fbb Added tag jdk7-b130 for changeset cc58c11af154 ! .hgtags Changeset: 0fd0aeb592cb Author: jqzuo Date: 2010-12-09 10:58 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/0fd0aeb592cb Merge Changeset: 20955959b7b7 Author: jqzuo Date: 2010-12-22 15:55 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/20955959b7b7 Merge Changeset: 08fe18caf411 Author: jqzuo Date: 2011-01-10 13:45 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/08fe18caf411 Merge Changeset: aee1b0183364 Author: jqzuo Date: 2011-01-24 17:14 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/aee1b0183364 Merge Changeset: 12764a5a3aec Author: jqzuo Date: 2011-02-01 15:03 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/12764a5a3aec Merge Changeset: df3abd560cbd Author: jqzuo Date: 2011-02-09 16:05 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/df3abd560cbd Merge Changeset: e2370dfcc721 Author: paulk Date: 2011-02-14 14:29 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/e2370dfcc721 7019371: JDK7 is not building UPX. IFTW wrappers are not compressed. Reviewed-by: billyh, jqzuo ! make/deploy-rules.gmk Changeset: 5466f13d19be Author: jqzuo Date: 2011-02-21 14:18 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/rev/5466f13d19be Merge From lana.steuck at oracle.com Wed Feb 23 18:56:51 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 23 Feb 2011 18:56:51 +0000 Subject: hg: jdk7/tl/jaxp: Added tag jdk7-b130 for changeset ab107c1bc4b9 Message-ID: <20110223185651.1D093479BA@hg.openjdk.java.net> Changeset: f2ad604323c0 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/f2ad604323c0 Added tag jdk7-b130 for changeset ab107c1bc4b9 ! .hgtags From lana.steuck at oracle.com Wed Feb 23 18:56:45 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 23 Feb 2011 18:56:45 +0000 Subject: hg: jdk7/tl/corba: 5 new changesets Message-ID: <20110223185652.35676479BB@hg.openjdk.java.net> Changeset: 30ecf5c90a30 Author: mfang Date: 2011-02-10 11:07 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/30ecf5c90a30 7014477: pt_BR corba resource bundle is missing in jdk7 build Reviewed-by: ohair ! make/common/Defs.gmk Changeset: c08dff674e53 Author: mfang Date: 2011-02-10 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/c08dff674e53 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_de.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_es.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_fr.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_it.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ja.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_ko.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_pt_BR.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_sv.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_CN.properties ! src/share/classes/com/sun/corba/se/impl/orbutil/resources/sunorb_zh_TW.properties Changeset: e0f0b358cd2c Author: mfang Date: 2011-02-11 22:50 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/e0f0b358cd2c Merge Changeset: 563a8f8b5be3 Author: mfang Date: 2011-02-11 23:35 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/563a8f8b5be3 Merge Changeset: 49a96611c870 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/corba/rev/49a96611c870 Added tag jdk7-b130 for changeset 563a8f8b5be3 ! .hgtags From lana.steuck at oracle.com Wed Feb 23 18:56:53 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 23 Feb 2011 18:56:53 +0000 Subject: hg: jdk7/tl/jaxws: Added tag jdk7-b130 for changeset ba1fac1c2083 Message-ID: <20110223185653.869CF479BC@hg.openjdk.java.net> Changeset: a8ffd75ad5df Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jaxws/rev/a8ffd75ad5df Added tag jdk7-b130 for changeset ba1fac1c2083 ! .hgtags From lana.steuck at oracle.com Wed Feb 23 18:57:04 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 23 Feb 2011 18:57:04 +0000 Subject: hg: jdk7/tl/langtools: 7 new changesets Message-ID: <20110223185718.4C0AC479BD@hg.openjdk.java.net> Changeset: 2cbaa43eb075 Author: lana Date: 2011-02-14 16:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/2cbaa43eb075 Merge - test/tools/javac/TryWithResources/TwrInference.java - test/tools/javac/TryWithResources/TwrIntersection.java - test/tools/javac/TryWithResources/TwrIntersection02.java - test/tools/javac/TryWithResources/TwrIntersection02.out Changeset: a21c7f194d31 Author: mfang Date: 2011-02-10 16:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/a21c7f194d31 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/tools/apt/resources/apt_ja.properties ! src/share/classes/com/sun/tools/apt/resources/apt_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_ja.properties ! src/share/classes/com/sun/tools/doclets/formats/html/resources/standard_zh_CN.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_ja.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets_zh_CN.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/resources/javac_ja.properties ! src/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_ja.properties ! src/share/classes/com/sun/tools/javadoc/resources/javadoc_zh_CN.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_ja.properties ! src/share/classes/com/sun/tools/javah/resources/l10n_zh_CN.properties Changeset: 4cdea0752a48 Author: mfang Date: 2011-02-11 22:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4cdea0752a48 Merge Changeset: 26071d11c613 Author: mfang Date: 2011-02-11 23:49 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/26071d11c613 Merge Changeset: 7a98db8cbfce Author: ohair Date: 2011-02-15 12:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/7a98db8cbfce Merge Changeset: 6cdb76cf4d1a Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/6cdb76cf4d1a Added tag jdk7-b130 for changeset 7a98db8cbfce ! .hgtags Changeset: 4b0491db73af Author: lana Date: 2011-02-23 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/4b0491db73af Merge From lana.steuck at oracle.com Wed Feb 23 18:57:02 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 23 Feb 2011 18:57:02 +0000 Subject: hg: jdk7/tl/hotspot: 26 new changesets Message-ID: <20110223185752.3F738479BE@hg.openjdk.java.net> Changeset: b7a938236e43 Author: tonyp Date: 2011-01-31 16:28 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b7a938236e43 7014679: G1: deadlock during concurrent cleanup Summary: There's a potential deadlock between the concurrent cleanup thread and the GC workers that are trying to allocate and waiting for more free regions to be made available. Reviewed-by: iveresov, jcoomes ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp Changeset: e49cfa28f585 Author: ysr Date: 2011-02-01 10:02 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e49cfa28f585 6999988: CMS: Increased fragmentation leading to promotion failure after CR#6631166 got implemented Summary: Fix calculation of _desired, in free list statistics, which was missing an intended set of parentheses. Reviewed-by: poonam, jmasa ! src/share/vm/gc_implementation/shared/allocationStats.hpp Changeset: 986b2844f7a2 Author: brutisso Date: 2011-02-01 14:05 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/986b2844f7a2 6789220: CMS: intermittent timeout running nsk/regression/b4796926 Summary: The reference handler java thread and the GC could dead lock Reviewed-by: never, johnc, jcoomes ! src/share/vm/compiler/compileBroker.cpp Changeset: c33825b68624 Author: johnc Date: 2011-02-02 10:41 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c33825b68624 6923430: G1: assert(res != 0,"This should have worked.") 7007446: G1: expand the heap with a single step, not one region at a time Summary: Changed G1CollectedHeap::expand() to expand the committed space by calling VirtualSpace::expand_by() once rather than for every region in the expansion amount. This allows the success or failure of the expansion to be determined before creating any heap regions. Introduced a develop flag G1ExitOnExpansionFailure (false by default) that, when true, will exit the VM if the expansion of the committed space fails. Finally G1CollectedHeap::expand() returns a status back to it's caller so that the caller knows whether to attempt the allocation. Reviewed-by: brutisso, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 176d0be30214 Author: phh Date: 2011-02-03 16:06 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/176d0be30214 7016998: gcutil class LinearLeastSquareFit doesn't initialize some of its fields Summary: Initialize _sum_x_squared, _intercept and _slope in constructor. Reviewed-by: bobv, coleenp ! src/share/vm/gc_implementation/shared/gcUtil.cpp Changeset: c6bf3ca2bb31 Author: trims Date: 2011-02-04 16:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/c6bf3ca2bb31 Merge Changeset: d70fe6ab4436 Author: coleenp Date: 2011-02-01 11:23 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d70fe6ab4436 6588413: Use -fvisibility=hidden for gcc compiles Summary: Add option for gcc 4 and above, define JNIEXPORT and JNIIMPORT to visibility=default, add for jio_snprintf and others since -fvisibility=hidden overrides --version-script definitions. Reviewed-by: kamg, never ! make/linux/makefiles/gcc.make ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/x86/vm/jni_x86.h ! src/cpu/zero/vm/jni_zero.h ! src/os/linux/vm/jvm_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/prims/forte.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: b92c45f2bc75 Author: bobv Date: 2011-02-02 11:35 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b92c45f2bc75 7016023: Enable building ARM and PPC from src/closed repository Reviewed-by: dholmes, bdelsart ! make/Makefile + make/closed.make ! make/jprt.properties ! make/linux/Makefile ! make/linux/makefiles/adlc.make + make/linux/makefiles/arm.make ! make/linux/makefiles/buildtree.make + make/linux/makefiles/ppc.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make + make/linux/platform_arm + make/linux/platform_ppc ! src/os/linux/vm/osThread_linux.cpp ! src/os/linux/vm/os_linux.cpp ! src/os/linux/vm/os_linux.inline.hpp ! src/os/linux/vm/thread_linux.inline.hpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/asm/codeBuffer.hpp ! src/share/vm/c1/c1_Defs.hpp ! src/share/vm/c1/c1_FpuStackSim.hpp ! src/share/vm/c1/c1_FrameMap.cpp ! src/share/vm/c1/c1_FrameMap.hpp ! src/share/vm/c1/c1_Instruction.hpp ! src/share/vm/c1/c1_LIRAssembler.cpp ! src/share/vm/c1/c1_LIRAssembler.hpp ! src/share/vm/c1/c1_LinearScan.cpp ! src/share/vm/c1/c1_LinearScan.hpp ! src/share/vm/c1/c1_MacroAssembler.hpp ! src/share/vm/c1/c1_globals.hpp ! src/share/vm/classfile/classFileStream.hpp ! src/share/vm/classfile/stackMapTable.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/code/codeBlob.cpp ! src/share/vm/code/compiledIC.hpp ! src/share/vm/code/icBuffer.cpp ! src/share/vm/code/relocInfo.cpp ! src/share/vm/code/relocInfo.hpp ! src/share/vm/code/vmreg.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/compiler/disassembler.hpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecode.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/bytecodeStream.hpp ! src/share/vm/interpreter/bytecodes.cpp ! src/share/vm/interpreter/bytecodes.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/interpreter/templateTable.hpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/typeArrayOop.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/locknode.hpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/regmask.cpp ! src/share/vm/opto/regmask.hpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/prims/jniCheck.cpp ! src/share/vm/prims/jni_md.h ! src/share/vm/prims/jvmtiClassFileReconstituter.cpp ! src/share/vm/runtime/deoptimization.cpp ! src/share/vm/runtime/dtraceJSDT.hpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/icache.hpp ! src/share/vm/runtime/java.cpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/javaFrameAnchor.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/registerMap.hpp ! src/share/vm/runtime/relocator.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/stackValueCollection.cpp ! src/share/vm/runtime/statSampler.cpp ! src/share/vm/runtime/stubCodeGenerator.cpp ! src/share/vm/runtime/stubRoutines.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/threadLocalStorage.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/utilities/copy.hpp ! src/share/vm/utilities/globalDefinitions.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 9cd8a2c2d584 Author: bobv Date: 2011-02-02 11:54 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/9cd8a2c2d584 Merge ! src/os/linux/vm/os_linux.cpp Changeset: face83fc8882 Author: coleenp Date: 2011-02-02 18:38 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/face83fc8882 7012088: jump to 0 address because of lack of memory ordering in SignatureHandlerLibrary::add Summary: Write method signature handler under lock to prevent race with growable array resizing Reviewed-by: dsamersoff, dholmes ! src/share/vm/interpreter/interpreterRuntime.cpp Changeset: bf8517f4e4d0 Author: kamg Date: 2011-02-02 14:38 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/bf8517f4e4d0 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread" Summary: Defer posting events from the compiler thread: use service thread Reviewed-by: coleenp, dholmes, never, dcubed - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java + agent/src/share/classes/sun/jvm/hotspot/runtime/ServiceThread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Thread.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/Threads.java ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp ! src/share/vm/runtime/fprofiler.hpp ! src/share/vm/runtime/mutexLocker.cpp ! src/share/vm/runtime/mutexLocker.hpp + src/share/vm/runtime/serviceThread.cpp + src/share/vm/runtime/serviceThread.hpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/runtime/vmStructs.cpp ! src/share/vm/services/attachListener.hpp ! src/share/vm/services/lowMemoryDetector.cpp ! src/share/vm/services/lowMemoryDetector.hpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/macros.hpp Changeset: d28def44457d Author: coleenp Date: 2011-02-03 21:30 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d28def44457d 7017009: Secondary out of c-heap memory error reporting out of memory Summary: Use os::malloc() to allocate buffer to read elf symbols and check for null Reviewed-by: zgu, phh, dsamersoff, dholmes, dcubed ! src/share/vm/utilities/elfSymbolTable.cpp Changeset: 5e139f767ddb Author: coleenp Date: 2011-02-03 20:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5e139f767ddb Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: e9f24eebafd4 Author: rottenha Date: 2011-02-07 08:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e9f24eebafd4 Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: d8a72fbc4be7 Author: kamg Date: 2011-02-08 17:20 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/d8a72fbc4be7 7003401: Implement VM error-reporting functionality on erroneous termination Summary: Add support for distribution-specific error reporting Reviewed-by: coleenp, phh, jcoomes, ohair ! make/Makefile + make/altsrc.make - make/closed.make ! make/linux/makefiles/adlc.make ! make/linux/makefiles/buildtree.make ! make/linux/makefiles/rules.make ! make/linux/makefiles/top.make ! make/linux/makefiles/vm.make ! make/solaris/makefiles/adlc.make ! make/solaris/makefiles/buildtree.make ! make/solaris/makefiles/rules.make ! make/solaris/makefiles/top.make ! make/solaris/makefiles/vm.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/vm.make ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/vm_version.cpp ! src/share/vm/runtime/vm_version.hpp + src/share/vm/utilities/errorReporter.cpp + src/share/vm/utilities/errorReporter.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp ! src/share/vm/utilities/vmError.cpp Changeset: fb539912d338 Author: coleenp Date: 2011-02-07 14:36 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/fb539912d338 6472925: OutOfMemoryError fails to generate stack trace as it now ought Summary: Print an additional message for OOM during stack trace printing Reviewed-by: dholmes, phh, acorn, kamg, dcubed ! src/share/vm/runtime/thread.cpp Changeset: 5fb3ee258e76 Author: coleenp Date: 2011-02-08 19:50 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5fb3ee258e76 Merge - make/closed.make Changeset: f36c9fe788b8 Author: mchung Date: 2011-02-08 09:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/f36c9fe788b8 7017673: Remove setting of the sun.jkernel.DownloadManager as a boot classloader hook Reviewed-by: alanb, dcubed, coleenp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/runtime/thread.cpp Changeset: 5197f3d713a1 Author: mchung Date: 2011-02-08 22:27 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/5197f3d713a1 Merge - make/closed.make ! src/share/vm/runtime/thread.cpp Changeset: 63d374c54045 Author: ctornqvi Date: 2011-02-09 11:08 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/63d374c54045 7014918: Improve core/minidump handling in Hotspot Summary: Added Minidump support on Windows, enabled large page core dumps when coredump_filter is present and writing out path/rlimit for core dumps. Reviewed-by: poonam, dsamersoff, sla, coleenp ! src/os/linux/vm/os_linux.cpp + src/os/posix/vm/os_posix.cpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: b83527d0482d Author: ctornqvi Date: 2011-02-10 12:55 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/b83527d0482d 7018366: hotspot/runtime_erro Fix for 7014918 does not build using MVC 2003 Summary: Looking at API_VERSION_NUMBER define to see what version of dbghelp.h/imagehlp.h is included to determine what MINIDUMP_TYPEs are defined in the header file Reviewed-by: acorn, brutisso, sla ! src/os/windows/vm/os_windows.cpp Changeset: e1523f7fd848 Author: rottenha Date: 2011-02-11 05:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e1523f7fd848 Merge - make/closed.make Changeset: 2a9f9f2200fa Author: trims Date: 2011-02-11 15:31 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/2a9f9f2200fa Merge - agent/src/share/classes/sun/jvm/hotspot/runtime/LowMemoryDetectorThread.java Changeset: 762bc029de50 Author: trims Date: 2011-02-11 15:32 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/762bc029de50 7019104: Bump the HS21 build number to 02 Summary: Update the HS21 build number to 02 Reviewed-by: jcoomes ! make/hotspot_version Changeset: e9aa2ca89ad6 Author: kamg Date: 2011-02-16 16:58 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/e9aa2ca89ad6 7019718: make error reporting flags product instead of diagnostic Summary: see synopsis Reviewed-by: acorn, coleenp ! src/share/vm/runtime/globals.hpp Changeset: 0a2ecf4cc384 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/hotspot/rev/0a2ecf4cc384 Added tag jdk7-b130 for changeset e9aa2ca89ad6 ! .hgtags From lana.steuck at oracle.com Wed Feb 23 18:59:20 2011 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 23 Feb 2011 18:59:20 +0000 Subject: hg: jdk7/tl/jdk: 40 new changesets Message-ID: <20110223190553.67005479C0@hg.openjdk.java.net> Changeset: bad0ddc6f573 Author: prr Date: 2011-01-26 11:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bad0ddc6f573 7014738: Update jdk repo application manifests with Windows 7 compatibility section. Reviewed-by: bae, igor ! src/windows/resource/java.manifest Changeset: d0e158473b6f Author: prr Date: 2011-01-26 13:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d0e158473b6f 6940890: Java doesn't pick up the correct fontconfig files in latest Solaris Next builds Reviewed-by: bae, igor ! src/share/classes/sun/java2d/SunGraphicsEnvironment.java Changeset: 4cf20706dbfa Author: dlila Date: 2011-01-27 16:43 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4cf20706dbfa 4645692: solveCubic does not return all solutions. Summary: more robust solveCubic implementation. Reviewed-by: flar ! src/share/classes/java/awt/geom/CubicCurve2D.java + test/java/awt/geom/CubicCurve2D/ContainsTest.java + test/java/awt/geom/CubicCurve2D/IntersectsTest.java + test/java/awt/geom/CubicCurve2D/SolveCubicTest.java Changeset: 21621a756b32 Author: lana Date: 2011-02-03 19:15 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/21621a756b32 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 5e624003e622 Author: dlila Date: 2011-02-08 09:22 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5e624003e622 7016856: dashing performance was reduced during latest changes to the OpenJDK rasterizer Summary: Optimized dashing, rasterizing, and the flow of transformed coordinates Reviewed-by: flar ! src/share/classes/sun/java2d/pisces/Curve.java ! src/share/classes/sun/java2d/pisces/Dasher.java ! src/share/classes/sun/java2d/pisces/Helpers.java ! src/share/classes/sun/java2d/pisces/PiscesCache.java ! src/share/classes/sun/java2d/pisces/PiscesRenderingEngine.java ! src/share/classes/sun/java2d/pisces/PiscesTileGenerator.java ! src/share/classes/sun/java2d/pisces/Renderer.java ! src/share/classes/sun/java2d/pisces/Stroker.java ! src/share/classes/sun/java2d/pisces/TransformingPathConsumer2D.java Changeset: 577c5d930e44 Author: dav Date: 2011-01-25 15:33 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/577c5d930e44 6693961: cross-window focus transfer ability in the Focus Spec should be revised Reviewed-by: ant, art ! src/share/classes/java/awt/doc-files/FocusSpec.html Changeset: 5f3615691623 Author: dav Date: 2011-01-25 19:07 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5f3615691623 6431076: Cursor gets reset to text cursor in xawt TextArea when autoscrolling on append Reviewed-by: art, anthony ! src/solaris/classes/sun/awt/X11/XComponentPeer.java ! src/solaris/classes/sun/awt/X11/XGlobalCursorManager.java ! src/solaris/classes/sun/awt/X11/XTextAreaPeer.java + test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test.java + test/java/awt/TextArea/MouseOverScrollbarWhenTyping/Test1.java Changeset: 6fd2d28e66cd Author: denis Date: 2011-01-28 16:52 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6fd2d28e66cd 6340263: Regression testcase java/awt/dnd/DnDClipboardDeadlockTest throughs IOException: Owner timed out Reviewed-by: anthony, art ! src/solaris/classes/sun/awt/X11/XSelection.java Changeset: 9da15efec22b Author: andrew Date: 2011-02-01 17:44 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9da15efec22b 7015232: missing copyright header in CheckZOrderChange.java Summary: Add standard GPL header as on other tests Reviewed-by: anthony ! test/java/awt/Container/CheckZOrderChange/CheckZOrderChange.java Changeset: 3244848a4a2b Author: dav Date: 2011-02-04 17:32 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3244848a4a2b 6741526: KeyboardFocusManager.setDefaultFocusTraversalPolicy(FocusTraversalPolicy) affects created components Reviewed-by: ant, dcherepanov ! src/share/classes/java/awt/Window.java + test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_AWT.java + test/java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java Changeset: b5fc02e1a944 Author: lana Date: 2011-02-08 14:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b5fc02e1a944 Merge Changeset: 69fac04eda38 Author: rupashka Date: 2011-01-27 14:23 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/69fac04eda38 6902615: Method JTextComponent.getKeyStrokesForAction() throws StackOverflowError Reviewed-by: peterz ! src/share/classes/javax/swing/text/Keymap.java Changeset: ec066e903b84 Author: rupashka Date: 2011-01-27 14:33 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ec066e903b84 6935155: @since tag is missing in JTextComponent.save/restoreComposedText Reviewed-by: alexp ! src/share/classes/javax/swing/text/JTextComponent.java Changeset: 457f6b2cc155 Author: malenkov Date: 2011-01-31 21:22 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/457f6b2cc155 7001484: DOC: Method javax.swing.border.StrokeBorder.getBorderInsets() should specify how it converts float Reviewed-by: alexp ! src/share/classes/javax/swing/border/StrokeBorder.java Changeset: 020b4695370c Author: malenkov Date: 2011-01-31 21:31 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/020b4695370c 7001118: DOC: javax.swing.border.StrokeBorder.paintBorder() doesn't throw NPE in all specified cases Reviewed-by: alexp ! src/share/classes/javax/swing/border/StrokeBorder.java Changeset: 07bea0d4e454 Author: malenkov Date: 2011-01-31 21:49 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/07bea0d4e454 6999045: DOC: Unclear spec for BevelBorder constructor and BorderFactory factory method (colors switching) Reviewed-by: alexp ! src/share/classes/javax/swing/BorderFactory.java ! src/share/classes/javax/swing/border/BevelBorder.java Changeset: cbcd461067c5 Author: rupashka Date: 2011-02-02 18:37 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/cbcd461067c5 6988168: Press the "Toggle Font" button.The size of the combo box didn't change. Reviewed-by: alexp ! src/share/classes/javax/swing/plaf/basic/BasicComboBoxUI.java Changeset: 6c4b6780ab20 Author: rupashka Date: 2011-02-02 18:41 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/6c4b6780ab20 6988176: There is focus painted inside the button. Reviewed-by: alexp ! src/share/classes/sun/swing/WindowsPlacesBar.java Changeset: 057e9b837105 Author: rupashka Date: 2011-02-03 16:30 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/057e9b837105 7013453: BufferStrategyPaintManager.dispose will cause IllegalMonitorStateException in event thread Reviewed-by: alexp ! src/share/classes/javax/swing/BufferStrategyPaintManager.java + test/javax/swing/RepaintManager/7013453/bug7013453.java Changeset: 0fae79ec7248 Author: naoto Date: 2011-02-03 09:59 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0fae79ec7248 7013282: No appropriate CCC request for listed JDK 7 changes in java.util.spi package (b121) Reviewed-by: peytoia ! src/share/classes/java/util/spi/LocaleNameProvider.java Changeset: c7e368a95c75 Author: alexp Date: 2011-02-07 21:15 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c7e368a95c75 7016942: Revert a refactoring in TooltipManager to allow reflection hack Reviewed-by: rupashka ! src/share/classes/javax/swing/ToolTipManager.java Changeset: 989f6d3eee0d Author: alexp Date: 2011-02-07 21:34 +0300 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/989f6d3eee0d 6979537: closed/javax/swing/JSplitPane/UnitTest/UnitTest.java fails Reviewed-by: rupashka ! src/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java Changeset: 842a0f8c89ea Author: naoto Date: 2011-02-08 09:04 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/842a0f8c89ea 7015500: Locale.toLanguageTag() uses "und" as lang subtag for private use only Locale Reviewed-by: srl ! src/share/classes/java/util/Locale.java ! src/share/classes/sun/util/locale/LanguageTag.java ! test/java/util/Locale/LocaleEnhanceTest.java Changeset: d002fe0c57c5 Author: lana Date: 2011-02-08 14:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d002fe0c57c5 Merge Changeset: 1899523d8f24 Author: lana Date: 2011-02-08 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1899523d8f24 Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: a8fcaf5097ec Author: lana Date: 2011-02-09 10:28 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a8fcaf5097ec Merge Changeset: 9d141e45ee4b Author: lana Date: 2011-02-14 16:30 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9d141e45ee4b Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: e4802c87e5c7 Author: herrick Date: 2011-02-09 09:19 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/e4802c87e5c7 7016724: Remove sun.jkernel.* classes in JDK 7 Summary: Remove sun.jkernel.* classes in JDK 7 Reviewed-by: ohair, alanb, mchung ! make/modules/modules.config ! make/sun/Makefile - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/util/zip/ZipEntry.java - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java ! src/share/classes/sun/jvmstat/monitor/MonitoredVmUtil.java ! src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/tools/attach/HotSpotAttachProvider.java ! src/windows/bin/java_md.c - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc Changeset: dc909d130397 Author: herrick Date: 2011-02-09 09:32 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc909d130397 Merge - make/java/hpi/Makefile - make/java/hpi/hpi_common.gmk - make/java/hpi/native/Makefile - make/java/hpi/native/mapfile-vers - make/java/hpi/native/reorder-i586 - make/java/hpi/native/reorder-sparc - make/java/hpi/native/reorder-sparcv9 - make/java/hpi/windows/Makefile - src/share/hpi/export/bool.h - src/share/hpi/export/dll.h - src/share/hpi/export/hpi.h - src/share/hpi/include/hpi_impl.h - src/share/hpi/include/vm_calls.h - src/share/hpi/src/hpi.c - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.8.properties - src/solaris/classes/sun/awt/fontconfigs/solaris.fontconfig.5.9.properties - src/solaris/hpi/export/byteorder_md.h - src/solaris/hpi/export/hpi_md.h - src/solaris/hpi/export/io_md.h - src/solaris/hpi/export/path_md.h - src/solaris/hpi/export/timeval_md.h - src/solaris/hpi/include/hpi_init.h - src/solaris/hpi/include/interrupt.h - src/solaris/hpi/include/largefile.h - src/solaris/hpi/include/largefile_linux.h - src/solaris/hpi/include/largefile_solaris.h - src/solaris/hpi/native_threads/include/condvar_md.h - src/solaris/hpi/native_threads/include/monitor_md.h - src/solaris/hpi/native_threads/include/mutex_md.h - src/solaris/hpi/native_threads/include/np.h - src/solaris/hpi/native_threads/include/porting.h - src/solaris/hpi/native_threads/include/threads_md.h - src/solaris/hpi/native_threads/src/condvar_md.c - src/solaris/hpi/native_threads/src/interrupt_md.c - src/solaris/hpi/native_threads/src/monitor_md.c - src/solaris/hpi/native_threads/src/mutex_md.c - src/solaris/hpi/native_threads/src/sys_api_td.c - src/solaris/hpi/native_threads/src/threads_linux.c - src/solaris/hpi/native_threads/src/threads_md.c - src/solaris/hpi/native_threads/src/threads_solaris.c - src/solaris/hpi/src/interrupt.c - src/solaris/hpi/src/linker_md.c - src/solaris/hpi/src/memory_md.c - src/solaris/hpi/src/system_md.c - src/windows/hpi/export/byteorder_md.h - src/windows/hpi/export/hpi_md.h - src/windows/hpi/export/io_md.h - src/windows/hpi/export/path_md.h - src/windows/hpi/export/timeval_md.h - src/windows/hpi/include/monitor_md.h - src/windows/hpi/include/mutex_md.h - src/windows/hpi/include/threads_md.h - src/windows/hpi/src/linker_md.c - src/windows/hpi/src/memory_md.c - src/windows/hpi/src/monitor_md.c - src/windows/hpi/src/path_md.c - src/windows/hpi/src/socket_md.c - src/windows/hpi/src/sys_api_md.c - src/windows/hpi/src/system_md.c - src/windows/hpi/src/threads_md.c - test/java/net/InetAddress/B4762344.java - test/java/net/InetAddress/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/java/net/InetAddress/Simple1NameServiceDescriptor.java - test/java/net/InetAddress/Simple2NameServiceDescriptor.java - test/java/net/InetAddress/SimpleNameService.java - test/sun/net/InetAddress/nameservice/B6442088.java - test/sun/net/InetAddress/nameservice/CacheTest.java - test/sun/net/InetAddress/nameservice/META-INF/services/sun.net.spi.nameservice.NameServiceDescriptor - test/sun/net/InetAddress/nameservice/SimpleNameService.java - test/sun/net/InetAddress/nameservice/SimpleNameServiceDescriptor.java Changeset: 4f84cda2a7d5 Author: igor Date: 2011-02-09 21:20 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/4f84cda2a7d5 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc Changeset: 802c085308bf Author: igor Date: 2011-02-15 19:16 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/802c085308bf Merge - src/share/classes/java/io/TempFileHelper.java - src/share/classes/java/nio/file/FileRef.java - src/share/classes/java/nio/file/attribute/Attributes.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributeView.java - src/share/classes/java/nio/file/attribute/FileStoreSpaceAttributes.java - src/share/demo/zipfs - test/java/nio/file/Files/ContentType.java - test/java/nio/file/Files/CreateFileTree.java - test/java/nio/file/Files/ForceLoad.java - test/java/nio/file/Files/META-INF/services/java.nio.file.spi.FileTypeDetector - test/java/nio/file/Files/MaxDepth.java - test/java/nio/file/Files/PrintFileTree.java - test/java/nio/file/Files/SimpleFileTypeDetector.java - test/java/nio/file/Files/SkipSiblings.java - test/java/nio/file/Files/TerminateWalk.java - test/java/nio/file/Files/WalkWithSecurity.java - test/java/nio/file/Files/denyAll.policy - test/java/nio/file/Files/grantAll.policy - test/java/nio/file/Files/grantTopOnly.policy - test/java/nio/file/Files/walk_file_tree.sh - test/java/nio/file/Path/CheckPermissions.java - test/java/nio/file/Path/CopyAndMove.java - test/java/nio/file/Path/DeleteOnClose.java - test/java/nio/file/Path/FileAttributes.java - test/java/nio/file/Path/InterruptCopy.java - test/java/nio/file/Path/Links.java - test/java/nio/file/Path/PassThroughFileSystem.java - test/java/nio/file/Path/SBC.java - test/java/nio/file/Path/TemporaryFiles.java - test/java/nio/file/Path/delete_on_close.sh - test/java/nio/file/attribute/FileStoreAttributeView/Basic.java Changeset: 9478964f9425 Author: ohair Date: 2011-02-10 20:51 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/9478964f9425 Merge Changeset: 71b52ce5f389 Author: mfang Date: 2011-02-10 20:52 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/71b52ce5f389 7017734: jdk7 message drop 1 translation integration Reviewed-by: ogino, yhuang ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_de.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_es.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_fr.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_it.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ja.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_ko.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_pt_BR.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_sv.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_CN.properties ! src/share/classes/com/sun/accessibility/internal/resources/accessibility_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_de.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_es.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_it.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ja.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_ko.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_sv.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_de.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_es.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_fr.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_it.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ja.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_ko.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_sv.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/motif/resources/motif_zh_TW.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_de.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_es.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_fr.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_it.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ja.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_ko.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_pt_BR.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_sv.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_CN.properties ! src/share/classes/com/sun/java/swing/plaf/windows/resources/windows_zh_TW.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_de.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_es.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_fr.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_it.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ja.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_ko.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_pt_BR.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_sv.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_CN.properties ! src/share/classes/com/sun/rowset/RowSetResourceBundle_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_de.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_es.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_it.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/basic/resources/basic_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_de.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_es.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_it.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/metal/resources/metal_zh_TW.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_de.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_es.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_fr.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_it.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ja.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_ko.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_pt_BR.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_sv.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_CN.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth_zh_TW.properties ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_ja.java ! src/share/classes/com/sun/tools/example/debug/tty/TTYResources_zh_CN.java ! src/share/classes/com/sun/tools/jdi/resources/jdi_ja.properties ! src/share/classes/com/sun/tools/jdi/resources/jdi_zh_CN.properties ! src/share/classes/sun/applet/resources/MsgAppletViewer_de.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_es.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_fr.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_it.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ja.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_ko.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_pt_BR.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_sv.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_CN.java ! src/share/classes/sun/applet/resources/MsgAppletViewer_zh_TW.java ! src/share/classes/sun/awt/resources/awt_de.properties ! src/share/classes/sun/awt/resources/awt_es.properties ! src/share/classes/sun/awt/resources/awt_fr.properties ! src/share/classes/sun/awt/resources/awt_it.properties ! src/share/classes/sun/awt/resources/awt_ja.properties ! src/share/classes/sun/awt/resources/awt_ko.properties ! src/share/classes/sun/awt/resources/awt_pt_BR.properties ! src/share/classes/sun/awt/resources/awt_sv.properties ! src/share/classes/sun/awt/resources/awt_zh_CN.properties ! src/share/classes/sun/awt/resources/awt_zh_TW.properties ! src/share/classes/sun/management/resources/agent_de.properties ! src/share/classes/sun/management/resources/agent_es.properties ! src/share/classes/sun/management/resources/agent_fr.properties ! src/share/classes/sun/management/resources/agent_it.properties ! src/share/classes/sun/management/resources/agent_ja.properties ! src/share/classes/sun/management/resources/agent_ko.properties ! src/share/classes/sun/management/resources/agent_pt_BR.properties ! src/share/classes/sun/management/resources/agent_sv.properties ! src/share/classes/sun/management/resources/agent_zh_CN.properties ! src/share/classes/sun/management/resources/agent_zh_TW.properties ! src/share/classes/sun/misc/resources/Messages_de.java ! src/share/classes/sun/misc/resources/Messages_es.java ! src/share/classes/sun/misc/resources/Messages_fr.java ! src/share/classes/sun/misc/resources/Messages_it.java ! src/share/classes/sun/misc/resources/Messages_ja.java ! src/share/classes/sun/misc/resources/Messages_ko.java ! src/share/classes/sun/misc/resources/Messages_pt_BR.java ! src/share/classes/sun/misc/resources/Messages_sv.java ! src/share/classes/sun/misc/resources/Messages_zh_CN.java ! src/share/classes/sun/misc/resources/Messages_zh_TW.java ! src/share/classes/sun/print/resources/serviceui_de.properties ! src/share/classes/sun/print/resources/serviceui_es.properties ! src/share/classes/sun/print/resources/serviceui_fr.properties ! src/share/classes/sun/print/resources/serviceui_it.properties ! src/share/classes/sun/print/resources/serviceui_ja.properties ! src/share/classes/sun/print/resources/serviceui_ko.properties ! src/share/classes/sun/print/resources/serviceui_pt_BR.properties ! src/share/classes/sun/print/resources/serviceui_sv.properties ! src/share/classes/sun/print/resources/serviceui_zh_CN.properties ! src/share/classes/sun/print/resources/serviceui_zh_TW.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_de.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_es.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_fr.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_it.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ja.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_ko.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_pt_BR.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_sv.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_CN.properties ! src/share/classes/sun/rmi/registry/resources/rmiregistry_zh_TW.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_ja.properties ! src/share/classes/sun/rmi/rmic/resources/rmic_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_de.properties ! src/share/classes/sun/rmi/server/resources/rmid_es.properties ! src/share/classes/sun/rmi/server/resources/rmid_fr.properties ! src/share/classes/sun/rmi/server/resources/rmid_it.properties ! src/share/classes/sun/rmi/server/resources/rmid_ja.properties ! src/share/classes/sun/rmi/server/resources/rmid_ko.properties ! src/share/classes/sun/rmi/server/resources/rmid_pt_BR.properties ! src/share/classes/sun/rmi/server/resources/rmid_sv.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_CN.properties ! src/share/classes/sun/rmi/server/resources/rmid_zh_TW.properties ! src/share/classes/sun/security/tools/JarSignerResources_ja.java ! src/share/classes/sun/security/tools/JarSignerResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_de.java ! src/share/classes/sun/security/util/AuthResources_es.java ! src/share/classes/sun/security/util/AuthResources_fr.java ! src/share/classes/sun/security/util/AuthResources_it.java ! src/share/classes/sun/security/util/AuthResources_ja.java ! src/share/classes/sun/security/util/AuthResources_ko.java ! src/share/classes/sun/security/util/AuthResources_pt_BR.java ! src/share/classes/sun/security/util/AuthResources_sv.java ! src/share/classes/sun/security/util/AuthResources_zh_CN.java ! src/share/classes/sun/security/util/AuthResources_zh_TW.java ! src/share/classes/sun/security/util/Resources_de.java ! src/share/classes/sun/security/util/Resources_es.java ! src/share/classes/sun/security/util/Resources_fr.java ! src/share/classes/sun/security/util/Resources_it.java ! src/share/classes/sun/security/util/Resources_ja.java ! src/share/classes/sun/security/util/Resources_ko.java ! src/share/classes/sun/security/util/Resources_pt_BR.java ! src/share/classes/sun/security/util/Resources_sv.java ! src/share/classes/sun/security/util/Resources_zh_CN.java ! src/share/classes/sun/security/util/Resources_zh_TW.java ! src/share/classes/sun/tools/jar/resources/jar_de.properties ! src/share/classes/sun/tools/jar/resources/jar_es.properties ! src/share/classes/sun/tools/jar/resources/jar_fr.properties ! src/share/classes/sun/tools/jar/resources/jar_it.properties ! src/share/classes/sun/tools/jar/resources/jar_ja.properties ! src/share/classes/sun/tools/jar/resources/jar_ko.properties ! src/share/classes/sun/tools/jar/resources/jar_pt_BR.properties ! src/share/classes/sun/tools/jar/resources/jar_sv.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_CN.properties ! src/share/classes/sun/tools/jar/resources/jar_zh_TW.properties ! src/share/classes/sun/tools/javac/resources/javac_ja.properties ! src/share/classes/sun/tools/javac/resources/javac_zh_CN.properties ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_ja.java ! src/share/classes/sun/tools/jconsole/resources/JConsoleResources_zh_CN.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_ja.java ! src/share/classes/sun/tools/native2ascii/resources/MsgNative2ascii_zh_CN.java ! src/share/classes/sun/tools/serialver/serialver_ja.properties ! src/share/classes/sun/tools/serialver/serialver_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_de.properties ! src/share/classes/sun/util/logging/resources/logging_es.properties ! src/share/classes/sun/util/logging/resources/logging_fr.properties ! src/share/classes/sun/util/logging/resources/logging_it.properties ! src/share/classes/sun/util/logging/resources/logging_ja.properties ! src/share/classes/sun/util/logging/resources/logging_ko.properties ! src/share/classes/sun/util/logging/resources/logging_pt_BR.properties ! src/share/classes/sun/util/logging/resources/logging_sv.properties ! src/share/classes/sun/util/logging/resources/logging_zh_CN.properties ! src/share/classes/sun/util/logging/resources/logging_zh_TW.properties ! src/share/demo/jfc/CodePointIM/resources/codepoint_ja.properties ! src/share/demo/jfc/CodePointIM/resources/codepoint_zh_CN.properties ! src/share/demo/jfc/Font2DTest/resources/TextResources_ja.properties ! src/share/demo/jfc/Font2DTest/resources/TextResources_zh_CN.properties ! src/share/demo/jfc/Notepad/resources/Notepad_ja.properties ! src/share/demo/jfc/Notepad/resources/Notepad_zh_CN.properties ! src/windows/classes/sun/awt/windows/awtLocalization_es.properties ! src/windows/classes/sun/awt/windows/awtLocalization_ja.properties ! src/windows/classes/sun/awt/windows/awtLocalization_ko.properties ! src/windows/classes/sun/awt/windows/awtLocalization_pt_BR.properties ! src/windows/classes/sun/awt/windows/awtLocalization_zh_CN.properties ! src/windows/classes/sun/awt/windows/awtLocalization_zh_TW.properties ! src/windows/native/sun/jkernel/kernel_de.rc ! src/windows/native/sun/jkernel/kernel_es.rc ! src/windows/native/sun/jkernel/kernel_fr.rc ! src/windows/native/sun/jkernel/kernel_it.rc ! src/windows/native/sun/jkernel/kernel_ja.rc ! src/windows/native/sun/jkernel/kernel_ko.rc ! src/windows/native/sun/jkernel/kernel_pt_BR.rc ! src/windows/native/sun/jkernel/kernel_sv.rc ! src/windows/native/sun/jkernel/kernel_zh.rc ! src/windows/native/sun/jkernel/kernel_zh_TW.rc Changeset: 8b6d1d96ef3d Author: mfang Date: 2011-02-11 22:57 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8b6d1d96ef3d Merge Changeset: 0eacbbc8e1fb Author: mfang Date: 2011-02-11 23:46 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0eacbbc8e1fb Merge Changeset: 780e53ad2896 Author: mfang Date: 2011-02-14 13:01 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/780e53ad2896 Merge Changeset: 5fab973e5a47 Author: ohair Date: 2011-02-15 12:34 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5fab973e5a47 Merge Changeset: bdc069d3f910 Author: ohair Date: 2011-02-15 20:18 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/bdc069d3f910 Merge Changeset: 89055b6d9ae0 Author: cl Date: 2011-02-18 14:23 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/89055b6d9ae0 Added tag jdk7-b130 for changeset bdc069d3f910 ! .hgtags Changeset: 744c2773e3f7 Author: lana Date: 2011-02-23 10:29 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/744c2773e3f7 Merge - make/sun/jkernel/FILES_c_windows.gmk - make/sun/jkernel/FILES_java.gmk - make/sun/jkernel/Makefile - src/share/classes/sun/jkernel/BackgroundDownloader.java - src/share/classes/sun/jkernel/Bundle.java - src/share/classes/sun/jkernel/BundleCheck.java - src/share/classes/sun/jkernel/ByteArrayToFromHexDigits.java - src/share/classes/sun/jkernel/DigestOutputStream.java - src/share/classes/sun/jkernel/DownloadManager.java - src/share/classes/sun/jkernel/KernelError.java - src/share/classes/sun/jkernel/Mutex.java - src/share/classes/sun/jkernel/StandaloneByteArrayAccess.java - src/share/classes/sun/jkernel/StandaloneMessageDigest.java - src/share/classes/sun/jkernel/StandaloneSHA.java - src/windows/native/sun/jkernel/DownloadDialog.cpp - src/windows/native/sun/jkernel/DownloadDialog.h - src/windows/native/sun/jkernel/DownloadHelper.cpp - src/windows/native/sun/jkernel/DownloadHelper.h - src/windows/native/sun/jkernel/graphics/bullet.bmp - src/windows/native/sun/jkernel/graphics/cautionshield32.bmp - src/windows/native/sun/jkernel/graphics/java-icon.ico - src/windows/native/sun/jkernel/graphics/masthead.bmp - src/windows/native/sun/jkernel/graphics/warningmasthead.bmp - src/windows/native/sun/jkernel/kernel.cpp - src/windows/native/sun/jkernel/kernel.def - src/windows/native/sun/jkernel/kernel.h - src/windows/native/sun/jkernel/kernel.rc - src/windows/native/sun/jkernel/kernel_de.rc - src/windows/native/sun/jkernel/kernel_en.rc - src/windows/native/sun/jkernel/kernel_es.rc - src/windows/native/sun/jkernel/kernel_fr.rc - src/windows/native/sun/jkernel/kernel_it.rc - src/windows/native/sun/jkernel/kernel_ja.rc - src/windows/native/sun/jkernel/kernel_ko.rc - src/windows/native/sun/jkernel/kernel_pt_BR.rc - src/windows/native/sun/jkernel/kernel_sv.rc - src/windows/native/sun/jkernel/kernel_zh.rc - src/windows/native/sun/jkernel/kernel_zh_TW.rc - src/windows/native/sun/jkernel/resource.h - src/windows/native/sun/jkernel/stdafx.cpp - src/windows/native/sun/jkernel/stdafx.h - src/windows/native/sun/jkernel/version.rc ! test/java/util/Locale/LocaleEnhanceTest.java From Alan.Bateman at oracle.com Wed Feb 23 20:03:49 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Feb 2011 20:03:49 +0000 Subject: Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security In-Reply-To: <4D654E60.9070106@oracle.com> References: <4D64558A.6040807@oracle.com> <4D64C8EF.2050101@oracle.com> <4D654E60.9070106@oracle.com> Message-ID: <4D656825.8080403@oracle.com> Rama Pulavarthi wrote: > : > > Just porting the fix along with tests from Open JDK 6 workspace, > that's why I kept the old date. Does it need to be changed? This test > was added then following the convention of other tests. I will check > other tests in JDK 7 to see if it needs any update. > Sorry Rama, it wasn't obvious that this was a forward-port, in which case ignore my comment on the year. On the test, we regularly have issues with tests that are scripts. From a brief glance it doesn't appear to be needed and instead just requires changing the @run tag to @run/othervm (might want to give it a better name too as "Test" doesn't convey much). -Alan. From stuart.marks at oracle.com Thu Feb 24 06:26:45 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 23 Feb 2011 22:26:45 -0800 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests Message-ID: <4D65FA25.8000302@oracle.com> Hi Sherman, all, Here's a webrev to convert code in the jar/zip implementation files and tests to use the new Java 7 try-with-resources construct. http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.0/ There are rather a lot of files, however, most of the changes are pretty straightforward. A typical conversion changes code like this: FileInputStream fis = new FileInputStream(filename); // use fis fis.close(); to this: try (FileInputStream fis = new FileInputStream(filename)) { // use fis } The majority of the conversions are like the above. However, there are a several places where I had to rearrange things either in order to get them to work at all, to improve robustness, or for general cleanup. Some of these are marked with "TODO". I will of course remove these comments before committing the changes. Where you see these comments, you might want to give the code a bit more scrutiny. Specific examples of things to look at follow: * test/java/util/jar/JarEntry/GetMethodsReturnClones.java I had to change the ordering of local variable declarations so that the variable was visible where it's used. TWR introduces a nested block, so obviously a local declared within will have to be moved outside in order to be used outside. This occurs in several other places as well. In some cases initialization order was changed. This shouldn't matter, though, since it's things like opening a file vs. allocating an array. * src/share/classes/com/sun/java/util/jar/pack/Driver.java I narrowed the scope of the open resource. No sense keeping it open any longer than necessary. This occurs in several other places as well. * src/share/classes/com/sun/java/util/jar/pack/PackageReader.java * src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java These changes rely on recent changes to TWR's handling of null resources. Currently, TWR will avoid calling close if the resource is null. Joe checked in this change just last week. Before that, a null resource would generate an unavoidable NPE when it attempted to call close(). Handling of non-null resources is unchanged. I don't think the change to null handling is in a promoted build yet. Is it OK to check in code that depends on it? All tests pass, but that just means that the path where the resource is null isn't tested. * src/share/classes/com/sun/java/util/jar/pack/PropMap.java Narrowed the scope of catch IOException; should be OK since the code that was migrated out cannot throw IOException. * src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java This closes its input after successful processing. I changed this so that it also closes its input if an exception is thrown. * test/java/util/zip/LargeZip.java I've "unrolled" a cascade of constructors into separate resource variables. This also occurs in several other places. Basically code that used to look like this: ZipOutputStream zos = new ZipOutputStream( new BufferedOutputStream( new FileOutputStream(largeFile))); // process zos zos.close(); is converted to this: try (FileOutputStream fos = new FileOutputStream(largeFile); BufferedOutputStream bos = new BufferedOutputStream(fos); ZipOutputStream zos = new ZipOutputStream(bos)) { // process zos } I think this more robust, since it closes the FileOutputStream if an exception occurs during the construction of one of the stacked streams, which the original code did not handle. Since the wrapper streams will close their underlying streams, this will result in redundant close() calls. However, close() is supposed to be idempotent so this should be OK. * test/java/util/zip/ZipFile/DeleteTempJar.java I'm not sure if this properly handles an IOException caused by HttpExchange.close(). Funny, the method isn't declared to throw IOE, but this test did compile and pass. * test/java/util/zip/ZipFile/LargeZipFile.java I changed this to fail the test if close() were to throw IOE. I think this is proper for test code. * test/java/util/zip/ZipFile/ReadZip.java I took the liberty of converting the file copying code to use the new java.nio.file.Files utilities. Well, I'm really following Alan's lead here since he's prompted me to do so in other places a couple times already. :-) Thanks for reviewing! s'marks From xueming.shen at oracle.com Thu Feb 24 06:46:22 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 23 Feb 2011 22:46:22 -0800 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D65FA25.8000302@oracle.com> References: <4D65FA25.8000302@oracle.com> Message-ID: <4D65FEBE.9040401@oracle.com> Kumar, Would you please help review the change in your pack code? Thanks, -Sherman On 2011-2-23 22:26, Stuart Marks wrote: > Hi Sherman, all, > > Here's a webrev to convert code in the jar/zip implementation files > and tests to use the new Java 7 try-with-resources construct. > > http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.0/ > > There are rather a lot of files, however, most of the changes are > pretty straightforward. A typical conversion changes code like this: > > FileInputStream fis = new FileInputStream(filename); > // use fis > fis.close(); > > to this: > > try (FileInputStream fis = new FileInputStream(filename)) { > // use fis > } > > The majority of the conversions are like the above. However, there are > a several places where I had to rearrange things either in order to > get them to work at all, to improve robustness, or for general cleanup. > > Some of these are marked with "TODO". I will of course remove these > comments before committing the changes. Where you see these comments, > you might want to give the code a bit more scrutiny. > > Specific examples of things to look at follow: > > * test/java/util/jar/JarEntry/GetMethodsReturnClones.java > > I had to change the ordering of local variable declarations so that > the variable was visible where it's used. TWR introduces a nested > block, so obviously a local declared within will have to be moved > outside in order to be used outside. This occurs in several other > places as well. In some cases initialization order was changed. This > shouldn't matter, though, since it's things like opening a file vs. > allocating an array. > > * src/share/classes/com/sun/java/util/jar/pack/Driver.java > > I narrowed the scope of the open resource. No sense keeping it open > any longer than necessary. This occurs in several other places as well. > > * src/share/classes/com/sun/java/util/jar/pack/PackageReader.java > * src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java > > These changes rely on recent changes to TWR's handling of null > resources. Currently, TWR will avoid calling close if the resource is > null. Joe checked in this change just last week. Before that, a null > resource would generate an unavoidable NPE when it attempted to call > close(). Handling of non-null resources is unchanged. > > I don't think the change to null handling is in a promoted build yet. > Is it OK to check in code that depends on it? All tests pass, but that > just means that the path where the resource is null isn't tested. > > * src/share/classes/com/sun/java/util/jar/pack/PropMap.java > > Narrowed the scope of catch IOException; should be OK since the code > that was migrated out cannot throw IOException. > > * src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java > > This closes its input after successful processing. I changed this so > that it also closes its input if an exception is thrown. > > * test/java/util/zip/LargeZip.java > > I've "unrolled" a cascade of constructors into separate resource > variables. This also occurs in several other places. Basically code > that used to look like this: > > ZipOutputStream zos = new ZipOutputStream( > new BufferedOutputStream( > new FileOutputStream(largeFile))); > // process zos > zos.close(); > > is converted to this: > > try (FileOutputStream fos = new FileOutputStream(largeFile); > BufferedOutputStream bos = new BufferedOutputStream(fos); > ZipOutputStream zos = new ZipOutputStream(bos)) > { > // process zos > } > > I think this more robust, since it closes the FileOutputStream if an > exception occurs during the construction of one of the stacked > streams, which the original code did not handle. Since the wrapper > streams will close their underlying streams, this will result in > redundant close() calls. However, close() is supposed to be idempotent > so this should be OK. > > * test/java/util/zip/ZipFile/DeleteTempJar.java > > I'm not sure if this properly handles an IOException caused by > HttpExchange.close(). Funny, the method isn't declared to throw IOE, > but this test did compile and pass. > > * test/java/util/zip/ZipFile/LargeZipFile.java > > I changed this to fail the test if close() were to throw IOE. I think > this is proper for test code. > > * test/java/util/zip/ZipFile/ReadZip.java > > I took the liberty of converting the file copying code to use the new > java.nio.file.Files utilities. Well, I'm really following Alan's lead > here since he's prompted me to do so in other places a couple times > already. :-) > > Thanks for reviewing! > > s'marks From bradford.wetmore at oracle.com Thu Feb 24 06:57:27 2011 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Thu, 24 Feb 2011 06:57:27 +0000 Subject: hg: jdk7/tl/jdk: 6844879: Source distribution should be more robustly built without the security source distribution Message-ID: <20110224065736.BBA04479F4@hg.openjdk.java.net> Changeset: 0f0d6b8f98cc Author: wetmore Date: 2011-02-23 22:54 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/0f0d6b8f98cc 6844879: Source distribution should be more robustly built without the security source distribution Reviewed-by: ohair ! make/common/shared/Defs-java.gmk From David.Holmes at oracle.com Thu Feb 24 07:11:46 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 24 Feb 2011 17:11:46 +1000 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D65FA25.8000302@oracle.com> References: <4D65FA25.8000302@oracle.com> Message-ID: <4D6604B2.6070104@oracle.com> Hi Stuart, Just taking a look as a curious observer ... I'm somewhat dismayed by the lack of exception handling in the original code. Stuart Marks said the following on 02/24/11 16:26: > > * src/share/classes/com/sun/java/util/jar/pack/Driver.java > > I narrowed the scope of the open resource. No sense keeping it open any > longer than necessary. This occurs in several other places as well. You also changed from using a BufferedStream to just the FileInputStream - was that intentional? > * src/share/classes/com/sun/java/util/jar/pack/PropMap.java > > Narrowed the scope of catch IOException; should be OK since the code > that was migrated out cannot throw IOException. So in this one: 128 boolean propsLoaded = false; 129 try (InputStream propStr = PackerImpl.class.getResourceAsStream(propFile)) { 130 props.load(propStr); 131 propsLoaded = true; 132 } catch (IOException ee) { 133 // ignore exception if it came from the close() 134 if (!propsLoaded) { 135 throw new RuntimeException(ee); 136 } 137 } The RuntimeException has a cause of ee, which in turn may have a suppressed IOException from the close(). test/java/util/zip/Available.java Don't you need to unroll the constructors here too: 47 try (ZipInputStream z = new ZipInputStream(new FileInputStream(f))) { 48 z.getNextEntry(); 49 tryAvail(z); 50 } test/java/util/zip/GZIP/GZIPInputStreamRead.java Unroll here too: 78 try (GZIPInputStream gzis = new GZIPInputStream( 79 new ByteArrayInputStream(dst), 80 gzisBufSize)) 81 { Cheers, David --------- > > * src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java > > This closes its input after successful processing. I changed this so > that it also closes its input if an exception is thrown. > > * test/java/util/zip/LargeZip.java > > I've "unrolled" a cascade of constructors into separate resource > variables. This also occurs in several other places. Basically code that > used to look like this: > > ZipOutputStream zos = new ZipOutputStream( > new BufferedOutputStream( > new FileOutputStream(largeFile))); > // process zos > zos.close(); > > is converted to this: > > try (FileOutputStream fos = new FileOutputStream(largeFile); > BufferedOutputStream bos = new BufferedOutputStream(fos); > ZipOutputStream zos = new ZipOutputStream(bos)) > { > // process zos > } > > I think this more robust, since it closes the FileOutputStream if an > exception occurs during the construction of one of the stacked streams, > which the original code did not handle. Since the wrapper streams will > close their underlying streams, this will result in redundant close() > calls. However, close() is supposed to be idempotent so this should be OK. > > * test/java/util/zip/ZipFile/DeleteTempJar.java > > I'm not sure if this properly handles an IOException caused by > HttpExchange.close(). Funny, the method isn't declared to throw IOE, but > this test did compile and pass. > > * test/java/util/zip/ZipFile/LargeZipFile.java > > I changed this to fail the test if close() were to throw IOE. I think > this is proper for test code. > > * test/java/util/zip/ZipFile/ReadZip.java > > I took the liberty of converting the file copying code to use the new > java.nio.file.Files utilities. Well, I'm really following Alan's lead > here since he's prompted me to do so in other places a couple times > already. :-) > > Thanks for reviewing! > > s'marks From xueming.shen at oracle.com Thu Feb 24 08:36:48 2011 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 24 Feb 2011 00:36:48 -0800 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D65FA25.8000302@oracle.com> References: <4D65FA25.8000302@oracle.com> Message-ID: <4D6618A0.7060801@oracle.com> Stuart, Here are my comments on non-pack changes. I'm sure Kumar will look at those pack files later. GetMethodsReturnClones.java: ln#43 diamond conersion? Available.java: it's not your change, but I believe we should do the try-with_resources on the ZipFile zfile as well. InfoZip.java.: ln#113/114 you probably don't need to separate out the "fis" in try-with-resources, the FileInputStream created should be closed by the ZipInputStream that it is embedded in. LargeZip.java: ln#101-1-4/148-151, same as above, only need to close ZipOut/InputStream TestEmptyZip.java: TestEmptyZip.java: Comment.java: ln#60-62 CorruptedZipFiles.java ln#50 DeleteTempJar.java: LargeZipFile.java. ManyEntries.java ReadZip.java. ShortRead.java only close the ZipIn/OutputStream -Sherman On 2011-2-23 22:26, Stuart Marks wrote: > Hi Sherman, all, > > Here's a webrev to convert code in the jar/zip implementation files > and tests to use the new Java 7 try-with-resources construct. > > http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.0/ > > There are rather a lot of files, however, most of the changes are > pretty straightforward. A typical conversion changes code like this: > > FileInputStream fis = new FileInputStream(filename); > // use fis > fis.close(); > > to this: > > try (FileInputStream fis = new FileInputStream(filename)) { > // use fis > } > > The majority of the conversions are like the above. However, there are > a several places where I had to rearrange things either in order to > get them to work at all, to improve robustness, or for general cleanup. > > Some of these are marked with "TODO". I will of course remove these > comments before committing the changes. Where you see these comments, > you might want to give the code a bit more scrutiny. > > Specific examples of things to look at follow: > > * test/java/util/jar/JarEntry/GetMethodsReturnClones.java > > I had to change the ordering of local variable declarations so that > the variable was visible where it's used. TWR introduces a nested > block, so obviously a local declared within will have to be moved > outside in order to be used outside. This occurs in several other > places as well. In some cases initialization order was changed. This > shouldn't matter, though, since it's things like opening a file vs. > allocating an array. > > * src/share/classes/com/sun/java/util/jar/pack/Driver.java > > I narrowed the scope of the open resource. No sense keeping it open > any longer than necessary. This occurs in several other places as well. > > * src/share/classes/com/sun/java/util/jar/pack/PackageReader.java > * src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java > > These changes rely on recent changes to TWR's handling of null > resources. Currently, TWR will avoid calling close if the resource is > null. Joe checked in this change just last week. Before that, a null > resource would generate an unavoidable NPE when it attempted to call > close(). Handling of non-null resources is unchanged. > > I don't think the change to null handling is in a promoted build yet. > Is it OK to check in code that depends on it? All tests pass, but that > just means that the path where the resource is null isn't tested. > > * src/share/classes/com/sun/java/util/jar/pack/PropMap.java > > Narrowed the scope of catch IOException; should be OK since the code > that was migrated out cannot throw IOException. > > * src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java > > This closes its input after successful processing. I changed this so > that it also closes its input if an exception is thrown. > > * test/java/util/zip/LargeZip.java > > I've "unrolled" a cascade of constructors into separate resource > variables. This also occurs in several other places. Basically code > that used to look like this: > > ZipOutputStream zos = new ZipOutputStream( > new BufferedOutputStream( > new FileOutputStream(largeFile))); > // process zos > zos.close(); > > is converted to this: > > try (FileOutputStream fos = new FileOutputStream(largeFile); > BufferedOutputStream bos = new BufferedOutputStream(fos); > ZipOutputStream zos = new ZipOutputStream(bos)) > { > // process zos > } > > I think this more robust, since it closes the FileOutputStream if an > exception occurs during the construction of one of the stacked > streams, which the original code did not handle. Since the wrapper > streams will close their underlying streams, this will result in > redundant close() calls. However, close() is supposed to be idempotent > so this should be OK. > > * test/java/util/zip/ZipFile/DeleteTempJar.java > > I'm not sure if this properly handles an IOException caused by > HttpExchange.close(). Funny, the method isn't declared to throw IOE, > but this test did compile and pass. > > * test/java/util/zip/ZipFile/LargeZipFile.java > > I changed this to fail the test if close() were to throw IOE. I think > this is proper for test code. > > * test/java/util/zip/ZipFile/ReadZip.java > > I took the liberty of converting the file copying code to use the new > java.nio.file.Files utilities. Well, I'm really following Alan's lead > here since he's prompted me to do so in other places a couple times > already. :-) > > Thanks for reviewing! > > s'marks From David.Holmes at oracle.com Thu Feb 24 09:39:55 2011 From: David.Holmes at oracle.com (David Holmes) Date: Thu, 24 Feb 2011 19:39:55 +1000 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D6618A0.7060801@oracle.com> References: <4D65FA25.8000302@oracle.com> <4D6618A0.7060801@oracle.com> Message-ID: <4D66276B.9040708@oracle.com> Hi Sherman, Xueming Shen said the following on 02/24/11 18:36: > InfoZip.java.: ln#113/114 you probably don't need to separate out the > "fis" in try-with-resources, the FileInputStream > created should be closed by the ZipInputStream that it is embedded in. The reason to do this is in case the ZipInputStream constructor throws an exception. In that case the fis will not be closed with the normal chained construction sequence. David > LargeZip.java: ln#101-1-4/148-151, same as above, only need to close > ZipOut/InputStream > > TestEmptyZip.java: > TestEmptyZip.java: > Comment.java: ln#60-62 > CorruptedZipFiles.java ln#50 > DeleteTempJar.java: > LargeZipFile.java. > ManyEntries.java > ReadZip.java. > ShortRead.java > only close the ZipIn/OutputStream > > -Sherman > > On 2011-2-23 22:26, Stuart Marks wrote: >> Hi Sherman, all, >> >> Here's a webrev to convert code in the jar/zip implementation files >> and tests to use the new Java 7 try-with-resources construct. >> >> http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.0/ >> >> There are rather a lot of files, however, most of the changes are >> pretty straightforward. A typical conversion changes code like this: >> >> FileInputStream fis = new FileInputStream(filename); >> // use fis >> fis.close(); >> >> to this: >> >> try (FileInputStream fis = new FileInputStream(filename)) { >> // use fis >> } >> >> The majority of the conversions are like the above. However, there are >> a several places where I had to rearrange things either in order to >> get them to work at all, to improve robustness, or for general cleanup. >> >> Some of these are marked with "TODO". I will of course remove these >> comments before committing the changes. Where you see these comments, >> you might want to give the code a bit more scrutiny. >> >> Specific examples of things to look at follow: >> >> * test/java/util/jar/JarEntry/GetMethodsReturnClones.java >> >> I had to change the ordering of local variable declarations so that >> the variable was visible where it's used. TWR introduces a nested >> block, so obviously a local declared within will have to be moved >> outside in order to be used outside. This occurs in several other >> places as well. In some cases initialization order was changed. This >> shouldn't matter, though, since it's things like opening a file vs. >> allocating an array. >> >> * src/share/classes/com/sun/java/util/jar/pack/Driver.java >> >> I narrowed the scope of the open resource. No sense keeping it open >> any longer than necessary. This occurs in several other places as well. >> >> * src/share/classes/com/sun/java/util/jar/pack/PackageReader.java >> * src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java >> >> These changes rely on recent changes to TWR's handling of null >> resources. Currently, TWR will avoid calling close if the resource is >> null. Joe checked in this change just last week. Before that, a null >> resource would generate an unavoidable NPE when it attempted to call >> close(). Handling of non-null resources is unchanged. >> >> I don't think the change to null handling is in a promoted build yet. >> Is it OK to check in code that depends on it? All tests pass, but that >> just means that the path where the resource is null isn't tested. >> >> * src/share/classes/com/sun/java/util/jar/pack/PropMap.java >> >> Narrowed the scope of catch IOException; should be OK since the code >> that was migrated out cannot throw IOException. >> >> * src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java >> >> This closes its input after successful processing. I changed this so >> that it also closes its input if an exception is thrown. >> >> * test/java/util/zip/LargeZip.java >> >> I've "unrolled" a cascade of constructors into separate resource >> variables. This also occurs in several other places. Basically code >> that used to look like this: >> >> ZipOutputStream zos = new ZipOutputStream( >> new BufferedOutputStream( >> new FileOutputStream(largeFile))); >> // process zos >> zos.close(); >> >> is converted to this: >> >> try (FileOutputStream fos = new FileOutputStream(largeFile); >> BufferedOutputStream bos = new BufferedOutputStream(fos); >> ZipOutputStream zos = new ZipOutputStream(bos)) >> { >> // process zos >> } >> >> I think this more robust, since it closes the FileOutputStream if an >> exception occurs during the construction of one of the stacked >> streams, which the original code did not handle. Since the wrapper >> streams will close their underlying streams, this will result in >> redundant close() calls. However, close() is supposed to be idempotent >> so this should be OK. >> >> * test/java/util/zip/ZipFile/DeleteTempJar.java >> >> I'm not sure if this properly handles an IOException caused by >> HttpExchange.close(). Funny, the method isn't declared to throw IOE, >> but this test did compile and pass. >> >> * test/java/util/zip/ZipFile/LargeZipFile.java >> >> I changed this to fail the test if close() were to throw IOE. I think >> this is proper for test code. >> >> * test/java/util/zip/ZipFile/ReadZip.java >> >> I took the liberty of converting the file copying code to use the new >> java.nio.file.Files utilities. Well, I'm really following Alan's lead >> here since he's prompted me to do so in other places a couple times >> already. :-) >> >> Thanks for reviewing! >> >> s'marks > From Alan.Bateman at oracle.com Thu Feb 24 10:20:48 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Feb 2011 10:20:48 +0000 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D65FA25.8000302@oracle.com> References: <4D65FA25.8000302@oracle.com> Message-ID: <4D663100.10109@oracle.com> Stuart Marks wrote: > Hi Sherman, all, > > Here's a webrev to convert code in the jar/zip implementation files > and tests to use the new Java 7 try-with-resources construct. > > http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.0/ I looked through the src/** changes (I don't have time to go through the test changes just now). All looks okay to me except for src/share/classes/com/sun/java/util/jar/pack/PropMap.java. At L129 it uses getResourceAsStream and that will return null if the properties file doesn't exist causing props.load to throw NPE. I realize the original code will NPE too but maybe this should be fixed while you are in the area. Also in this code it's not clear to me that propsLoaded is needed. I realize you're keeping existing behavior but it means that we get NPE if the properties file doesn't exist, throw RuntimeException if there is a problem reading it, and do nothing if close fails. I can't think of a case where close could fail here and maybe it would be better to just handle it in the same way as an error reading the properties. -Alan. From chris.hegarty at oracle.com Thu Feb 24 12:58:36 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 24 Feb 2011 12:58:36 +0000 Subject: hg: jdk7/tl/jdk: 7020136: java/net/URLConnection/RedirectLimit.java fails intermittently Message-ID: <20110224125845.F3A9247A07@hg.openjdk.java.net> Changeset: c2c8f9c38fd1 Author: chegar Date: 2011-02-24 12:57 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c2c8f9c38fd1 7020136: java/net/URLConnection/RedirectLimit.java fails intermittently Summary: Increase the socket timeout and clean up the test Reviewed-by: alanb ! test/java/net/URLConnection/RedirectLimit.java From chris.hegarty at oracle.com Thu Feb 24 13:42:50 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 24 Feb 2011 13:42:50 +0000 Subject: hg: jdk7/tl/jdk: 6849693: index of fdTable should be less than num. of fdTable in jdk7 Message-ID: <20110224134259.E77FD47A0C@hg.openjdk.java.net> Changeset: 1f41e41ef2db Author: chegar Date: 2011-02-24 13:42 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/1f41e41ef2db 6849693: index of fdTable should be less than num. of fdTable in jdk7 Reviewed-by: alanb ! src/solaris/native/java/net/linux_close.c From edharned at gmail.com Thu Feb 24 14:14:35 2011 From: edharned at gmail.com (Edward Harned) Date: Thu, 24 Feb 2011 09:14:35 -0500 Subject: FW: [concurrency-interest] ForkJoin Improvements In-Reply-To: References: Message-ID: David Holmes and others keep pushing the Fork-Join framework for inclusion in JDK7 while this framework is an utter calamity. http://www.coopsoft.com/ar/CalamityArticle.html The latest framework update makes it even more complex without addressing the fatal flaws (archaic work-stealing algorithms, faulty task management, lack of scalability and others). This is further proof that the architect is totally alienated from understanding the needs of application developers. I love Doug Lea. He has done wonders for the advancement of concurrent programming in Java. His concurrent utilities have made code better and programming easier. However, he is a professor with absolutely no commercial application development experience (malloc is a systems program.) This is why his framework is so lacking in industry professional attributes. Doug Lea has been tinkering with these same classes for the past eleven years. The framework is based on papers written in the 1990?s for techniques popular before then. In those eleven years, many more advanced, superior Fork-Join frameworks have emerged: [yes, I maintain three of them] http://coopsoft.com/JavaProduct.html http://supertech.csail.mit.edu/jCilkImp.html It is not too late to address the issue. Notwithstanding the deference the committee has given to the architect for his enormous contribution to Java, it is not worth the harm to core Java to including this framework in JDK7. Deference granted for including Classes that had absolutely nothing to do with concurrency into the original concurrency package (Executor, Future, etc.) The Fork-Join Classes also have nothing to do with concurrency. In fact, the architect specifically warns users not to use any concurrency methods as this may break the framework. Deferred to JDK8 are 486 extra classes and interfaces, having nothing whatsoever to do with concurrency, the architect wants to add to core Java to support the framework. The time to stop this is now. Ed Harned On Mon, Feb 21, 2011 at 8:44 PM, David Holmes wrote: > FYI > > David Holmes > > -----Original Message----- > From: concurrency-interest-bounces at cs.oswego.edu > [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Doug Lea > Sent: Tuesday, 22 February 2011 11:21 AM > To: Concurrency-interest at cs.oswego.edu > Subject: [concurrency-interest] ForkJoin Improvements > > Another round of improvements to ForkJoin framework is > now available in the usual places (see below). The main > change is an overhaul to core control that better avoids > creating or restarting more threads than needed. You'll > probably see better overall performance too. > Also, exceptions stemming from user errors are now > more informative. > > Please try these out let us know about any problems. > Pasting from http://gee.cs.oswego.edu/dl/concurrency-interest/index.html > > > jsr166y versions > * API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/ > * jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166y.jar > (compiled > using Java6 javac). > * Browsable CVS sources: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166y/ > > java7 java.util.concurrent versions > * API specs: http://gee.cs.oswego.edu/dl/jsr166/dist/docs/ > * jar file: http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166.jar > * Browsable CVS sources: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/main/java/util/ > * Browsable CVS TCK test sources: > http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/tests/tck/ > > You may be able to use these versions now, without waiting for JDK > releases, > by > obtaining jsr166 jar and running java using the option > -Xbootclasspath/p:jsr166.jar (You may need to precede "jsr166.jar" with its > full > file path.) > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest at cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest > > From pcj at roundroom.net Thu Feb 24 15:07:58 2011 From: pcj at roundroom.net (Peter Jones) Date: Thu, 24 Feb 2011 10:07:58 -0500 Subject: Review CR #6611830: UUID thread-safety and performance improvements In-Reply-To: References: Message-ID: This change seems good all around. In addition to fixing the noted race, it removes a substantial amount of redundant instance footprint from a class whose instances are not infrequently collected in significant numbers-- fields most of which just served methods that are essentially never used in critical code anyway. Of course hashCode is used, but it's not computationally like String.hashCode. Agree with Alan that the code for variant() requires an extra stare to make sense of, so more comment might be helpful-- otherwise looks good to me. -- Peter On Tue, Feb 22, 2011 at 7:29 PM, Mike Duigou wrote: > Daniel Aioanei reported via Josh Bloch a data race issue with the UUID accessor and hashCode() methods. I've prepared a webrev with the suggested changes: > > http://cr.openjdk.java.net/~mduigou/6611830/webrev.0/webrev/ > > I've tested the change against the standard UUID tests and did a microbenchmark test of one method, variant(), to see what impact not caching had on performance. Since there was only negligible change in performance vs. the existing UUID implementation I am comfortable with eliminating the cache values. It would appear that a field access plus a shift is not a significant cost over a field access. > > Mike From jim.holmlund at sun.com Thu Feb 24 16:42:09 2011 From: jim.holmlund at sun.com (jim.holmlund at sun.com) Date: Thu, 24 Feb 2011 16:42:09 +0000 Subject: hg: jdk7/tl/langtools: 7018753: tools/javac/varargs/warning/Warn5.java times out on slow machines Message-ID: <20110224164211.D273747A13@hg.openjdk.java.net> Changeset: 3e30c95da3c6 Author: jjh Date: 2011-02-24 08:40 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/3e30c95da3c6 7018753: tools/javac/varargs/warning/Warn5.java times out on slow machines Summary: Use a single file manager for all JavacTasks Reviewed-by: jjg, mcimadamore ! test/tools/javac/varargs/6199075/T6199075.java ! test/tools/javac/varargs/warning/Warn4.java ! test/tools/javac/varargs/warning/Warn5.java From mandy.chung at oracle.com Thu Feb 24 18:30:16 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 24 Feb 2011 10:30:16 -0800 Subject: Review request for 7016707 "Remove the BootClassLoaderHook for jkernel support" Message-ID: <4D66A3B8.1000406@oracle.com> 7016707: Remove the BootClassLoaderHook for jkernel support Webrev at: http://cr.openjdk.java.net/~mchung/7016707/webrev.00/ The sun.jkernel.* classes have been removed from JDK 7: http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/e4802c87e5c7 This fix is to remove sun.misc.BootClassLoaderHook that was added to remove classloader dependency on jkernel: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c499401bc138 Thanks Mandy From michael.x.mcmahon at oracle.com Thu Feb 24 18:36:29 2011 From: michael.x.mcmahon at oracle.com (michael.x.mcmahon at oracle.com) Date: Thu, 24 Feb 2011 18:36:29 +0000 Subject: hg: jdk7/tl/jdk: 6835668: Use of /usr/include/linux/ files creates a dependence on kernel-headers Message-ID: <20110224183639.B1D7847A18@hg.openjdk.java.net> Changeset: 51ef29aafc1b Author: michaelm Date: 2011-02-24 18:35 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/51ef29aafc1b 6835668: Use of /usr/include/linux/ files creates a dependence on kernel-headers Reviewed-by: chegar ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/PlainDatagramSocketImpl.c ! src/solaris/native/java/net/PlainSocketImpl.c From kelly.ohair at oracle.com Thu Feb 24 19:41:05 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 24 Feb 2011 11:41:05 -0800 Subject: Review request for 7016707 "Remove the BootClassLoaderHook for jkernel support" In-Reply-To: <4D66A3B8.1000406@oracle.com> References: <4D66A3B8.1000406@oracle.com> Message-ID: <359024C2-613E-4941-8F9A-5BA77D8D6492@oracle.com> Makefile change is fine. Sorry I wasn't able to look at the code changes. -kto On Feb 24, 2011, at 10:30 AM, Mandy Chung wrote: > 7016707: Remove the BootClassLoaderHook for jkernel support > > Webrev at: > http://cr.openjdk.java.net/~mchung/7016707/webrev.00/ > > The sun.jkernel.* classes have been removed from JDK 7: > http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/e4802c87e5c7 > > This fix is to remove sun.misc.BootClassLoaderHook that was added to > remove classloader dependency on jkernel: > http://hg.openjdk.java.net/jdk7/tl/jdk/rev/c499401bc138 > > Thanks > Mandy From Alan.Bateman at oracle.com Thu Feb 24 20:26:58 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Feb 2011 20:26:58 +0000 Subject: Review request for 7016707 "Remove the BootClassLoaderHook for jkernel support" In-Reply-To: <4D66A3B8.1000406@oracle.com> References: <4D66A3B8.1000406@oracle.com> Message-ID: <4D66BF12.4050403@oracle.com> Mandy Chung wrote: > 7016707: Remove the BootClassLoaderHook for jkernel support > > Webrev at: > http://cr.openjdk.java.net/~mchung/7016707/webrev.00/ These changes looks fine to me. -Alan. From stuart.marks at oracle.com Thu Feb 24 22:19:55 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 24 Feb 2011 14:19:55 -0800 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D6604B2.6070104@oracle.com> References: <4D65FA25.8000302@oracle.com> <4D6604B2.6070104@oracle.com> Message-ID: <4D66D98B.8020908@oracle.com> On 2/23/11 11:11 PM, David Holmes wrote: > Hi Stuart, > > Just taking a look as a curious observer ... Good comments, thanks. > I'm somewhat dismayed by the lack of exception handling in the original code. Yes. As Josh observed in his initial "Automatic Resource Management" proposal [*] (precursor of try-with-resources), "2/3 of the uses of the close method in the JDK itself are wrong". I guess it's one thing to see this statement in some email, it's another to see actual examples littered around the code. I don't know if his statement is literally true, but I certainly believe that a large fraction of sites where code does something like opening a file do one of: a) failing to close the file at all; b) mishandling exceptions that occur during processing, for example by failing to close; or c) failing to handle exceptions from the close call. This webrev represents only a subset of what findbugs and Jackpot found. I'm sure there are many other examples still remaining, unfortunately. But, it's a start! [*] http://mail.openjdk.java.net/pipermail/coin-dev/2009-February/000011.html >> * src/share/classes/com/sun/java/util/jar/pack/Driver.java >> >> I narrowed the scope of the open resource. No sense keeping it open any >> longer than necessary. This occurs in several other places as well. > > You also changed from using a BufferedStream to just the FileInputStream - was > that intentional? Oh yes, I forgot to mention this. Properties.load() now does buffering internally, so it's unnecessary for callers to wrap their streams in a BufferedInputStream. I've seen this occur fairly frequently. >> * src/share/classes/com/sun/java/util/jar/pack/PropMap.java >> >> Narrowed the scope of catch IOException; should be OK since the code that was >> migrated out cannot throw IOException. > > So in this one: > > 128 boolean propsLoaded = false; > 129 try (InputStream propStr = > PackerImpl.class.getResourceAsStream(propFile)) { > 130 props.load(propStr); > 131 propsLoaded = true; > 132 } catch (IOException ee) { > 133 // ignore exception if it came from the close() > 134 if (!propsLoaded) { > 135 throw new RuntimeException(ee); > 136 } > 137 } > > The RuntimeException has a cause of ee, which in turn may have a suppressed > IOException from the close(). The intent of the original code was to convert any IOException thrown by opening or processing the stream into a RuntimeException, with the IOException as the cause. The intent was also simply to ignore an IOException from the close() if it occurred after successful processing. I've tried to preserve this intent. What you said above would occur if IOExceptions occur both in opening/processing and in the close(). This is somewhat odd but probably OK if we wanted to keep things this way. But Alan pointed out in his comments that it's probably not worth special-casing the treatment of close() here, so I'll pull out the propsLoaded logic. He also suggested handling a null return from getResourceAsStream(). So I'll end up reworking this code anyway. > test/java/util/zip/Available.java > > Don't you need to unroll the constructors here too: > > 47 try (ZipInputStream z = new ZipInputStream(new > FileInputStream(f))) { > 48 z.getNextEntry(); > 49 tryAvail(z); > 50 } Missed this one, thanks. This case was an automatically generated change from Jackpot but in most cases I've had to go back in and tinker with stuff manually. > test/java/util/zip/GZIP/GZIPInputStreamRead.java > > Unroll here too: > > 78 try (GZIPInputStream gzis = new GZIPInputStream( > 79 new ByteArrayInputStream(dst), > 80 gzisBufSize)) > 81 { Same thing here, maybe, or perhaps I was lazy :-) and decided that unrolling didn't need to be done because there's no point in ensuring that a ByteArrayInputStream is closed (its close method is defined to be a no-op). I'm reconsidering this, though. It may be confusing to "unroll" the resources in some cases but not in others. Also, sometimes it's hard to tell whether it's safe to leave the resources rolled up in a cascade of constructors. Does try-with-resources actually provide any value at all if the underlying stream is a byte array instead of an external resource like a file or a socket? Or, do you really need to make sure that, say, a BufferedReader is closed as long as its underlying FileReader is closed? I'm on the fence on this one. It may be that it's easier just to unroll every time instead of going through the is-it-safe analysis all the time. s'marks > > > Cheers, > David > --------- > >> >> * src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java >> >> This closes its input after successful processing. I changed this so that it >> also closes its input if an exception is thrown. >> >> * test/java/util/zip/LargeZip.java >> >> I've "unrolled" a cascade of constructors into separate resource variables. >> This also occurs in several other places. Basically code that used to look >> like this: >> >> ZipOutputStream zos = new ZipOutputStream( >> new BufferedOutputStream( >> new FileOutputStream(largeFile))); >> // process zos >> zos.close(); >> >> is converted to this: >> >> try (FileOutputStream fos = new FileOutputStream(largeFile); >> BufferedOutputStream bos = new BufferedOutputStream(fos); >> ZipOutputStream zos = new ZipOutputStream(bos)) >> { >> // process zos >> } >> >> I think this more robust, since it closes the FileOutputStream if an >> exception occurs during the construction of one of the stacked streams, which >> the original code did not handle. Since the wrapper streams will close their >> underlying streams, this will result in redundant close() calls. However, >> close() is supposed to be idempotent so this should be OK. >> >> * test/java/util/zip/ZipFile/DeleteTempJar.java >> >> I'm not sure if this properly handles an IOException caused by >> HttpExchange.close(). Funny, the method isn't declared to throw IOE, but this >> test did compile and pass. >> >> * test/java/util/zip/ZipFile/LargeZipFile.java >> >> I changed this to fail the test if close() were to throw IOE. I think this is >> proper for test code. >> >> * test/java/util/zip/ZipFile/ReadZip.java >> >> I took the liberty of converting the file copying code to use the new >> java.nio.file.Files utilities. Well, I'm really following Alan's lead here >> since he's prompted me to do so in other places a couple times already. :-) >> >> Thanks for reviewing! >> >> s'marks From stuart.marks at oracle.com Thu Feb 24 22:34:34 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 24 Feb 2011 14:34:34 -0800 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D6618A0.7060801@oracle.com> References: <4D65FA25.8000302@oracle.com> <4D6618A0.7060801@oracle.com> Message-ID: <4D66DCFA.5090406@oracle.com> On 2/24/11 12:36 AM, Xueming Shen wrote: > Stuart, > > Here are my comments on non-pack changes. I'm sure Kumar will look at those > pack files later. > > GetMethodsReturnClones.java: ln#43 diamond conersion? Oh yes, I could do that. How could I have forgotten about diamond? :-) > Available.java: it's not your change, but I believe we should do the > try-with_resources on the ZipFile zfile as well. Good catch. There are a couple uses of ZipFile in this file that aren't protected by TWR. > InfoZip.java.: ln#113/114 you probably don't need to separate out the "fis" in > try-with-resources, the FileInputStream > created should be closed by the ZipInputStream that it is embedded in. > > LargeZip.java: ln#101-1-4/148-151, same as above, only need to close > ZipOut/InputStream > > TestEmptyZip.java: > TestEmptyZip.java: > Comment.java: ln#60-62 > CorruptedZipFiles.java ln#50 > DeleteTempJar.java: > LargeZipFile.java. > ManyEntries.java > ReadZip.java. > ShortRead.java > only close the ZipIn/OutputStream David answered this already (and I think we chatted briefly about this on the phone call this morning too) and I think we agree that it's safer to "unroll" the resources into separate variables to make sure they all get closed if there's an exception during construction of one of the wrapper resources. Thanks! s'marks > > -Sherman > > On 2011-2-23 22:26, Stuart Marks wrote: >> Hi Sherman, all, >> >> Here's a webrev to convert code in the jar/zip implementation files and tests >> to use the new Java 7 try-with-resources construct. >> >> http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.0/ >> >> There are rather a lot of files, however, most of the changes are pretty >> straightforward. A typical conversion changes code like this: >> >> FileInputStream fis = new FileInputStream(filename); >> // use fis >> fis.close(); >> >> to this: >> >> try (FileInputStream fis = new FileInputStream(filename)) { >> // use fis >> } >> >> The majority of the conversions are like the above. However, there are a >> several places where I had to rearrange things either in order to get them to >> work at all, to improve robustness, or for general cleanup. >> >> Some of these are marked with "TODO". I will of course remove these comments >> before committing the changes. Where you see these comments, you might want >> to give the code a bit more scrutiny. >> >> Specific examples of things to look at follow: >> >> * test/java/util/jar/JarEntry/GetMethodsReturnClones.java >> >> I had to change the ordering of local variable declarations so that the >> variable was visible where it's used. TWR introduces a nested block, so >> obviously a local declared within will have to be moved outside in order to >> be used outside. This occurs in several other places as well. In some cases >> initialization order was changed. This shouldn't matter, though, since it's >> things like opening a file vs. allocating an array. >> >> * src/share/classes/com/sun/java/util/jar/pack/Driver.java >> >> I narrowed the scope of the open resource. No sense keeping it open any >> longer than necessary. This occurs in several other places as well. >> >> * src/share/classes/com/sun/java/util/jar/pack/PackageReader.java >> * src/share/classes/com/sun/java/util/jar/pack/PackageWriter.java >> >> These changes rely on recent changes to TWR's handling of null resources. >> Currently, TWR will avoid calling close if the resource is null. Joe checked >> in this change just last week. Before that, a null resource would generate an >> unavoidable NPE when it attempted to call close(). Handling of non-null >> resources is unchanged. >> >> I don't think the change to null handling is in a promoted build yet. Is it >> OK to check in code that depends on it? All tests pass, but that just means >> that the path where the resource is null isn't tested. >> >> * src/share/classes/com/sun/java/util/jar/pack/PropMap.java >> >> Narrowed the scope of catch IOException; should be OK since the code that was >> migrated out cannot throw IOException. >> >> * src/share/classes/com/sun/java/util/jar/pack/UnpackerImpl.java >> >> This closes its input after successful processing. I changed this so that it >> also closes its input if an exception is thrown. >> >> * test/java/util/zip/LargeZip.java >> >> I've "unrolled" a cascade of constructors into separate resource variables. >> This also occurs in several other places. Basically code that used to look >> like this: >> >> ZipOutputStream zos = new ZipOutputStream( >> new BufferedOutputStream( >> new FileOutputStream(largeFile))); >> // process zos >> zos.close(); >> >> is converted to this: >> >> try (FileOutputStream fos = new FileOutputStream(largeFile); >> BufferedOutputStream bos = new BufferedOutputStream(fos); >> ZipOutputStream zos = new ZipOutputStream(bos)) >> { >> // process zos >> } >> >> I think this more robust, since it closes the FileOutputStream if an >> exception occurs during the construction of one of the stacked streams, which >> the original code did not handle. Since the wrapper streams will close their >> underlying streams, this will result in redundant close() calls. However, >> close() is supposed to be idempotent so this should be OK. >> >> * test/java/util/zip/ZipFile/DeleteTempJar.java >> >> I'm not sure if this properly handles an IOException caused by >> HttpExchange.close(). Funny, the method isn't declared to throw IOE, but this >> test did compile and pass. >> >> * test/java/util/zip/ZipFile/LargeZipFile.java >> >> I changed this to fail the test if close() were to throw IOE. I think this is >> proper for test code. >> >> * test/java/util/zip/ZipFile/ReadZip.java >> >> I took the liberty of converting the file copying code to use the new >> java.nio.file.Files utilities. Well, I'm really following Alan's lead here >> since he's prompted me to do so in other places a couple times already. :-) >> >> Thanks for reviewing! >> >> s'marks > From lnarasimhan at in.ibm.com Thu Feb 24 22:33:41 2011 From: lnarasimhan at in.ibm.com (Lakshmi Narasimhan) Date: Fri, 25 Feb 2011 04:03:41 +0530 Subject: AUTO: I'm off on 25th Feb 2011 (returning 28/02/2011) Message-ID: I am out of the office until 28/02/2011. Please contact Anshu Verma (ansverma at in.ibm.com) for any CL issues. Note: This is an automated response to your message "core-libs-dev Digest, Vol 46, Issue 39" sent on 25/2/11 0:00:46. This is the only notification you will receive while this person is away. From stuart.marks at oracle.com Thu Feb 24 23:20:50 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 24 Feb 2011 15:20:50 -0800 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D663100.10109@oracle.com> References: <4D65FA25.8000302@oracle.com> <4D663100.10109@oracle.com> Message-ID: <4D66E7D2.1010605@oracle.com> On 2/24/11 2:20 AM, Alan Bateman wrote: > All looks okay to me except for > src/share/classes/com/sun/java/util/jar/pack/PropMap.java. > > At L129 it uses getResourceAsStream and that will return null if the properties > file doesn't exist causing props.load to throw NPE. I realize the original code > will NPE too but maybe this should be fixed while you are in the area. Now that I'm looking at this more closely, what should happen if the properties file doesn't exist? This is in a static initializer and it's attempting to load "intrinsic.properties" which should always be present -- if it's not present, the system was constructed improperly. So, if intrinsic.properties isn't found, what should happen? Ignore this (seems like a bad idea); issue warning message (how?); throw something like FileNotFoundException? Well, static initializers can't throw checked exceptions, so maybe throw a RuntimeException with a suitable message? Advice appreciated. s'marks From stuart.marks at oracle.com Thu Feb 24 23:35:21 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 24 Feb 2011 15:35:21 -0800 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D663100.10109@oracle.com> References: <4D65FA25.8000302@oracle.com> <4D663100.10109@oracle.com> Message-ID: <4D66EB39.9080703@oracle.com> [this is a resend of an earlier message, which apparently didn't go through] On 2/24/11 2:20 AM, Alan Bateman wrote: > Stuart Marks wrote: >> Hi Sherman, all, >> >> Here's a webrev to convert code in the jar/zip implementation files and tests >> to use the new Java 7 try-with-resources construct. >> >> http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.0/ > I looked through the src/** changes (I don't have time to go through the test > changes just now). Thanks, this is helpful. > All looks okay to me except for > src/share/classes/com/sun/java/util/jar/pack/PropMap.java. > > At L129 it uses getResourceAsStream and that will return null if the properties > file doesn't exist causing props.load to throw NPE. I realize the original code > will NPE too but maybe this should be fixed while you are in the area. Good point. I'm definitely of the mindset of cleaning up stuff in the same area, even unrelated to TWR, if it's reasonably straightforward to do so. > Also in this code it's not clear to me that propsLoaded is needed. I realize > you're keeping existing behavior but it means that we get NPE if the properties > file doesn't exist, throw RuntimeException if there is a problem reading it, > and do nothing if close fails. I can't think of a case where close could fail > here and maybe it would be better to just handle it in the same way as an error > reading the properties. Yeah, the existing behavior seemed dubious and I didn't like that I had to invent a boolean to preserve that behavior. If you think it's OK to change the behavior here to handle (instead of ignore) an IOException thrown by close() then I'm all for it. In general whereas it's clear that a failure in close() after writing needs to be handled, I'm less clear on whether a failure in close() for something that's read-only ought to be handled -- or even what such a failure means. If it "never" happens then it's probably not worth special-casing it to make it a no-op. Also, if there is an exception thrown from close() even on something that's read-only, maybe the system is trying to tell us something ("You know those bytes you just read? Well, they were wrong.") so we ought to handle the exception instead of ignoring it. It's hard to imagine this happening, but just because it's hard to imagine doesn't mean that it won't happen. OK, I think I've convinced myself that one should never ignore an exception from close() even on something read-only. With TWR there's no point in doing so. You already have a try-block that does the processing; it implicitly includes the close() now. It either has a catch of IOException, or there is a "throws IOException" on the enclosing method. So IOException should already be handled properly, so there's nothing to be gained by special-casing IOException from close(). s'marks From kumar.x.srinivasan at oracle.com Fri Feb 25 01:17:26 2011 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 24 Feb 2011 17:17:26 -0800 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D66E7D2.1010605@oracle.com> References: <4D65FA25.8000302@oracle.com> <4D663100.10109@oracle.com> <4D66E7D2.1010605@oracle.com> Message-ID: <4D670326.8080507@oracle.COM> All the changes look good, the regression test jdk/test/tools/pack200 and jdk/test/tools/jar must be run, as jprt does not run these by default, also suggest a full control build using jdk, deploy and install. >> All looks okay to me except for >> src/share/classes/com/sun/java/util/jar/pack/PropMap.java. >> >> At L129 it uses getResourceAsStream and that will return null if the >> properties >> file doesn't exist causing props.load to throw NPE. I realize the >> original code >> will NPE too but maybe this should be fixed while you are in the area. > > Now that I'm looking at this more closely, what should happen if the > properties file doesn't exist? This is in a static initializer and > it's attempting to load "intrinsic.properties" which should always be > present -- if it's not present, the system was constructed improperly. Yes intrinsic.properties *must* be present in the system, I think we added the logic to fail in the early development days to ensure this is always present, and is specifically needed for jcov builds required by SQE. > > So, if intrinsic.properties isn't found, what should happen? Ignore > this (seems like a bad idea); issue warning message (how?); throw > something like FileNotFoundException? Well, static initializers can't > throw checked exceptions, so maybe throw a RuntimeException with a > suitable message? RE will be fine here, as you have already detected this condition should never happen unless there was a build issue. Thanks Kumar > > Advice appreciated. > > s'marks From valerie.peng at oracle.com Fri Feb 25 01:36:26 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Thu, 24 Feb 2011 17:36:26 -0800 Subject: Code Review for 7001933: Deadlock in java.lang.classloader.getPackage() Message-ID: <4D67079A.3050109@oracle.com> Hi, Can someone please review for 7001933: Deadlock in java.lang.classloader.getPackage()? http://cr.openjdk.java.net/~valeriep/7001933/webrev.00/ The fixes are straightforward - release the lock when delegating to the parent. The change has been verified by the submitter. Thanks, Valerie From David.Holmes at oracle.com Fri Feb 25 01:50:11 2011 From: David.Holmes at oracle.com (David Holmes) Date: Fri, 25 Feb 2011 11:50:11 +1000 Subject: Code Review for 7001933: Deadlock in java.lang.classloader.getPackage() In-Reply-To: <4D67079A.3050109@oracle.com> References: <4D67079A.3050109@oracle.com> Message-ID: <4D670AD3.8080908@oracle.com> HI Valerie, Valerie (Yu-Ching) Peng said the following on 02/25/11 11:36: > Can someone please review for 7001933: Deadlock in > java.lang.classloader.getPackage()? > > http://cr.openjdk.java.net/~valeriep/7001933/webrev.00/ > > The fixes are straightforward - release the lock when delegating to the > parent. > The change has been verified by the submitter. 1642 synchronized (packages) { 1643 if (packages.get(name) != null) { 1644 packages.put(name, pkg); 1645 } 1646 } This looks wrong to me. Shouldn't you only do the put if the get returns null? And if the get doesn't return null shouldn't the method return that result ie: synchronized (packages) { Package pkg2 = null; if ((pkg2 = packages.get(name)) == null) { packages.put(name, pkg); } else pkg = pkg2; } ... return pkg; In general it is easy to break a deadlock by making an open-call, as you have done, but the harder question to answer is: what possible side-effects could there be due to races now that this method is not atomic? Cheers, David From stuart.marks at oracle.com Fri Feb 25 04:32:43 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 24 Feb 2011 20:32:43 -0800 Subject: review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D670326.8080507@oracle.COM> References: <4D65FA25.8000302@oracle.com> <4D663100.10109@oracle.com> <4D66E7D2.1010605@oracle.com> <4D670326.8080507@oracle.COM> Message-ID: <4D6730EB.2010401@oracle.com> On 2/24/11 5:17 PM, Kumar Srinivasan wrote: > All the changes look good, the regression test > jdk/test/tools/pack200 and jdk/test/tools/jar > must be run, as jprt does not run these by default, > also suggest a full control build using jdk, deploy and install. Thanks for looking at the changes. What I'll do is separate out the pack200 changes and file a bug and create a separate webrev for them. That way I can push the other changes while we do the additional testing for pack200. >> So, if intrinsic.properties isn't found, what should happen? Ignore this >> (seems like a bad idea); issue warning message (how?); throw something like >> FileNotFoundException? Well, static initializers can't throw checked >> exceptions, so maybe throw a RuntimeException with a suitable message? > > RE will be fine here, as you have already detected this condition should never > happen > unless there was a build issue. OK, I'll have it throw a RuntimeException with a suitable message. Thanks. I'll let you know how the testing goes. s'marks > > Thanks > Kumar > >> >> Advice appreciated. >> >> s'marks > From stuart.marks at oracle.com Fri Feb 25 07:49:51 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 24 Feb 2011 23:49:51 -0800 Subject: updated review request for 7021582, use try-with-resources in jar/zip implementation and tests Message-ID: <4D675F1F.1030207@oracle.com> Hi all, updated webrev is here: http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.1/ I've removed the pack200 files (i.e. those in src/share/classes/com/sun/java/util/jar/pack) so I can do more thorough deploy/install testing per Kumar's request. The change to PropMap.java, which generated a fair bit of discussion, is actually in the pack200 library so it's no longer part of this webrev. Otherwise there are only a couple changes which shouldn't come as a surprise to anyone: test/java/util/jar/JarEntry/GetMethodsReturnClones.java - use diamond test/java/util/zip/Available.java test/java/util/zip/GZIP/GZIPInputStreamRead.java - unrolled constructors test/java/util/zip/Available.java - add use of TWR for a couple ZipFile instances Thanks, s'marks From stuart.marks at oracle.com Fri Feb 25 08:04:31 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 25 Feb 2011 08:04:31 +0000 Subject: hg: jdk7/tl/jdk: 7022383: add reference to CR for ReadLongZipFileName test to problem list Message-ID: <20110225080442.3FD3E47A43@hg.openjdk.java.net> Changeset: b74f1b830484 Author: smarks Date: 2011-02-24 22:26 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/b74f1b830484 7022383: add reference to CR for ReadLongZipFileName test to problem list Reviewed-by: ohair ! test/ProblemList.txt From Alan.Bateman at oracle.com Fri Feb 25 10:20:16 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Feb 2011 10:20:16 +0000 Subject: updated review request for 7021582, use try-with-resources in jar/zip implementation and tests In-Reply-To: <4D675F1F.1030207@oracle.com> References: <4D675F1F.1030207@oracle.com> Message-ID: <4D678260.2060402@oracle.com> Stuart Marks wrote: > Hi all, updated webrev is here: > > http://cr.openjdk.java.net/~smarks/reviews/7021582/webrev.1/ > > I've removed the pack200 files (i.e. those in > src/share/classes/com/sun/java/util/jar/pack) so I can do more > thorough deploy/install testing per Kumar's request. The change to > PropMap.java, which generated a fair bit of discussion, is actually in > the pack200 library so it's no longer part of this webrev. These changes look good to me. -Alan. From rama.pulavarthi at oracle.com Fri Feb 25 18:12:27 2011 From: rama.pulavarthi at oracle.com (Rama Pulavarthi) Date: Fri, 25 Feb 2011 10:12:27 -0800 Subject: Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security In-Reply-To: <4D654E60.9070106@oracle.com> References: <4D64558A.6040807@oracle.com> <4D64C8EF.2050101@oracle.com> <4D654E60.9070106@oracle.com> Message-ID: <4D67F10B.80506@oracle.com> Please review this updated webrev that has the patch for JDK 7 repo. http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws-7020513-open/webrev/ For background on this issue, this is not a new one. I am trying to port the old fixes made in jdk repo as part of earlier jax-ws integrations in to Open JDK 6. The original issue CR 6592792 was fixed in JDK 6u7 and then ported to Open JDK 6. When Open JDK 6 transitioned to Hg, it was committed as [1]. As fix for CR 6831313 :update jaxws in OpenJDK7 to 2.1 plus bug fixes from OpenJDK 6, Only the changes in jaxws sources are ported to JDK 7 [2]. But, there are other changes that are made in jdk repo required for this fix. [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/586feec8273d [2] http://hg.openjdk.java.net/jdk7/build/jaxws/rev/31822b475baa thanks, Rama Pulavarthi From mandy.chung at oracle.com Fri Feb 25 19:42:53 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 25 Feb 2011 19:42:53 +0000 Subject: hg: jdk7/tl/jdk: 7021939: com.oracle.net is not a NON_CORE_PKGS Message-ID: <20110225194303.02F9547A64@hg.openjdk.java.net> Changeset: 32dc1cb2b995 Author: mchung Date: 2011-02-25 11:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/32dc1cb2b995 7021939: com.oracle.net is not a NON_CORE_PKGS Reviewed-by: ohair, alanb ! make/common/Release.gmk ! make/docs/NON_CORE_PKGS.gmk From jonathan.gibbons at oracle.com Fri Feb 25 20:10:07 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 25 Feb 2011 20:10:07 +0000 Subject: hg: jdk7/tl/langtools: 7021650: fix Context issues Message-ID: <20110225201009.D3BB547A69@hg.openjdk.java.net> Changeset: 8f0dcb9499db Author: jjg Date: 2011-02-25 12:09 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/8f0dcb9499db 7021650: fix Context issues Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/apt/util/Bark.java ! src/share/classes/com/sun/tools/javac/api/JavacTool.java ! src/share/classes/com/sun/tools/javac/file/CacheFSInfo.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/util/Context.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java ! src/share/classes/com/sun/tools/javadoc/JavadocTodo.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! test/tools/javac/diags/ArgTypeCompilerFactory.java ! test/tools/javac/diags/Example.java + test/tools/javac/util/context/T7021650.java From mandy.chung at oracle.com Fri Feb 25 20:11:54 2011 From: mandy.chung at oracle.com (mandy.chung at oracle.com) Date: Fri, 25 Feb 2011 20:11:54 +0000 Subject: hg: jdk7/tl/jdk: 7016707: Remove the BootClassLoaderHook for jkernel support Message-ID: <20110225201203.C03BC47A6A@hg.openjdk.java.net> Changeset: 5dc98de2a35e Author: mchung Date: 2011-02-25 12:11 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/5dc98de2a35e 7016707: Remove the BootClassLoaderHook for jkernel support Reviewed-by: alanb, ohair ! make/java/java/FILES_java.gmk ! src/share/classes/java/awt/color/ICC_Profile.java ! src/share/classes/java/lang/ClassLoader.java ! src/share/classes/java/util/zip/ZipEntry.java - src/share/classes/sun/misc/BootClassLoaderHook.java ! src/share/classes/sun/misc/Launcher.java - test/sun/misc/BootClassLoaderHook/TestHook.java From pbenedict at apache.org Fri Feb 25 20:15:58 2011 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 25 Feb 2011 14:15:58 -0600 Subject: How to find IBM's contributions? Message-ID: To the community, Is there any easily identifiable way to determine when IBM contributes fixes/patches to the repositories? I know all Oracle employees have Oracle email addresses. What about those from IBM? I was hoping to see what they contribute since they joined OpenJDK. Thanks! Paul From jonathan.gibbons at oracle.com Fri Feb 25 20:20:28 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 25 Feb 2011 20:20:28 +0000 Subject: hg: jdk7/tl/langtools: 7022310: test/tools/javac/diags/Example: args added twice Message-ID: <20110225202030.6DCEE47A6C@hg.openjdk.java.net> Changeset: 23b64ad3eec8 Author: jjg Date: 2011-02-25 12:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/23b64ad3eec8 7022310: test/tools/javac/diags/Example: args added twice Reviewed-by: mcimadamore ! test/tools/javac/diags/Example.java From sean.mullan at oracle.com Fri Feb 25 20:21:37 2011 From: sean.mullan at oracle.com (Sean Mullan) Date: Fri, 25 Feb 2011 15:21:37 -0500 Subject: Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security In-Reply-To: <4D67F10B.80506@oracle.com> References: <4D64558A.6040807@oracle.com> <4D64C8EF.2050101@oracle.com> <4D654E60.9070106@oracle.com> <4D67F10B.80506@oracle.com> Message-ID: <4D680F51.3050906@oracle.com> Looks good to me. --Sean On 2/25/11 1:12 PM, Rama Pulavarthi wrote: > Please review this updated webrev that has the patch for JDK 7 repo. > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws-7020513-open/webrev/ > > For background on this issue, this is not a new one. I am trying to port > the old fixes made in jdk repo as part of earlier jax-ws integrations in > to Open JDK 6. > The original issue CR 6592792 was fixed in JDK 6u7 and then ported to > Open JDK 6. When Open JDK 6 transitioned to Hg, it was committed as > [1]. As fix for CR 6831313 > :update jaxws in > OpenJDK7 to 2.1 plus bug fixes from OpenJDK 6, Only the changes in jaxws > sources are ported to JDK 7 [2]. But, there are other changes that are > made in jdk repo required for this fix. > > [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/586feec8273d > > [2] http://hg.openjdk.java.net/jdk7/build/jaxws/rev/31822b475baa > > > > thanks, > Rama Pulavarthi From gnu_andrew at member.fsf.org Fri Feb 25 20:48:22 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Fri, 25 Feb 2011 20:48:22 +0000 Subject: How to find IBM's contributions? In-Reply-To: References: Message-ID: On 25 February 2011 20:15, Paul Benedict wrote: > To the community, > > Is there any easily identifiable way to determine when IBM contributes > fixes/patches to the repositories? I know all Oracle employees have Oracle > email addresses. What about those from IBM? I was hoping to see what they > contribute since they joined OpenJDK. > > Thanks! > Paul > Well I don't see IBM listed at all on http://db.openjdk.java.net/people so presumably none of them yet have commit access (though they are some with no affiliation). A quick check of the repositories for ibm.com e-mail addresses in the contributed line gives only: changeset: 3318:0ef137ae6f3b user: alanb date: Wed Dec 15 09:15:20 2010 +0000 files: src/share/demo/jvmti/heapTracker/heapTracker.c description: 6927816: Demo crash in heaptracker with Non-Sun JDK due to possible violation of JNI spec Reviewed-by: ohair, alanb Contributed-by: spoole at uk.ibm.com It was discussed on the serviceability list: http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003176.html I have noticed anything else going in. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From stuart.marks at oracle.com Fri Feb 25 21:36:34 2011 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Fri, 25 Feb 2011 21:36:34 +0000 Subject: hg: jdk7/tl/jdk: 7021582: convert jar/zip code and tests to use try-with-resources Message-ID: <20110225213644.78C1147A6F@hg.openjdk.java.net> Changeset: 8887cb2f5d19 Author: smarks Date: 2011-02-25 02:06 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/8887cb2f5d19 7021582: convert jar/zip code and tests to use try-with-resources Reviewed-by: alanb, dholmes, sherman ! src/share/classes/java/util/jar/JarFile.java ! test/java/util/jar/JarEntry/GetMethodsReturnClones.java ! test/java/util/jar/JarFile/ScanSignedJar.java ! test/java/util/zip/Available.java ! test/java/util/zip/FileBuilder.java ! test/java/util/zip/GZIP/Accordion.java ! test/java/util/zip/GZIP/GZIPInputStreamRead.java ! test/java/util/zip/InflateIn_DeflateOut.java ! test/java/util/zip/InfoZip.java ! test/java/util/zip/LargeZip.java ! test/java/util/zip/TestEmptyZip.java ! test/java/util/zip/ZipCoding.java ! test/java/util/zip/ZipFile/Assortment.java ! test/java/util/zip/ZipFile/Comment.java ! test/java/util/zip/ZipFile/CopyJar.java ! test/java/util/zip/ZipFile/CorruptedZipFiles.java ! test/java/util/zip/ZipFile/DeleteTempJar.java ! test/java/util/zip/ZipFile/EnumAfterClose.java ! test/java/util/zip/ZipFile/GetDirEntry.java ! test/java/util/zip/ZipFile/LargeZipFile.java ! test/java/util/zip/ZipFile/ManyEntries.java ! test/java/util/zip/ZipFile/ManyZipFiles.java ! test/java/util/zip/ZipFile/ReadAfterClose.java ! test/java/util/zip/ZipFile/ReadZip.java ! test/java/util/zip/ZipFile/ShortRead.java ! test/java/util/zip/zip.java From mike.duigou at oracle.com Fri Feb 25 21:42:09 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 25 Feb 2011 22:42:09 +0100 Subject: How to find IBM's contributions? In-Reply-To: References: Message-ID: Two patches by Neil Richards have also gone in during the last week. There were some organizational logistic issues which resulted in a slow start but the pace can be expected to increase. Mike On Feb 25 2011, at 21:48 , Dr Andrew John Hughes wrote: > On 25 February 2011 20:15, Paul Benedict wrote: >> To the community, >> >> Is there any easily identifiable way to determine when IBM contributes >> fixes/patches to the repositories? I know all Oracle employees have Oracle >> email addresses. What about those from IBM? I was hoping to see what they >> contribute since they joined OpenJDK. >> >> Thanks! >> Paul >> > > Well I don't see IBM listed at all on > http://db.openjdk.java.net/people so presumably none of them yet have > commit access (though they are some with no affiliation). > > A quick check of the repositories for ibm.com e-mail addresses in the > contributed line gives only: > > changeset: 3318:0ef137ae6f3b > user: alanb > date: Wed Dec 15 09:15:20 2010 +0000 > files: src/share/demo/jvmti/heapTracker/heapTracker.c > description: > 6927816: Demo crash in heaptracker with Non-Sun JDK due to possible > violation of JNI spec > Reviewed-by: ohair, alanb > Contributed-by: spoole at uk.ibm.com > > It was discussed on the serviceability list: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003176.html > > I have noticed anything else going in. > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From pbenedict at apache.org Fri Feb 25 22:11:22 2011 From: pbenedict at apache.org (Paul Benedict) Date: Fri, 25 Feb 2011 16:11:22 -0600 Subject: How to find IBM's contributions? In-Reply-To: References: Message-ID: Mike, are the commits coming directly from an IBM address, or are they submitted as patches for Oracle employees to apply? On Fri, Feb 25, 2011 at 3:42 PM, Mike Duigou wrote: > Two patches by Neil Richards have also gone in during the last week. There > were some organizational logistic issues which resulted in a slow start but > the pace can be expected to increase. > > Mike > > On Feb 25 2011, at 21:48 , Dr Andrew John Hughes wrote: > > > On 25 February 2011 20:15, Paul Benedict wrote: > >> To the community, > >> > >> Is there any easily identifiable way to determine when IBM contributes > >> fixes/patches to the repositories? I know all Oracle employees have > Oracle > >> email addresses. What about those from IBM? I was hoping to see what > they > >> contribute since they joined OpenJDK. > >> > >> Thanks! > >> Paul > >> > > > > Well I don't see IBM listed at all on > > http://db.openjdk.java.net/people so presumably none of them yet have > > commit access (though they are some with no affiliation). > > > > A quick check of the repositories for ibm.com e-mail addresses in the > > contributed line gives only: > > > > changeset: 3318:0ef137ae6f3b > > user: alanb > > date: Wed Dec 15 09:15:20 2010 +0000 > > files: src/share/demo/jvmti/heapTracker/heapTracker.c > > description: > > 6927816: Demo crash in heaptracker with Non-Sun JDK due to possible > > violation of JNI spec > > Reviewed-by: ohair, alanb > > Contributed-by: spoole at uk.ibm.com > > > > It was discussed on the serviceability list: > > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003176.html > > > > I have noticed anything else going in. > > -- > > Andrew :-) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Support Free Java! > > Contribute to GNU Classpath and the OpenJDK > > http://www.gnu.org/software/classpath > > http://openjdk.java.net > > > > PGP Key: F5862A37 (https://keys.indymedia.org/) > > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 > > From mike.duigou at oracle.com Fri Feb 25 22:43:00 2011 From: mike.duigou at oracle.com (Mike Duigou) Date: Fri, 25 Feb 2011 23:43:00 +0100 Subject: How to find IBM's contributions? In-Reply-To: References: Message-ID: <0347E29E-D85B-44AB-A979-4CDFCABBA01B@oracle.com> I can only speak to the patches I've been involved with; currently the IBM employees post their webrevs for review to the public -dev lists and upon completion the webrevs are committed by an openJDK committer (who need not be an Oracle employee). IBM employees are expected to have their own openJDK committers in the near future. Essentially the process has been the same as for any community contributor upon first taking up with OpenJDK. The process is likely to be streamlined as IBM itself has more OpenJDK mentors within it's teams. This is true even within Oracle (and previously Sun), there's a mentoring and education process for new committers provided by established committers prior to full OpenJDK committer status. Mike On Feb 25 2011, at 23:11 , Paul Benedict wrote: > Mike, are the commits coming directly from an IBM address, or are they submitted as patches for Oracle employees to apply? > > On Fri, Feb 25, 2011 at 3:42 PM, Mike Duigou wrote: > Two patches by Neil Richards have also gone in during the last week. There were some organizational logistic issues which resulted in a slow start but the pace can be expected to increase. > > Mike > > On Feb 25 2011, at 21:48 , Dr Andrew John Hughes wrote: > > > On 25 February 2011 20:15, Paul Benedict wrote: > >> To the community, > >> > >> Is there any easily identifiable way to determine when IBM contributes > >> fixes/patches to the repositories? I know all Oracle employees have Oracle > >> email addresses. What about those from IBM? I was hoping to see what they > >> contribute since they joined OpenJDK. > >> > >> Thanks! > >> Paul > >> > > > > Well I don't see IBM listed at all on > > http://db.openjdk.java.net/people so presumably none of them yet have > > commit access (though they are some with no affiliation). > > > > A quick check of the repositories for ibm.com e-mail addresses in the > > contributed line gives only: > > > > changeset: 3318:0ef137ae6f3b > > user: alanb > > date: Wed Dec 15 09:15:20 2010 +0000 > > files: src/share/demo/jvmti/heapTracker/heapTracker.c > > description: > > 6927816: Demo crash in heaptracker with Non-Sun JDK due to possible > > violation of JNI spec > > Reviewed-by: ohair, alanb > > Contributed-by: spoole at uk.ibm.com > > > > It was discussed on the serviceability list: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2010-December/003176.html > > > > I have noticed anything else going in. > > -- > > Andrew :-) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Support Free Java! > > Contribute to GNU Classpath and the OpenJDK > > http://www.gnu.org/software/classpath > > http://openjdk.java.net > > > > PGP Key: F5862A37 (https://keys.indymedia.org/) > > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 > > From valerie.peng at oracle.com Sat Feb 26 00:36:30 2011 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Fri, 25 Feb 2011 16:36:30 -0800 Subject: Code Review for 7001933: Deadlock in java.lang.classloader.getPackage() In-Reply-To: <4D670AD3.8080908@oracle.com> References: <4D67079A.3050109@oracle.com> <4D670AD3.8080908@oracle.com> Message-ID: <4D684B0E.50407@oracle.com> David, Thanks for the comments. I've updated the webrev accordingly at: http://cr.openjdk.java.net/~valeriep/7001933/webrev.01/ In the case of a race condition, we'll just return the earlier defined package object, i.e. pkg2 in your code sample. Or, we could also get rid of this code block altogether, then there shouldn't be a race condition. However, this means that we'll call into the parent loader for the packages that they defined which implies some performance cost. For the time being, I'll hold this off for a little longer, so people have more time to give comments. Thanks, Valerie On 02/24/11 05:50 PM, David Holmes wrote: > HI Valerie, > > Valerie (Yu-Ching) Peng said the following on 02/25/11 11:36: >> Can someone please review for 7001933: Deadlock in >> java.lang.classloader.getPackage()? >> >> http://cr.openjdk.java.net/~valeriep/7001933/webrev.00/ >> >> The fixes are straightforward - release the lock when delegating to >> the parent. >> The change has been verified by the submitter. > > 1642 synchronized (packages) { > 1643 if (packages.get(name) != null) { > 1644 packages.put(name, pkg); > 1645 } > 1646 } > > This looks wrong to me. Shouldn't you only do the put if the get > returns null? And if the get doesn't return null shouldn't the method > return that result ie: > > synchronized (packages) { > Package pkg2 = null; > if ((pkg2 = packages.get(name)) == null) { > packages.put(name, pkg); > } > else > pkg = pkg2; > } > ... > return pkg; > > In general it is easy to break a deadlock by making an open-call, as > you have done, but the harder question to answer is: what possible > side-effects could there be due to races now that this method is not > atomic? > > Cheers, > David From Alan.Bateman at oracle.com Sat Feb 26 08:57:53 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 26 Feb 2011 08:57:53 +0000 Subject: Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security In-Reply-To: <4D67F10B.80506@oracle.com> References: <4D64558A.6040807@oracle.com> <4D64C8EF.2050101@oracle.com> <4D654E60.9070106@oracle.com> <4D67F10B.80506@oracle.com> Message-ID: <4D68C091.4080506@oracle.com> Rama Pulavarthi wrote: > Please review this updated webrev that has the patch for JDK 7 repo. > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws-7020513-open/webrev/ > Looks good to me too. -Alan. From Alan.Bateman at oracle.com Sat Feb 26 09:40:33 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 26 Feb 2011 09:40:33 +0000 Subject: Code Review for 7001933: Deadlock in java.lang.classloader.getPackage() In-Reply-To: <4D684B0E.50407@oracle.com> References: <4D67079A.3050109@oracle.com> <4D670AD3.8080908@oracle.com> <4D684B0E.50407@oracle.com> Message-ID: <4D68CA91.7040005@oracle.com> Valerie (Yu-Ching) Peng wrote: > David, > > Thanks for the comments. I've updated the webrev accordingly at: > http://cr.openjdk.java.net/~valeriep/7001933/webrev.01/ > > In the case of a race condition, we'll just return the earlier defined > package object, i.e. pkg2 in your code sample. > Or, we could also get rid of this code block altogether, then there > shouldn't be a race condition. However, this means that we'll call > into the parent loader for the packages that they defined which > implies some performance cost. > I think the updated changes are okay/harmless but it's not completely clear to me that the specific deadlock that this bug is about can actually happen in jdk7 (because AppClassLoader is parallel capable). It would be great to put in time to develop a test to demonstrate the original issue, even if can't be an automated regression test (I've no doubt that it would need to run many iterations to duplicate). I also think we should submit a bug to re-examine how java.net.URL behaves when java.protocol.handler.pkgs is set. Minimally I think it needs to be clearer on the initiating loaders used when attempting to load the protocol handler. In addition it's not clear to me that it should fallback to the system class loader for the "file" protocol handler as that is required early in the startup to define the system package. -Alan From chris.hegarty at oracle.com Mon Feb 28 11:04:55 2011 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 28 Feb 2011 11:04:55 +0000 Subject: hg: jdk7/tl/jdk: 7022269: clean up fscanf usage in Linux networking native code Message-ID: <20110228110523.0536647B06@hg.openjdk.java.net> Changeset: 29f25ba547fc Author: chegar Date: 2011-02-28 11:03 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/29f25ba547fc 7022269: clean up fscanf usage in Linux networking native code Reviewed-by: michaelm, alanb ! src/solaris/native/java/net/NetworkInterface.c ! src/solaris/native/java/net/net_util_md.c From david.holmes at oracle.com Mon Feb 28 11:41:46 2011 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Mon, 28 Feb 2011 11:41:46 +0000 Subject: hg: jdk7/tl/jdk: 7022386: gethostbyname_r needs a pointer aligned buffer passed to it Message-ID: <20110228114212.658C947B08@hg.openjdk.java.net> Changeset: a3b6c262195b Author: dholmes Date: 2011-02-28 06:40 -0500 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/a3b6c262195b 7022386: gethostbyname_r needs a pointer aligned buffer passed to it Summary: Change buffer type to ensure pointer-alignment Reviewed-by: alanb, chegar ! src/solaris/native/java/net/Inet4AddressImpl.c From maurizio.cimadamore at oracle.com Mon Feb 28 11:52:48 2011 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 28 Feb 2011 11:52:48 +0000 Subject: hg: jdk7/tl/langtools: 2 new changesets Message-ID: <20110228115253.E224347B09@hg.openjdk.java.net> Changeset: 9286a5d1fae3 Author: mcimadamore Date: 2011-02-28 11:48 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9286a5d1fae3 7015430: Incorrect thrown type determined for unchecked invocations Summary: Thrown types do not get updated after 15.12.2.8, and do not get erased as per 15.12.2.6 Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java + test/tools/javac/generics/7015430/T7015430.java + test/tools/javac/generics/7015430/T7015430.out Changeset: 9f9df9684cfc Author: mcimadamore Date: 2011-02-28 11:50 +0000 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9f9df9684cfc 7015715: lub gets stuck on type with complex supertype Summary: lub should not scan supertypes unnecessarily Reviewed-by: jjg, dlsmith ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/generics/inference/T7015715.java From weijun.wang at oracle.com Mon Feb 28 15:04:29 2011 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Mon, 28 Feb 2011 15:04:29 +0000 Subject: hg: jdk7/tl/jdk: 7021789: Remove jarsigner -crl option Message-ID: <20110228150446.D3C2447B11@hg.openjdk.java.net> Changeset: f4613b378874 Author: weijun Date: 2011-02-28 23:02 +0800 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/f4613b378874 7021789: Remove jarsigner -crl option Reviewed-by: mullan ! src/share/classes/com/sun/jarsigner/ContentSignerParameters.java ! src/share/classes/java/security/CodeSigner.java - src/share/classes/sun/misc/JavaSecurityCodeSignerAccess.java ! src/share/classes/sun/misc/SharedSecrets.java ! src/share/classes/sun/security/tools/JarSigner.java ! src/share/classes/sun/security/tools/JarSignerResources.java ! src/share/classes/sun/security/tools/KeyTool.java ! src/share/classes/sun/security/tools/TimestampedSigner.java ! src/share/classes/sun/security/util/SignatureFileVerifier.java ! test/sun/security/tools/jarsigner/crl.sh From jonathan.gibbons at oracle.com Mon Feb 28 20:20:23 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 28 Feb 2011 20:20:23 +0000 Subject: hg: jdk7/tl/langtools: 7022337: repeated warnings about bootclasspath not set Message-ID: <20110228202026.E893A47B21@hg.openjdk.java.net> Changeset: 9029f694e5df Author: jjg Date: 2011-02-28 12:19 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/9029f694e5df 7022337: repeated warnings about bootclasspath not set Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java - test/tools/javac/T6900037.java - test/tools/javac/T6900037.out + test/tools/javac/options/T6900037.java + test/tools/javac/options/T6900037.out + test/tools/javac/options/T7022337.java From mandy.chung at oracle.com Mon Feb 28 21:26:31 2011 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 28 Feb 2011 13:26:31 -0800 Subject: Review request for 7020513 : Add com.sun.xml.internal to the "package.access" property in java.security In-Reply-To: <4D67F10B.80506@oracle.com> References: <4D64558A.6040807@oracle.com> <4D64C8EF.2050101@oracle.com> <4D654E60.9070106@oracle.com> <4D67F10B.80506@oracle.com> Message-ID: <4D6C1307.6020905@oracle.com> Rama, Looks good to me. Are you planning to add a regression test? You had it in the webrev of an earlier version. Mandy On 02/25/11 10:12, Rama Pulavarthi wrote: > Please review this updated webrev that has the patch for JDK 7 repo. > http://cr.openjdk.java.net/~ohair/openjdk7/jdk7-tl-jaxws-7020513-open/webrev/ > > For background on this issue, this is not a new one. I am trying to port > the old fixes made in jdk repo as part of earlier jax-ws integrations in > to Open JDK 6. > The original issue CR 6592792 was fixed in JDK 6u7 and then ported to > Open JDK 6. When Open JDK 6 transitioned to Hg, it was committed as > [1]. As fix for CR 6831313 > :update jaxws in > OpenJDK7 to 2.1 plus bug fixes from OpenJDK 6, Only the changes in jaxws > sources are ported to JDK 7 [2]. But, there are other changes that are > made in jdk repo required for this fix. > > [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/586feec8273d > > [2] http://hg.openjdk.java.net/jdk7/build/jaxws/rev/31822b475baa > > > > thanks, > Rama Pulavarthi From jonathan.gibbons at oracle.com Mon Feb 28 21:38:16 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 28 Feb 2011 21:38:16 +0000 Subject: hg: jdk7/tl/langtools: 7022741: warning counts are wrong after anno processing Message-ID: <20110228213818.5B08D47B25@hg.openjdk.java.net> Changeset: bf9f162c7104 Author: jjg Date: 2011-02-28 13:37 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/bf9f162c7104 7022741: warning counts are wrong after anno processing Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java + test/tools/javac/processing/TestWarnErrorCount.java ! test/tools/javac/processing/warnings/gold_0.out ! test/tools/javac/processing/warnings/gold_sv_warn_0_2.out ! test/tools/javac/processing/warnings/gold_sv_warn_2_3.out ! test/tools/javac/processing/warnings/gold_sv_warn_5_6.out From jonathan.gibbons at oracle.com Mon Feb 28 21:42:45 2011 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 28 Feb 2011 21:42:45 +0000 Subject: hg: jdk7/tl/langtools: 7022711: compiler crash in try-with-resources Message-ID: <20110228214246.F370247B26@hg.openjdk.java.net> Changeset: 67d6b2df47ba Author: jjg Date: 2011-02-28 13:42 -0800 URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/67d6b2df47ba 7022711: compiler crash in try-with-resources Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Kinds.java + test/tools/javac/TryWithResources/T7022711.java + test/tools/javac/TryWithResources/T7022711.out From stuart.marks at oracle.com Mon Feb 28 22:29:48 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 28 Feb 2011 14:29:48 -0800 Subject: review request for 7022624, convert java.io test to use try-with-resources Message-ID: <4D6C21DC.1010106@oracle.com> Here's a small webrev with changes to a handful of java.io tests to use TWR. http://cr.openjdk.java.net/~smarks/reviews/7022624/webrev.0/ I have a few minor questions: * test/java/io/File/SetLastModified.java Should the channel corresponding to a stream be considered a separate resource, or is it more like another object that represents the "same" resource? Since closing one closes the other, I treated them as peers and I didn't unroll the FileOutputStream and its channel into separate resource variables. However, I'm flexible on this. * test/java/io/OutputStreamWriter/Encode.java Pretty clearly a ServerSocket is a distinct resource from a Socket returned from the accept() call. However, does Socket.getInputStream() represent a distinct resource from the Socket? In this case it seemed most sensible to unroll them into separate resource variables, but again I could go either way on this. * test/java/io/PrintStream/FailingConstructors.java Please check over my NIO usage here. Hm, I did more conversion here than in the other FailingConstructors tests (see webrev for 7021209). Maybe I should go back and fix the others.... * test/java/io/Serializable/evolution/RenamePackage/install/SerialDriver.java * test/java/io/Serializable/evolution/RenamePackage/test/SerialDriver.java Odd, seems like mostly duplicate code.... Thanks! s'marks