From chris.hegarty at oracle.com Thu Aug 1 04:38:33 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 01 Aug 2013 11:38:33 +0000 Subject: hg: jdk8/tl/jdk: 8022061: More ProblemList.txt updates (7/2013) Message-ID: <20130801113906.30C9B484F7@hg.openjdk.java.net> Changeset: c49b538ef054 Author: chegar Date: 2013-08-01 12:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c49b538ef054 8022061: More ProblemList.txt updates (7/2013) Reviewed-by: alanb, psandoz ! test/ProblemList.txt From dmitry.degrave at oracle.com Thu Aug 1 05:59:17 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 01 Aug 2013 12:59:17 +0000 Subject: hg: jdk8/tl/corba: 8015987: The corba repo contains unneeded .sjava files Message-ID: <20130801125918.9222C48507@hg.openjdk.java.net> Changeset: cc11a0efb4f9 Author: aefimov Date: 2013-08-01 14:59 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/cc11a0efb4f9 8015987: The corba repo contains unneeded .sjava files Reviewed-by: alanb, chegar, coffeys - src/share/classes/com/sun/corba/se/impl/copyobject/JavaInputStream.sjava - src/share/classes/com/sun/corba/se/impl/copyobject/JavaOutputStream.sjava - src/share/classes/com/sun/corba/se/impl/interceptors/ThreadCurrentStack.sjava - src/share/classes/com/sun/corba/se/impl/orbutil/DefineWrapper.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLNameTranslatorImpl_save.sjava - src/share/classes/com/sun/corba/se/impl/presentation/rmi/IDLTypesUtil_save.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalClientResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerRequestImpl.sjava - src/share/classes/com/sun/corba/se/impl/protocol/oldlocal/LocalServerResponseImpl.sjava - src/share/classes/com/sun/corba/se/impl/transport/BufferConnectionImpl.sjava From dmitry.degrave at oracle.com Thu Aug 1 07:20:44 2013 From: dmitry.degrave at oracle.com (dmitry.degrave at oracle.com) Date: Thu, 01 Aug 2013 14:20:44 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130801142116.CDC4A4850C@hg.openjdk.java.net> Changeset: 36f4cf8872f3 Author: igerasim Date: 2013-07-30 21:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/36f4cf8872f3 7192942: (coll) Inefficient calculation of power of two in HashMap Reviewed-by: mduigou ! src/share/classes/java/util/HashMap.java Changeset: 54329c24c2f4 Author: igerasim Date: 2013-07-29 12:35 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54329c24c2f4 8020669: (fs) Files.readAllBytes() does not read any data when Files.size() is 0 Reviewed-by: alanb, chegar, martin, rriggs ! src/share/classes/java/nio/file/Files.java ! test/java/nio/file/Files/BytesAndLines.java From xuelei.fan at oracle.com Thu Aug 1 07:35:37 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 01 Aug 2013 14:35:37 +0000 Subject: hg: jdk8/tl/jdk: 7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID Message-ID: <20130801143551.326ED4850E@hg.openjdk.java.net> Changeset: d6de149b9f20 Author: xuelei Date: 2013-08-01 07:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d6de149b9f20 7127524: P11TlsPrfGenerator has anonymous inner class with serialVersionUID Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11TlsPrfGenerator.java From chris.hegarty at oracle.com Thu Aug 1 08:54:13 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 01 Aug 2013 15:54:13 +0000 Subject: hg: jdk8/tl/jdk: 8022087: Fix doclint issues in j.u.Deque & Queue Message-ID: <20130801155429.B1FE048510@hg.openjdk.java.net> Changeset: cd13a4a45a37 Author: chegar Date: 2013-08-01 16:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd13a4a45a37 8022087: Fix doclint issues in j.u.Deque & Queue Reviewed-by: chegar, darcy Contributed-by: Doug Lea
! src/share/classes/java/util/Deque.java ! src/share/classes/java/util/Queue.java From paul.sandoz at oracle.com Thu Aug 1 14:07:32 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Thu, 01 Aug 2013 21:07:32 +0000 Subject: hg: jdk8/tl/jdk: 8020016: Numerous splitereator impls do not throw NPE for null Consumers Message-ID: <20130801210757.ADA8748544@hg.openjdk.java.net> Changeset: 0be7839d4599 Author: psandoz Date: 2013-08-01 15:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0be7839d4599 8020016: Numerous splitereator impls do not throw NPE for null Consumers Reviewed-by: mduigou, alanb, henryjen ! src/share/classes/java/util/stream/SpinedBuffer.java ! src/share/classes/java/util/stream/StreamSpliterators.java ! src/share/classes/java/util/stream/Streams.java ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java ! test/java/util/stream/bootlib/java/util/stream/SpliteratorTestHelper.java From stuart.marks at oracle.com Thu Aug 1 14:18:01 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 01 Aug 2013 14:18:01 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <20130731213957.GA24485@mhcomputing.net> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> Message-ID: <51FAD089.9000805@oracle.com> On 7/31/13 2:39 PM, Matthew Hall wrote: > On Wed, Jul 31, 2013 at 02:38:26PM -0700, Stuart Marks wrote: >> The alternative is to add "@throws SocketException never" to the >> javadoc, just to get rid of the doclint warning, but this has the >> consequence of requiring people to keep dead code around >> indefinitely, and furthermore it requires them to add new dead code >> every time they create a DatagramPacket. > > I have never understood in many years using Java why the compiler generates > errors about attempting to catch supposedly-impossible exceptions, instead of > warnings. > > For me it only leads to difficulties when I'm trying to write prototypes or > refactor and clean up some old brittle code, and I run into that rather > dubious sort of error. > > This is a good example of where it causes more harm than good. Is there still > a really good reason for this over-paranoid compiler error given that checked > exceptions aren't as popular as they used to be anyways? I don't have the definitive answer, but it was a very early Java design decision to make unreachable code be a compilation error instead of a warning. This is a matter of judgment, of course; reasonable people come down on different sides of this, for different cases. For example, see this Stackoverflow conversation: http://stackoverflow.com/questions/3795585/why-does-java-have-an-unreachable-statement-compiler-error * * * Meanwhile, I did a little bit of studying about DatagramPacket. The doclint warnings occur on two of the six DatagramPacket constructors: DatagramPacket(byte[] buf, int len, SocketAddress sa) DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) There are two other equivalent overloaded constructors that take InetAddress and port arguments: DatagramPacket(byte[] buf, int len, InetAddress ia, int port) DatagramPacket(byte[] buf, int off, int len, InetAddress ia, int port) To my eye the InetAddress/port constructors are used quite a bit more often than the SocketAddress ones. I did a web search for "java DatagramPacket example" and looked at all the examples on the first page of hits. All of them used the InetAddress+port constructor overloads (including the Oracle Java tutorial). I didn't see any uses of the SocketAddress overloads. I also did an ohloh search for "new DatagramPacket(": http://code.ohloh.net/search?s=%22new%20DatagramPacket%28%22&p=2&pp=0&fl=Java&mp=1&ml=1&me=1&md=1&ff=1&filterChecked=true (HT: Dalibor) I looked through around 100 examples, and the vast majority of them use the InetAddress+port overloads. I saw three examples that use the SocketAddress overloads. Two of them were within methods that declared "throws Exception." The third was within a try/catch block that catches IOException. None of the three cases would suffer a source incompatibility. This isn't definitive, of course, but it does seem to supply some evidence that making this change would result in a relatively minor source incompatibility. s'marks From mhall at mhcomputing.net Thu Aug 1 14:56:16 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 1 Aug 2013 14:56:16 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <51FAD089.9000805@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> Message-ID: <20130801215616.GA6859@mhcomputing.net> On Thu, Aug 01, 2013 at 02:18:01PM -0700, Stuart Marks wrote: > This isn't definitive, of course, but it does seem to supply some > evidence that making this change would result in a relatively minor > source incompatibility. Good, maybe it will allow a true fix to be made in this case. Matthew. From Alan.Bateman at oracle.com Thu Aug 1 15:08:39 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 Aug 2013 15:08:39 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <51FAD089.9000805@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> Message-ID: <51FADC67.9020502@oracle.com> On 01/08/2013 14:18, Stuart Marks wrote: > : > > To my eye the InetAddress/port constructors are used quite a bit more > often than the SocketAddress ones. I did a web search for "java > DatagramPacket example" and looked at all the examples on the first > page of hits. All of them used the InetAddress+port constructor > overloads (including the Oracle Java tutorial). I didn't see any uses > of the SocketAddress overloads. That's what I would expect as DatagramPacket is old and and pre-dates the SocketAddress abstraction. One other thing to check is whether this API bug has ever been reported. If not then it suggests that not too many people have actually run into it. If these constructors are widely used then I would expect that the bug would be reported before now. -Alan From weijun.wang at oracle.com Thu Aug 1 18:17:36 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 02 Aug 2013 01:17:36 +0000 Subject: hg: jdk8/tl/jdk: 8021789: jarsigner parses alias as command line option (depending on locale) Message-ID: <20130802011827.507EE48551@hg.openjdk.java.net> Changeset: 29f153e11683 Author: weijun Date: 2013-08-02 08:59 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/29f153e11683 8021789: jarsigner parses alias as command line option (depending on locale) Reviewed-by: vinnie ! src/share/classes/sun/security/tools/jarsigner/Main.java + test/sun/security/tools/jarsigner/collator.sh From joe.darcy at oracle.com Thu Aug 1 22:04:06 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Thu, 01 Aug 2013 22:04:06 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <51FADC67.9020502@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> <51FADC67.9020502@oracle.com> Message-ID: <51FB3DC6.80705@oracle.com> On 08/01/2013 03:08 PM, Alan Bateman wrote: > On 01/08/2013 14:18, Stuart Marks wrote: >> : >> >> To my eye the InetAddress/port constructors are used quite a bit more >> often than the SocketAddress ones. I did a web search for "java >> DatagramPacket example" and looked at all the examples on the first >> page of hits. All of them used the InetAddress+port constructor >> overloads (including the Oracle Java tutorial). I didn't see any uses >> of the SocketAddress overloads. > That's what I would expect as DatagramPacket is old and and pre-dates > the SocketAddress abstraction. > > One other thing to check is whether this API bug has ever been > reported. If not then it suggests that not too many people have > actually run into it. If these constructors are widely used then I > would expect that the bug would be reported before now. > > -Alan Given the results of Stuart's initial investigation, I would favor removing the throws clauses and calling out the change in the release notes. Cheers, -Joe From chris.hegarty at oracle.com Fri Aug 2 02:37:13 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 02 Aug 2013 10:37:13 +0100 Subject: Remaining doclint issues in java.net In-Reply-To: <51FAD089.9000805@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> Message-ID: <51FB7DC9.9000605@oracle.com> comments inline... On 01/08/2013 22:18, Stuart Marks wrote: > On 7/31/13 2:39 PM, Matthew Hall wrote: >> On Wed, Jul 31, 2013 at 02:38:26PM -0700, Stuart Marks wrote: >>> The alternative is to add "@throws SocketException never" to the >>> javadoc, just to get rid of the doclint warning, but this has the >>> consequence of requiring people to keep dead code around >>> indefinitely, and furthermore it requires them to add new dead code >>> every time they create a DatagramPacket. >> >> I have never understood in many years using Java why the compiler >> generates >> errors about attempting to catch supposedly-impossible exceptions, >> instead of >> warnings. >> >> For me it only leads to difficulties when I'm trying to write >> prototypes or >> refactor and clean up some old brittle code, and I run into that rather >> dubious sort of error. >> >> This is a good example of where it causes more harm than good. Is >> there still >> a really good reason for this over-paranoid compiler error given that >> checked >> exceptions aren't as popular as they used to be anyways? > > I don't have the definitive answer, but it was a very early Java design > decision to make unreachable code be a compilation error instead of a > warning. This is a matter of judgment, of course; reasonable people come > down on different sides of this, for different cases. For example, see > this Stackoverflow conversation: > > http://stackoverflow.com/questions/3795585/why-does-java-have-an-unreachable-statement-compiler-error > > > * * * > > Meanwhile, I did a little bit of studying about DatagramPacket. The > doclint warnings occur on two of the six DatagramPacket constructors: > > DatagramPacket(byte[] buf, int len, SocketAddress sa) > DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) > > There are two other equivalent overloaded constructors that take > InetAddress and port arguments: > > DatagramPacket(byte[] buf, int len, InetAddress ia, int port) > DatagramPacket(byte[] buf, int off, int len, InetAddress ia, int port) > > To my eye the InetAddress/port constructors are used quite a bit more > often than the SocketAddress ones. I did a web search for "java > DatagramPacket example" and looked at all the examples on the first page > of hits. All of them used the InetAddress+port constructor overloads > (including the Oracle Java tutorial). I didn't see any uses of the > SocketAddress overloads. > > I also did an ohloh search for "new DatagramPacket(": > > http://code.ohloh.net/search?s=%22new%20DatagramPacket%28%22&p=2&pp=0&fl=Java&mp=1&ml=1&me=1&md=1&ff=1&filterChecked=true Thank you Stuart, this is really helpful. > (HT: Dalibor) > > I looked through around 100 examples, and the vast majority of them use > the InetAddress+port overloads. I saw three examples that use the I would tend to agree with this, the InetAddress+port are probably most commonly used. The SocketAddress variants are useful when you have already constructed an InetSocketAddress elsewhere and pass it into the method that creates/sends the packet. I can only find this sort of code in tests. Also worth noting is that typically datagram packets are created in close proximity to the code that sends them, and the sending of a packet requires handling IOE. This, IMO, further reduces the impact of removing 'throw SE'. > SocketAddress overloads. Two of them were within methods that declared > "throws Exception." The third was within a try/catch block that catches > IOException. None of the three cases would suffer a source incompatibility. I cannot comment on the code you are talking about, but removing 'throws SE' from these constructors will affect anyone that is catching IOE ( since SE is a subclass of IOE ). Simple test: : cat ThrowingCtrs.java import java.net.*; import java.io.IOException; public class ThrowingCtrs { public static void main(String[] args) { SocketAddress sa = new InetSocketAddress("127.0.0.1", 45678); // DatagramPacket(byte[], int, SocketAddress) try { DatagramPacket dp = new DatagramPacket(new byte[1], 1, sa); } catch (SocketException x) { } try { DatagramPacket dp = new DatagramPacket(new byte[1], 1, sa); } catch (IOException x) { } try { DatagramPacket dp = new DatagramPacket(new byte[1], 1, sa); } catch (Exception x) { } // DatagramPacket(byte[], int, int, SocketAddress) try { DatagramPacket dp = new DatagramPacket(new byte[1], 0, 1, sa); } catch (SocketException x) { } try { DatagramPacket dp = new DatagramPacket(new byte[1], 0, 1, sa); } catch (IOException x) { } try { DatagramPacket dp = new DatagramPacket(new byte[1], 0, 1, sa); } catch (Exception x) { } } } Output of javac from a build with SE removed. build/solaris-x86_64-normal-server-release/jdk/bin/javac ThrowingCtrs.java ThrowingCtrs.java:11: error: exception SocketException is never thrown in body of corresponding try statement catch (SocketException x) { } ^ ThrowingCtrs.java:14: error: exception IOException is never thrown in body of corresponding try statement catch (IOException x) { } ^ ThrowingCtrs.java:21: error: exception SocketException is never thrown in body of corresponding try statement catch (SocketException x) { } ^ ThrowingCtrs.java:24: error: exception IOException is never thrown in body of corresponding try statement catch (IOException x) { } ^ 4 errors > This isn't definitive, of course, but it does seem to supply some > evidence that making this change would result in a relatively minor > source incompatibility. Given the above, I still agree with the sentiment here. I will file a bug and proceed with the necessary changes to remove SE. Thanks again, -Chris. > > s'marks From chris.hegarty at oracle.com Fri Aug 2 02:38:08 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 02 Aug 2013 10:38:08 +0100 Subject: Remaining doclint issues in java.net In-Reply-To: <51FADC67.9020502@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> <51FADC67.9020502@oracle.com> Message-ID: <51FB7E00.3040106@oracle.com> On 01/08/2013 23:08, Alan Bateman wrote: > On 01/08/2013 14:18, Stuart Marks wrote: >> : >> >> To my eye the InetAddress/port constructors are used quite a bit more >> often than the SocketAddress ones. I did a web search for "java >> DatagramPacket example" and looked at all the examples on the first >> page of hits. All of them used the InetAddress+port constructor >> overloads (including the Oracle Java tutorial). I didn't see any uses >> of the SocketAddress overloads. > That's what I would expect as DatagramPacket is old and and pre-dates > the SocketAddress abstraction. > > One other thing to check is whether this API bug has ever been reported. > If not then it suggests that not too many people have actually run into > it. If these constructors are widely used then I would expect that the > bug would be reported before now. I can find not such bug(s) reporting this issue. But I will file one now ;-) -Chris. > > -Alan > > > From chris.hegarty at oracle.com Fri Aug 2 03:25:17 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 02 Aug 2013 10:25:17 +0000 Subject: hg: jdk8/tl/jdk: 8022121: Remove superfluous @test tag from SpliteratorTraversingAndSplittingTest Message-ID: <20130802102548.A0C5D48569@hg.openjdk.java.net> Changeset: 60c275e56a69 Author: chegar Date: 2013-08-02 11:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/60c275e56a69 8022121: Remove superfluous @test tag from SpliteratorTraversingAndSplittingTest Reviewed-by: psandoz ! test/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java From chris.hegarty at oracle.com Fri Aug 2 06:30:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 02 Aug 2013 13:30:49 +0000 Subject: hg: jdk8/tl/jdk: 8020291: j.u.c.CompletionStage; ... Message-ID: <20130802133116.5F3184856D@hg.openjdk.java.net> Changeset: 6ec910ff3ea1 Author: chegar Date: 2013-08-02 14:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6ec910ff3ea1 8020291: j.u.c.CompletionStage 8020435: CompletableFuture/Basic.java fails on single core machine Reviewed-by: chegar, psandoz Contributed-by: Doug Lea
! src/share/classes/java/util/concurrent/CompletableFuture.java + src/share/classes/java/util/concurrent/CompletionStage.java ! test/ProblemList.txt ! test/java/util/concurrent/CompletableFuture/Basic.java From sean.mullan at oracle.com Fri Aug 2 06:39:43 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Fri, 02 Aug 2013 13:39:43 +0000 Subject: hg: jdk8/tl/jdk: 3 new changesets Message-ID: <20130802134021.928284856E@hg.openjdk.java.net> Changeset: 42b786f2fb99 Author: mullan Date: 2013-08-02 08:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/42b786f2fb99 8001319: Add SecurityPermission "insertProvider" target name Reviewed-by: vinnie ! src/share/classes/java/security/Security.java ! src/share/classes/java/security/SecurityPermission.java + test/java/security/Security/AddProvider.java + test/java/security/Security/AddProvider.policy.1 + test/java/security/Security/AddProvider.policy.2 + test/java/security/Security/AddProvider.policy.3 Changeset: 7bbc6c2351d7 Author: mullan Date: 2013-08-02 08:37 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bbc6c2351d7 Merge - src/share/classes/java/net/package.html - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 0a778e487a73 Author: mullan Date: 2013-08-02 09:38 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0a778e487a73 Merge From joe.darcy at oracle.com Fri Aug 2 14:19:21 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Fri, 02 Aug 2013 21:19:21 +0000 Subject: hg: jdk8/tl/jdk: 6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion Message-ID: <20130802212009.363134859F@hg.openjdk.java.net> Changeset: 33617583c545 Author: bpb Date: 2013-07-31 10:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/33617583c545 6476168: (fmt) Inconsistency formatting subnormal doubles with hexadecimal conversion Summary: Update specification to match implementation. Reviewed-by: darcy Contributed-by: Brian Burkhalter ! src/share/classes/java/util/Formatter.java ! test/java/util/Formatter/Basic-X.java.template ! test/java/util/Formatter/Basic.java ! test/java/util/Formatter/BasicDouble.java From stuart.marks at oracle.com Fri Aug 2 14:38:33 2013 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 02 Aug 2013 14:38:33 -0700 Subject: Remaining doclint issues in java.net In-Reply-To: <51FB7DC9.9000605@oracle.com> References: <51F67C14.5040804@oracle.com> <51F983D2.3050501@oracle.com> <20130731213957.GA24485@mhcomputing.net> <51FAD089.9000805@oracle.com> <51FB7DC9.9000605@oracle.com> Message-ID: <51FC26D9.1050800@oracle.com> On 8/2/13 2:37 AM, Chris Hegarty wrote: > On 01/08/2013 22:18, Stuart Marks wrote: >> SocketAddress overloads. Two of them were within methods that declared >> "throws Exception." The third was within a try/catch block that catches >> IOException. None of the three cases would suffer a source incompatibility. > > I cannot comment on the code you are talking about, but removing 'throws SE' > from these constructors will affect anyone that is catching IOE ( since SE is a > subclass of IOE ). Simple test: [...] You're correct, of course, that constructing a new DatagramPacket within a try/catch of IOException would suffer the source incompatibility. I had neglected to mention, though, that the try/catch(IOException) code that I looked at also did a bunch of other IOException-throwing stuff within the try block. So in that particular case the code wouldn't have had a compatibility issue. >> This isn't definitive, of course, but it does seem to supply some >> evidence that making this change would result in a relatively minor >> source incompatibility. > > Given the above, I still agree with the sentiment here. I will file a bug and > proceed with the necessary changes to remove SE. Great! Glad to hear it. Thanks. s'marks From naoto.sato at oracle.com Fri Aug 2 15:45:52 2013 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 02 Aug 2013 22:45:52 +0000 Subject: hg: jdk8/tl/jdk: 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Message-ID: <20130802224616.147DA485A2@hg.openjdk.java.net> Changeset: 883cc296ec89 Author: bchristi Date: 2013-08-02 15:30 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/883cc296ec89 8011194: Apps launched via double-clicked .jars have file.encoding value of US-ASCII on Mac OS X Summary: On Mac, default to UTF-8 if no environmental hints are available Reviewed-by: naoto, ddehaven ! src/solaris/native/java/lang/java_props_md.c + test/java/lang/System/MacEncoding/ExpectedEncoding.java + test/java/lang/System/MacEncoding/MacJNUEncoding.sh + test/java/lang/System/MacEncoding/TestFileEncoding.java - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh From alan.bateman at oracle.com Sat Aug 3 19:14:50 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sun, 04 Aug 2013 02:14:50 +0000 Subject: hg: jdk8/tl/jdk: 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect Message-ID: <20130804021551.9BF2A485B9@hg.openjdk.java.net> Changeset: dd1040690e31 Author: bpb Date: 2013-08-02 11:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dd1040690e31 8022094: BigDecimal/CompareToTests and BigInteger/CompareToTests are incorrect Summary: Fail test if errors; fix test values; port BigDecimal version to BigInteger Reviewed-by: smarks, alanb Contributed-by: Brian Burkhalter ! test/java/math/BigDecimal/CompareToTests.java ! test/java/math/BigInteger/CompareToTests.java From joe.darcy at oracle.com Mon Aug 5 07:50:31 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Mon, 05 Aug 2013 14:50:31 +0000 Subject: hg: jdk8/tl/jdk: 8022190: Fix varargs lint warnings in the JDK Message-ID: <20130805145121.77CAF485DA@hg.openjdk.java.net> Changeset: 80da091343af Author: darcy Date: 2013-08-05 07:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/80da091343af 8022190: Fix varargs lint warnings in the JDK Reviewed-by: alanb, lancea, alexsch ! src/share/classes/java/util/stream/Stream.java ! src/share/classes/javax/swing/SwingWorker.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java ! src/share/classes/sun/swing/AccumulativeRunnable.java From stuart.marks at oracle.com Mon Aug 5 19:08:25 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 06 Aug 2013 02:08:25 +0000 Subject: hg: jdk8/tl/jdk: 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address Message-ID: <20130806020849.73652485F5@hg.openjdk.java.net> Changeset: 31759750ff63 Author: smarks Date: 2013-08-05 19:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31759750ff63 8020854: change RMI javadocs to specify that remote objects are exported to the wildcard address Reviewed-by: rgallard, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java ! src/share/classes/java/rmi/server/UnicastRemoteObject.java From dmitry.samersoff at oracle.com Tue Aug 6 03:05:31 2013 From: dmitry.samersoff at oracle.com (dmitry.samersoff at oracle.com) Date: Tue, 06 Aug 2013 10:05:31 +0000 Subject: hg: jdk8/tl/jdk: 8011038: sourceObj validation during desereliazation of RelationNotification should be relaxed Message-ID: <20130806100558.D1A33485FD@hg.openjdk.java.net> Changeset: fce446b29577 Author: dsamersoff Date: 2013-08-06 14:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fce446b29577 8011038: sourceObj validation during desereliazation of RelationNotification should be relaxed Summary: sourceObj could be set to null by setSource() relax a validation of deserialized object. Reviewed-by: sjiang, skoivu, dfuchs ! src/share/classes/javax/management/relation/RelationNotification.java From chris.hegarty at oracle.com Tue Aug 6 04:12:58 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 06 Aug 2013 12:12:58 +0100 Subject: RFR Additional debug info for test/java/net/NetworkInterface/IndexTest.java Message-ID: <5200DA3A.2010105@oracle.com> This test has been seen to fail intermittently on a number of systems. This change proposes to add some additional debug information to help diagnose the failure when it appears again. The test remains silent until it encounters an issue. I need a reviewer before I can push this simple change. diff -r 0a778e487a73 test/java/net/NetworkInterface/IndexTest.java --- a/test/java/net/NetworkInterface/IndexTest.java Fri Aug 02 09:38:13 2013 -0400 +++ b/test/java/net/NetworkInterface/IndexTest.java Tue Aug 06 12:06:09 2013 +0100 @@ -27,7 +27,10 @@ */ import java.net.*; +import java.util.Arrays; +import java.util.Collections; import java.util.Enumeration; +import static java.lang.System.out; public class IndexTest { public static void main(String[] args) throws Exception { @@ -39,12 +42,17 @@ public class IndexTest { if (index >= 0) { NetworkInterface nif2 = NetworkInterface.getByIndex(index); if (! nif.equals(nif2)) { + out.printf("\nExpected interfaces to be the same, but got:\n"); + displayInterfaceInformation(nif); + displayInterfaceInformation(nif2); throw new RuntimeException("both interfaces should be equal"); } } } try { nif = NetworkInterface.getByIndex(-1); + out.printf("\ngetByIndex(-1) should have thrown, but instead returned:\n"); + displayInterfaceInformation(nif); throw new RuntimeException("Should have thrown IllegalArgumentException"); } catch (IllegalArgumentException e) { // OK @@ -52,7 +60,29 @@ public class IndexTest { // In all likelyhood, this interface should not exist. nif = NetworkInterface.getByIndex(Integer.MAX_VALUE - 1); if (nif != null) { + out.printf("\ngetByIndex(MAX_VALUE - 1), expected null, got:\n"); + displayInterfaceInformation(nif); throw new RuntimeException("getByIndex() should have returned null"); } } + + static void displayInterfaceInformation(NetworkInterface netint) throws SocketException { + out.printf("Display name: %s\n", netint.getDisplayName()); + out.printf("Name: %s\n", netint.getName()); + Enumeration inetAddresses = netint.getInetAddresses(); + + for (InetAddress inetAddress : Collections.list(inetAddresses)) + out.printf("InetAddress: %s\n", inetAddress); + + out.printf("Up? %s\n", netint.isUp()); + out.printf("Loopback? %s\n", netint.isLoopback()); + out.printf("PointToPoint? %s\n", netint.isPointToPoint()); + out.printf("Supports multicast? %s\n", netint.supportsMulticast()); + out.printf("Virtual? %s\n", netint.isVirtual()); + out.printf("Hardware address: %s\n", + Arrays.toString(netint.getHardwareAddress())); + out.printf("MTU: %s\n", netint.getMTU()); + out.printf("Index: %s\n", netint.getIndex()); + out.printf("\n"); + } } -Chris. From michael.x.mcmahon at oracle.com Tue Aug 6 04:21:29 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 06 Aug 2013 12:21:29 +0100 Subject: RFR Additional debug info for test/java/net/NetworkInterface/IndexTest.java In-Reply-To: <5200DA3A.2010105@oracle.com> References: <5200DA3A.2010105@oracle.com> Message-ID: <5200DC39.40501@oracle.com> Looks fine, Chris Michael On 06/08/13 12:12, Chris Hegarty wrote: > This test has been seen to fail intermittently on a number of systems. > This change proposes to add some additional debug information to help > diagnose the failure when it appears again. The test remains silent > until it encounters an issue. > > I need a reviewer before I can push this simple change. > > > diff -r 0a778e487a73 test/java/net/NetworkInterface/IndexTest.java > --- a/test/java/net/NetworkInterface/IndexTest.java Fri Aug 02 > 09:38:13 2013 -0400 > +++ b/test/java/net/NetworkInterface/IndexTest.java Tue Aug 06 > 12:06:09 2013 +0100 > @@ -27,7 +27,10 @@ > */ > > import java.net.*; > +import java.util.Arrays; > +import java.util.Collections; > import java.util.Enumeration; > +import static java.lang.System.out; > > public class IndexTest { > public static void main(String[] args) throws Exception { > @@ -39,12 +42,17 @@ public class IndexTest { > if (index >= 0) { > NetworkInterface nif2 = > NetworkInterface.getByIndex(index); > if (! nif.equals(nif2)) { > + out.printf("\nExpected interfaces to be the same, > but got:\n"); > + displayInterfaceInformation(nif); > + displayInterfaceInformation(nif2); > throw new RuntimeException("both interfaces > should be equal"); > } > } > } > try { > nif = NetworkInterface.getByIndex(-1); > + out.printf("\ngetByIndex(-1) should have thrown, but > instead returned:\n"); > + displayInterfaceInformation(nif); > throw new RuntimeException("Should have thrown > IllegalArgumentException"); > } catch (IllegalArgumentException e) { > // OK > @@ -52,7 +60,29 @@ public class IndexTest { > // In all likelyhood, this interface should not exist. > nif = NetworkInterface.getByIndex(Integer.MAX_VALUE - 1); > if (nif != null) { > + out.printf("\ngetByIndex(MAX_VALUE - 1), expected null, > got:\n"); > + displayInterfaceInformation(nif); > throw new RuntimeException("getByIndex() should have > returned null"); > } > } > + > + static void displayInterfaceInformation(NetworkInterface netint) > throws SocketException { > + out.printf("Display name: %s\n", netint.getDisplayName()); > + out.printf("Name: %s\n", netint.getName()); > + Enumeration inetAddresses = > netint.getInetAddresses(); > + > + for (InetAddress inetAddress : Collections.list(inetAddresses)) > + out.printf("InetAddress: %s\n", inetAddress); > + > + out.printf("Up? %s\n", netint.isUp()); > + out.printf("Loopback? %s\n", netint.isLoopback()); > + out.printf("PointToPoint? %s\n", netint.isPointToPoint()); > + out.printf("Supports multicast? %s\n", > netint.supportsMulticast()); > + out.printf("Virtual? %s\n", netint.isVirtual()); > + out.printf("Hardware address: %s\n", > + Arrays.toString(netint.getHardwareAddress())); > + out.printf("MTU: %s\n", netint.getMTU()); > + out.printf("Index: %s\n", netint.getIndex()); > + out.printf("\n"); > + } > } > > -Chris. From xuelei.fan at oracle.com Tue Aug 6 04:44:57 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 06 Aug 2013 19:44:57 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot Message-ID: <5200E1B9.7070002@oracle.com> Hi, Please review the bug fix to strict the illegal input checking in IDN. webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ Here is two test cases, which are expected to get IAE. Case 1: String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); Exception in thread "main" java.lang.StringIndexOutOfBoundsException: String index out of range: 0 at java.lang.StringBuffer.charAt(StringBuffer.java:204) at java.net.IDN.toASCIIInternal(IDN.java:279) at java.net.IDN.toASCII(IDN.java:118) Case 2: String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); Thanks, Xuelei From Alan.Bateman at oracle.com Tue Aug 6 07:09:55 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 07:09:55 -0700 Subject: RFR Additional debug info for test/java/net/NetworkInterface/IndexTest.java In-Reply-To: <5200DA3A.2010105@oracle.com> References: <5200DA3A.2010105@oracle.com> Message-ID: <520103B3.3050601@oracle.com> On 06/08/2013 04:12, Chris Hegarty wrote: > This test has been seen to fail intermittently on a number of systems. > This change proposes to add some additional debug information to help > diagnose the failure when it appears again. The test remains silent > until it encounters an issue. > > I need a reviewer before I can push this simple change. Looks okay to me (although I guess I might have used %n to be more portable). -Alan From chris.hegarty at oracle.com Tue Aug 6 07:15:41 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 06 Aug 2013 15:15:41 +0100 Subject: RFR Additional debug info for test/java/net/NetworkInterface/IndexTest.java In-Reply-To: <520103B3.3050601@oracle.com> References: <5200DA3A.2010105@oracle.com> <520103B3.3050601@oracle.com> Message-ID: <5201050D.3000604@oracle.com> On 06/08/2013 15:09, Alan Bateman wrote: > On 06/08/2013 04:12, Chris Hegarty wrote: >> This test has been seen to fail intermittently on a number of systems. >> This change proposes to add some additional debug information to help >> diagnose the failure when it appears again. The test remains silent >> until it encounters an issue. >> >> I need a reviewer before I can push this simple change. > Looks okay to me (although I guess I might have used %n to be more > portable). Will update before the push. -Chris. > > -Alan From vicente.romero at oracle.com Tue Aug 6 07:18:15 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Tue, 06 Aug 2013 14:18:15 +0000 Subject: hg: jdk8/tl/langtools: 8022186: javac generates dead code if a try with an empty body has a finalizer Message-ID: <20130806141821.C84924860B@hg.openjdk.java.net> Changeset: 99b60bcf3862 Author: vromero Date: 2013-08-06 15:08 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/99b60bcf3862 8022186: javac generates dead code if a try with an empty body has a finalizer Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/Gen.java + test/tools/javac/T8022186/DeadCodeGeneratedForEmptyTryTest.java From chris.hegarty at oracle.com Tue Aug 6 07:35:49 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 06 Aug 2013 14:35:49 +0000 Subject: hg: jdk8/tl/jdk: 8022344: Additional debug info for test/java/net/NetworkInterface/IndexTest.java Message-ID: <20130806143616.38D8B4860E@hg.openjdk.java.net> Changeset: 6773af0dda02 Author: chegar Date: 2013-08-06 15:35 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6773af0dda02 8022344: Additional debug info for test/java/net/NetworkInterface/IndexTest.java Reviewed-by: michaelm, alanb ! test/java/net/NetworkInterface/IndexTest.java From weijun.wang at oracle.com Tue Aug 6 08:08:33 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 06 Aug 2013 23:08:33 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5200E1B9.7070002@oracle.com> References: <5200E1B9.7070002@oracle.com> Message-ID: <52011171.7090808@oracle.com> I am not sure if IDN.java is the correct place to change. At least I've seen trailing dots in DNS entries. So maybe it's not so illegal. --Max On 8/6/13 7:44 PM, Xuelei Fan wrote: > Hi, > > Please review the bug fix to strict the illegal input checking in IDN. > > webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ > > Here is two test cases, which are expected to get IAE. > > Case 1: > String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); > Exception in thread "main" java.lang.StringIndexOutOfBoundsException: > String index out of range: 0 > at java.lang.StringBuffer.charAt(StringBuffer.java:204) > at java.net.IDN.toASCIIInternal(IDN.java:279) > at java.net.IDN.toASCII(IDN.java:118) > > Case 2: > String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); > > Thanks, > Xuelei > From Xuelei.Fan at Oracle.Com Tue Aug 6 08:25:31 2013 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Tue, 6 Aug 2013 23:25:31 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52011171.7090808@oracle.com> References: <5200E1B9.7070002@oracle.com> <52011171.7090808@oracle.com> Message-ID: On Aug 6, 2013, at 23:08, Weijun Wang wrote: > I am not sure if IDN.java is the correct place to change. At least I've seen trailing dots in DNS entries. So maybe it's not so illegal. > Per RFC 1034, a domain name cannot end with dot. I will check other related specifications. What's the case you saw with trailing dots? Thanks, Xuelei > --Max > > On 8/6/13 7:44 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the bug fix to strict the illegal input checking in IDN. >> >> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >> >> Here is two test cases, which are expected to get IAE. >> >> Case 1: >> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >> String index out of range: 0 >> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >> at java.net.IDN.toASCIIInternal(IDN.java:279) >> at java.net.IDN.toASCII(IDN.java:118) >> >> Case 2: >> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >> >> Thanks, >> Xuelei >> From chris.hegarty at oracle.com Tue Aug 6 08:32:43 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 06 Aug 2013 16:32:43 +0100 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress Message-ID: <5201171B.3030907@oracle.com> This is a followup to the recent discussion on: http://mail.openjdk.java.net/pipermail/net-dev/2013-July/006889.html (cont'd) http://mail.openjdk.java.net/pipermail/net-dev/2013-August/006914.html Two DatagramPacket constructors declare that they throw SocketException. DatagramPacket(byte[] buf, int len, SocketAddress sa) throws SocketException DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) throws SocketException As it happens 'throws SE' was incorrectly added to these constructors when introduced in 1.4. The original API specified that SE was thrown when the given SocketAddress was not supported. That was later changed to throw IAE, in 1.4.2. These constructor now can never throw SE. Removing 'throws SE' from the method declaration is a binary compatible change, but not source compatible ( XXX is never thrown in body of corresponding try statement ). The conclusion of the discussion is that since these constructors are not that widely used (the InetAddress+port variants are more popular). Where they are, the affected code typically sends the packet, which requires handling of IOException anyway. A note will be added to the jdk8 release notes documenting this incompatibility. diff -r 6773af0dda02 src/share/classes/java/net/DatagramPacket.java --- a/src/share/classes/java/net/DatagramPacket.java Tue Aug 06 15:35:20 2013 +0100 +++ b/src/share/classes/java/net/DatagramPacket.java Tue Aug 06 16:26:38 2013 +0100 @@ -140,7 +140,7 @@ class DatagramPacket { * @since 1.4 */ public DatagramPacket(byte buf[], int offset, int length, - SocketAddress address) throws SocketException { + SocketAddress address) { setData(buf, offset, length); setSocketAddress(address); } @@ -176,7 +176,7 @@ class DatagramPacket { * @see java.net.InetAddress */ public DatagramPacket(byte buf[], int length, - SocketAddress address) throws SocketException { + SocketAddress address) { this(buf, 0, length, address); } -Chris. From Alan.Bateman at oracle.com Tue Aug 6 08:57:17 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 06 Aug 2013 08:57:17 -0700 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <5201171B.3030907@oracle.com> References: <5201171B.3030907@oracle.com> Message-ID: <52011CDD.2000001@oracle.com> On 06/08/2013 08:32, Chris Hegarty wrote: > This is a followup to the recent discussion on: > http://mail.openjdk.java.net/pipermail/net-dev/2013-July/006889.html > (cont'd) > http://mail.openjdk.java.net/pipermail/net-dev/2013-August/006914.html > > Two DatagramPacket constructors declare that they throw SocketException. > > DatagramPacket(byte[] buf, int len, SocketAddress sa) throws > SocketException > DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) > throws SocketException > > As it happens 'throws SE' was incorrectly added to these constructors > when introduced in 1.4. The original API specified that SE was thrown > when the given SocketAddress was not supported. That was later changed > to throw IAE, in 1.4.2. These constructor now can never throw SE. > > Removing 'throws SE' from the method declaration is a binary > compatible change, but not source compatible ( XXX is never thrown in > body of corresponding try statement ). > > The conclusion of the discussion is that since these constructors are > not that widely used (the InetAddress+port variants are more popular). > Where they are, the affected code typically sends the packet, which > requires handling of IOException anyway. > > A note will be added to the jdk8 release notes documenting this > incompatibility. While it a source incompatible change, I think it's the right thing to do. The patch looks fine to me (if you want then the declaration will probably fit on one line now). -Alan. From sean.mullan at oracle.com Tue Aug 6 08:56:29 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 06 Aug 2013 15:56:29 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130806155652.F28CB48610@hg.openjdk.java.net> Changeset: 1f4af3e0447e Author: mullan Date: 2013-08-06 08:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f4af3e0447e 8022120: JCK test api/javax_xml/crypto/dsig/TransformService/index_ParamMethods fails Summary: TransformService.init and marshalParams must throw NullPointerException when parent parameter is null Reviewed-by: xuelei ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java + test/javax/xml/crypto/dsig/TransformService/NullParent.java Changeset: ba634b53f53a Author: mullan Date: 2013-08-06 08:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba634b53f53a Merge From mhall at mhcomputing.net Tue Aug 6 09:06:16 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 06 Aug 2013 09:06:16 -0700 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52011171.7090808@oracle.com> References: <5200E1B9.7070002@oracle.com> <52011171.7090808@oracle.com> Message-ID: <056269b4-7ea6-4077-a189-ce40ce332dfb@email.android.com> Trailing dots are allowed in plain DNS (thus almost surely in IDN), and the single dot represents the root zone. So you have to be careful making this sort of change to check the DNS RFCs first. Matthew. -- Sent from my mobile device. Weijun Wang wrote: >I am not sure if IDN.java is the correct place to change. At least I've > >seen trailing dots in DNS entries. So maybe it's not so illegal. > >--Max > >On 8/6/13 7:44 PM, Xuelei Fan wrote: >> Hi, >> >> Please review the bug fix to strict the illegal input checking in >IDN. >> >> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >> >> Here is two test cases, which are expected to get IAE. >> >> Case 1: >> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >> String index out of range: 0 >> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >> at java.net.IDN.toASCIIInternal(IDN.java:279) >> at java.net.IDN.toASCII(IDN.java:118) >> >> Case 2: >> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >> >> Thanks, >> Xuelei >> From mhall at mhcomputing.net Tue Aug 6 09:09:07 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 06 Aug 2013 09:09:07 -0700 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <056269b4-7ea6-4077-a189-ce40ce332dfb@email.android.com> References: <5200E1B9.7070002@oracle.com> <52011171.7090808@oracle.com> <056269b4-7ea6-4077-a189-ce40ce332dfb@email.android.com> Message-ID: <7ea06d02-2224-44fb-af21-dc3af48fb603@email.android.com> Take a look here for more clarity: http://en.wikipedia.org/wiki/Fully_qualified_domain_name -- Sent from my mobile device. Matthew Hall wrote: >Trailing dots are allowed in plain DNS (thus almost surely in IDN), and >the single dot represents the root zone. So you have to be careful >making this sort of change to check the DNS RFCs first. > >Matthew. From dmitry.samersoff at oracle.com Tue Aug 6 09:43:15 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 06 Aug 2013 20:43:15 +0400 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5200E1B9.7070002@oracle.com> References: <5200E1B9.7070002@oracle.com> Message-ID: <520127A3.3060405@oracle.com> Xuelei, . (dot) is perfectly valid domain name and it means root domain so com. is valid domain name as well. It thinks to me that in context of methods your change we should ignore trailing dots, rather than throw exception. -Dmitry On 2013-08-06 15:44, Xuelei Fan wrote: > Hi, > > Please review the bug fix to strict the illegal input checking in IDN. > > webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ > > Here is two test cases, which are expected to get IAE. > > Case 1: > String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); > Exception in thread "main" java.lang.StringIndexOutOfBoundsException: > String index out of range: 0 > at java.lang.StringBuffer.charAt(StringBuffer.java:204) > at java.net.IDN.toASCIIInternal(IDN.java:279) > at java.net.IDN.toASCII(IDN.java:118) > > Case 2: > String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); > > Thanks, > Xuelei > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From michael.x.mcmahon at oracle.com Tue Aug 6 10:18:39 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 06 Aug 2013 18:18:39 +0100 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <52011CDD.2000001@oracle.com> References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com> Message-ID: <52012FEF.9030307@oracle.com> On 06/08/13 16:57, Alan Bateman wrote: > On 06/08/2013 08:32, Chris Hegarty wrote: >> This is a followup to the recent discussion on: >> http://mail.openjdk.java.net/pipermail/net-dev/2013-July/006889.html >> (cont'd) >> http://mail.openjdk.java.net/pipermail/net-dev/2013-August/006914.html >> >> Two DatagramPacket constructors declare that they throw SocketException. >> >> DatagramPacket(byte[] buf, int len, SocketAddress sa) throws >> SocketException >> DatagramPacket(byte[] buf, int off, int len, SocketAddress sa) >> throws SocketException >> >> As it happens 'throws SE' was incorrectly added to these constructors >> when introduced in 1.4. The original API specified that SE was thrown >> when the given SocketAddress was not supported. That was later >> changed to throw IAE, in 1.4.2. These constructor now can never throw >> SE. >> >> Removing 'throws SE' from the method declaration is a binary >> compatible change, but not source compatible ( XXX is never thrown in >> body of corresponding try statement ). >> >> The conclusion of the discussion is that since these constructors are >> not that widely used (the InetAddress+port variants are more >> popular). Where they are, the affected code typically sends the >> packet, which requires handling of IOException anyway. >> >> A note will be added to the jdk8 release notes documenting this >> incompatibility. > While it a source incompatible change, I think it's the right thing to > do. > > The patch looks fine to me (if you want then the declaration will > probably fit on one line now). > > -Alan. Late to this discussion ... So, the extent of the source compatibility is that a possible user of this class may have to edit their calling code, when recompiling in JDK 8 to possibly remove a catch(SocketException) block, which was dead code that was never being called? I guess that is okay especially since it's not so likely to happen. But, if it does, it will probably cause some confusion, as developers won't be expecting it. Documenting in release notes is okay too, but I suspect developers are not likely to look there at first anyway. Thinking aloud, it would be nice if some kind of annotation could be associated with the affected constructors such that a more meaningful/customized error message could be emitted by javac. But, perhaps there aren't sufficient other use cases to justify that. Michael. From michael.x.mcmahon at oracle.com Tue Aug 6 10:35:03 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 06 Aug 2013 18:35:03 +0100 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <520127A3.3060405@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> Message-ID: <520133C7.20401@oracle.com> I don't really understand the reason for the restriction in SNIHostName But, I guess that is where it should be enforced if it is required. Michael. On 06/08/13 17:43, Dmitry Samersoff wrote: > Xuelei, > > . (dot) is perfectly valid domain name and it means root domain so com. > is valid domain name as well. > > It thinks to me that in context of methods your change we should ignore > trailing dots, rather than throw exception. > > -Dmitry > > > > On 2013-08-06 15:44, Xuelei Fan wrote: >> Hi, >> >> Please review the bug fix to strict the illegal input checking in IDN. >> >> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >> >> Here is two test cases, which are expected to get IAE. >> >> Case 1: >> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >> String index out of range: 0 >> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >> at java.net.IDN.toASCIIInternal(IDN.java:279) >> at java.net.IDN.toASCII(IDN.java:118) >> >> Case 2: >> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >> >> Thanks, >> Xuelei >> > From mhall at mhcomputing.net Tue Aug 6 12:25:20 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Tue, 6 Aug 2013 12:25:20 -0700 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <52012FEF.9030307@oracle.com> References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com> <52012FEF.9030307@oracle.com> Message-ID: <20130806192520.GB5157@mhcomputing.net> On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote: > Documenting in release notes is okay too, but I suspect developers are not > likely to look there at first anyway. Thinking aloud, it would be nice if > some kind of annotation could be associated with the affected constructors > such that a more meaningful/customized error message could be emitted by > javac. But, perhaps there aren't sufficient other use cases to justify that. Many of us use Eclipse, NetBeans, and JavaDoc. So if we just had a comment in the JavaDoc, saying this was fixed, and what to do, that ought to be more than adequate, and would prevent missing it if you didn't see the relnotes. Matthew. From joe.darcy at oracle.com Tue Aug 6 13:25:21 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 06 Aug 2013 20:25:21 +0000 Subject: hg: jdk8/tl/jdk: 8022174: Fix doclint warnings in javax.sound; ... Message-ID: <20130806202538.5AED948628@hg.openjdk.java.net> Changeset: 98643f3ddf40 Author: darcy Date: 2013-08-06 13:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/98643f3ddf40 8022174: Fix doclint warnings in javax.sound 8022404: Fix doclint issues in java.applet Reviewed-by: prr ! src/share/classes/java/applet/AppletContext.java ! src/share/classes/javax/sound/midi/MetaMessage.java ! src/share/classes/javax/sound/midi/MidiDevice.java ! src/share/classes/javax/sound/midi/MidiDeviceReceiver.java ! src/share/classes/javax/sound/midi/MidiDeviceTransmitter.java ! src/share/classes/javax/sound/midi/MidiFileFormat.java ! src/share/classes/javax/sound/midi/MidiMessage.java ! src/share/classes/javax/sound/midi/MidiSystem.java ! src/share/classes/javax/sound/midi/ShortMessage.java ! src/share/classes/javax/sound/midi/Synthesizer.java ! src/share/classes/javax/sound/midi/SysexMessage.java ! src/share/classes/javax/sound/midi/Track.java ! src/share/classes/javax/sound/sampled/AudioFileFormat.java ! src/share/classes/javax/sound/sampled/AudioFormat.java ! src/share/classes/javax/sound/sampled/AudioSystem.java ! src/share/classes/javax/sound/sampled/BooleanControl.java ! src/share/classes/javax/sound/sampled/Mixer.java ! src/share/classes/javax/sound/sampled/spi/FormatConversionProvider.java From stuart.marks at oracle.com Tue Aug 6 13:40:32 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 06 Aug 2013 20:40:32 +0000 Subject: hg: jdk8/tl/jdk: 8022412: Fixed warnings in java.util root, except for HashMap Message-ID: <20130806204046.A790D4862B@hg.openjdk.java.net> Changeset: 12c1b78acf9a Author: lagergren Date: 2013-08-06 12:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/12c1b78acf9a 8022412: Fixed warnings in java.util root, except for HashMap Reviewed-by: mduigou, darcy Contributed-by: marcus.lagergren at oracle.com ! src/share/classes/java/util/ArrayPrefixHelpers.java ! src/share/classes/java/util/Collections.java ! src/share/classes/java/util/Comparator.java ! src/share/classes/java/util/Comparators.java ! src/share/classes/java/util/Hashtable.java ! src/share/classes/java/util/IdentityHashMap.java ! src/share/classes/java/util/Vector.java ! src/share/classes/java/util/WeakHashMap.java From dan.xu at oracle.com Tue Aug 6 14:34:13 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Tue, 06 Aug 2013 21:34:13 +0000 Subject: hg: jdk8/tl/jdk: 8022410: Fix Javac Warnings in com.sun.security.auth Package Message-ID: <20130806213427.3FD5948632@hg.openjdk.java.net> Changeset: 4b8b811059db Author: dxu Date: 2013-08-06 14:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4b8b811059db 8022410: Fix Javac Warnings in com.sun.security.auth Package Reviewed-by: darcy ! src/share/classes/com/sun/security/auth/PolicyFile.java ! src/share/classes/com/sun/security/auth/SubjectCodeSource.java From stuart.marks at oracle.com Tue Aug 6 14:19:57 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Tue, 06 Aug 2013 21:19:57 +0000 Subject: hg: jdk8/tl/jdk: 8022440: suppress deprecation warnings in sun.rmi Message-ID: <20130806212010.B4F394862F@hg.openjdk.java.net> Changeset: 31e923842d49 Author: smarks Date: 2013-08-06 14:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/31e923842d49 8022440: suppress deprecation warnings in sun.rmi Reviewed-by: mduigou ! src/share/classes/sun/rmi/runtime/Log.java ! src/share/classes/sun/rmi/server/ActivatableRef.java ! src/share/classes/sun/rmi/server/Dispatcher.java ! src/share/classes/sun/rmi/server/LoaderHandler.java ! src/share/classes/sun/rmi/server/UnicastRef.java ! src/share/classes/sun/rmi/server/UnicastServerRef.java ! src/share/classes/sun/rmi/server/Util.java ! src/share/classes/sun/rmi/transport/DGCImpl.java ! src/share/classes/sun/rmi/transport/StreamRemoteCall.java ! src/share/classes/sun/rmi/transport/Transport.java ! src/share/classes/sun/rmi/transport/proxy/RMIMasterSocketFactory.java ! src/share/classes/sun/rmi/transport/tcp/ConnectionMultiplexer.java ! src/share/classes/sun/rmi/transport/tcp/TCPTransport.java From joe.darcy at oracle.com Tue Aug 6 16:01:58 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 06 Aug 2013 23:01:58 +0000 Subject: hg: jdk8/tl/jdk: 8022406: Fix doclint issues in java.beans Message-ID: <20130806230214.28DEC48634@hg.openjdk.java.net> Changeset: d5694d78ebc6 Author: darcy Date: 2013-08-06 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d5694d78ebc6 8022406: Fix doclint issues in java.beans Reviewed-by: prr ! src/share/classes/java/beans/AppletInitializer.java ! src/share/classes/java/beans/Beans.java ! src/share/classes/java/beans/ConstructorProperties.java ! src/share/classes/java/beans/DefaultPersistenceDelegate.java ! src/share/classes/java/beans/EventHandler.java ! src/share/classes/java/beans/Expression.java ! src/share/classes/java/beans/IndexedPropertyDescriptor.java ! src/share/classes/java/beans/Introspector.java ! src/share/classes/java/beans/PersistenceDelegate.java ! src/share/classes/java/beans/PropertyChangeSupport.java ! src/share/classes/java/beans/PropertyDescriptor.java ! src/share/classes/java/beans/Transient.java ! src/share/classes/java/beans/VetoableChangeSupport.java ! src/share/classes/java/beans/beancontext/BeanContext.java ! src/share/classes/java/beans/beancontext/BeanContextChild.java ! src/share/classes/java/beans/beancontext/BeanContextChildSupport.java ! src/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java ! src/share/classes/java/beans/beancontext/BeanContextServices.java ! src/share/classes/java/beans/beancontext/BeanContextServicesSupport.java ! src/share/classes/java/beans/beancontext/BeanContextSupport.java From joe.darcy at oracle.com Tue Aug 6 16:45:51 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 06 Aug 2013 23:45:51 +0000 Subject: hg: jdk8/tl/jdk: 8022453: Fix doclint issues in javax.accessibility Message-ID: <20130806234603.A3A9048638@hg.openjdk.java.net> Changeset: 6cc8c2ad9804 Author: darcy Date: 2013-08-06 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cc8c2ad9804 8022453: Fix doclint issues in javax.accessibility Reviewed-by: prr ! src/share/classes/javax/accessibility/Accessible.java ! src/share/classes/javax/accessibility/AccessibleBundle.java ! src/share/classes/javax/accessibility/AccessibleExtendedTable.java ! src/share/classes/javax/accessibility/AccessibleRelationSet.java ! src/share/classes/javax/accessibility/AccessibleTable.java ! src/share/classes/javax/accessibility/AccessibleTableModelChange.java ! src/share/classes/javax/accessibility/AccessibleTextSequence.java ! src/share/classes/javax/accessibility/AccessibleValue.java From lana.steuck at oracle.com Tue Aug 6 17:16:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:51 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130807001653.ECB1B4863C@hg.openjdk.java.net> Changeset: 528c7e76eaee Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/528c7e76eaee Added tag jdk8-b101 for changeset a013024b0747 ! .hgtags Changeset: 342a954b68f3 Author: lana Date: 2013-08-06 16:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/342a954b68f3 Merge From lana.steuck at oracle.com Tue Aug 6 17:16:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:56 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b101 for changeset 60b623a36164 Message-ID: <20130807001701.D5BDD4863E@hg.openjdk.java.net> Changeset: 988a5f2ac559 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/988a5f2ac559 Added tag jdk8-b101 for changeset 60b623a36164 ! .hgtags From lana.steuck at oracle.com Tue Aug 6 17:16:59 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:59 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130807001704.8F0EE4863F@hg.openjdk.java.net> Changeset: 573ccf92d646 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/573ccf92d646 Added tag jdk8-b101 for changeset a302b05d0ee4 ! .hgtags Changeset: e966ff0a3ffe Author: lana Date: 2013-08-06 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e966ff0a3ffe Merge Changeset: ab90c566272d Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/ab90c566272d Merge From lana.steuck at oracle.com Tue Aug 6 17:16:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:56 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130807001706.D504A48640@hg.openjdk.java.net> Changeset: b8cd8b101ecb Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b8cd8b101ecb Added tag jdk8-b101 for changeset 0a7432f898e5 ! .hgtags Changeset: 7cffafa606e9 Author: lana Date: 2013-08-06 10:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/7cffafa606e9 Merge From lana.steuck at oracle.com Tue Aug 6 17:17:23 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:17:23 +0000 Subject: hg: jdk8/tl/hotspot: 61 new changesets Message-ID: <20130807001932.4D8C048642@hg.openjdk.java.net> Changeset: 2285b4a0a4e6 Author: amurillo Date: 2013-07-18 09:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2285b4a0a4e6 8020797: new hotspot build - hs25-b43 Reviewed-by: jcoomes ! make/hotspot_version Changeset: dbc0b5dc08f5 Author: fparain Date: 2013-07-10 15:49 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dbc0b5dc08f5 7143807: ResourceMark nesting problem in stringStream Reviewed-by: kvn, dcubed ! src/share/vm/memory/resourceArea.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/ostream.hpp Changeset: c9a5fab39234 Author: zgu Date: 2013-07-11 13:15 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c9a5fab39234 8012241: NMT huge memory footprint, it usually leads to OOME Summary: Enforce memory limitation on NMT to prevent JVM OOM Reviewed-by: acorn, dcubed, minqi ! src/share/vm/services/memTracker.cpp Changeset: 5f056abe17c6 Author: zgu Date: 2013-07-12 04:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5f056abe17c6 Merge Changeset: 2e8f19c2feef Author: allwin Date: 2013-07-12 18:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/2e8f19c2feef 7162400: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Summary: Intermittent java.io.IOException: Bad file number during HotSpotVirtualMachine.executeCommand Reviewed-by: dcubed, dholmes, sspitsyn, mgerdin, ctornqvi, dsamersoff ! src/os/bsd/vm/attachListener_bsd.cpp ! src/os/linux/vm/attachListener_linux.cpp ! src/os/solaris/vm/attachListener_solaris.cpp ! src/os/windows/vm/attachListener_windows.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/services/attachListener.hpp + test/serviceability/attach/AttachWithStalePidFile.java + test/serviceability/attach/AttachWithStalePidFileTarget.java Changeset: c0cb474be37e Author: ctornqvi Date: 2013-07-12 20:47 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c0cb474be37e Merge Changeset: 862625d214fa Author: fparain Date: 2013-07-15 00:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/862625d214fa Merge Changeset: 23123fc6968a Author: rbackman Date: 2013-07-15 11:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/23123fc6968a 8019324: assert(_f2 == 0 || _f2 == f2) failed: illegal field change Reviewed-by: dholmes, rbackman Contributed-by: David Simms ! src/share/vm/oops/cpCache.hpp Changeset: ee9e76adced3 Author: rbackman Date: 2013-07-15 12:06 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ee9e76adced3 Merge Changeset: 33c52908bcdb Author: dholmes Date: 2013-07-15 23:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33c52908bcdb 8015759: hotspot changes needed to compile with Visual Studio 2012 Reviewed-by: anthony, dholmes, dcubed Contributed-by: Tim Bell ! make/windows/makefiles/compile.make ! make/windows/makefiles/sanity.make ! make/windows/makefiles/vm.make ! src/os_cpu/windows_x86/vm/unwind_windows_x86.hpp Changeset: 39deebbc90b3 Author: mgerdin Date: 2013-07-16 07:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39deebbc90b3 6671508: JNI GetPrimitiveArrayCritical should not be callable on object arrays Summary: Checked JNI now reports error for Get/ReleasePrimitiveArrayCritical on object arrays Reviewed-by: dholmes, acorn Contributed-by: david.simms at oracle.com ! src/share/vm/prims/jniCheck.cpp Changeset: e619a2766bcc Author: rbackman Date: 2013-06-12 11:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e619a2766bcc 8016131: nsk/sysdict/vm/stress/chain tests crash the VM in 'entry_frame_is_first()' Reviewed-by: jrose, kvn, mgronlun ! src/cpu/sparc/vm/frame_sparc.inline.hpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/share/vm/prims/forte.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.hpp ! src/share/vm/runtime/javaCalls.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 732af649bc3a Author: ccheung Date: 2013-07-17 12:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/732af649bc3a 8017498: JVM crashes when native code calls sigaction(sig) where sig>=0x20 Summary: Added (sig < MAXSIGNUM) check in jsig.c Reviewed-by: dholmes, acorn ! src/os/linux/vm/jsig.c + test/runtime/jsig/Test8017498.sh + test/runtime/jsig/TestJNI.c + test/runtime/jsig/TestJNI.java Changeset: 825e6cb66923 Author: jiangli Date: 2013-07-17 18:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/825e6cb66923 8020309: Eliminate InstanceKlass::_cached_class_file_len. Summary: Use JvmtiCachedClassFileData. Reviewed-by: iklam, sspitsyn, dcubed ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/instanceKlass.hpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiExport.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiRedefineClasses.hpp Changeset: 6388dbc4b7ca Author: jiangli Date: 2013-07-17 17:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6388dbc4b7ca Merge Changeset: c29568b733d2 Author: dholmes Date: 2013-07-18 06:47 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c29568b733d2 8020697: jniCheck.cpp:check_is_obj_array asserts on TypeArrayKlass::cast(aOop->klass()) Reviewed-by: dcubed, fparain, dholmes Contributed-by: David Simms ! src/share/vm/prims/jniCheck.cpp Changeset: 5e3b6f79d280 Author: rbackman Date: 2013-07-17 13:48 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e3b6f79d280 8020701: Avoid crashes in WatcherThread Reviewed-by: acorn, dcubed, dsimms ! src/os/posix/vm/os_posix.cpp ! src/os/posix/vm/os_posix.hpp ! src/os/windows/vm/os_windows.cpp ! src/os/windows/vm/os_windows.hpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/mutex.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 248c459b2b75 Author: dcubed Date: 2013-07-18 12:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/248c459b2b75 Merge ! src/share/vm/services/memTracker.cpp Changeset: af21010d1062 Author: dcubed Date: 2013-07-18 12:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/af21010d1062 Merge ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp ! src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/runtime/os.hpp Changeset: 02d7aa1456c9 Author: ccheung Date: 2013-07-18 14:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/02d7aa1456c9 8004872: Early loading of HashMap and StringValue under -XX:+AggressiveOpts can be removed Summary: this fix also removes the -XX:+UseStringCache option Reviewed-by: dholmes, acorn, iklam ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/opto/bytecodeInfo.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp Changeset: 383a5e21cc2d Author: minqi Date: 2013-07-18 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/383a5e21cc2d Merge Changeset: 060ae9b7ffea Author: mgronlun Date: 2013-07-19 17:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/060ae9b7ffea 8020547: Event based tracing needs a UNICODE string type Reviewed-by: egahlin, rbackman, dcubed, brutisso, acorn ! src/share/vm/trace/traceDataTypes.hpp ! src/share/vm/trace/tracetypes.xml ! src/share/vm/trace/xinclude.mod Changeset: 4614a598dae1 Author: minqi Date: 2013-07-19 08:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/4614a598dae1 8016538: volatile double access via Unsafe.cpp is not atomic Summary: volatile jdouble load/store is not atomic, fix by using of existing volatile jlong operations which are atomic for jdouble. Reviewed-by: kvn, vladidan, jrose Contributed-by: david.holmes at oracle.com ! src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp ! src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp ! src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp ! src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp Changeset: 55a61ceb2fe7 Author: minqi Date: 2013-07-19 11:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/55a61ceb2fe7 Merge Changeset: 16511b7e3d35 Author: emc Date: 2013-07-22 17:57 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/16511b7e3d35 8019632: Method parameters are not copied in clone_with_new_data Summary: Add code to copy method parameters data in clone_with_new_data Reviewed-by: coleenp, sspitsyn ! src/share/vm/oops/method.cpp Changeset: 72727c4b6dec Author: ccheung Date: 2013-07-19 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/72727c4b6dec 8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code Summary: Added -DLINUX to the gcc command and improved the .sh script Reviewed-by: dcubed, dholmes, minqi ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 5165d659cebd Author: minqi Date: 2013-07-22 22:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5165d659cebd Merge Changeset: c0f353803b47 Author: minqi Date: 2013-07-23 12:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c0f353803b47 Merge Changeset: c90c698831d7 Author: kvn Date: 2013-07-12 14:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c90c698831d7 8020215: Different execution plan when using JIT vs interpreter Summary: fix bytecode analyzer Reviewed-by: twisti ! src/share/vm/ci/bcEscapeAnalyzer.cpp ! src/share/vm/ci/bcEscapeAnalyzer.hpp + test/compiler/EscapeAnalysis/Test8020215.java Changeset: fcf521c3fbc6 Author: kvn Date: 2013-07-12 14:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fcf521c3fbc6 8007898: Incorrect optimization of Memory Barriers in Matcher::post_store_load_barrier() Summary: generate one "fat" membar instead of set of barriers for volitile store Reviewed-by: roland ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/parse3.cpp + test/compiler/membars/DekkerTest.java Changeset: 34ce0b5acb81 Author: morris Date: 2013-07-15 06:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/34ce0b5acb81 Merge Changeset: 0f57ccdb9084 Author: kvn Date: 2013-07-15 10:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f57ccdb9084 8020433: Crash when using -XX:+RestoreMXCSROnJNICalls Summary: remove StubRoutines::x86::_mxcsr_std and use StubRoutines::_mxcsr_std Reviewed-by: jrose ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.cpp ! src/cpu/x86/vm/stubRoutines_x86_64.hpp + test/compiler/cpuflags/RestoreMXCSR.java Changeset: 46a90f83df31 Author: morris Date: 2013-07-19 13:59 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46a90f83df31 Merge ! src/cpu/x86/vm/stubGenerator_x86_64.cpp Changeset: 6efedc114807 Author: morris Date: 2013-07-24 13:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6efedc114807 Merge Changeset: 01aa164323fa Author: dholmes Date: 2013-07-24 19:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/01aa164323fa 8020799: Allow customization of hotspot source directories and files Reviewed-by: kvn, dlong ! make/linux/makefiles/vm.make Changeset: a4b9a8ec8f4a Author: jiangli Date: 2013-07-25 18:12 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/a4b9a8ec8f4a Merge Changeset: 46487ba40ff2 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/46487ba40ff2 Merge Changeset: f6921c876db1 Author: amurillo Date: 2013-07-26 03:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f6921c876db1 Added tag hs25-b43 for changeset 46487ba40ff2 ! .hgtags Changeset: 7c9885d23744 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7c9885d23744 Added tag jdk8-b101 for changeset f6921c876db1 ! .hgtags Changeset: e84845884c85 Author: amurillo Date: 2013-07-26 04:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e84845884c85 8021566: new hotspot build - hs25-b44 Reviewed-by: jcoomes ! make/hotspot_version Changeset: d90d1b96b65b Author: kvn Date: 2013-07-26 12:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d90d1b96b65b 8008938: TieredCompilation should be default Summary: switch on TieredCompilation by default Reviewed-by: twisti ! src/cpu/sparc/vm/c2_globals_sparc.hpp ! src/cpu/x86/vm/c2_globals_x86.hpp Changeset: 1b6395189726 Author: minqi Date: 2013-07-19 14:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/1b6395189726 8012263: ciReplay: gracefully exit & report meaningful error when replay data parsing fails Summary: find_method could return NULL so need explicitly check if there is error after parse_method, exit on error to avoid crash. Reviewed-by: kvn, twisti Contributed-by: yumin.qi at oracle.com ! src/share/vm/ci/ciReplay.cpp Changeset: 5ad7f8179bf7 Author: minqi Date: 2013-07-24 08:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5ad7f8179bf7 Merge Changeset: b6baf306e698 Author: fparain Date: 2013-07-26 05:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b6baf306e698 Merge Changeset: 83ca9dc4564d Author: fparain Date: 2013-07-26 15:24 +0000 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/83ca9dc4564d 8019845: Memory leak during class redefinition Reviewed-by: acorn, jmasa, coleenp, dcubed, mgerdin ! src/share/vm/memory/metaspace.cpp Changeset: f9ee986a9fea Author: ccheung Date: 2013-07-30 14:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f9ee986a9fea 8021296: [TESTBUG] Test8017498.sh fails to find "gcc" and fails to compile on some Linux releases Summary: Added checking for gcc and simplified the sig_handler() in the test case Reviewed-by: dcubed, coleenp, minqi, dlong ! test/runtime/6929067/Test6929067.sh ! test/runtime/7107135/Test7107135.sh ! test/runtime/jsig/Test8017498.sh ! test/runtime/jsig/TestJNI.c Changeset: 0f98cc013b21 Author: fparain Date: 2013-07-31 08:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f98cc013b21 Merge Changeset: c65045599519 Author: dholmes Date: 2013-07-25 21:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c65045599519 8021314: minimal1.make needs to force off components not supported by the minimal VM Reviewed-by: coleenp, bpittore ! make/bsd/makefiles/minimal1.make ! make/linux/makefiles/minimal1.make Changeset: 078e5eb2e52e Author: clucasius Date: 2013-07-27 17:23 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/078e5eb2e52e Merge Changeset: da839a3c5735 Author: dholmes Date: 2013-07-31 19:05 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/da839a3c5735 Merge Changeset: e3c8767c5cf8 Author: tschatzl Date: 2013-07-24 10:07 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e3c8767c5cf8 8020123: Test gc/g1/TestPrintRegionRememberedSetInfo.java fails with "test result: Error. No action after @build" Summary: Remove the @build tag and replace it by a @run tag so that the test gets executed Reviewed-by: brutisso, mgerdin ! test/gc/g1/TestPrintRegionRememberedSetInfo.java Changeset: 7b06ae405d7b Author: jmasa Date: 2013-07-23 09:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b06ae405d7b 6990419: CMS Remaining work for 6572569: consistently skewed work distribution in (long) re-mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/runtime/globals.hpp Changeset: fb7010c7c011 Author: jmasa Date: 2013-07-25 07:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fb7010c7c011 Merge Changeset: ca9dedeebdec Author: jmasa Date: 2013-07-25 11:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca9dedeebdec 6412968: CMS Long initial mark pauses Reviewed-by: rasbold, tschatzl, jmasa Contributed-by: yamauchi at google.com ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsOopClosures.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/runtime/globals.hpp Changeset: 8796fd3ac898 Author: tamao Date: 2013-07-26 13:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8796fd3ac898 Merge ! src/share/vm/runtime/globals.hpp Changeset: 313227279a05 Author: brutisso Date: 2013-08-01 07:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/313227279a05 8021967: Deprecate -XX:DefaultMaxRAMFraction Reviewed-by: tschatzl, jmasa, kvn, tamao ! src/share/vm/runtime/arguments.cpp + test/gc/startup_warnings/TestDefaultMaxRAMFraction.java Changeset: dae8324fc7d1 Author: brutisso Date: 2013-08-01 09:35 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dae8324fc7d1 8021879: G1: G1HeapRegionSize flag value not updated correctly Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/heapRegion.cpp + test/gc/arguments/TestG1HeapRegionSize.java Changeset: 8d4ff57af591 Author: brutisso Date: 2013-08-01 17:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d4ff57af591 8022051: G1: Remove some unused G1 flags Reviewed-by: tschatzl, jmasa ! src/share/vm/gc_implementation/g1/g1_globals.hpp Changeset: 69d0dbb53c78 Author: tamao Date: 2013-08-01 17:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/69d0dbb53c78 Merge Changeset: 530fe88b3b2c Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/530fe88b3b2c Merge Changeset: c4697c1c4484 Author: amurillo Date: 2013-08-02 02:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c4697c1c4484 Added tag hs25-b44 for changeset 530fe88b3b2c ! .hgtags From lana.steuck at oracle.com Tue Aug 6 17:17:01 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:17:01 +0000 Subject: hg: jdk8/tl/langtools: 4 new changesets Message-ID: <20130807001717.0D2A148641@hg.openjdk.java.net> Changeset: 4c42fba7b0e7 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4c42fba7b0e7 Added tag jdk8-b101 for changeset 0324dbf07b0f ! .hgtags Changeset: 453a305e1165 Author: lana Date: 2013-08-06 10:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/453a305e1165 Merge Changeset: f3ea20a6e958 Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3ea20a6e958 Merge Changeset: b926dc251be8 Author: lana Date: 2013-08-06 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b926dc251be8 Merge From lana.steuck at oracle.com Tue Aug 6 17:19:12 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:19:12 +0000 Subject: hg: jdk8/tl/jdk: 28 new changesets Message-ID: <20130807002511.5A6A848643@hg.openjdk.java.net> Changeset: b52a2ecdb803 Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b52a2ecdb803 Added tag jdk8-b101 for changeset 690161232823 ! .hgtags Changeset: 2978c0a543ed Author: prr Date: 2013-07-22 12:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2978c0a543ed 7196866: CTW fails on all Solaris platforms Reviewed-by: prr, jrose, twisti, kvn ! src/solaris/native/sun/awt/awt_GraphicsEnv.c ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 784589c7bc55 Author: vadim Date: 2013-07-24 13:38 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/784589c7bc55 8008782: NPE in TrueTypeGlyphMapper Reviewed-by: bae, prr ! src/share/classes/sun/font/TrueTypeFont.java Changeset: db2e3a686cf3 Author: jchen Date: 2013-07-24 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/db2e3a686cf3 8011709: [parfait] False positive: memory leak in jdk/src/share/native/sun/font/layout/CanonShaping.cpp Reviewed-by: jgodinez, prr ! src/share/native/sun/font/layout/CanonShaping.cpp Changeset: c2e27e7a42ae Author: jchen Date: 2013-07-24 13:05 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c2e27e7a42ae 8005126: [parfait] #418 - #428 XRBackendNative.c Integer overflow Reviewed-by: prr, vadim ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 833f05116f7b Author: bae Date: 2013-07-25 17:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/833f05116f7b 8019201: Regression: java.awt.image.ConvolveOp throws java.awt.image.ImagingOpException Reviewed-by: prr ! src/share/native/sun/awt/medialib/awt_ImagingLib.c + test/sun/awt/image/ImagingLib/SamePackingTypeTest.java Changeset: a8b9df782017 Author: serb Date: 2013-07-26 21:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a8b9df782017 7190349: [macosx] Text (Label) is incorrectly drawn with a rotated g2d 8013569: [macosx] JLabel preferred size incorrect on retina displays with non-default font size Reviewed-by: prr ! src/macosx/classes/sun/font/CStrike.java ! src/macosx/native/sun/font/AWTStrike.h ! src/macosx/native/sun/font/AWTStrike.m ! src/macosx/native/sun/font/CGGlyphImages.m + test/java/awt/Graphics2D/DrawString/DrawRotatedString.java + test/java/awt/Graphics2D/IncorrectTextSize/IncorrectTextSize.java Changeset: 467a0c21790b Author: jgodinez Date: 2013-07-26 15:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/467a0c21790b 8020208: NullPointerException at sun.print.Win32PrintService.getMediaPrintables Reviewed-by: jchen, prr ! src/windows/classes/sun/print/Win32PrintService.java Changeset: 56c6f9a9653d Author: jgodinez Date: 2013-07-26 15:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/56c6f9a9653d 8016343: [macosx] Print job goes to default printer regardless of chosen printer Reviewed-by: jchen, prr ! src/share/classes/sun/print/PSPrinterJob.java ! src/solaris/classes/sun/print/IPPPrintService.java ! src/solaris/classes/sun/print/UnixPrintJob.java ! test/javax/print/DialogMargins.java Changeset: 1c48544c3da9 Author: lana Date: 2013-07-26 15:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c48544c3da9 Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 921338e44ba7 Author: lana Date: 2013-07-26 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/921338e44ba7 Merge Changeset: 046025f78ea8 Author: jgodinez Date: 2013-07-30 13:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/046025f78ea8 8021835: Fix for 8016343 will not compile on Windows. Reviewed-by: jchen, prr ! src/share/classes/sun/print/PSPrinterJob.java Changeset: 7f0e569c5a66 Author: bae Date: 2013-07-31 13:11 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7f0e569c5a66 8020983: OutOfMemoryError caused by non garbage collected JPEGImageWriter Instances Reviewed-by: prr, flar ! src/share/native/sun/awt/image/jpeg/imageioJPEG.c + test/javax/imageio/plugins/jpeg/JpegWriterLeakTest.java Changeset: 607ad960fe24 Author: malenkov Date: 2013-07-22 15:36 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/607ad960fe24 8019975: closed/javax/swing/JFileChooser/4966171/bug4966171.java throws java.io.NotSerializableException: javax.swing.plaf.basic.BasicFileChooserUI$AcceptAllFileFilter Reviewed-by: alexsch ! src/share/classes/javax/swing/JFileChooser.java Changeset: 3cbe376233a9 Author: malenkov Date: 2013-07-22 20:33 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3cbe376233a9 8015926: NPE when using SynthTreeUI's expandPath() Reviewed-by: alexsch ! src/share/classes/javax/swing/plaf/synth/SynthTreeUI.java + test/javax/swing/plaf/synth/Test8015926.java Changeset: bdad697c03aa Author: pchelko Date: 2013-07-23 13:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bdad697c03aa 7184951: [macosx] Exception at java.awt.datatransfer on headless mode (only in GUI session) Reviewed-by: art, anthony ! src/macosx/classes/sun/lwawt/macosx/CDataTransferer.java Changeset: 99ee6ddab113 Author: serb Date: 2013-07-24 17:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/99ee6ddab113 8017189: [macosx] AWT program menu disabled on Mac Reviewed-by: leonidr, anthony ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java ! src/macosx/native/sun/awt/AWTWindow.h ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CMenuBar.m Changeset: 7bd6eda2d217 Author: leonidr Date: 2013-07-26 16:22 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7bd6eda2d217 8007267: [macosx] com.apple.eawt.Application.setDefaultMenuBar is not working Reviewed-by: anthony, serb ! src/macosx/classes/com/apple/eawt/_AppMenuBarHandler.java ! src/macosx/classes/sun/lwawt/macosx/CMenuComponent.java ! src/macosx/native/sun/awt/AWTWindow.m ! src/macosx/native/sun/awt/CMenuItem.m Changeset: 65c90209edbb Author: lana Date: 2013-07-26 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/65c90209edbb Merge - src/share/classes/com/sun/org/apache/xml/internal/security/resource/log4j.properties - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHereContext.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathAPIHolder.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/CachedXPathFuncHereAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFuncHereAPI.java - src/share/classes/java/util/stream/StreamBuilder.java - src/share/classes/javax/security/auth/callback/package.html - src/share/classes/javax/security/auth/kerberos/package.html - src/share/classes/javax/security/auth/login/package.html - src/share/classes/javax/security/auth/package.html - src/share/classes/javax/security/auth/spi/package.html - src/share/classes/javax/security/auth/x500/package.html - src/share/classes/javax/security/cert/package.html - src/share/classes/javax/security/sasl/package.html - test/java/util/Collections/EmptySortedSet.java Changeset: 37016eaea5d2 Author: serb Date: 2013-07-29 16:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/37016eaea5d2 6230360: Spelling mistake in documentation for AWT: 1.4, 1.5, 1.6, 1.7 Reviewed-by: malenkov, art ! src/share/classes/java/awt/AWTException.java Changeset: bf80c2965a84 Author: malenkov Date: 2013-07-29 18:48 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf80c2965a84 8010782: clean up source files containing carriage return characters Reviewed-by: alexsch, art ! src/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk.properties ! src/share/classes/com/sun/swing/internal/plaf/synth/resources/synth.properties Changeset: 1e482f58c747 Author: ant Date: 2013-07-30 16:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1e482f58c747 8020927: JLightweightFrame API should export layout properties change notifications Reviewed-by: anthony ! src/share/classes/sun/swing/JLightweightFrame.java ! src/share/classes/sun/swing/LightweightContent.java Changeset: 336a94dbecb5 Author: malenkov Date: 2013-07-30 17:46 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/336a94dbecb5 8015300: JComboBox text sometimes become selected, sometimes not (Windows LAF) Reviewed-by: alexsch, serb ! src/share/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java + test/javax/swing/JComboBox/8015300/Test8015300.java Changeset: 726ac8f75b54 Author: lana Date: 2013-07-31 12:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/726ac8f75b54 Merge Changeset: 0741b19835b0 Author: lana Date: 2013-07-31 13:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0741b19835b0 Merge - src/share/classes/java/net/package.html Changeset: 8ed8e2b4b90e Author: lana Date: 2013-08-06 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8ed8e2b4b90e Merge Changeset: 2bc9ce1aade5 Author: lana Date: 2013-08-06 17:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2bc9ce1aade5 Merge Changeset: 7ab5f19a9a31 Author: lana Date: 2013-08-06 17:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7ab5f19a9a31 Merge From lana.steuck at oracle.com Tue Aug 6 17:16:51 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 07 Aug 2013 00:16:51 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b101 for changeset 9f74a220677d Message-ID: <20130807001651.B35284863B@hg.openjdk.java.net> Changeset: 5eb3c1dc348f Author: cl Date: 2013-08-01 04:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/5eb3c1dc348f Added tag jdk8-b101 for changeset 9f74a220677d ! .hgtags From dan.xu at oracle.com Tue Aug 6 17:57:20 2013 From: dan.xu at oracle.com (Dan Xu) Date: Tue, 06 Aug 2013 17:57:20 -0700 Subject: RFR:JDK-8022478 - Fix Warnings In sun.net.www.protocol.http Package Message-ID: <52019B70.807@oracle.com> Hi All, Please review the [serial] warning fix inside sun.net.www.protocol.http package. Webrev: http://cr.openjdk.java.net/~dxu/8022478/webrev/ Thanks, -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130806/a790d735/attachment.html From joe.darcy at oracle.com Tue Aug 6 18:01:08 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 06 Aug 2013 18:01:08 -0700 Subject: RFR:JDK-8022478 - Fix Warnings In sun.net.www.protocol.http Package In-Reply-To: <52019B70.807@oracle.com> References: <52019B70.807@oracle.com> Message-ID: <52019C54.6070103@oracle.com> Hi Dan, As we discussed in person, since you are adding serial version uid that matches the existing type, this is fine. Approved to go back. Thanks, -Joe On 08/06/2013 05:57 PM, Dan Xu wrote: > Hi All, > > Please review the [serial] warning fix inside > sun.net.www.protocol.http package. > > Webrev: http://cr.openjdk.java.net/~dxu/8022478/webrev/ > > Thanks, > > -Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130806/014fd5bb/attachment.html From dan.xu at oracle.com Tue Aug 6 18:16:57 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 07 Aug 2013 01:16:57 +0000 Subject: hg: jdk8/tl/jdk: 8022478: Fix Warnings In sun.net.www.protocol.http Package Message-ID: <20130807011708.86F7148645@hg.openjdk.java.net> Changeset: 1d21ff5c2b3f Author: dxu Date: 2013-08-06 18:16 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d21ff5c2b3f 8022478: Fix Warnings In sun.net.www.protocol.http Package Reviewed-by: darcy ! src/share/classes/sun/net/www/protocol/http/AuthCacheValue.java ! src/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java From mike.duigou at oracle.com Tue Aug 6 18:21:43 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 07 Aug 2013 01:21:43 +0000 Subject: hg: jdk8/tl/jdk: 8022476: cleanup some raw types and unchecked warnings in java.util.stream Message-ID: <20130807012155.28BBF48646@hg.openjdk.java.net> Changeset: e117fcdd2176 Author: mduigou Date: 2013-08-06 18:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e117fcdd2176 8022476: cleanup some raw types and unchecked warnings in java.util.stream Reviewed-by: darcy Contributed-by: mike.duigou at oracle.com, henry.jen at oracle.com ! src/share/classes/java/util/Optional.java ! src/share/classes/java/util/stream/AbstractPipeline.java ! src/share/classes/java/util/stream/AbstractShortCircuitTask.java ! src/share/classes/java/util/stream/DoublePipeline.java ! src/share/classes/java/util/stream/IntPipeline.java ! src/share/classes/java/util/stream/LongPipeline.java ! src/share/classes/java/util/stream/Nodes.java ! src/share/classes/java/util/stream/ReduceOps.java ! src/share/classes/java/util/stream/ReferencePipeline.java ! src/share/classes/java/util/stream/Sink.java ! src/share/classes/java/util/stream/SortedOps.java ! src/share/classes/java/util/stream/StreamSpliterators.java From vicente.romero at oracle.com Wed Aug 7 02:41:49 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 07 Aug 2013 09:41:49 +0000 Subject: hg: jdk8/tl/langtools: 8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations Message-ID: <20130807094204.96FBC48665@hg.openjdk.java.net> Changeset: f3deeccbf4cf Author: vromero Date: 2013-08-07 10:41 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f3deeccbf4cf 8020997: TreeMaker.AnnotationBuilder creates broken element literals with repeating annotations Reviewed-by: jjg, jfranck ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java + test/tools/javac/T8020997/CannotCompileRepeatedAnnoTest.java From vicente.romero at oracle.com Wed Aug 7 03:11:08 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 07 Aug 2013 10:11:08 +0000 Subject: hg: jdk8/tl/langtools: 8008274: javac should not reference/use sample code Message-ID: <20130807101110.F276C48668@hg.openjdk.java.net> Changeset: c7dcf899ffff Author: vromero Date: 2013-08-07 11:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c7dcf899ffff 8008274: javac should not reference/use sample code Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/Main.java From weijun.wang at oracle.com Wed Aug 7 04:07:15 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Wed, 07 Aug 2013 11:07:15 +0000 Subject: hg: jdk8/tl/jdk: 7151062: [macosx] SCDynamicStore prints error messages to stderr Message-ID: <20130807110825.4E6F348669@hg.openjdk.java.net> Changeset: 906dd23334c1 Author: weijun Date: 2013-08-07 19:06 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/906dd23334c1 7151062: [macosx] SCDynamicStore prints error messages to stderr Reviewed-by: xuelei ! src/macosx/native/java/util/SCDynamicStoreConfig.m From xuelei.fan at oracle.com Wed Aug 7 05:44:15 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 07 Aug 2013 20:44:15 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <520133C7.20401@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> Message-ID: <5202411F.2010706@oracle.com> On 8/7/2013 12:06 AM, Matthew Hall wrote: > Trailing dots are allowed in plain DNS (thus almost surely in IDN), > and the single dot represents the root zone. So you have to be > careful making this sort of change to check the DNS RFCs first. That's the first question we need to answer, whether IDN allow tailling dots ("com."), zero-length root label ("."), and zero-length label ("", for example ""example..com")? Per the specification of IDN.toASCII(): ======================================= "ToASCII operation can fail. ToASCII fails if any step of it fails. If ToASCII operation fails, an IllegalArgumentException will be thrown. In this case, the input string should not be used in an internationalized domain name. A label is an individual part of a domain name. The original ToASCII operation, as defined in RFC 3490, only operates on a single label. This method can handle both label and entire domain name, by assuming that labels in a domain name are always separated by dots. ... Throws IllegalArgumentException - if the input string doesn't conform to RFC 3490 specification" Per the specification of RFC 3490: ================================== [section 2] "A label is an individual part of a domain name. Labels are usually shown separated by dots; for example, the domain name "www.example.com" is composed of three labels: "www", "example", and "com". (The zero-length root label described in [STD13], which can be explicit as in "www.example.com." or implicit as in "www.example.com", is not considered a label in this specification.)" "An "internationalized label" is a label to which the ToASCII operation (see section 4) can be applied without failing (with the UseSTD3ASCIIRules flag unset). ... Although most Unicode characters can appear in internationalized labels, ToASCII will fail for some input strings, and such strings are not valid internationalized labels." "An "internationalized domain name" (IDN) is a domain name in which every label is an internationalized label." [Section 4.1] "ToASCII consists of the following steps: ... 8. Verify that the number of code points is in the range 1 to 63 inclusive." Here are the questions: 1. whether "example..com" is an valid IDN? As dot is used as label separators, there are three labels, "example", "", "com". Per RFC 3490, "" is not a valid label. Hence, "example..com" is not a valid IDN. We need to address the issue in IDN. 2. whether "xyz." is an valid IDN? It's an gray area, I think. We can treat the trailing "." as root label, or a label separator. If the trailing "." is treated as label separator, "xyz." is invalid per RFC 3490. if the trailing "." is treated as root label, what's the expected return value of IDN.toASCII("xyz.")? I think the return value can be either "xyz." or "xyz". The current implementation returns "xyz". We may need not to update the implementation if tailing "." is treated as root label. 3. whether "." is an valid IDN? It's an gray area again, I think. As above, if the trailing "." is treated as root label, I think the return value can be either "." or "". The current implementation throws a StringIndexOutOfBoundsException. However, what empty domain name ("") really means? I would prefer to return "." for "." instead. We need to address the issue in IDN. Here comes the solution, the IDN.toASCII() returns: 1. "." for "."; 2. "xyz" for "xyz."; 3. IAE for "example..com". Does it make sense? Thanks, Xuelei On 8/7/2013 1:35 AM, Michael McMahon wrote: > I don't really understand the reason for the restriction in SNIHostName > But, I guess that is where it should be enforced if it is required. > > Michael. > > On 06/08/13 17:43, Dmitry Samersoff wrote: >> Xuelei, >> >> . (dot) is perfectly valid domain name and it means root domain so com. >> is valid domain name as well. >> >> It thinks to me that in context of methods your change we should ignore >> trailing dots, rather than throw exception. >> >> -Dmitry >> >> >> >> On 2013-08-06 15:44, Xuelei Fan wrote: >>> Hi, >>> >>> Please review the bug fix to strict the illegal input checking in IDN. >>> >>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >>> >>> Here is two test cases, which are expected to get IAE. >>> >>> Case 1: >>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >>> String index out of range: 0 >>> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >>> at java.net.IDN.toASCIIInternal(IDN.java:279) >>> at java.net.IDN.toASCII(IDN.java:118) >>> >>> Case 2: >>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >>> >>> Thanks, >>> Xuelei >>> >> > From dmitry.samersoff at oracle.com Wed Aug 7 06:10:23 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 07 Aug 2013 17:10:23 +0400 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5202411F.2010706@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> Message-ID: <5202473F.70808@oracle.com> Xuelei, root label is an empty label[1], dot is a label separator, so in printed form domain names is dot-terminated. Please see also below inline. [1] RFC rfc1034.txt: Internally, programs that manipulate domain names should represent them as sequences of labels, where each label is a length octet followed by an octet string. Because all domain names end at the root, *which has a null string for a label*, these internal representations can use a length byte of zero to terminate a domain name. On 2013-08-07 16:44, Xuelei Fan wrote: > On 8/7/2013 12:06 AM, Matthew Hall wrote: >> Trailing dots are allowed in plain DNS (thus almost surely in IDN), >> and the single dot represents the root zone. So you have to be >> careful making this sort of change to check the DNS RFCs first. > > That's the first question we need to answer, whether IDN allow tailling > dots ("com."), zero-length root label ("."), and zero-length label ("", > for example ""example..com")? > > Per the specification of IDN.toASCII(): > ======================================= > "ToASCII operation can fail. ToASCII fails if any step of it fails. If > ToASCII operation fails, an IllegalArgumentException will be thrown. In > this case, the input string should not be used in an internationalized > domain name. > > A label is an individual part of a domain name. The original ToASCII > operation, as defined in RFC 3490, only operates on a single label. This > method can handle both label and entire domain name, by assuming that > labels in a domain name are always separated by dots. ... > > Throws IllegalArgumentException - if the input string doesn't conform to > RFC 3490 specification" > > Per the specification of RFC 3490: > ================================== > [section 2] > "A label is an individual part of a domain name. Labels are usually > shown separated by dots; for example, the domain name > "www.example.com" is composed of three labels: "www", "example", and > "com". (The zero-length root label described in [STD13], which can > be explicit as in "www.example.com." or implicit as in > "www.example.com", is not considered a label in this specification.)" > > "An "internationalized label" is a label to which the ToASCII > operation (see section 4) can be applied without failing (with the > UseSTD3ASCIIRules flag unset). ... > Although most Unicode characters can appear in > internationalized labels, ToASCII will fail for some input strings, > and such strings are not valid internationalized labels." > > "An "internationalized domain name" (IDN) is a domain name in which > every label is an internationalized label." > > [Section 4.1] > "ToASCII consists of the following steps: > > ... > > 8. Verify that the number of code points is in the range 1 to 63 > inclusive." > > > Here are the questions: > 1. whether "example..com" is an valid IDN? > As dot is used as label separators, there are three labels, > "example", "", "com". Per RFC 3490, "" is not a valid label. Hence, > "example..com" is not a valid IDN. > > We need to address the issue in IDN. Root label can't appear in the middle of domain name, so example..com is an invalid domain name and appropriate exception have to be thrown. > > 2. whether "xyz." is an valid IDN? > It's an gray area, I think. We can treat the trailing "." as root > label, or a label separator. > If the trailing "." is treated as label separator, "xyz." is invalid > per RFC 3490. > if the trailing "." is treated as root label, what's the expected > return value of IDN.toASCII("xyz.")? I think the return value can be > either "xyz." or "xyz". The current implementation returns "xyz". > > We may need not to update the implementation if tailing "." is > treated as root label. Empty label at the end of domain names is valid per RFC 1034 and means root label. So we should process this name and return all non-empty labels. > 3. whether "." is an valid IDN? > It's an gray area again, I think. > As above, if the trailing "." is treated as root label, I think the > return value can be either "." or "". The current implementation throws > a StringIndexOutOfBoundsException. > > However, what empty domain name ("") really means? I would prefer to > return "." for "." instead. > > We need to address the issue in IDN. As dot is a label separator and root (empty) label can't appear in the middle of domain name, . (dot) is not valid name and this case is similar to case (1) - we should throw an appropriate exception. -Dmitry > > Here comes the solution, the IDN.toASCII() returns: > 1. "." for "."; > 2. "xyz" for "xyz."; > 3. IAE for "example..com". > > Does it make sense? > > Thanks, > Xuelei > > > On 8/7/2013 1:35 AM, Michael McMahon wrote: >> I don't really understand the reason for the restriction in SNIHostName >> But, I guess that is where it should be enforced if it is required. >> >> Michael. >> >> On 06/08/13 17:43, Dmitry Samersoff wrote: >>> Xuelei, >>> >>> . (dot) is perfectly valid domain name and it means root domain so com. >>> is valid domain name as well. >>> >>> It thinks to me that in context of methods your change we should ignore >>> trailing dots, rather than throw exception. >>> >>> -Dmitry >>> >>> >>> >>> On 2013-08-06 15:44, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review the bug fix to strict the illegal input checking in IDN. >>>> >>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >>>> >>>> Here is two test cases, which are expected to get IAE. >>>> >>>> Case 1: >>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >>>> String index out of range: 0 >>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >>>> at java.net.IDN.toASCIIInternal(IDN.java:279) >>>> at java.net.IDN.toASCII(IDN.java:118) >>>> >>>> Case 2: >>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >>>> >>>> Thanks, >>>> Xuelei >>>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From xuelei.fan at oracle.com Wed Aug 7 06:43:10 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Wed, 07 Aug 2013 13:43:10 +0000 Subject: hg: jdk8/tl/jdk: 8013809: deadlock in SSLSocketImpl between between write and close Message-ID: <20130807134325.C4A2E48679@hg.openjdk.java.net> Changeset: 8c7cf4926157 Author: xuelei Date: 2013-08-07 06:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c7cf4926157 8013809: deadlock in SSLSocketImpl between between write and close Reviewed-by: wetmore ! src/share/classes/sun/security/ssl/SSLSocketImpl.java From michael.x.mcmahon at oracle.com Wed Aug 7 07:05:40 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 07 Aug 2013 15:05:40 +0100 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5202411F.2010706@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> Message-ID: <52025434.8070200@oracle.com> Resolvers seem to accept queries using trailing dots. eg nslookup www.oracle.com. or InetAddress.getByName("www.oracle.com."); The part of RFC3490 quoted below seems to me to be saying that the empty label implied by the trailing dot is not regarded as a label so that you don't end up calling toAscii() or toUnicode() with an empty string. I don't think it's saying the trailing dot can't be there. Michael On 07/08/13 13:44, Xuelei Fan wrote: > On 8/7/2013 12:06 AM, Matthew Hall wrote: >> Trailing dots are allowed in plain DNS (thus almost surely in IDN), >> and the single dot represents the root zone. So you have to be >> careful making this sort of change to check the DNS RFCs first. > That's the first question we need to answer, whether IDN allow tailling > dots ("com."), zero-length root label ("."), and zero-length label ("", > for example ""example..com")? > > Per the specification of IDN.toASCII(): > ======================================= > "ToASCII operation can fail. ToASCII fails if any step of it fails. If > ToASCII operation fails, an IllegalArgumentException will be thrown. In > this case, the input string should not be used in an internationalized > domain name. > > A label is an individual part of a domain name. The original ToASCII > operation, as defined in RFC 3490, only operates on a single label. This > method can handle both label and entire domain name, by assuming that > labels in a domain name are always separated by dots. ... > > Throws IllegalArgumentException - if the input string doesn't conform to > RFC 3490 specification" > > Per the specification of RFC 3490: > ================================== > [section 2] > "A label is an individual part of a domain name. Labels are usually > shown separated by dots; for example, the domain name > "www.example.com" is composed of three labels: "www", "example", and > "com". (The zero-length root label described in [STD13], which can > be explicit as in "www.example.com." or implicit as in > "www.example.com", is not considered a label in this specification.)" > > "An "internationalized label" is a label to which the ToASCII > operation (see section 4) can be applied without failing (with the > UseSTD3ASCIIRules flag unset). ... > Although most Unicode characters can appear in > internationalized labels, ToASCII will fail for some input strings, > and such strings are not valid internationalized labels." > > "An "internationalized domain name" (IDN) is a domain name in which > every label is an internationalized label." > > [Section 4.1] > "ToASCII consists of the following steps: > > ... > > 8. Verify that the number of code points is in the range 1 to 63 > inclusive." > > > Here are the questions: > 1. whether "example..com" is an valid IDN? > As dot is used as label separators, there are three labels, > "example", "", "com". Per RFC 3490, "" is not a valid label. Hence, > "example..com" is not a valid IDN. > > We need to address the issue in IDN. > > 2. whether "xyz." is an valid IDN? > It's an gray area, I think. We can treat the trailing "." as root > label, or a label separator. > If the trailing "." is treated as label separator, "xyz." is invalid > per RFC 3490. > if the trailing "." is treated as root label, what's the expected > return value of IDN.toASCII("xyz.")? I think the return value can be > either "xyz." or "xyz". The current implementation returns "xyz". > > We may need not to update the implementation if tailing "." is > treated as root label. > > 3. whether "." is an valid IDN? > It's an gray area again, I think. > As above, if the trailing "." is treated as root label, I think the > return value can be either "." or "". The current implementation throws > a StringIndexOutOfBoundsException. > > However, what empty domain name ("") really means? I would prefer to > return "." for "." instead. > > We need to address the issue in IDN. > > > Here comes the solution, the IDN.toASCII() returns: > 1. "." for "."; > 2. "xyz" for "xyz."; > 3. IAE for "example..com". > > Does it make sense? > > Thanks, > Xuelei > > > On 8/7/2013 1:35 AM, Michael McMahon wrote: >> I don't really understand the reason for the restriction in SNIHostName >> But, I guess that is where it should be enforced if it is required. >> >> Michael. >> >> On 06/08/13 17:43, Dmitry Samersoff wrote: >>> Xuelei, >>> >>> . (dot) is perfectly valid domain name and it means root domain so com. >>> is valid domain name as well. >>> >>> It thinks to me that in context of methods your change we should ignore >>> trailing dots, rather than throw exception. >>> >>> -Dmitry >>> >>> >>> >>> On 2013-08-06 15:44, Xuelei Fan wrote: >>>> Hi, >>>> >>>> Please review the bug fix to strict the illegal input checking in IDN. >>>> >>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >>>> >>>> Here is two test cases, which are expected to get IAE. >>>> >>>> Case 1: >>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >>>> String index out of range: 0 >>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >>>> at java.net.IDN.toASCIIInternal(IDN.java:279) >>>> at java.net.IDN.toASCII(IDN.java:118) >>>> >>>> Case 2: >>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >>>> >>>> Thanks, >>>> Xuelei >>>> From xuelei.fan at oracle.com Wed Aug 7 07:13:46 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 07 Aug 2013 22:13:46 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52025434.8070200@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> Message-ID: <5202561A.5040908@oracle.com> On 8/7/2013 10:05 PM, Michael McMahon wrote: > Resolvers seem to accept queries using trailing dots. > > eg nslookup www.oracle.com. > > or InetAddress.getByName("www.oracle.com."); > > The part of RFC3490 quoted below seems to me to be saying > that the empty label implied by the trailing dot is not regarded > as a label so that you don't end up calling toAscii() or toUnicode() > with an empty string. I don't think it's saying the trailing dot can't > be there. > It makes sense. What's your preference to return for IDN.toASCII("www.oracle.com."), "www.oracle.com." or "www.oracle.com"? The current returned value is "www.oracle.com". I would like to reserve the behavior in this update. I think we are on same page soon. Thanks, Xuelei > Michael > > On 07/08/13 13:44, Xuelei Fan wrote: >> On 8/7/2013 12:06 AM, Matthew Hall wrote: >>> Trailing dots are allowed in plain DNS (thus almost surely in IDN), >>> and the single dot represents the root zone. So you have to be >>> careful making this sort of change to check the DNS RFCs first. >> That's the first question we need to answer, whether IDN allow tailling >> dots ("com."), zero-length root label ("."), and zero-length label ("", >> for example ""example..com")? >> >> Per the specification of IDN.toASCII(): >> ======================================= >> "ToASCII operation can fail. ToASCII fails if any step of it fails. If >> ToASCII operation fails, an IllegalArgumentException will be thrown. In >> this case, the input string should not be used in an internationalized >> domain name. >> >> A label is an individual part of a domain name. The original ToASCII >> operation, as defined in RFC 3490, only operates on a single label. This >> method can handle both label and entire domain name, by assuming that >> labels in a domain name are always separated by dots. ... >> >> Throws IllegalArgumentException - if the input string doesn't conform to >> RFC 3490 specification" >> >> Per the specification of RFC 3490: >> ================================== >> [section 2] >> "A label is an individual part of a domain name. Labels are usually >> shown separated by dots; for example, the domain name >> "www.example.com" is composed of three labels: "www", "example", and >> "com". (The zero-length root label described in [STD13], which can >> be explicit as in "www.example.com." or implicit as in >> "www.example.com", is not considered a label in this specification.)" >> >> "An "internationalized label" is a label to which the ToASCII >> operation (see section 4) can be applied without failing (with the >> UseSTD3ASCIIRules flag unset). ... >> Although most Unicode characters can appear in >> internationalized labels, ToASCII will fail for some input strings, >> and such strings are not valid internationalized labels." >> >> "An "internationalized domain name" (IDN) is a domain name in which >> every label is an internationalized label." >> >> [Section 4.1] >> "ToASCII consists of the following steps: >> >> ... >> >> 8. Verify that the number of code points is in the range 1 to 63 >> inclusive." >> >> >> Here are the questions: >> 1. whether "example..com" is an valid IDN? >> As dot is used as label separators, there are three labels, >> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence, >> "example..com" is not a valid IDN. >> >> We need to address the issue in IDN. >> >> 2. whether "xyz." is an valid IDN? >> It's an gray area, I think. We can treat the trailing "." as root >> label, or a label separator. >> If the trailing "." is treated as label separator, "xyz." is invalid >> per RFC 3490. >> if the trailing "." is treated as root label, what's the expected >> return value of IDN.toASCII("xyz.")? I think the return value can be >> either "xyz." or "xyz". The current implementation returns "xyz". >> >> We may need not to update the implementation if tailing "." is >> treated as root label. >> >> 3. whether "." is an valid IDN? >> It's an gray area again, I think. >> As above, if the trailing "." is treated as root label, I think the >> return value can be either "." or "". The current implementation throws >> a StringIndexOutOfBoundsException. >> >> However, what empty domain name ("") really means? I would prefer to >> return "." for "." instead. >> >> We need to address the issue in IDN. >> >> >> Here comes the solution, the IDN.toASCII() returns: >> 1. "." for "."; >> 2. "xyz" for "xyz."; >> 3. IAE for "example..com". >> >> Does it make sense? >> >> Thanks, >> Xuelei >> >> >> On 8/7/2013 1:35 AM, Michael McMahon wrote: >>> I don't really understand the reason for the restriction in SNIHostName >>> But, I guess that is where it should be enforced if it is required. >>> >>> Michael. >>> >>> On 06/08/13 17:43, Dmitry Samersoff wrote: >>>> Xuelei, >>>> >>>> . (dot) is perfectly valid domain name and it means root domain so com. >>>> is valid domain name as well. >>>> >>>> It thinks to me that in context of methods your change we should ignore >>>> trailing dots, rather than throw exception. >>>> >>>> -Dmitry >>>> >>>> >>>> >>>> On 2013-08-06 15:44, Xuelei Fan wrote: >>>>> Hi, >>>>> >>>>> Please review the bug fix to strict the illegal input checking in IDN. >>>>> >>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >>>>> >>>>> Here is two test cases, which are expected to get IAE. >>>>> >>>>> Case 1: >>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >>>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >>>>> String index out of range: 0 >>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >>>>> at java.net.IDN.toASCIIInternal(IDN.java:279) >>>>> at java.net.IDN.toASCII(IDN.java:118) >>>>> >>>>> Case 2: >>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> > From michael.x.mcmahon at oracle.com Wed Aug 7 07:18:14 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 07 Aug 2013 15:18:14 +0100 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5202561A.5040908@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> Message-ID: <52025726.8060203@oracle.com> On 07/08/13 15:13, Xuelei Fan wrote: > On 8/7/2013 10:05 PM, Michael McMahon wrote: >> Resolvers seem to accept queries using trailing dots. >> >> eg nslookup www.oracle.com. >> >> or InetAddress.getByName("www.oracle.com."); >> >> The part of RFC3490 quoted below seems to me to be saying >> that the empty label implied by the trailing dot is not regarded >> as a label so that you don't end up calling toAscii() or toUnicode() >> with an empty string. I don't think it's saying the trailing dot can't >> be there. >> > It makes sense. > > What's your preference to return for IDN.toASCII("www.oracle.com."), > "www.oracle.com." or "www.oracle.com"? The current returned value is > "www.oracle.com". I would like to reserve the behavior in this update. My opinion is to keep it as at present ie. "www.oracle.com." Michael > I think we are on same page soon. > > Thanks, > Xuelei > >> Michael >> >> On 07/08/13 13:44, Xuelei Fan wrote: >>> On 8/7/2013 12:06 AM, Matthew Hall wrote: >>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN), >>>> and the single dot represents the root zone. So you have to be >>>> careful making this sort of change to check the DNS RFCs first. >>> That's the first question we need to answer, whether IDN allow tailling >>> dots ("com."), zero-length root label ("."), and zero-length label ("", >>> for example ""example..com")? >>> >>> Per the specification of IDN.toASCII(): >>> ======================================= >>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If >>> ToASCII operation fails, an IllegalArgumentException will be thrown. In >>> this case, the input string should not be used in an internationalized >>> domain name. >>> >>> A label is an individual part of a domain name. The original ToASCII >>> operation, as defined in RFC 3490, only operates on a single label. This >>> method can handle both label and entire domain name, by assuming that >>> labels in a domain name are always separated by dots. ... >>> >>> Throws IllegalArgumentException - if the input string doesn't conform to >>> RFC 3490 specification" >>> >>> Per the specification of RFC 3490: >>> ================================== >>> [section 2] >>> "A label is an individual part of a domain name. Labels are usually >>> shown separated by dots; for example, the domain name >>> "www.example.com" is composed of three labels: "www", "example", and >>> "com". (The zero-length root label described in [STD13], which can >>> be explicit as in "www.example.com." or implicit as in >>> "www.example.com", is not considered a label in this specification.)" >>> >>> "An "internationalized label" is a label to which the ToASCII >>> operation (see section 4) can be applied without failing (with the >>> UseSTD3ASCIIRules flag unset). ... >>> Although most Unicode characters can appear in >>> internationalized labels, ToASCII will fail for some input strings, >>> and such strings are not valid internationalized labels." >>> >>> "An "internationalized domain name" (IDN) is a domain name in which >>> every label is an internationalized label." >>> >>> [Section 4.1] >>> "ToASCII consists of the following steps: >>> >>> ... >>> >>> 8. Verify that the number of code points is in the range 1 to 63 >>> inclusive." >>> >>> >>> Here are the questions: >>> 1. whether "example..com" is an valid IDN? >>> As dot is used as label separators, there are three labels, >>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence, >>> "example..com" is not a valid IDN. >>> >>> We need to address the issue in IDN. >>> >>> 2. whether "xyz." is an valid IDN? >>> It's an gray area, I think. We can treat the trailing "." as root >>> label, or a label separator. >>> If the trailing "." is treated as label separator, "xyz." is invalid >>> per RFC 3490. >>> if the trailing "." is treated as root label, what's the expected >>> return value of IDN.toASCII("xyz.")? I think the return value can be >>> either "xyz." or "xyz". The current implementation returns "xyz". >>> >>> We may need not to update the implementation if tailing "." is >>> treated as root label. >>> >>> 3. whether "." is an valid IDN? >>> It's an gray area again, I think. >>> As above, if the trailing "." is treated as root label, I think the >>> return value can be either "." or "". The current implementation throws >>> a StringIndexOutOfBoundsException. >>> >>> However, what empty domain name ("") really means? I would prefer to >>> return "." for "." instead. >>> >>> We need to address the issue in IDN. >>> >>> >>> Here comes the solution, the IDN.toASCII() returns: >>> 1. "." for "."; >>> 2. "xyz" for "xyz."; >>> 3. IAE for "example..com". >>> >>> Does it make sense? >>> >>> Thanks, >>> Xuelei >>> >>> >>> On 8/7/2013 1:35 AM, Michael McMahon wrote: >>>> I don't really understand the reason for the restriction in SNIHostName >>>> But, I guess that is where it should be enforced if it is required. >>>> >>>> Michael. >>>> >>>> On 06/08/13 17:43, Dmitry Samersoff wrote: >>>>> Xuelei, >>>>> >>>>> . (dot) is perfectly valid domain name and it means root domain so com. >>>>> is valid domain name as well. >>>>> >>>>> It thinks to me that in context of methods your change we should ignore >>>>> trailing dots, rather than throw exception. >>>>> >>>>> -Dmitry >>>>> >>>>> >>>>> >>>>> On 2013-08-06 15:44, Xuelei Fan wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the bug fix to strict the illegal input checking in IDN. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >>>>>> >>>>>> Here is two test cases, which are expected to get IAE. >>>>>> >>>>>> Case 1: >>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >>>>>> Exception in thread "main" java.lang.StringIndexOutOfBoundsException: >>>>>> String index out of range: 0 >>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279) >>>>>> at java.net.IDN.toASCII(IDN.java:118) >>>>>> >>>>>> Case 2: >>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> From xuelei.fan at oracle.com Wed Aug 7 08:17:05 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 07 Aug 2013 23:17:05 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52025726.8060203@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> Message-ID: <520264F1.1090802@oracle.com> Please review the new update: http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ With this update, "com." is valid (return "com."); "." and "example..com" are invalid. And IAE will be thrown for invalid IDN. Thanks, Xuelei On 8/7/2013 10:18 PM, Michael McMahon wrote: > On 07/08/13 15:13, Xuelei Fan wrote: >> On 8/7/2013 10:05 PM, Michael McMahon wrote: >>> Resolvers seem to accept queries using trailing dots. >>> >>> eg nslookup www.oracle.com. >>> >>> or InetAddress.getByName("www.oracle.com."); >>> >>> The part of RFC3490 quoted below seems to me to be saying >>> that the empty label implied by the trailing dot is not regarded >>> as a label so that you don't end up calling toAscii() or toUnicode() >>> with an empty string. I don't think it's saying the trailing dot can't >>> be there. >>> >> It makes sense. >> >> What's your preference to return for IDN.toASCII("www.oracle.com."), >> "www.oracle.com." or "www.oracle.com"? The current returned value is >> "www.oracle.com". I would like to reserve the behavior in this update. > > My opinion is to keep it as at present ie. "www.oracle.com." > > Michael > >> I think we are on same page soon. >> >> Thanks, >> Xuelei >> >>> Michael >>> >>> On 07/08/13 13:44, Xuelei Fan wrote: >>>> On 8/7/2013 12:06 AM, Matthew Hall wrote: >>>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN), >>>>> and the single dot represents the root zone. So you have to be >>>>> careful making this sort of change to check the DNS RFCs first. >>>> That's the first question we need to answer, whether IDN allow tailling >>>> dots ("com."), zero-length root label ("."), and zero-length label ("", >>>> for example ""example..com")? >>>> >>>> Per the specification of IDN.toASCII(): >>>> ======================================= >>>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If >>>> ToASCII operation fails, an IllegalArgumentException will be thrown. In >>>> this case, the input string should not be used in an internationalized >>>> domain name. >>>> >>>> A label is an individual part of a domain name. The original ToASCII >>>> operation, as defined in RFC 3490, only operates on a single label. >>>> This >>>> method can handle both label and entire domain name, by assuming that >>>> labels in a domain name are always separated by dots. ... >>>> >>>> Throws IllegalArgumentException - if the input string doesn't >>>> conform to >>>> RFC 3490 specification" >>>> >>>> Per the specification of RFC 3490: >>>> ================================== >>>> [section 2] >>>> "A label is an individual part of a domain name. Labels are usually >>>> shown separated by dots; for example, the domain name >>>> "www.example.com" is composed of three labels: "www", "example", and >>>> "com". (The zero-length root label described in [STD13], which can >>>> be explicit as in "www.example.com." or implicit as in >>>> "www.example.com", is not considered a label in this >>>> specification.)" >>>> >>>> "An "internationalized label" is a label to which the ToASCII >>>> operation (see section 4) can be applied without failing (with the >>>> UseSTD3ASCIIRules flag unset). ... >>>> Although most Unicode characters can appear in >>>> internationalized labels, ToASCII will fail for some input strings, >>>> and such strings are not valid internationalized labels." >>>> >>>> "An "internationalized domain name" (IDN) is a domain name in which >>>> every label is an internationalized label." >>>> >>>> [Section 4.1] >>>> "ToASCII consists of the following steps: >>>> >>>> ... >>>> >>>> 8. Verify that the number of code points is in the range 1 to 63 >>>> inclusive." >>>> >>>> >>>> Here are the questions: >>>> 1. whether "example..com" is an valid IDN? >>>> As dot is used as label separators, there are three labels, >>>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence, >>>> "example..com" is not a valid IDN. >>>> >>>> We need to address the issue in IDN. >>>> >>>> 2. whether "xyz." is an valid IDN? >>>> It's an gray area, I think. We can treat the trailing "." as root >>>> label, or a label separator. >>>> If the trailing "." is treated as label separator, "xyz." is >>>> invalid >>>> per RFC 3490. >>>> if the trailing "." is treated as root label, what's the expected >>>> return value of IDN.toASCII("xyz.")? I think the return value can be >>>> either "xyz." or "xyz". The current implementation returns "xyz". >>>> >>>> We may need not to update the implementation if tailing "." is >>>> treated as root label. >>>> >>>> 3. whether "." is an valid IDN? >>>> It's an gray area again, I think. >>>> As above, if the trailing "." is treated as root label, I think >>>> the >>>> return value can be either "." or "". The current implementation >>>> throws >>>> a StringIndexOutOfBoundsException. >>>> >>>> However, what empty domain name ("") really means? I would >>>> prefer to >>>> return "." for "." instead. >>>> >>>> We need to address the issue in IDN. >>>> >>>> >>>> Here comes the solution, the IDN.toASCII() returns: >>>> 1. "." for "."; >>>> 2. "xyz" for "xyz."; >>>> 3. IAE for "example..com". >>>> >>>> Does it make sense? >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> >>>> On 8/7/2013 1:35 AM, Michael McMahon wrote: >>>>> I don't really understand the reason for the restriction in >>>>> SNIHostName >>>>> But, I guess that is where it should be enforced if it is required. >>>>> >>>>> Michael. >>>>> >>>>> On 06/08/13 17:43, Dmitry Samersoff wrote: >>>>>> Xuelei, >>>>>> >>>>>> . (dot) is perfectly valid domain name and it means root domain so >>>>>> com. >>>>>> is valid domain name as well. >>>>>> >>>>>> It thinks to me that in context of methods your change we should >>>>>> ignore >>>>>> trailing dots, rather than throw exception. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> >>>>>> On 2013-08-06 15:44, Xuelei Fan wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review the bug fix to strict the illegal input checking in >>>>>>> IDN. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >>>>>>> >>>>>>> Here is two test cases, which are expected to get IAE. >>>>>>> >>>>>>> Case 1: >>>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >>>>>>> Exception in thread "main" >>>>>>> java.lang.StringIndexOutOfBoundsException: >>>>>>> String index out of range: 0 >>>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >>>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279) >>>>>>> at java.net.IDN.toASCII(IDN.java:118) >>>>>>> >>>>>>> Case 2: >>>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> > From chris.hegarty at oracle.com Wed Aug 7 08:45:55 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 07 Aug 2013 16:45:55 +0100 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <20130806192520.GB5157@mhcomputing.net> References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com> <52012FEF.9030307@oracle.com> <20130806192520.GB5157@mhcomputing.net> Message-ID: <52026BB3.5000406@oracle.com> I'm not sure if there is precedent for adding such release notes inline in the javadoc (and subsequently removed in the next major release), but I am not opposed to it in principle. I guess it may look something like: *

Note: In this release, this constructor no longer declares * that it throws {@code SocketException}. Callers that explicitly * handle {@code SocketException} ( or one of its superclasses ) * may need to remove this explicit exception handling. Anyone every encounter this kind of comment before, or have a strong opinion either way ( I'm personally on the fence ). -Chris. On 06/08/2013 20:25, Matthew Hall wrote: > On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote: >> Documenting in release notes is okay too, but I suspect developers are not >> likely to look there at first anyway. Thinking aloud, it would be nice if >> some kind of annotation could be associated with the affected constructors >> such that a more meaningful/customized error message could be emitted by >> javac. But, perhaps there aren't sufficient other use cases to justify that. > > Many of us use Eclipse, NetBeans, and JavaDoc. > > So if we just had a comment in the JavaDoc, saying this was fixed, and what to > do, that ought to be more than adequate, and would prevent missing it if you > didn't see the relnotes. > > Matthew. From michael.x.mcmahon at oracle.com Wed Aug 7 08:49:40 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 07 Aug 2013 16:49:40 +0100 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <52026BB3.5000406@oracle.com> References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com> <52012FEF.9030307@oracle.com> <20130806192520.GB5157@mhcomputing.net> <52026BB3.5000406@oracle.com> Message-ID: <52026C94.3030309@oracle.com> As a matter of interest, what (if any) precedent is there for such source incompatible changes? Maybe it's more common that I thought. Michael. On 07/08/13 16:45, Chris Hegarty wrote: > I'm not sure if there is precedent for adding such release notes > inline in the javadoc (and subsequently removed in the next major > release), but I am not opposed to it in principle. I guess it may look > something like: > > *

Note: In this release, this constructor no longer declares > * that it throws {@code SocketException}. Callers that explicitly > * handle {@code SocketException} ( or one of its superclasses ) > * may need to remove this explicit exception handling. > > Anyone every encounter this kind of comment before, or have a strong > opinion either way ( I'm personally on the fence ). > > -Chris. > > On 06/08/2013 20:25, Matthew Hall wrote: >> On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote: >>> Documenting in release notes is okay too, but I suspect developers >>> are not >>> likely to look there at first anyway. Thinking aloud, it would be >>> nice if >>> some kind of annotation could be associated with the affected >>> constructors >>> such that a more meaningful/customized error message could be >>> emitted by >>> javac. But, perhaps there aren't sufficient other use cases to >>> justify that. >> >> Many of us use Eclipse, NetBeans, and JavaDoc. >> >> So if we just had a comment in the JavaDoc, saying this was fixed, >> and what to >> do, that ought to be more than adequate, and would prevent missing it >> if you >> didn't see the relnotes. >> >> Matthew. From joe.darcy at oracle.com Wed Aug 7 09:03:30 2013 From: joe.darcy at oracle.com (Joe Darcy) Date: Wed, 07 Aug 2013 09:03:30 -0700 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <52026C94.3030309@oracle.com> References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com> <52012FEF.9030307@oracle.com> <20130806192520.GB5157@mhcomputing.net> <52026BB3.5000406@oracle.com> <52026C94.3030309@oracle.com> Message-ID: <52026FD2.7080902@oracle.com> Hello, Source incompatible changes of this magnitude (if not exact character), have been made in major release before. IMO, release notes are the proper mechanism to inform users of such a change rather than the constructor javadoc. (Putting such time-sensitive notes in javadoc tends to age poorly and become a distraction rather than a help.) Cheers, -Joe On 08/07/2013 08:49 AM, Michael McMahon wrote: > As a matter of interest, what (if any) precedent is there for such > source incompatible changes? Maybe it's more common that I thought. > > Michael. > > On 07/08/13 16:45, Chris Hegarty wrote: >> I'm not sure if there is precedent for adding such release notes >> inline in the javadoc (and subsequently removed in the next major >> release), but I am not opposed to it in principle. I guess it may >> look something like: >> >> *

Note: In this release, this constructor no longer declares >> * that it throws {@code SocketException}. Callers that explicitly >> * handle {@code SocketException} ( or one of its superclasses ) >> * may need to remove this explicit exception handling. >> >> Anyone every encounter this kind of comment before, or have a strong >> opinion either way ( I'm personally on the fence ). >> >> -Chris. >> >> On 06/08/2013 20:25, Matthew Hall wrote: >>> On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote: >>>> Documenting in release notes is okay too, but I suspect developers >>>> are not >>>> likely to look there at first anyway. Thinking aloud, it would be >>>> nice if >>>> some kind of annotation could be associated with the affected >>>> constructors >>>> such that a more meaningful/customized error message could be >>>> emitted by >>>> javac. But, perhaps there aren't sufficient other use cases to >>>> justify that. >>> >>> Many of us use Eclipse, NetBeans, and JavaDoc. >>> >>> So if we just had a comment in the JavaDoc, saying this was fixed, >>> and what to >>> do, that ought to be more than adequate, and would prevent missing >>> it if you >>> didn't see the relnotes. >>> >>> Matthew. > From michael.x.mcmahon at oracle.com Wed Aug 7 09:22:14 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 07 Aug 2013 17:22:14 +0100 Subject: RFR 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress In-Reply-To: <52026FD2.7080902@oracle.com> References: <5201171B.3030907@oracle.com> <52011CDD.2000001@oracle.com> <52012FEF.9030307@oracle.com> <20130806192520.GB5157@mhcomputing.net> <52026BB3.5000406@oracle.com> <52026C94.3030309@oracle.com> <52026FD2.7080902@oracle.com> Message-ID: <52027436.3090308@oracle.com> In that case, my vote would be to just put it in release notes. If there are others in JDK 8, then maybe they could be listed together. Michael On 07/08/13 17:03, Joe Darcy wrote: > Hello, > > Source incompatible changes of this magnitude (if not exact > character), have been made in major release before. > > IMO, release notes are the proper mechanism to inform users of such a > change rather than the constructor javadoc. (Putting such > time-sensitive notes in javadoc tends to age poorly and become a > distraction rather than a help.) > > Cheers, > > -Joe > > On 08/07/2013 08:49 AM, Michael McMahon wrote: >> As a matter of interest, what (if any) precedent is there for such >> source incompatible changes? Maybe it's more common that I thought. >> >> Michael. >> >> On 07/08/13 16:45, Chris Hegarty wrote: >>> I'm not sure if there is precedent for adding such release notes >>> inline in the javadoc (and subsequently removed in the next major >>> release), but I am not opposed to it in principle. I guess it may >>> look something like: >>> >>> *

Note: In this release, this constructor no longer declares >>> * that it throws {@code SocketException}. Callers that explicitly >>> * handle {@code SocketException} ( or one of its superclasses ) >>> * may need to remove this explicit exception handling. >>> >>> Anyone every encounter this kind of comment before, or have a strong >>> opinion either way ( I'm personally on the fence ). >>> >>> -Chris. >>> >>> On 06/08/2013 20:25, Matthew Hall wrote: >>>> On Tue, Aug 06, 2013 at 06:18:39PM +0100, Michael McMahon wrote: >>>>> Documenting in release notes is okay too, but I suspect developers >>>>> are not >>>>> likely to look there at first anyway. Thinking aloud, it would be >>>>> nice if >>>>> some kind of annotation could be associated with the affected >>>>> constructors >>>>> such that a more meaningful/customized error message could be >>>>> emitted by >>>>> javac. But, perhaps there aren't sufficient other use cases to >>>>> justify that. >>>> >>>> Many of us use Eclipse, NetBeans, and JavaDoc. >>>> >>>> So if we just had a comment in the JavaDoc, saying this was fixed, >>>> and what to >>>> do, that ought to be more than adequate, and would prevent missing >>>> it if you >>>> didn't see the relnotes. >>>> >>>> Matthew. >> > From joe.darcy at oracle.com Wed Aug 7 09:39:59 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 07 Aug 2013 16:39:59 +0000 Subject: hg: jdk8/tl/jdk: 8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools Message-ID: <20130807164058.5468948686@hg.openjdk.java.net> Changeset: c1f129f62f36 Author: lagergren Date: 2013-08-07 08:08 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c1f129f62f36 8022454: Fixed various serializations and deprecation warnings in java.util, java.net and sun.tools Reviewed-by: darcy Contributed-by: marcus.lagergren at oracle.com ! src/share/classes/java/net/SocketAddress.java ! src/share/classes/java/util/logging/XMLFormatter.java ! src/share/classes/sun/tools/jar/JarException.java From dan.xu at oracle.com Wed Aug 7 12:13:55 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Wed, 07 Aug 2013 19:13:55 +0000 Subject: hg: jdk8/tl/jdk: 8022554: Fix Warnings in sun.invoke.anon Package Message-ID: <20130807191425.1EC9648690@hg.openjdk.java.net> Changeset: d1c82d5bee3f Author: dxu Date: 2013-08-07 12:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d1c82d5bee3f 8022554: Fix Warnings in sun.invoke.anon Package Reviewed-by: darcy, mduigou, lancea ! src/share/classes/sun/invoke/anon/ConstantPoolPatch.java From Alan.Bateman at oracle.com Wed Aug 7 18:05:10 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Aug 2013 18:05:10 -0700 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202EA83.70207@oracle.com> References: <5202EA83.70207@oracle.com> Message-ID: <5202EEC6.8050106@oracle.com> (cc'ing net-dev). The change looks okay to me. One suggestion (while you are there) is to check the return from GetStringUTFChars so that the name returns when it fails with NULL. -Alan. On 07/08/2013 17:46, Ivan Gerasimov wrote: > Hello everybody! > > Some methods of NetworkInterface class were reported to leak memory. > http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) > > Examples are isUp() and isLoopback(). > > Affected versions of jdk are 6, 7 and 8 > > Would you please review a simple fix that removes the unnecessary > allocation? > http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ > > Sincerely yours, > Ivan From ivan.gerasimov at oracle.com Wed Aug 7 18:20:04 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 05:20:04 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202EEC6.8050106@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> Message-ID: <5202F244.6070006@oracle.com> Thanks Alan! I've checked that and it turns out that GetStringUTFChars cannot return NULL. For allocation of the result string it calls AllocateHeap() with the default EXIT_OOM fail strategy. Thus, in case of being unable to allocate memory it simply stops VM. Sincerely yours, Ivan On 08.08.2013 5:05, Alan Bateman wrote: > (cc'ing net-dev). > > The change looks okay to me. One suggestion (while you are there) is > to check the return from GetStringUTFChars so that the name returns > when it fails with NULL. > > -Alan. > > On 07/08/2013 17:46, Ivan Gerasimov wrote: >> Hello everybody! >> >> Some methods of NetworkInterface class were reported to leak memory. >> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) >> >> Examples are isUp() and isLoopback(). >> >> Affected versions of jdk are 6, 7 and 8 >> >> Would you please review a simple fix that removes the unnecessary >> allocation? >> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >> >> Sincerely yours, >> Ivan > > > From stuart.marks at oracle.com Wed Aug 7 16:25:51 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Wed, 07 Aug 2013 23:25:51 +0000 Subject: hg: jdk8/tl/jdk: 8022479: clean up warnings from sun.tools.asm Message-ID: <20130807232621.8D617486AD@hg.openjdk.java.net> Changeset: 8c50c27418d3 Author: smarks Date: 2013-08-07 16:29 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c50c27418d3 8022479: clean up warnings from sun.tools.asm Reviewed-by: lancea, darcy ! src/share/classes/sun/tools/asm/Assembler.java ! src/share/classes/sun/tools/asm/ConstantPool.java ! src/share/classes/sun/tools/asm/Instruction.java ! src/share/classes/sun/tools/asm/SwitchData.java ! src/share/classes/sun/tools/asm/TryData.java From david.holmes at oracle.com Wed Aug 7 18:35:16 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Aug 2013 11:35:16 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202F244.6070006@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> Message-ID: <5202F5D4.7070806@oracle.com> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: > Thanks Alan! > > I've checked that and it turns out that GetStringUTFChars cannot return > NULL. > For allocation of the result string it calls AllocateHeap() with the > default EXIT_OOM fail strategy. > Thus, in case of being unable to allocate memory it simply stops VM. Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw OutOfMemoryError if it has memory issues, not abort the VM! I recommend that you check for NULL and/or a pending exception. David > Sincerely yours, > Ivan > > On 08.08.2013 5:05, Alan Bateman wrote: >> (cc'ing net-dev). >> >> The change looks okay to me. One suggestion (while you are there) is >> to check the return from GetStringUTFChars so that the name returns >> when it fails with NULL. >> >> -Alan. >> >> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>> Hello everybody! >>> >>> Some methods of NetworkInterface class were reported to leak memory. >>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet available.) >>> >>> Examples are isUp() and isLoopback(). >>> >>> Affected versions of jdk are 6, 7 and 8 >>> >>> Would you please review a simple fix that removes the unnecessary >>> allocation? >>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>> >>> Sincerely yours, >>> Ivan >> >> >> > From Alan.Bateman at oracle.com Wed Aug 7 18:38:28 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 07 Aug 2013 18:38:28 -0700 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202F244.6070006@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> Message-ID: <5202F694.5080707@oracle.com> On 07/08/2013 18:20, Ivan Gerasimov wrote: > Thanks Alan! > > I've checked that and it turns out that GetStringUTFChars cannot > return NULL. > For allocation of the result string it calls AllocateHeap() with the > default EXIT_OOM fail strategy. > Thus, in case of being unable to allocate memory it simply stops VM. > GetStringUTFChars is supposed to return NULL in OOM situations so this may be a bug (but if you can, it would be good to handle it in the NetworkInterface code). -Alan From ivan.gerasimov at oracle.com Wed Aug 7 21:05:07 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 08:05:07 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5202F5D4.7070806@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> Message-ID: <520318F3.7080609@oracle.com> David, Alan, I added checking for NULL results and throwing OOMException if necessary. I've also added some spaces along the code to improve indentation. Would you please review the updated webrev? http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ Sincerely yours, Ivan On 08.08.2013 5:35, David Holmes wrote: > On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >> Thanks Alan! >> >> I've checked that and it turns out that GetStringUTFChars cannot return >> NULL. >> For allocation of the result string it calls AllocateHeap() with the >> default EXIT_OOM fail strategy. >> Thus, in case of being unable to allocate memory it simply stops VM. > > Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw > OutOfMemoryError if it has memory issues, not abort the VM! > > I recommend that you check for NULL and/or a pending exception. > > David > >> Sincerely yours, >> Ivan >> >> On 08.08.2013 5:05, Alan Bateman wrote: >>> (cc'ing net-dev). >>> >>> The change looks okay to me. One suggestion (while you are there) is >>> to check the return from GetStringUTFChars so that the name returns >>> when it fails with NULL. >>> >>> -Alan. >>> >>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>> Hello everybody! >>>> >>>> Some methods of NetworkInterface class were reported to leak memory. >>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>> available.) >>>> >>>> Examples are isUp() and isLoopback(). >>>> >>>> Affected versions of jdk are 6, 7 and 8 >>>> >>>> Would you please review a simple fix that removes the unnecessary >>>> allocation? >>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>> >>> >>> >> > > From masayoshi.okutsu at oracle.com Wed Aug 7 21:52:43 2013 From: masayoshi.okutsu at oracle.com (masayoshi.okutsu at oracle.com) Date: Thu, 08 Aug 2013 04:52:43 +0000 Subject: hg: jdk8/tl/jdk: 8015986: Incorrect Localization of HijrahChronology Message-ID: <20130808045318.043F3486C2@hg.openjdk.java.net> Changeset: 0beaa65c90c8 Author: okutsu Date: 2013-08-08 13:51 +0900 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0beaa65c90c8 8015986: Incorrect Localization of HijrahChronology Reviewed-by: naoto Contributed-by: scolebourne at joda.org, roger.riggs at oracle.com ! make/tools/src/build/tools/cldrconverter/CLDRConverter.java ! make/tools/src/build/tools/cldrconverter/CalendarType.java ! src/share/classes/sun/text/resources/FormatData.java ! src/share/classes/sun/text/resources/ar/FormatData_ar.java ! test/java/time/test/java/time/format/TestNonIsoFormatter.java From david.holmes at oracle.com Wed Aug 7 22:01:25 2013 From: david.holmes at oracle.com (David Holmes) Date: Thu, 08 Aug 2013 15:01:25 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <520318F3.7080609@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> Message-ID: <52032625.3000501@oracle.com> Ivan, On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: > David, Alan, > > I added checking for NULL results and throwing OOMException if necessary. You don't need to throw it yourself: JNU_ThrowOutOfMemoryError(env, NULL); Assuming a correct VM implementation if NULL is returned then an OOME should already be pending and will be thrown as soon as your native code returns to Java. Thanks, David > I've also added some spaces along the code to improve indentation. > > Would you please review the updated webrev? > http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ > > Sincerely yours, > Ivan > > > On 08.08.2013 5:35, David Holmes wrote: >> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>> Thanks Alan! >>> >>> I've checked that and it turns out that GetStringUTFChars cannot return >>> NULL. >>> For allocation of the result string it calls AllocateHeap() with the >>> default EXIT_OOM fail strategy. >>> Thus, in case of being unable to allocate memory it simply stops VM. >> >> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >> OutOfMemoryError if it has memory issues, not abort the VM! >> >> I recommend that you check for NULL and/or a pending exception. >> >> David >> >>> Sincerely yours, >>> Ivan >>> >>> On 08.08.2013 5:05, Alan Bateman wrote: >>>> (cc'ing net-dev). >>>> >>>> The change looks okay to me. One suggestion (while you are there) is >>>> to check the return from GetStringUTFChars so that the name returns >>>> when it fails with NULL. >>>> >>>> -Alan. >>>> >>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>> Hello everybody! >>>>> >>>>> Some methods of NetworkInterface class were reported to leak memory. >>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>> available.) >>>>> >>>>> Examples are isUp() and isLoopback(). >>>>> >>>>> Affected versions of jdk are 6, 7 and 8 >>>>> >>>>> Would you please review a simple fix that removes the unnecessary >>>>> allocation? >>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>> >>>> >>>> >>> >> >> > From chris.hegarty at oracle.com Thu Aug 8 01:43:04 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 08 Aug 2013 09:43:04 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52032625.3000501@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> Message-ID: <52035A18.8020803@oracle.com> Thanks for taking this Ivan. Can you please make the changes suggested by both David and Alan ( simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars fails ( returns NULL ), then I will sponsor this change into jdk8 for you. Please post an update webrev to cr.openjdk.java.net. -Chris. On 08/08/2013 06:01 AM, David Holmes wrote: > Ivan, > > On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >> David, Alan, >> >> I added checking for NULL results and throwing OOMException if >> necessary. > > You don't need to throw it yourself: > > JNU_ThrowOutOfMemoryError(env, NULL); > > Assuming a correct VM implementation if NULL is returned then an OOME > should already be pending and will be thrown as soon as your native code > returns to Java. > > Thanks, > David > >> I've also added some spaces along the code to improve indentation. >> >> Would you please review the updated webrev? >> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >> >> Sincerely yours, >> Ivan >> >> >> On 08.08.2013 5:35, David Holmes wrote: >>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>> Thanks Alan! >>>> >>>> I've checked that and it turns out that GetStringUTFChars cannot return >>>> NULL. >>>> For allocation of the result string it calls AllocateHeap() with the >>>> default EXIT_OOM fail strategy. >>>> Thus, in case of being unable to allocate memory it simply stops VM. >>> >>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>> OutOfMemoryError if it has memory issues, not abort the VM! >>> >>> I recommend that you check for NULL and/or a pending exception. >>> >>> David >>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>> (cc'ing net-dev). >>>>> >>>>> The change looks okay to me. One suggestion (while you are there) is >>>>> to check the return from GetStringUTFChars so that the name returns >>>>> when it fails with NULL. >>>>> >>>>> -Alan. >>>>> >>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>> Hello everybody! >>>>>> >>>>>> Some methods of NetworkInterface class were reported to leak memory. >>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>> available.) >>>>>> >>>>>> Examples are isUp() and isLoopback(). >>>>>> >>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>> >>>>>> Would you please review a simple fix that removes the unnecessary >>>>>> allocation? >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>> >>>>> >>>>> >>>> >>> >>> >> From vicente.romero at oracle.com Thu Aug 8 03:49:52 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 08 Aug 2013 10:49:52 +0000 Subject: hg: jdk8/tl/langtools: 8019486: javac, generates erroneous LVT for a test case with lambda code Message-ID: <20130808105013.81177486D1@hg.openjdk.java.net> Changeset: b8610a65fbf9 Author: vromero Date: 2013-08-08 11:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b8610a65fbf9 8019486: javac, generates erroneous LVT for a test case with lambda code Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java + test/tools/javac/T8019486/WrongLVTForLambdaTest.java From weijun.wang at oracle.com Thu Aug 8 06:13:28 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Thu, 08 Aug 2013 13:13:28 +0000 Subject: hg: jdk8/tl/jdk: 8016594: Native Windows ccache still reads DES tickets Message-ID: <20130808131448.9A66E486D9@hg.openjdk.java.net> Changeset: b7d594716f86 Author: weijun Date: 2013-08-08 21:13 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7d594716f86 8016594: Native Windows ccache still reads DES tickets Reviewed-by: dsamersoff, xuelei ! src/share/classes/sun/security/krb5/Credentials.java ! src/share/native/sun/security/krb5/nativeccache.c ! src/windows/native/sun/security/krb5/NativeCreds.c From ivan.gerasimov at oracle.com Thu Aug 8 06:33:34 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 17:33:34 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52035A18.8020803@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> Message-ID: <52039E2E.6090504@oracle.com> Hello Chris! Here's the update: http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ Thanks for offering the sponsorship! Here's the hg-export http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch Sincerely yours, Ivan On 08.08.2013 12:43, Chris Hegarty wrote: > Thanks for taking this Ivan. > > Can you please make the changes suggested by both David and Alan ( > simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars > fails ( returns NULL ), then I will sponsor this change into jdk8 for > you. > > Please post an update webrev to cr.openjdk.java.net. > > -Chris. > > On 08/08/2013 06:01 AM, David Holmes wrote: >> Ivan, >> >> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>> David, Alan, >>> >>> I added checking for NULL results and throwing OOMException if >>> necessary. >> >> You don't need to throw it yourself: >> >> JNU_ThrowOutOfMemoryError(env, NULL); >> >> Assuming a correct VM implementation if NULL is returned then an OOME >> should already be pending and will be thrown as soon as your native code >> returns to Java. >> >> Thanks, >> David >> >>> I've also added some spaces along the code to improve indentation. >>> >>> Would you please review the updated webrev? >>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 08.08.2013 5:35, David Holmes wrote: >>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>> Thanks Alan! >>>>> >>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>> return >>>>> NULL. >>>>> For allocation of the result string it calls AllocateHeap() with the >>>>> default EXIT_OOM fail strategy. >>>>> Thus, in case of being unable to allocate memory it simply stops VM. >>>> >>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>> >>>> I recommend that you check for NULL and/or a pending exception. >>>> >>>> David >>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>> (cc'ing net-dev). >>>>>> >>>>>> The change looks okay to me. One suggestion (while you are there) is >>>>>> to check the return from GetStringUTFChars so that the name returns >>>>>> when it fails with NULL. >>>>>> >>>>>> -Alan. >>>>>> >>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>> Hello everybody! >>>>>>> >>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>> memory. >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>> available.) >>>>>>> >>>>>>> Examples are isUp() and isLoopback(). >>>>>>> >>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>> >>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>> allocation? >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> > > From ivan.gerasimov at oracle.com Thu Aug 8 06:39:55 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 17:39:55 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52032625.3000501@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> Message-ID: <52039FAB.3040206@oracle.com> Thanks, David I've updated the webrev http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/. On 08.08.2013 9:01, David Holmes wrote: > Ivan, > > On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >> David, Alan, >> >> I added checking for NULL results and throwing OOMException if >> necessary. > > You don't need to throw it yourself: > > JNU_ThrowOutOfMemoryError(env, NULL); > > Assuming a correct VM implementation if NULL is returned then an OOME > should already be pending and will be thrown as soon as your native > code returns to Java. It seemed to me that, JNU_ThrowOutOfMemoryError only throws an exception in a case one is not pending. But I don't mind to remove it, relaying on the correct implementation of GetStringUTFChars. Sincerely yours, Ivan > Thanks, > David > >> I've also added some spaces along the code to improve indentation. >> >> Would you please review the updated webrev? >> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >> >> Sincerely yours, >> Ivan >> >> >> On 08.08.2013 5:35, David Holmes wrote: >>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>> Thanks Alan! >>>> >>>> I've checked that and it turns out that GetStringUTFChars cannot >>>> return >>>> NULL. >>>> For allocation of the result string it calls AllocateHeap() with the >>>> default EXIT_OOM fail strategy. >>>> Thus, in case of being unable to allocate memory it simply stops VM. >>> >>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>> OutOfMemoryError if it has memory issues, not abort the VM! >>> >>> I recommend that you check for NULL and/or a pending exception. >>> >>> David >>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>> (cc'ing net-dev). >>>>> >>>>> The change looks okay to me. One suggestion (while you are there) is >>>>> to check the return from GetStringUTFChars so that the name returns >>>>> when it fails with NULL. >>>>> >>>>> -Alan. >>>>> >>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>> Hello everybody! >>>>>> >>>>>> Some methods of NetworkInterface class were reported to leak memory. >>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>> available.) >>>>>> >>>>>> Examples are isUp() and isLoopback(). >>>>>> >>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>> >>>>>> Would you please review a simple fix that removes the unnecessary >>>>>> allocation? >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>> >>>>> >>>>> >>>> >>> >>> >> > > From chris.hegarty at oracle.com Thu Aug 8 06:50:59 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 08 Aug 2013 14:50:59 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52039E2E.6090504@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> Message-ID: <5203A243.60505@oracle.com> Looks good to me. Thanks Ivan. -Chris. On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: > Hello Chris! > > Here's the update: > http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ > > Thanks for offering the sponsorship! > Here's the hg-export > http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch > > > Sincerely yours, > Ivan > > On 08.08.2013 12:43, Chris Hegarty wrote: >> Thanks for taking this Ivan. >> >> Can you please make the changes suggested by both David and Alan ( >> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >> fails ( returns NULL ), then I will sponsor this change into jdk8 for >> you. >> >> Please post an update webrev to cr.openjdk.java.net. >> >> -Chris. >> >> On 08/08/2013 06:01 AM, David Holmes wrote: >>> Ivan, >>> >>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>> David, Alan, >>>> >>>> I added checking for NULL results and throwing OOMException if >>>> necessary. >>> >>> You don't need to throw it yourself: >>> >>> JNU_ThrowOutOfMemoryError(env, NULL); >>> >>> Assuming a correct VM implementation if NULL is returned then an OOME >>> should already be pending and will be thrown as soon as your native code >>> returns to Java. >>> >>> Thanks, >>> David >>> >>>> I've also added some spaces along the code to improve indentation. >>>> >>>> Would you please review the updated webrev? >>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 08.08.2013 5:35, David Holmes wrote: >>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>> Thanks Alan! >>>>>> >>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>> return >>>>>> NULL. >>>>>> For allocation of the result string it calls AllocateHeap() with the >>>>>> default EXIT_OOM fail strategy. >>>>>> Thus, in case of being unable to allocate memory it simply stops VM. >>>>> >>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>> >>>>> I recommend that you check for NULL and/or a pending exception. >>>>> >>>>> David >>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>> (cc'ing net-dev). >>>>>>> >>>>>>> The change looks okay to me. One suggestion (while you are there) is >>>>>>> to check the return from GetStringUTFChars so that the name returns >>>>>>> when it fails with NULL. >>>>>>> >>>>>>> -Alan. >>>>>>> >>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>> Hello everybody! >>>>>>>> >>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>> memory. >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>> available.) >>>>>>>> >>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>> >>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>> >>>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>>> allocation? >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >> >> > From michael.x.mcmahon at oracle.com Thu Aug 8 06:51:19 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 08 Aug 2013 14:51:19 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52039FAB.3040206@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52039FAB.3040206@oracle.com> Message-ID: <5203A257.7000803@oracle.com> The patch looks good to me. I guess a regression test isn't feasible. So, the bug will be tagged noreg-hard Michael On 08/08/13 14:39, Ivan Gerasimov wrote: > Thanks, David > > I've updated the webrev > http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/. > > On 08.08.2013 9:01, David Holmes wrote: >> Ivan, >> >> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>> David, Alan, >>> >>> I added checking for NULL results and throwing OOMException if >>> necessary. >> >> You don't need to throw it yourself: >> >> JNU_ThrowOutOfMemoryError(env, NULL); >> >> Assuming a correct VM implementation if NULL is returned then an OOME >> should already be pending and will be thrown as soon as your native >> code returns to Java. > > It seemed to me that, JNU_ThrowOutOfMemoryError only throws an > exception in a case one is not pending. > But I don't mind to remove it, relaying on the correct implementation > of GetStringUTFChars. > > Sincerely yours, > Ivan > >> Thanks, >> David >> >>> I've also added some spaces along the code to improve indentation. >>> >>> Would you please review the updated webrev? >>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 08.08.2013 5:35, David Holmes wrote: >>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>> Thanks Alan! >>>>> >>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>> return >>>>> NULL. >>>>> For allocation of the result string it calls AllocateHeap() with the >>>>> default EXIT_OOM fail strategy. >>>>> Thus, in case of being unable to allocate memory it simply stops VM. >>>> >>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>> >>>> I recommend that you check for NULL and/or a pending exception. >>>> >>>> David >>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>> (cc'ing net-dev). >>>>>> >>>>>> The change looks okay to me. One suggestion (while you are there) is >>>>>> to check the return from GetStringUTFChars so that the name returns >>>>>> when it fails with NULL. >>>>>> >>>>>> -Alan. >>>>>> >>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>> Hello everybody! >>>>>>> >>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>> memory. >>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>> available.) >>>>>>> >>>>>>> Examples are isUp() and isLoopback(). >>>>>>> >>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>> >>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>> allocation? >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From Alan.Bateman at oracle.com Thu Aug 8 08:27:20 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 08 Aug 2013 08:27:20 -0700 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52039FAB.3040206@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52039FAB.3040206@oracle.com> Message-ID: <5203B8D8.3090206@oracle.com> On 08/08/2013 06:39, Ivan Gerasimov wrote: > Thanks, David > > I've updated the webrev > http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/. Thanks for fixing the other GetStringUTFChars usages too. This version looks good to me. -Alan. From ivan.gerasimov at oracle.com Thu Aug 8 11:17:57 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 22:17:57 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5203A257.7000803@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52039FAB.3040206@oracle.com> <5203A257.7000803@oracle.com> Message-ID: <5203E0D5.8000308@oracle.com> Thank you Michael! I'm working on the test. Chris, if it's not too late, I would like to include a regtest into the change. It will be ready in a few minutes and I'll send an updated webrev. Thanks, Ivan On 08.08.2013 17:51, Michael McMahon wrote: > The patch looks good to me. I guess a regression test isn't feasible. > So, the bug will be tagged noreg-hard > > Michael > > On 08/08/13 14:39, Ivan Gerasimov wrote: >> Thanks, David >> >> I've updated the webrev >> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/. >> >> On 08.08.2013 9:01, David Holmes wrote: >>> Ivan, >>> >>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>> David, Alan, >>>> >>>> I added checking for NULL results and throwing OOMException if >>>> necessary. >>> >>> You don't need to throw it yourself: >>> >>> JNU_ThrowOutOfMemoryError(env, NULL); >>> >>> Assuming a correct VM implementation if NULL is returned then an >>> OOME should already be pending and will be thrown as soon as your >>> native code returns to Java. >> >> It seemed to me that, JNU_ThrowOutOfMemoryError only throws an >> exception in a case one is not pending. >> But I don't mind to remove it, relaying on the correct implementation >> of GetStringUTFChars. >> >> Sincerely yours, >> Ivan >> >>> Thanks, >>> David >>> >>>> I've also added some spaces along the code to improve indentation. >>>> >>>> Would you please review the updated webrev? >>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 08.08.2013 5:35, David Holmes wrote: >>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>> Thanks Alan! >>>>>> >>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>> return >>>>>> NULL. >>>>>> For allocation of the result string it calls AllocateHeap() with the >>>>>> default EXIT_OOM fail strategy. >>>>>> Thus, in case of being unable to allocate memory it simply stops VM. >>>>> >>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>> >>>>> I recommend that you check for NULL and/or a pending exception. >>>>> >>>>> David >>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>> (cc'ing net-dev). >>>>>>> >>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>> there) is >>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>> returns >>>>>>> when it fails with NULL. >>>>>>> >>>>>>> -Alan. >>>>>>> >>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>> Hello everybody! >>>>>>>> >>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>> memory. >>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>> available.) >>>>>>>> >>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>> >>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>> >>>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>>> allocation? >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> > > > From ivan.gerasimov at oracle.com Thu Aug 8 11:41:06 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 08 Aug 2013 22:41:06 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5203A243.60505@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> Message-ID: <5203E642.40005@oracle.com> Chris, if it's not too late, I'd like to include a regtest in the fix. Here's webrev that includes the test: http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7 as expected. Sincerely yours, Ivan On 08.08.2013 17:50, Chris Hegarty wrote: > Looks good to me. Thanks Ivan. > > -Chris. > > On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >> Hello Chris! >> >> Here's the update: >> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >> >> Thanks for offering the sponsorship! >> Here's the hg-export >> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >> >> >> >> Sincerely yours, >> Ivan >> >> On 08.08.2013 12:43, Chris Hegarty wrote: >>> Thanks for taking this Ivan. >>> >>> Can you please make the changes suggested by both David and Alan ( >>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >>> fails ( returns NULL ), then I will sponsor this change into jdk8 for >>> you. >>> >>> Please post an update webrev to cr.openjdk.java.net. >>> >>> -Chris. >>> >>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>> Ivan, >>>> >>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>> David, Alan, >>>>> >>>>> I added checking for NULL results and throwing OOMException if >>>>> necessary. >>>> >>>> You don't need to throw it yourself: >>>> >>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>> >>>> Assuming a correct VM implementation if NULL is returned then an OOME >>>> should already be pending and will be thrown as soon as your native >>>> code >>>> returns to Java. >>>> >>>> Thanks, >>>> David >>>> >>>>> I've also added some spaces along the code to improve indentation. >>>>> >>>>> Would you please review the updated webrev? >>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>> Thanks Alan! >>>>>>> >>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>> return >>>>>>> NULL. >>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>> the >>>>>>> default EXIT_OOM fail strategy. >>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>> VM. >>>>>> >>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>> >>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>> >>>>>> David >>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>> (cc'ing net-dev). >>>>>>>> >>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>> there) is >>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>> returns >>>>>>>> when it fails with NULL. >>>>>>>> >>>>>>>> -Alan. >>>>>>>> >>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>> Hello everybody! >>>>>>>>> >>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>> memory. >>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>> available.) >>>>>>>>> >>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>> >>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>> >>>>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>>>> allocation? >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >> > > From xueming.shen at oracle.com Thu Aug 8 12:00:49 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 08 Aug 2013 19:00:49 +0000 Subject: hg: jdk8/tl/jdk: 8015666: test/tools/pack200/TimeStamp.java failing Message-ID: <20130808190152.9A34248707@hg.openjdk.java.net> Changeset: a388263a7287 Author: sherman Date: 2013-08-08 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a388263a7287 8015666: test/tools/pack200/TimeStamp.java failing Summary: to keep the default behavior of ZOS unchanged, if ze extra time not explicitly set Reviewed-by: alanb, ksrini ! src/share/classes/java/util/zip/ZipConstants.java ! src/share/classes/java/util/zip/ZipEntry.java ! src/share/classes/java/util/zip/ZipFile.java ! src/share/classes/java/util/zip/ZipInputStream.java ! src/share/classes/java/util/zip/ZipOutputStream.java ! src/share/classes/java/util/zip/ZipUtils.java ! test/ProblemList.txt ! test/java/util/zip/TestExtraTime.java ! test/tools/pack200/TimeStamp.java From david.holmes at oracle.com Thu Aug 8 14:15:34 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Aug 2013 07:15:34 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5203E642.40005@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> Message-ID: <52040A76.3060602@oracle.com> Main fix looks good to me. Regression test may need some tweaking eg I think othervm will be needed. Also this: System.out.println("WARNING: Cannot perform memory leak detection on this OS"); should probably just say something like "Test skipped on this OS" - there are other tests that do this so just check if there is common terminology. (In the future we may have keyword tags to flag this as linux only etc.) Thanks, David On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: > Chris, if it's not too late, I'd like to include a regtest in the fix. > > Here's webrev that includes the test: > http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ > > The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7 > as expected. > > Sincerely yours, > Ivan > > On 08.08.2013 17:50, Chris Hegarty wrote: >> Looks good to me. Thanks Ivan. >> >> -Chris. >> >> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>> Hello Chris! >>> >>> Here's the update: >>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>> >>> Thanks for offering the sponsorship! >>> Here's the hg-export >>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>> >>> >>> >>> Sincerely yours, >>> Ivan >>> >>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>> Thanks for taking this Ivan. >>>> >>>> Can you please make the changes suggested by both David and Alan ( >>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for >>>> you. >>>> >>>> Please post an update webrev to cr.openjdk.java.net. >>>> >>>> -Chris. >>>> >>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>> Ivan, >>>>> >>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>> David, Alan, >>>>>> >>>>>> I added checking for NULL results and throwing OOMException if >>>>>> necessary. >>>>> >>>>> You don't need to throw it yourself: >>>>> >>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>> >>>>> Assuming a correct VM implementation if NULL is returned then an OOME >>>>> should already be pending and will be thrown as soon as your native >>>>> code >>>>> returns to Java. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> I've also added some spaces along the code to improve indentation. >>>>>> >>>>>> Would you please review the updated webrev? >>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> >>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>> Thanks Alan! >>>>>>>> >>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>> return >>>>>>>> NULL. >>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>> the >>>>>>>> default EXIT_OOM fail strategy. >>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>> VM. >>>>>>> >>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to throw >>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>> >>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>> (cc'ing net-dev). >>>>>>>>> >>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>> there) is >>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>> returns >>>>>>>>> when it fails with NULL. >>>>>>>>> >>>>>>>>> -Alan. >>>>>>>>> >>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>> Hello everybody! >>>>>>>>>> >>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>> memory. >>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>> available.) >>>>>>>>>> >>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>> >>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>> >>>>>>>>>> Would you please review a simple fix that removes the unnecessary >>>>>>>>>> allocation? >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>> >>>> >>> >> >> > From michael.x.mcmahon at oracle.com Thu Aug 8 14:38:34 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 08 Aug 2013 22:38:34 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52040A76.3060602@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> Message-ID: <52040FDA.2040600@oracle.com> Yes, definitely "othervm" would be required for the test. Also, why skip other OS'es? The fix is only for Linux, but it might catch future leaks on Windows. The trouble with tests like this, is they sometimes don't age well. Future changes in OS kernel behavior could cause problems but I guess 32MB is a fairly large difference. So, it should be okay Michael On 08/08/13 22:15, David Holmes wrote: > Main fix looks good to me. > > Regression test may need some tweaking eg I think othervm will be needed. > > Also this: > > System.out.println("WARNING: Cannot perform memory leak detection on > this OS"); > > should probably just say something like "Test skipped on this OS" - > there are other tests that do this so just check if there is common > terminology. (In the future we may have keyword tags to flag this as > linux only etc.) > > Thanks, > David > > On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >> Chris, if it's not too late, I'd like to include a regtest in the fix. >> >> Here's webrev that includes the test: >> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >> >> The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7 >> as expected. >> >> Sincerely yours, >> Ivan >> >> On 08.08.2013 17:50, Chris Hegarty wrote: >>> Looks good to me. Thanks Ivan. >>> >>> -Chris. >>> >>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>> Hello Chris! >>>> >>>> Here's the update: >>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>> >>>> Thanks for offering the sponsorship! >>>> Here's the hg-export >>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>> >>>> >>>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>> Thanks for taking this Ivan. >>>>> >>>>> Can you please make the changes suggested by both David and Alan ( >>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for >>>>> you. >>>>> >>>>> Please post an update webrev to cr.openjdk.java.net. >>>>> >>>>> -Chris. >>>>> >>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>> Ivan, >>>>>> >>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>> David, Alan, >>>>>>> >>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>> necessary. >>>>>> >>>>>> You don't need to throw it yourself: >>>>>> >>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>> >>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>> OOME >>>>>> should already be pending and will be thrown as soon as your native >>>>>> code >>>>>> returns to Java. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I've also added some spaces along the code to improve indentation. >>>>>>> >>>>>>> Would you please review the updated webrev? >>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>> Thanks Alan! >>>>>>>>> >>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>>> return >>>>>>>>> NULL. >>>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>>> the >>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>>> VM. >>>>>>>> >>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>> throw >>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>> >>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>> (cc'ing net-dev). >>>>>>>>>> >>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>> there) is >>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>> returns >>>>>>>>>> when it fails with NULL. >>>>>>>>>> >>>>>>>>>> -Alan. >>>>>>>>>> >>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>> Hello everybody! >>>>>>>>>>> >>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>> memory. >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>> available.) >>>>>>>>>>> >>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>> >>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>> >>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>> unnecessary >>>>>>>>>>> allocation? >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>> >> From ivan.gerasimov at oracle.com Thu Aug 8 15:15:49 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 Aug 2013 02:15:49 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52040FDA.2040600@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com> Message-ID: <52041895.9010706@oracle.com> Michael, The test uses /proc/self/stat file to detect changes in virtual memory usage. This approach is specific for Linux. That's why I included the check of OS in the test. Sincerely yours, Ivan On 09.08.2013 1:38, Michael McMahon wrote: > Yes, definitely "othervm" would be required for the test. Also, why > skip other OS'es? > The fix is only for Linux, but it might catch future leaks on Windows. > > The trouble with tests like this, is they sometimes don't age well. > Future changes in OS kernel behavior could cause problems but I guess > 32MB is a fairly large difference. > So, it should be okay > > Michael > > On 08/08/13 22:15, David Holmes wrote: >> Main fix looks good to me. >> >> Regression test may need some tweaking eg I think othervm will be >> needed. >> >> Also this: >> >> System.out.println("WARNING: Cannot perform memory leak detection on >> this OS"); >> >> should probably just say something like "Test skipped on this OS" - >> there are other tests that do this so just check if there is common >> terminology. (In the future we may have keyword tags to flag this as >> linux only etc.) >> >> Thanks, >> David >> >> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>> >>> Here's webrev that includes the test: >>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>> >>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>> jdk7 >>> as expected. >>> >>> Sincerely yours, >>> Ivan >>> >>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>> Looks good to me. Thanks Ivan. >>>> >>>> -Chris. >>>> >>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>> Hello Chris! >>>>> >>>>> Here's the update: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>> >>>>> Thanks for offering the sponsorship! >>>>> Here's the hg-export >>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>> >>>>> >>>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>> Thanks for taking this Ivan. >>>>>> >>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>> GetStringUTFChars >>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>> for >>>>>> you. >>>>>> >>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>> Ivan, >>>>>>> >>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>> David, Alan, >>>>>>>> >>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>> necessary. >>>>>>> >>>>>>> You don't need to throw it yourself: >>>>>>> >>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>> >>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>> OOME >>>>>>> should already be pending and will be thrown as soon as your native >>>>>>> code >>>>>>> returns to Java. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I've also added some spaces along the code to improve indentation. >>>>>>>> >>>>>>>> Would you please review the updated webrev? >>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>> Thanks Alan! >>>>>>>>>> >>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>>>> return >>>>>>>>>> NULL. >>>>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>>>> the >>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>>>> VM. >>>>>>>>> >>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>> throw >>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>> >>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>> >>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>> there) is >>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>> returns >>>>>>>>>>> when it fails with NULL. >>>>>>>>>>> >>>>>>>>>>> -Alan. >>>>>>>>>>> >>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>> Hello everybody! >>>>>>>>>>>> >>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>> memory. >>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>> available.) >>>>>>>>>>>> >>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>> >>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>> >>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>> unnecessary >>>>>>>>>>>> allocation? >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> > > > From michael.x.mcmahon at oracle.com Thu Aug 8 15:19:17 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 08 Aug 2013 23:19:17 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52041895.9010706@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com> <52041895.9010706@oracle.com> Message-ID: <52041965.3090808@oracle.com> Ivan, Right, it's not worth trying to do the equivalent, whatever it is, for Windows. The test is fine with me. Thanks Michael On 08/08/13 23:15, Ivan Gerasimov wrote: > Michael, > > The test uses /proc/self/stat file to detect changes in virtual memory > usage. > This approach is specific for Linux. > That's why I included the check of OS in the test. > > Sincerely yours, > Ivan > > On 09.08.2013 1:38, Michael McMahon wrote: >> Yes, definitely "othervm" would be required for the test. Also, why >> skip other OS'es? >> The fix is only for Linux, but it might catch future leaks on Windows. >> >> The trouble with tests like this, is they sometimes don't age well. >> Future changes in OS kernel behavior could cause problems but I guess >> 32MB is a fairly large difference. >> So, it should be okay >> >> Michael >> >> On 08/08/13 22:15, David Holmes wrote: >>> Main fix looks good to me. >>> >>> Regression test may need some tweaking eg I think othervm will be >>> needed. >>> >>> Also this: >>> >>> System.out.println("WARNING: Cannot perform memory leak detection >>> on this OS"); >>> >>> should probably just say something like "Test skipped on this OS" - >>> there are other tests that do this so just check if there is common >>> terminology. (In the future we may have keyword tags to flag this as >>> linux only etc.) >>> >>> Thanks, >>> David >>> >>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>>> >>>> Here's webrev that includes the test: >>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>> >>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>> jdk7 >>>> as expected. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>> Looks good to me. Thanks Ivan. >>>>> >>>>> -Chris. >>>>> >>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>> Hello Chris! >>>>>> >>>>>> Here's the update: >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>> >>>>>> Thanks for offering the sponsorship! >>>>>> Here's the hg-export >>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>> Thanks for taking this Ivan. >>>>>>> >>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>> GetStringUTFChars >>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>> jdk8 for >>>>>>> you. >>>>>>> >>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>> Ivan, >>>>>>>> >>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>> David, Alan, >>>>>>>>> >>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>> necessary. >>>>>>>> >>>>>>>> You don't need to throw it yourself: >>>>>>>> >>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>> >>>>>>>> Assuming a correct VM implementation if NULL is returned then >>>>>>>> an OOME >>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>> native >>>>>>>> code >>>>>>>> returns to Java. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>> indentation. >>>>>>>>> >>>>>>>>> Would you please review the updated webrev? >>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>> Thanks Alan! >>>>>>>>>>> >>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>> cannot >>>>>>>>>>> return >>>>>>>>>>> NULL. >>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>> with >>>>>>>>>>> the >>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>> stops >>>>>>>>>>> VM. >>>>>>>>>> >>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>> throw >>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>> >>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>> >>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>> there) is >>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>> returns >>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>> >>>>>>>>>>>> -Alan. >>>>>>>>>>>> >>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>> >>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>> memory. >>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>> available.) >>>>>>>>>>>>> >>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>> >>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>> >>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>> unnecessary >>>>>>>>>>>>> allocation? >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >> >> >> > From ivan.gerasimov at oracle.com Thu Aug 8 15:19:52 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 Aug 2013 02:19:52 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52040A76.3060602@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> Message-ID: <52041988.80705@oracle.com> Thanks David! On 09.08.2013 1:15, David Holmes wrote: > Main fix looks good to me. > > Regression test may need some tweaking eg I think othervm will be needed. > Yes, it's a good point. Since there may be a memory leak in the test, it'd better not interfere with other tests in jtreg. > Also this: > > System.out.println("WARNING: Cannot perform memory leak detection on > this OS"); > > should probably just say something like "Test skipped on this OS" - > there are other tests that do this so just check if there is common > terminology. (In the future we may have keyword tags to flag this as > linux only etc.) > OK, I changed the phrase to "Test only runs on Linux". Updated webrev is here: http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ Updated export is at the same place: http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch Sincerely yours, Ivan > Thanks, > David > > On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >> Chris, if it's not too late, I'd like to include a regtest in the fix. >> >> Here's webrev that includes the test: >> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >> >> The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7 >> as expected. >> >> Sincerely yours, >> Ivan >> >> On 08.08.2013 17:50, Chris Hegarty wrote: >>> Looks good to me. Thanks Ivan. >>> >>> -Chris. >>> >>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>> Hello Chris! >>>> >>>> Here's the update: >>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>> >>>> Thanks for offering the sponsorship! >>>> Here's the hg-export >>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>> >>>> >>>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>> Thanks for taking this Ivan. >>>>> >>>>> Can you please make the changes suggested by both David and Alan ( >>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for >>>>> you. >>>>> >>>>> Please post an update webrev to cr.openjdk.java.net. >>>>> >>>>> -Chris. >>>>> >>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>> Ivan, >>>>>> >>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>> David, Alan, >>>>>>> >>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>> necessary. >>>>>> >>>>>> You don't need to throw it yourself: >>>>>> >>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>> >>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>> OOME >>>>>> should already be pending and will be thrown as soon as your native >>>>>> code >>>>>> returns to Java. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> I've also added some spaces along the code to improve indentation. >>>>>>> >>>>>>> Would you please review the updated webrev? >>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>> Thanks Alan! >>>>>>>>> >>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>>> return >>>>>>>>> NULL. >>>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>>> the >>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>>> VM. >>>>>>>> >>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>> throw >>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>> >>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>> (cc'ing net-dev). >>>>>>>>>> >>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>> there) is >>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>> returns >>>>>>>>>> when it fails with NULL. >>>>>>>>>> >>>>>>>>>> -Alan. >>>>>>>>>> >>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>> Hello everybody! >>>>>>>>>>> >>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>> memory. >>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>> available.) >>>>>>>>>>> >>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>> >>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>> >>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>> unnecessary >>>>>>>>>>> allocation? >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> >>>> >>> >>> >> > > From ivan.gerasimov at oracle.com Thu Aug 8 15:24:36 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 Aug 2013 02:24:36 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52041965.3090808@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com> <52041895.9010706@oracle.com> <52041965.3090808@oracle.com> Message-ID: <52041AA4.2000406@oracle.com> Thank you Michael! On 09.08.2013 2:19, Michael McMahon wrote: > Ivan, > > Right, it's not worth trying to do the equivalent, whatever it is, for > Windows. > The test is fine with me. > > Thanks > Michael > > On 08/08/13 23:15, Ivan Gerasimov wrote: >> Michael, >> >> The test uses /proc/self/stat file to detect changes in virtual >> memory usage. >> This approach is specific for Linux. >> That's why I included the check of OS in the test. >> >> Sincerely yours, >> Ivan >> >> On 09.08.2013 1:38, Michael McMahon wrote: >>> Yes, definitely "othervm" would be required for the test. Also, why >>> skip other OS'es? >>> The fix is only for Linux, but it might catch future leaks on Windows. >>> >>> The trouble with tests like this, is they sometimes don't age well. >>> Future changes in OS kernel behavior could cause problems but I >>> guess 32MB is a fairly large difference. >>> So, it should be okay >>> >>> Michael >>> >>> On 08/08/13 22:15, David Holmes wrote: >>>> Main fix looks good to me. >>>> >>>> Regression test may need some tweaking eg I think othervm will be >>>> needed. >>>> >>>> Also this: >>>> >>>> System.out.println("WARNING: Cannot perform memory leak detection >>>> on this OS"); >>>> >>>> should probably just say something like "Test skipped on this OS" - >>>> there are other tests that do this so just check if there is common >>>> terminology. (In the future we may have keyword tags to flag this >>>> as linux only etc.) >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>> fix. >>>>> >>>>> Here's webrev that includes the test: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>> >>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 >>>>> and jdk7 >>>>> as expected. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>> Looks good to me. Thanks Ivan. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>> Hello Chris! >>>>>>> >>>>>>> Here's the update: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>> >>>>>>> Thanks for offering the sponsorship! >>>>>>> Here's the hg-export >>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>> Thanks for taking this Ivan. >>>>>>>> >>>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>> GetStringUTFChars >>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>> jdk8 for >>>>>>>> you. >>>>>>>> >>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>> Ivan, >>>>>>>>> >>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>> David, Alan, >>>>>>>>>> >>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>> necessary. >>>>>>>>> >>>>>>>>> You don't need to throw it yourself: >>>>>>>>> >>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>> >>>>>>>>> Assuming a correct VM implementation if NULL is returned then >>>>>>>>> an OOME >>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>> native >>>>>>>>> code >>>>>>>>> returns to Java. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>> indentation. >>>>>>>>>> >>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>> >>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>> cannot >>>>>>>>>>>> return >>>>>>>>>>>> NULL. >>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>> with >>>>>>>>>>>> the >>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>> stops >>>>>>>>>>>> VM. >>>>>>>>>>> >>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed >>>>>>>>>>> to throw >>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>> >>>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>> >>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>> there) is >>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>> returns >>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>> >>>>>>>>>>>>> -Alan. >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>>> memory. >>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>> available.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >>> >> > > > From xuelei.fan at oracle.com Thu Aug 8 17:41:23 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 09 Aug 2013 08:41:23 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <520264F1.1090802@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> Message-ID: <52043AB3.6060704@oracle.com> Ping. Thanks, Xuelei On 8/7/2013 11:17 PM, Xuelei Fan wrote: > Please review the new update: > > http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ > > With this update, "com." is valid (return "com."); "." and > "example..com" are invalid. And IAE will be thrown for invalid IDN. > > Thanks, > Xuelei > > On 8/7/2013 10:18 PM, Michael McMahon wrote: >> On 07/08/13 15:13, Xuelei Fan wrote: >>> On 8/7/2013 10:05 PM, Michael McMahon wrote: >>>> Resolvers seem to accept queries using trailing dots. >>>> >>>> eg nslookup www.oracle.com. >>>> >>>> or InetAddress.getByName("www.oracle.com."); >>>> >>>> The part of RFC3490 quoted below seems to me to be saying >>>> that the empty label implied by the trailing dot is not regarded >>>> as a label so that you don't end up calling toAscii() or toUnicode() >>>> with an empty string. I don't think it's saying the trailing dot can't >>>> be there. >>>> >>> It makes sense. >>> >>> What's your preference to return for IDN.toASCII("www.oracle.com."), >>> "www.oracle.com." or "www.oracle.com"? The current returned value is >>> "www.oracle.com". I would like to reserve the behavior in this update. >> >> My opinion is to keep it as at present ie. "www.oracle.com." >> >> Michael >> >>> I think we are on same page soon. >>> >>> Thanks, >>> Xuelei >>> >>>> Michael >>>> >>>> On 07/08/13 13:44, Xuelei Fan wrote: >>>>> On 8/7/2013 12:06 AM, Matthew Hall wrote: >>>>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN), >>>>>> and the single dot represents the root zone. So you have to be >>>>>> careful making this sort of change to check the DNS RFCs first. >>>>> That's the first question we need to answer, whether IDN allow tailling >>>>> dots ("com."), zero-length root label ("."), and zero-length label ("", >>>>> for example ""example..com")? >>>>> >>>>> Per the specification of IDN.toASCII(): >>>>> ======================================= >>>>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If >>>>> ToASCII operation fails, an IllegalArgumentException will be thrown. In >>>>> this case, the input string should not be used in an internationalized >>>>> domain name. >>>>> >>>>> A label is an individual part of a domain name. The original ToASCII >>>>> operation, as defined in RFC 3490, only operates on a single label. >>>>> This >>>>> method can handle both label and entire domain name, by assuming that >>>>> labels in a domain name are always separated by dots. ... >>>>> >>>>> Throws IllegalArgumentException - if the input string doesn't >>>>> conform to >>>>> RFC 3490 specification" >>>>> >>>>> Per the specification of RFC 3490: >>>>> ================================== >>>>> [section 2] >>>>> "A label is an individual part of a domain name. Labels are usually >>>>> shown separated by dots; for example, the domain name >>>>> "www.example.com" is composed of three labels: "www", "example", and >>>>> "com". (The zero-length root label described in [STD13], which can >>>>> be explicit as in "www.example.com." or implicit as in >>>>> "www.example.com", is not considered a label in this >>>>> specification.)" >>>>> >>>>> "An "internationalized label" is a label to which the ToASCII >>>>> operation (see section 4) can be applied without failing (with the >>>>> UseSTD3ASCIIRules flag unset). ... >>>>> Although most Unicode characters can appear in >>>>> internationalized labels, ToASCII will fail for some input strings, >>>>> and such strings are not valid internationalized labels." >>>>> >>>>> "An "internationalized domain name" (IDN) is a domain name in which >>>>> every label is an internationalized label." >>>>> >>>>> [Section 4.1] >>>>> "ToASCII consists of the following steps: >>>>> >>>>> ... >>>>> >>>>> 8. Verify that the number of code points is in the range 1 to 63 >>>>> inclusive." >>>>> >>>>> >>>>> Here are the questions: >>>>> 1. whether "example..com" is an valid IDN? >>>>> As dot is used as label separators, there are three labels, >>>>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence, >>>>> "example..com" is not a valid IDN. >>>>> >>>>> We need to address the issue in IDN. >>>>> >>>>> 2. whether "xyz." is an valid IDN? >>>>> It's an gray area, I think. We can treat the trailing "." as root >>>>> label, or a label separator. >>>>> If the trailing "." is treated as label separator, "xyz." is >>>>> invalid >>>>> per RFC 3490. >>>>> if the trailing "." is treated as root label, what's the expected >>>>> return value of IDN.toASCII("xyz.")? I think the return value can be >>>>> either "xyz." or "xyz". The current implementation returns "xyz". >>>>> >>>>> We may need not to update the implementation if tailing "." is >>>>> treated as root label. >>>>> >>>>> 3. whether "." is an valid IDN? >>>>> It's an gray area again, I think. >>>>> As above, if the trailing "." is treated as root label, I think >>>>> the >>>>> return value can be either "." or "". The current implementation >>>>> throws >>>>> a StringIndexOutOfBoundsException. >>>>> >>>>> However, what empty domain name ("") really means? I would >>>>> prefer to >>>>> return "." for "." instead. >>>>> >>>>> We need to address the issue in IDN. >>>>> >>>>> >>>>> Here comes the solution, the IDN.toASCII() returns: >>>>> 1. "." for "."; >>>>> 2. "xyz" for "xyz."; >>>>> 3. IAE for "example..com". >>>>> >>>>> Does it make sense? >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> >>>>> On 8/7/2013 1:35 AM, Michael McMahon wrote: >>>>>> I don't really understand the reason for the restriction in >>>>>> SNIHostName >>>>>> But, I guess that is where it should be enforced if it is required. >>>>>> >>>>>> Michael. >>>>>> >>>>>> On 06/08/13 17:43, Dmitry Samersoff wrote: >>>>>>> Xuelei, >>>>>>> >>>>>>> . (dot) is perfectly valid domain name and it means root domain so >>>>>>> com. >>>>>>> is valid domain name as well. >>>>>>> >>>>>>> It thinks to me that in context of methods your change we should >>>>>>> ignore >>>>>>> trailing dots, rather than throw exception. >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2013-08-06 15:44, Xuelei Fan wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review the bug fix to strict the illegal input checking in >>>>>>>> IDN. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >>>>>>>> >>>>>>>> Here is two test cases, which are expected to get IAE. >>>>>>>> >>>>>>>> Case 1: >>>>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >>>>>>>> Exception in thread "main" >>>>>>>> java.lang.StringIndexOutOfBoundsException: >>>>>>>> String index out of range: 0 >>>>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >>>>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279) >>>>>>>> at java.net.IDN.toASCII(IDN.java:118) >>>>>>>> >>>>>>>> Case 2: >>>>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >> > From weijun.wang at oracle.com Thu Aug 8 18:22:53 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 09 Aug 2013 09:22:53 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52043AB3.6060704@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> Message-ID: <5204446D.7030603@oracle.com> I tried nslookup. Those with ".." inside are illegal, $ nslookup com.. nslookup: 'com..' is not a legal name (empty label) but $ nslookup . Server: 192.168.10.1 Address: 192.168.10.1#53 Non-authoritative answer: *** Can't find .: No answer Also, since this bug was originally about SNIHostName, do you need to add some extra restriction there to reject "oracle.com." things? Thanks Max On 8/9/13 8:41 AM, Xuelei Fan wrote: > Ping. > > Thanks, > Xuelei > > On 8/7/2013 11:17 PM, Xuelei Fan wrote: >> Please review the new update: >> >> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >> >> With this update, "com." is valid (return "com."); "." and >> "example..com" are invalid. And IAE will be thrown for invalid IDN. >> >> Thanks, >> Xuelei >> From xuelei.fan at oracle.com Thu Aug 8 18:37:01 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 09 Aug 2013 09:37:01 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5204446D.7030603@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> Message-ID: <520447BD.30206@oracle.com> On 8/9/2013 9:22 AM, Weijun Wang wrote: > I tried nslookup. Those with ".." inside are illegal, > > $ nslookup com.. > nslookup: 'com..' is not a legal name (empty label) > > but > > $ nslookup . > Server: 192.168.10.1 > Address: 192.168.10.1#53 > > Non-authoritative answer: > *** Can't find .: No answer > Thanks for the testing. The behaviors are the same as this fix now. Learn something new today to use nslookup. > Also, since this bug was originally about SNIHostName, do you need to > add some extra restriction there to reject "oracle.com." things? > No, we cannot restrict the format of IDN in SNIHostName more than in IDN. However, we may need to rethink about the comparing of two IDN, for example, "example.com." should equal to "example.com". I want to consider it in another bug. Can I push the changeset? Thanks, Xuelei > Thanks > Max > > On 8/9/13 8:41 AM, Xuelei Fan wrote: >> Ping. >> >> Thanks, >> Xuelei >> >> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>> Please review the new update: >>> >>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>> >>> With this update, "com." is valid (return "com."); "." and >>> "example..com" are invalid. And IAE will be thrown for invalid IDN. >>> >>> Thanks, >>> Xuelei >>> From weijun.wang at oracle.com Thu Aug 8 19:14:08 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 09 Aug 2013 10:14:08 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <520447BD.30206@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> Message-ID: <52045070.1000506@oracle.com> On 8/9/13 9:37 AM, Xuelei Fan wrote: > On 8/9/2013 9:22 AM, Weijun Wang wrote: >> I tried nslookup. Those with ".." inside are illegal, >> >> $ nslookup com.. >> nslookup: 'com..' is not a legal name (empty label) >> >> but >> >> $ nslookup . >> Server: 192.168.10.1 >> Address: 192.168.10.1#53 >> >> Non-authoritative answer: >> *** Can't find .: No answer >> > Thanks for the testing. The behaviors are the same as this fix now. No exactly. It seems nslookup still regards "." legal but just cannot find an IP for it. > > Learn something new today to use nslookup. > >> Also, since this bug was originally about SNIHostName, do you need to >> add some extra restriction there to reject "oracle.com." things? >> > No, we cannot restrict the format of IDN in SNIHostName more than in > IDN. However, we may need to rethink about the comparing of two IDN, for > example, "example.com." should equal to "example.com". I want to > consider it in another bug. Not sure. Does the spec say IDN and SNIHostName are equivalent sets? And it's not one is another's subset? > > Can I push the changeset? I think it's better to ask someone in the networking team to make the suggestion. From what I read Michael in this thread, he does not seem totally agreed with your code changes (at least not the 00 version). Thanks Max > > Thanks, > Xuelei > >> Thanks >> Max >> >> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>> Ping. >>> >>> Thanks, >>> Xuelei >>> >>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>> Please review the new update: >>>> >>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>> >>>> With this update, "com." is valid (return "com."); "." and >>>> "example..com" are invalid. And IAE will be thrown for invalid IDN. >>>> >>>> Thanks, >>>> Xuelei >>>> > From xuelei.fan at oracle.com Thu Aug 8 19:50:07 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 09 Aug 2013 10:50:07 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52045070.1000506@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> Message-ID: <520458DF.1030502@oracle.com> On 8/9/2013 10:14 AM, Weijun Wang wrote: > > > On 8/9/13 9:37 AM, Xuelei Fan wrote: >> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>> I tried nslookup. Those with ".." inside are illegal, >>> >>> $ nslookup com.. >>> nslookup: 'com..' is not a legal name (empty label) >>> >>> but >>> >>> $ nslookup . >>> Server: 192.168.10.1 >>> Address: 192.168.10.1#53 >>> >>> Non-authoritative answer: >>> *** Can't find .: No answer >>> >> Thanks for the testing. The behaviors are the same as this fix now. > > No exactly. It seems nslookup still regards "." legal but just cannot > find an IP for it. > I'm not sure whether a root domain name can be stand alone. Root label is not considered as a label in IDN. I think it is safe to regard that "." is not a valid IDN as it contains no label. Anyway, it is a corner case. There are many online IDN conversion web services, some of them can convert ".", some of the cannot. In the present implementation, we cannot recognize ".", and IDN.toASCII(".") throws StringIndexOutOfBoundsException. With this fix, I was wondering IAE is a better exception for IDN.toASCII("."). >> >> Learn something new today to use nslookup. >> >>> Also, since this bug was originally about SNIHostName, do you need to >>> add some extra restriction there to reject "oracle.com." things? >>> >> No, we cannot restrict the format of IDN in SNIHostName more than in >> IDN. However, we may need to rethink about the comparing of two IDN, for >> example, "example.com." should equal to "example.com". I want to >> consider it in another bug. > > Not sure. Does the spec say IDN and SNIHostName are equivalent sets? And > it's not one is another's subset? > Per TLS specification, host name in SNI is an IDN. The spec of SNIHostname says, "hostname is not a valid Internationalized Domain Name (IDN) compliant with the RFC 3490 specification". The spec in SNIHostName has the same means as IDN. I won't want to add additional restrict beyond the specification of an IDN. Xuelei >> >> Can I push the changeset? > > I think it's better to ask someone in the networking team to make the > suggestion. From what I read Michael in this thread, he does not seem > totally agreed with your code changes (at least not the 00 version). > > Thanks > Max > >> >> Thanks, >> Xuelei >> >>> Thanks >>> Max >>> >>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>> Ping. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>> Please review the new update: >>>>> >>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>> >>>>> With this update, "com." is valid (return "com."); "." and >>>>> "example..com" are invalid. And IAE will be thrown for invalid IDN. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >> From mhall at mhcomputing.net Thu Aug 8 20:24:41 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 08 Aug 2013 20:24:41 -0700 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <520458DF.1030502@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> Message-ID: But, DNS considers "." as the valid root zone... -- Sent from my mobile device. Xuelei Fan wrote: >On 8/9/2013 10:14 AM, Weijun Wang wrote: >> >> >> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>> I tried nslookup. Those with ".." inside are illegal, >>>> >>>> $ nslookup com.. >>>> nslookup: 'com..' is not a legal name (empty label) >>>> >>>> but >>>> >>>> $ nslookup . >>>> Server: 192.168.10.1 >>>> Address: 192.168.10.1#53 >>>> >>>> Non-authoritative answer: >>>> *** Can't find .: No answer >>>> >>> Thanks for the testing. The behaviors are the same as this fix now. >> >> No exactly. It seems nslookup still regards "." legal but just cannot >> find an IP for it. >> >I'm not sure whether a root domain name can be stand alone. Root label >is not considered as a label in IDN. I think it is safe to regard that >"." is not a valid IDN as it contains no label. Anyway, it is a corner >case. > >There are many online IDN conversion web services, some of them can >convert ".", some of the cannot. In the present implementation, we >cannot recognize ".", and IDN.toASCII(".") throws >StringIndexOutOfBoundsException. With this fix, I was wondering IAE is >a better exception for IDN.toASCII("."). > >>> >>> Learn something new today to use nslookup. >>> >>>> Also, since this bug was originally about SNIHostName, do you need >to >>>> add some extra restriction there to reject "oracle.com." things? >>>> >>> No, we cannot restrict the format of IDN in SNIHostName more than in >>> IDN. However, we may need to rethink about the comparing of two IDN, >for >>> example, "example.com." should equal to "example.com". I want to >>> consider it in another bug. >> >> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? >And >> it's not one is another's subset? >> >Per TLS specification, host name in SNI is an IDN. The spec of >SNIHostname says, "hostname is not a valid Internationalized Domain >Name >(IDN) compliant with the RFC 3490 specification". The spec in >SNIHostName has the same means as IDN. I won't want to add additional >restrict beyond the specification of an IDN. > >Xuelei > >>> >>> Can I push the changeset? >> >> I think it's better to ask someone in the networking team to make the >> suggestion. From what I read Michael in this thread, he does not seem >> totally agreed with your code changes (at least not the 00 version). >> >> Thanks >> Max >> >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>> Ping. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>> Please review the new update: >>>>>> >>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>> >>>>>> With this update, "com." is valid (return "com."); "." and >>>>>> "example..com" are invalid. And IAE will be thrown for invalid >IDN. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>> From weijun.wang at oracle.com Thu Aug 8 20:42:53 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Fri, 09 Aug 2013 03:42:53 +0000 Subject: hg: jdk8/tl/jdk: 8021788: JarInputStream doesn't provide certificates for some file under META-INF Message-ID: <20130809034314.C36B848735@hg.openjdk.java.net> Changeset: 758e3117899c Author: weijun Date: 2013-08-09 11:41 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/758e3117899c 8021788: JarInputStream doesn't provide certificates for some file under META-INF Reviewed-by: chegar, sherman ! src/share/classes/java/util/jar/JarVerifier.java + test/java/util/jar/JarInputStream/ExtraFileInMetaInf.java From xuelei.fan at oracle.com Thu Aug 8 20:45:18 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 09 Aug 2013 11:45:18 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> Message-ID: <520465CE.5020000@oracle.com> On 8/9/2013 11:24 AM, Matthew Hall wrote: > But, DNS considers "." as the valid root zone... > Good! Looks like that IDN.toASCII(".") should returns ".", so that a general domain name can always use IDN.toASCII() conversion instead of throwing runtime exception. Xuelei From xuelei.fan at oracle.com Thu Aug 8 21:28:35 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 09 Aug 2013 12:28:35 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <520458DF.1030502@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> Message-ID: <52046FF3.1040903@oracle.com> Thanks for your feedback and suggestions. Here is the new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ "." is regarded as valid IDN in this update. Thanks, Xuelei On 8/9/2013 10:50 AM, Xuelei Fan wrote: > On 8/9/2013 10:14 AM, Weijun Wang wrote: >> >> >> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>> I tried nslookup. Those with ".." inside are illegal, >>>> >>>> $ nslookup com.. >>>> nslookup: 'com..' is not a legal name (empty label) >>>> >>>> but >>>> >>>> $ nslookup . >>>> Server: 192.168.10.1 >>>> Address: 192.168.10.1#53 >>>> >>>> Non-authoritative answer: >>>> *** Can't find .: No answer >>>> >>> Thanks for the testing. The behaviors are the same as this fix now. >> >> No exactly. It seems nslookup still regards "." legal but just cannot >> find an IP for it. >> > I'm not sure whether a root domain name can be stand alone. Root label > is not considered as a label in IDN. I think it is safe to regard that > "." is not a valid IDN as it contains no label. Anyway, it is a corner > case. > > There are many online IDN conversion web services, some of them can > convert ".", some of the cannot. In the present implementation, we > cannot recognize ".", and IDN.toASCII(".") throws > StringIndexOutOfBoundsException. With this fix, I was wondering IAE is > a better exception for IDN.toASCII("."). > >>> >>> Learn something new today to use nslookup. >>> >>>> Also, since this bug was originally about SNIHostName, do you need to >>>> add some extra restriction there to reject "oracle.com." things? >>>> >>> No, we cannot restrict the format of IDN in SNIHostName more than in >>> IDN. However, we may need to rethink about the comparing of two IDN, for >>> example, "example.com." should equal to "example.com". I want to >>> consider it in another bug. >> >> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? And >> it's not one is another's subset? >> > Per TLS specification, host name in SNI is an IDN. The spec of > SNIHostname says, "hostname is not a valid Internationalized Domain Name > (IDN) compliant with the RFC 3490 specification". The spec in > SNIHostName has the same means as IDN. I won't want to add additional > restrict beyond the specification of an IDN. > > Xuelei > >>> >>> Can I push the changeset? >> >> I think it's better to ask someone in the networking team to make the >> suggestion. From what I read Michael in this thread, he does not seem >> totally agreed with your code changes (at least not the 00 version). >> >> Thanks >> Max >> >>> >>> Thanks, >>> Xuelei >>> >>>> Thanks >>>> Max >>>> >>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>> Ping. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>> Please review the new update: >>>>>> >>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>> >>>>>> With this update, "com." is valid (return "com."); "." and >>>>>> "example..com" are invalid. And IAE will be thrown for invalid IDN. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>> > From david.holmes at oracle.com Thu Aug 8 22:21:42 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Aug 2013 15:21:42 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52041988.80705@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> Message-ID: <52047C66.2080001@oracle.com> Thumbs up! Thanks, David On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: > Thanks David! > > On 09.08.2013 1:15, David Holmes wrote: >> Main fix looks good to me. >> >> Regression test may need some tweaking eg I think othervm will be needed. >> > Yes, it's a good point. > Since there may be a memory leak in the test, it'd better not interfere > with other tests in jtreg. > >> Also this: >> >> System.out.println("WARNING: Cannot perform memory leak detection on >> this OS"); >> >> should probably just say something like "Test skipped on this OS" - >> there are other tests that do this so just check if there is common >> terminology. (In the future we may have keyword tags to flag this as >> linux only etc.) >> > OK, I changed the phrase to "Test only runs on Linux". > > Updated webrev is here: > http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ > > Updated export is at the same place: > http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch > > > Sincerely yours, > Ivan > > >> Thanks, >> David >> >> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>> >>> Here's webrev that includes the test: >>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>> >>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and jdk7 >>> as expected. >>> >>> Sincerely yours, >>> Ivan >>> >>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>> Looks good to me. Thanks Ivan. >>>> >>>> -Chris. >>>> >>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>> Hello Chris! >>>>> >>>>> Here's the update: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>> >>>>> Thanks for offering the sponsorship! >>>>> Here's the hg-export >>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>> >>>>> >>>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>> Thanks for taking this Ivan. >>>>>> >>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if GetStringUTFChars >>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 for >>>>>> you. >>>>>> >>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>> Ivan, >>>>>>> >>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>> David, Alan, >>>>>>>> >>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>> necessary. >>>>>>> >>>>>>> You don't need to throw it yourself: >>>>>>> >>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>> >>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>> OOME >>>>>>> should already be pending and will be thrown as soon as your native >>>>>>> code >>>>>>> returns to Java. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> I've also added some spaces along the code to improve indentation. >>>>>>>> >>>>>>>> Would you please review the updated webrev? >>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>> Thanks Alan! >>>>>>>>>> >>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>>>> return >>>>>>>>>> NULL. >>>>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>>>> the >>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>>>> VM. >>>>>>>>> >>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>> throw >>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>> >>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>> >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>> >>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>> there) is >>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>> returns >>>>>>>>>>> when it fails with NULL. >>>>>>>>>>> >>>>>>>>>>> -Alan. >>>>>>>>>>> >>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>> Hello everybody! >>>>>>>>>>>> >>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>> memory. >>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>> available.) >>>>>>>>>>>> >>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>> >>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>> >>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>> unnecessary >>>>>>>>>>>> allocation? >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > From david.holmes at oracle.com Thu Aug 8 22:47:21 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Aug 2013 15:47:21 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52047C66.2080001@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> Message-ID: <52048269.7000501@oracle.com> Sorry I messed this up. The JNI book says GetStringUTFChars will return NULL and post OOME but the JNI spec (latest version 6.0) does not - it only says it will return NULL on failure. So your previous version was the more correct. Given we just failed to allocate C-heap I think we are on thin ice anyway, but better to at least attempt to do the right thing. FYI I filed 8022683 to fix GetStringUTFChars. David ----- On 9/08/2013 3:21 PM, David Holmes wrote: > Thumbs up! > > Thanks, > David > > On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >> Thanks David! >> >> On 09.08.2013 1:15, David Holmes wrote: >>> Main fix looks good to me. >>> >>> Regression test may need some tweaking eg I think othervm will be >>> needed. >>> >> Yes, it's a good point. >> Since there may be a memory leak in the test, it'd better not interfere >> with other tests in jtreg. >> >>> Also this: >>> >>> System.out.println("WARNING: Cannot perform memory leak detection on >>> this OS"); >>> >>> should probably just say something like "Test skipped on this OS" - >>> there are other tests that do this so just check if there is common >>> terminology. (In the future we may have keyword tags to flag this as >>> linux only etc.) >>> >> OK, I changed the phrase to "Test only runs on Linux". >> >> Updated webrev is here: >> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >> >> Updated export is at the same place: >> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >> >> >> >> Sincerely yours, >> Ivan >> >> >>> Thanks, >>> David >>> >>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>>> >>>> Here's webrev that includes the test: >>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>> >>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>> jdk7 >>>> as expected. >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>> Looks good to me. Thanks Ivan. >>>>> >>>>> -Chris. >>>>> >>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>> Hello Chris! >>>>>> >>>>>> Here's the update: >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>> >>>>>> Thanks for offering the sponsorship! >>>>>> Here's the hg-export >>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>> Thanks for taking this Ivan. >>>>>>> >>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>> GetStringUTFChars >>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>>> for >>>>>>> you. >>>>>>> >>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>> Ivan, >>>>>>>> >>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>> David, Alan, >>>>>>>>> >>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>> necessary. >>>>>>>> >>>>>>>> You don't need to throw it yourself: >>>>>>>> >>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>> >>>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>>> OOME >>>>>>>> should already be pending and will be thrown as soon as your native >>>>>>>> code >>>>>>>> returns to Java. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> I've also added some spaces along the code to improve indentation. >>>>>>>>> >>>>>>>>> Would you please review the updated webrev? >>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>> Thanks Alan! >>>>>>>>>>> >>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars cannot >>>>>>>>>>> return >>>>>>>>>>> NULL. >>>>>>>>>>> For allocation of the result string it calls AllocateHeap() with >>>>>>>>>>> the >>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>> Thus, in case of being unable to allocate memory it simply stops >>>>>>>>>>> VM. >>>>>>>>>> >>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>> throw >>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>> >>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>> >>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>> there) is >>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>> returns >>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>> >>>>>>>>>>>> -Alan. >>>>>>>>>>>> >>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>> >>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>> memory. >>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>> available.) >>>>>>>>>>>>> >>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>> >>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>> >>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>> unnecessary >>>>>>>>>>>>> allocation? >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> >> From dmitry.samersoff at oracle.com Thu Aug 8 23:08:19 2013 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Fri, 09 Aug 2013 10:08:19 +0400 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52043AB3.6060704@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> Message-ID: <52048753.4040208@oracle.com> Xuelei, 119 p = q + 1; 120 if (p < input.length() || q == (input.length() - 1)) { Could be simplified to: q <= input.length()-1 -Dmitry On 2013-08-09 04:41, Xuelei Fan wrote: > Ping. > > Thanks, > Xuelei > > On 8/7/2013 11:17 PM, Xuelei Fan wrote: >> Please review the new update: >> >> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >> >> With this update, "com." is valid (return "com."); "." and >> "example..com" are invalid. And IAE will be thrown for invalid IDN. >> >> Thanks, >> Xuelei >> >> On 8/7/2013 10:18 PM, Michael McMahon wrote: >>> On 07/08/13 15:13, Xuelei Fan wrote: >>>> On 8/7/2013 10:05 PM, Michael McMahon wrote: >>>>> Resolvers seem to accept queries using trailing dots. >>>>> >>>>> eg nslookup www.oracle.com. >>>>> >>>>> or InetAddress.getByName("www.oracle.com."); >>>>> >>>>> The part of RFC3490 quoted below seems to me to be saying >>>>> that the empty label implied by the trailing dot is not regarded >>>>> as a label so that you don't end up calling toAscii() or toUnicode() >>>>> with an empty string. I don't think it's saying the trailing dot can't >>>>> be there. >>>>> >>>> It makes sense. >>>> >>>> What's your preference to return for IDN.toASCII("www.oracle.com."), >>>> "www.oracle.com." or "www.oracle.com"? The current returned value is >>>> "www.oracle.com". I would like to reserve the behavior in this update. >>> >>> My opinion is to keep it as at present ie. "www.oracle.com." >>> >>> Michael >>> >>>> I think we are on same page soon. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Michael >>>>> >>>>> On 07/08/13 13:44, Xuelei Fan wrote: >>>>>> On 8/7/2013 12:06 AM, Matthew Hall wrote: >>>>>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN), >>>>>>> and the single dot represents the root zone. So you have to be >>>>>>> careful making this sort of change to check the DNS RFCs first. >>>>>> That's the first question we need to answer, whether IDN allow tailling >>>>>> dots ("com."), zero-length root label ("."), and zero-length label ("", >>>>>> for example ""example..com")? >>>>>> >>>>>> Per the specification of IDN.toASCII(): >>>>>> ======================================= >>>>>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If >>>>>> ToASCII operation fails, an IllegalArgumentException will be thrown. In >>>>>> this case, the input string should not be used in an internationalized >>>>>> domain name. >>>>>> >>>>>> A label is an individual part of a domain name. The original ToASCII >>>>>> operation, as defined in RFC 3490, only operates on a single label. >>>>>> This >>>>>> method can handle both label and entire domain name, by assuming that >>>>>> labels in a domain name are always separated by dots. ... >>>>>> >>>>>> Throws IllegalArgumentException - if the input string doesn't >>>>>> conform to >>>>>> RFC 3490 specification" >>>>>> >>>>>> Per the specification of RFC 3490: >>>>>> ================================== >>>>>> [section 2] >>>>>> "A label is an individual part of a domain name. Labels are usually >>>>>> shown separated by dots; for example, the domain name >>>>>> "www.example.com" is composed of three labels: "www", "example", and >>>>>> "com". (The zero-length root label described in [STD13], which can >>>>>> be explicit as in "www.example.com." or implicit as in >>>>>> "www.example.com", is not considered a label in this >>>>>> specification.)" >>>>>> >>>>>> "An "internationalized label" is a label to which the ToASCII >>>>>> operation (see section 4) can be applied without failing (with the >>>>>> UseSTD3ASCIIRules flag unset). ... >>>>>> Although most Unicode characters can appear in >>>>>> internationalized labels, ToASCII will fail for some input strings, >>>>>> and such strings are not valid internationalized labels." >>>>>> >>>>>> "An "internationalized domain name" (IDN) is a domain name in which >>>>>> every label is an internationalized label." >>>>>> >>>>>> [Section 4.1] >>>>>> "ToASCII consists of the following steps: >>>>>> >>>>>> ... >>>>>> >>>>>> 8. Verify that the number of code points is in the range 1 to 63 >>>>>> inclusive." >>>>>> >>>>>> >>>>>> Here are the questions: >>>>>> 1. whether "example..com" is an valid IDN? >>>>>> As dot is used as label separators, there are three labels, >>>>>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence, >>>>>> "example..com" is not a valid IDN. >>>>>> >>>>>> We need to address the issue in IDN. >>>>>> >>>>>> 2. whether "xyz." is an valid IDN? >>>>>> It's an gray area, I think. We can treat the trailing "." as root >>>>>> label, or a label separator. >>>>>> If the trailing "." is treated as label separator, "xyz." is >>>>>> invalid >>>>>> per RFC 3490. >>>>>> if the trailing "." is treated as root label, what's the expected >>>>>> return value of IDN.toASCII("xyz.")? I think the return value can be >>>>>> either "xyz." or "xyz". The current implementation returns "xyz". >>>>>> >>>>>> We may need not to update the implementation if tailing "." is >>>>>> treated as root label. >>>>>> >>>>>> 3. whether "." is an valid IDN? >>>>>> It's an gray area again, I think. >>>>>> As above, if the trailing "." is treated as root label, I think >>>>>> the >>>>>> return value can be either "." or "". The current implementation >>>>>> throws >>>>>> a StringIndexOutOfBoundsException. >>>>>> >>>>>> However, what empty domain name ("") really means? I would >>>>>> prefer to >>>>>> return "." for "." instead. >>>>>> >>>>>> We need to address the issue in IDN. >>>>>> >>>>>> >>>>>> Here comes the solution, the IDN.toASCII() returns: >>>>>> 1. "." for "."; >>>>>> 2. "xyz" for "xyz."; >>>>>> 3. IAE for "example..com". >>>>>> >>>>>> Does it make sense? >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> >>>>>> On 8/7/2013 1:35 AM, Michael McMahon wrote: >>>>>>> I don't really understand the reason for the restriction in >>>>>>> SNIHostName >>>>>>> But, I guess that is where it should be enforced if it is required. >>>>>>> >>>>>>> Michael. >>>>>>> >>>>>>> On 06/08/13 17:43, Dmitry Samersoff wrote: >>>>>>>> Xuelei, >>>>>>>> >>>>>>>> . (dot) is perfectly valid domain name and it means root domain so >>>>>>>> com. >>>>>>>> is valid domain name as well. >>>>>>>> >>>>>>>> It thinks to me that in context of methods your change we should >>>>>>>> ignore >>>>>>>> trailing dots, rather than throw exception. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2013-08-06 15:44, Xuelei Fan wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review the bug fix to strict the illegal input checking in >>>>>>>>> IDN. >>>>>>>>> >>>>>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >>>>>>>>> >>>>>>>>> Here is two test cases, which are expected to get IAE. >>>>>>>>> >>>>>>>>> Case 1: >>>>>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >>>>>>>>> Exception in thread "main" >>>>>>>>> java.lang.StringIndexOutOfBoundsException: >>>>>>>>> String index out of range: 0 >>>>>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >>>>>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279) >>>>>>>>> at java.net.IDN.toASCII(IDN.java:118) >>>>>>>>> >>>>>>>>> Case 2: >>>>>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From Xuelei.Fan at Oracle.Com Fri Aug 9 00:09:33 2013 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Fri, 9 Aug 2013 15:09:33 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52048753.4040208@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <52048753.4040208@oracle.com> Message-ID: On Aug 9, 2013, at 14:08, Dmitry Samersoff wrote: > Xuelei, > > 119 p = q + 1; > 120 if (p < input.length() || q == (input.length() - 1)) { > > Could be simplified to: > > q <= input.length()-1 > It's cool! Xuelei > -Dmitry > > On 2013-08-09 04:41, Xuelei Fan wrote: >> Ping. >> >> Thanks, >> Xuelei >> >> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>> Please review the new update: >>> >>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>> >>> With this update, "com." is valid (return "com."); "." and >>> "example..com" are invalid. And IAE will be thrown for invalid IDN. >>> >>> Thanks, >>> Xuelei >>> >>> On 8/7/2013 10:18 PM, Michael McMahon wrote: >>>> On 07/08/13 15:13, Xuelei Fan wrote: >>>>> On 8/7/2013 10:05 PM, Michael McMahon wrote: >>>>>> Resolvers seem to accept queries using trailing dots. >>>>>> >>>>>> eg nslookup www.oracle.com. >>>>>> >>>>>> or InetAddress.getByName("www.oracle.com."); >>>>>> >>>>>> The part of RFC3490 quoted below seems to me to be saying >>>>>> that the empty label implied by the trailing dot is not regarded >>>>>> as a label so that you don't end up calling toAscii() or toUnicode() >>>>>> with an empty string. I don't think it's saying the trailing dot can't >>>>>> be there. >>>>> It makes sense. >>>>> >>>>> What's your preference to return for IDN.toASCII("www.oracle.com."), >>>>> "www.oracle.com." or "www.oracle.com"? The current returned value is >>>>> "www.oracle.com". I would like to reserve the behavior in this update. >>>> >>>> My opinion is to keep it as at present ie. "www.oracle.com." >>>> >>>> Michael >>>> >>>>> I think we are on same page soon. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> Michael >>>>>> >>>>>> On 07/08/13 13:44, Xuelei Fan wrote: >>>>>>> On 8/7/2013 12:06 AM, Matthew Hall wrote: >>>>>>>> Trailing dots are allowed in plain DNS (thus almost surely in IDN), >>>>>>>> and the single dot represents the root zone. So you have to be >>>>>>>> careful making this sort of change to check the DNS RFCs first. >>>>>>> That's the first question we need to answer, whether IDN allow tailling >>>>>>> dots ("com."), zero-length root label ("."), and zero-length label ("", >>>>>>> for example ""example..com")? >>>>>>> >>>>>>> Per the specification of IDN.toASCII(): >>>>>>> ======================================= >>>>>>> "ToASCII operation can fail. ToASCII fails if any step of it fails. If >>>>>>> ToASCII operation fails, an IllegalArgumentException will be thrown. In >>>>>>> this case, the input string should not be used in an internationalized >>>>>>> domain name. >>>>>>> >>>>>>> A label is an individual part of a domain name. The original ToASCII >>>>>>> operation, as defined in RFC 3490, only operates on a single label. >>>>>>> This >>>>>>> method can handle both label and entire domain name, by assuming that >>>>>>> labels in a domain name are always separated by dots. ... >>>>>>> >>>>>>> Throws IllegalArgumentException - if the input string doesn't >>>>>>> conform to >>>>>>> RFC 3490 specification" >>>>>>> >>>>>>> Per the specification of RFC 3490: >>>>>>> ================================== >>>>>>> [section 2] >>>>>>> "A label is an individual part of a domain name. Labels are usually >>>>>>> shown separated by dots; for example, the domain name >>>>>>> "www.example.com" is composed of three labels: "www", "example", and >>>>>>> "com". (The zero-length root label described in [STD13], which can >>>>>>> be explicit as in "www.example.com." or implicit as in >>>>>>> "www.example.com", is not considered a label in this >>>>>>> specification.)" >>>>>>> >>>>>>> "An "internationalized label" is a label to which the ToASCII >>>>>>> operation (see section 4) can be applied without failing (with the >>>>>>> UseSTD3ASCIIRules flag unset). ... >>>>>>> Although most Unicode characters can appear in >>>>>>> internationalized labels, ToASCII will fail for some input strings, >>>>>>> and such strings are not valid internationalized labels." >>>>>>> >>>>>>> "An "internationalized domain name" (IDN) is a domain name in which >>>>>>> every label is an internationalized label." >>>>>>> >>>>>>> [Section 4.1] >>>>>>> "ToASCII consists of the following steps: >>>>>>> >>>>>>> ... >>>>>>> >>>>>>> 8. Verify that the number of code points is in the range 1 to 63 >>>>>>> inclusive." >>>>>>> >>>>>>> >>>>>>> Here are the questions: >>>>>>> 1. whether "example..com" is an valid IDN? >>>>>>> As dot is used as label separators, there are three labels, >>>>>>> "example", "", "com". Per RFC 3490, "" is not a valid label. Hence, >>>>>>> "example..com" is not a valid IDN. >>>>>>> >>>>>>> We need to address the issue in IDN. >>>>>>> >>>>>>> 2. whether "xyz." is an valid IDN? >>>>>>> It's an gray area, I think. We can treat the trailing "." as root >>>>>>> label, or a label separator. >>>>>>> If the trailing "." is treated as label separator, "xyz." is >>>>>>> invalid >>>>>>> per RFC 3490. >>>>>>> if the trailing "." is treated as root label, what's the expected >>>>>>> return value of IDN.toASCII("xyz.")? I think the return value can be >>>>>>> either "xyz." or "xyz". The current implementation returns "xyz". >>>>>>> >>>>>>> We may need not to update the implementation if tailing "." is >>>>>>> treated as root label. >>>>>>> >>>>>>> 3. whether "." is an valid IDN? >>>>>>> It's an gray area again, I think. >>>>>>> As above, if the trailing "." is treated as root label, I think >>>>>>> the >>>>>>> return value can be either "." or "". The current implementation >>>>>>> throws >>>>>>> a StringIndexOutOfBoundsException. >>>>>>> >>>>>>> However, what empty domain name ("") really means? I would >>>>>>> prefer to >>>>>>> return "." for "." instead. >>>>>>> >>>>>>> We need to address the issue in IDN. >>>>>>> >>>>>>> >>>>>>> Here comes the solution, the IDN.toASCII() returns: >>>>>>> 1. "." for "."; >>>>>>> 2. "xyz" for "xyz."; >>>>>>> 3. IAE for "example..com". >>>>>>> >>>>>>> Does it make sense? >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> >>>>>>> On 8/7/2013 1:35 AM, Michael McMahon wrote: >>>>>>>> I don't really understand the reason for the restriction in >>>>>>>> SNIHostName >>>>>>>> But, I guess that is where it should be enforced if it is required. >>>>>>>> >>>>>>>> Michael. >>>>>>>> >>>>>>>> On 06/08/13 17:43, Dmitry Samersoff wrote: >>>>>>>>> Xuelei, >>>>>>>>> >>>>>>>>> . (dot) is perfectly valid domain name and it means root domain so >>>>>>>>> com. >>>>>>>>> is valid domain name as well. >>>>>>>>> >>>>>>>>> It thinks to me that in context of methods your change we should >>>>>>>>> ignore >>>>>>>>> trailing dots, rather than throw exception. >>>>>>>>> >>>>>>>>> -Dmitry >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2013-08-06 15:44, Xuelei Fan wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review the bug fix to strict the illegal input checking in >>>>>>>>>> IDN. >>>>>>>>>> >>>>>>>>>> webrev: http://cr.openjdk.java.net./~xuelei/8020842/webrev.00/ >>>>>>>>>> >>>>>>>>>> Here is two test cases, which are expected to get IAE. >>>>>>>>>> >>>>>>>>>> Case 1: >>>>>>>>>> String host = IDN.toASCII(".", IDN.USE_STD3_ASCII_RULES); >>>>>>>>>> Exception in thread "main" >>>>>>>>>> java.lang.StringIndexOutOfBoundsException: >>>>>>>>>> String index out of range: 0 >>>>>>>>>> at java.lang.StringBuffer.charAt(StringBuffer.java:204) >>>>>>>>>> at java.net.IDN.toASCIIInternal(IDN.java:279) >>>>>>>>>> at java.net.IDN.toASCII(IDN.java:118) >>>>>>>>>> >>>>>>>>>> Case 2: >>>>>>>>>> String host = IDN.toASCII("com.", IDN.USE_STD3_ASCII_RULES); >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the source code. From xueming.shen at oracle.com Thu Aug 8 23:39:17 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 09 Aug 2013 06:39:17 +0000 Subject: hg: jdk8/tl/jdk: 6614237: missing codepage Cp290 at java runtime Message-ID: <20130809063942.0D9734873B@hg.openjdk.java.net> Changeset: 54f0ccdd9ad7 Author: sherman Date: 2013-08-08 23:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/54f0ccdd9ad7 6614237: missing codepage Cp290 at java runtime Summary: to add charset Cp290 and Cp300 Reviewed-by: okutsu + make/tools/CharsetMapping/IBM290.c2b + make/tools/CharsetMapping/IBM290.map + make/tools/CharsetMapping/IBM300.c2b + make/tools/CharsetMapping/IBM300.map ! make/tools/CharsetMapping/dbcs ! make/tools/CharsetMapping/extsbcs ! make/tools/src/build/tools/charsetmapping/DBCS.java ! src/share/classes/sun/nio/cs/ext/ExtendedCharsets.java From chris.hegarty at oracle.com Fri Aug 9 00:25:47 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 Aug 2013 08:25:47 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52048269.7000501@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> Message-ID: <5204997B.3090601@oracle.com> On 09/08/2013 06:47, David Holmes wrote: > Sorry I messed this up. The JNI book says GetStringUTFChars will return > NULL and post OOME but the JNI spec (latest version 6.0) does not - it > only says it will return NULL on failure. This is indeed strange. Most usages of this function in the jdk expect the former. If this is not the case, then we may need to do an audit of all usages. > So your previous version was the more correct. Given we just failed to > allocate C-heap I think we are on thin ice anyway, but better to at > least attempt to do the right thing. I'm not sure what the right thing to do here is? It seems a little unwieldy! if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { if ((*env)->ExceptionOccurred(env)) { return NULL/JNI_False/-1; } else { throwException(env, "java/lang/InternalError", "GetStringUTFChars failed"); return NULL/JNI_False/-1; } Given we have no idea why GetStringUTFChars may have failed, what exception do we throw? Also worth noting is that this bug fix has moved away from the original problem (memory leak), and is now focused on code cleanup. If we cannot get agreement on the cleanup, or it looks like more clarification is needed around the cleanup effort, then I would like to suggest that we proceed with the original fix for the memory leak and separate out the cleanup effort. -Chris. > FYI I filed 8022683 to fix GetStringUTFChars. > > David > ----- > > On 9/08/2013 3:21 PM, David Holmes wrote: >> Thumbs up! >> >> Thanks, >> David >> >> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>> Thanks David! >>> >>> On 09.08.2013 1:15, David Holmes wrote: >>>> Main fix looks good to me. >>>> >>>> Regression test may need some tweaking eg I think othervm will be >>>> needed. >>>> >>> Yes, it's a good point. >>> Since there may be a memory leak in the test, it'd better not interfere >>> with other tests in jtreg. >>> >>>> Also this: >>>> >>>> System.out.println("WARNING: Cannot perform memory leak detection on >>>> this OS"); >>>> >>>> should probably just say something like "Test skipped on this OS" - >>>> there are other tests that do this so just check if there is common >>>> terminology. (In the future we may have keyword tags to flag this as >>>> linux only etc.) >>>> >>> OK, I changed the phrase to "Test only runs on Linux". >>> >>> Updated webrev is here: >>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>> >>> Updated export is at the same place: >>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>> >>> >>> >>> >>> Sincerely yours, >>> Ivan >>> >>> >>>> Thanks, >>>> David >>>> >>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>> Chris, if it's not too late, I'd like to include a regtest in the fix. >>>>> >>>>> Here's webrev that includes the test: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>> >>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>>> jdk7 >>>>> as expected. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>> Looks good to me. Thanks Ivan. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>> Hello Chris! >>>>>>> >>>>>>> Here's the update: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>> >>>>>>> Thanks for offering the sponsorship! >>>>>>> Here's the hg-export >>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>> Thanks for taking this Ivan. >>>>>>>> >>>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>> GetStringUTFChars >>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>>>> for >>>>>>>> you. >>>>>>>> >>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>> Ivan, >>>>>>>>> >>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>> David, Alan, >>>>>>>>>> >>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>> necessary. >>>>>>>>> >>>>>>>>> You don't need to throw it yourself: >>>>>>>>> >>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>> >>>>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>>>> OOME >>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>> native >>>>>>>>> code >>>>>>>>> returns to Java. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>> indentation. >>>>>>>>>> >>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>> >>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>> cannot >>>>>>>>>>>> return >>>>>>>>>>>> NULL. >>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>> with >>>>>>>>>>>> the >>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>> stops >>>>>>>>>>>> VM. >>>>>>>>>>> >>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>>> throw >>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>> >>>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>> >>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>> there) is >>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>> returns >>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>> >>>>>>>>>>>>> -Alan. >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>>> memory. >>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>> available.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> From chris.hegarty at oracle.com Fri Aug 9 02:23:02 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 Aug 2013 10:23:02 +0100 Subject: RFR 8022661: InetAddress.writeObject() performs flush() on object output stream Message-ID: <5204B4F6.9090102@oracle.com> This is a trivial change to remove the unnecessary flush from InetAddress.writeObject(). The flush can have a negative affect if the ObjectOutputStream is wrapping an underlying Socket stream. diff -r 662115496d6b src/share/classes/java/net/InetAddress.java --- a/src/share/classes/java/net/InetAddress.java Thu Aug 08 17:28:00 2013 +0400 +++ b/src/share/classes/java/net/InetAddress.java Fri Aug 09 10:17:11 2013 +0100 @@ -1601,7 +1601,6 @@ class InetAddress implements java.io.Ser pf.put("address", holder().getAddress()); pf.put("family", holder().getFamily()); s.writeFields(); - s.flush(); } } -Chris. From ivan.gerasimov at oracle.com Fri Aug 9 02:27:15 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Fri, 09 Aug 2013 13:27:15 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204997B.3090601@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> Message-ID: <5204B5F3.6000506@oracle.com> Chris, I would use this if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); return NULL/JNI_False/-1; } If I understand it correctly, JNU_ThrowOutOfMemoryError throws an exception only if it hasn't been already thrown. Sincerely yours, Ivan On 09.08.2013 11:25, Chris Hegarty wrote: > On 09/08/2013 06:47, David Holmes wrote: >> Sorry I messed this up. The JNI book says GetStringUTFChars will return >> NULL and post OOME but the JNI spec (latest version 6.0) does not - it >> only says it will return NULL on failure. > > This is indeed strange. Most usages of this function in the jdk expect > the former. If this is not the case, then we may need to do an audit > of all usages. > >> So your previous version was the more correct. Given we just failed to >> allocate C-heap I think we are on thin ice anyway, but better to at >> least attempt to do the right thing. > > I'm not sure what the right thing to do here is? It seems a little > unwieldy! > > if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == > NULL) { > if ((*env)->ExceptionOccurred(env)) { > return NULL/JNI_False/-1; > } else { > throwException(env, "java/lang/InternalError", > "GetStringUTFChars failed"); > return NULL/JNI_False/-1; > } > > Given we have no idea why GetStringUTFChars may have failed, what > exception do we throw? > > Also worth noting is that this bug fix has moved away from the > original problem (memory leak), and is now focused on code cleanup. > > If we cannot get agreement on the cleanup, or it looks like more > clarification is needed around the cleanup effort, then I would like > to suggest that we proceed with the original fix for the memory leak > and separate out the cleanup effort. > > -Chris. > >> FYI I filed 8022683 to fix GetStringUTFChars. >> >> David >> ----- >> >> On 9/08/2013 3:21 PM, David Holmes wrote: >>> Thumbs up! >>> >>> Thanks, >>> David >>> >>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>> Thanks David! >>>> >>>> On 09.08.2013 1:15, David Holmes wrote: >>>>> Main fix looks good to me. >>>>> >>>>> Regression test may need some tweaking eg I think othervm will be >>>>> needed. >>>>> >>>> Yes, it's a good point. >>>> Since there may be a memory leak in the test, it'd better not >>>> interfere >>>> with other tests in jtreg. >>>> >>>>> Also this: >>>>> >>>>> System.out.println("WARNING: Cannot perform memory leak detection on >>>>> this OS"); >>>>> >>>>> should probably just say something like "Test skipped on this OS" - >>>>> there are other tests that do this so just check if there is common >>>>> terminology. (In the future we may have keyword tags to flag this as >>>>> linux only etc.) >>>>> >>>> OK, I changed the phrase to "Test only runs on Linux". >>>> >>>> Updated webrev is here: >>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>> >>>> Updated export is at the same place: >>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>> >>>> >>>> >>>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>> fix. >>>>>> >>>>>> Here's webrev that includes the test: >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>> >>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>>>> jdk7 >>>>>> as expected. >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>> Looks good to me. Thanks Ivan. >>>>>>> >>>>>>> -Chris. >>>>>>> >>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>> Hello Chris! >>>>>>>> >>>>>>>> Here's the update: >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>> >>>>>>>> Thanks for offering the sponsorship! >>>>>>>> Here's the hg-export >>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>> Thanks for taking this Ivan. >>>>>>>>> >>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>> Alan ( >>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>> GetStringUTFChars >>>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>>>>> for >>>>>>>>> you. >>>>>>>>> >>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>> Ivan, >>>>>>>>>> >>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>> David, Alan, >>>>>>>>>>> >>>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>>> necessary. >>>>>>>>>> >>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>> >>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>> >>>>>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>>>>> OOME >>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>> native >>>>>>>>>> code >>>>>>>>>> returns to Java. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>> indentation. >>>>>>>>>>> >>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>> >>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>> cannot >>>>>>>>>>>>> return >>>>>>>>>>>>> NULL. >>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>>> with >>>>>>>>>>>>> the >>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>> stops >>>>>>>>>>>>> VM. >>>>>>>>>>>> >>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>>>> throw >>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>> >>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>> exception. >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>> >>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>>> there) is >>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>>> returns >>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> > > From michael.x.mcmahon at oracle.com Fri Aug 9 02:56:29 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 09 Aug 2013 10:56:29 +0100 Subject: RFR 8022661: InetAddress.writeObject() performs flush() on object output stream In-Reply-To: <5204B4F6.9090102@oracle.com> References: <5204B4F6.9090102@oracle.com> Message-ID: <5204BCCD.7060105@oracle.com> Looks fine to me. - Michael. On 09/08/13 10:23, Chris Hegarty wrote: > This is a trivial change to remove the unnecessary flush from > InetAddress.writeObject(). The flush can have a negative affect if the > ObjectOutputStream is wrapping an underlying Socket stream. > > diff -r 662115496d6b src/share/classes/java/net/InetAddress.java > --- a/src/share/classes/java/net/InetAddress.java Thu Aug 08 > 17:28:00 2013 +0400 > +++ b/src/share/classes/java/net/InetAddress.java Fri Aug 09 > 10:17:11 2013 +0100 > @@ -1601,7 +1601,6 @@ class InetAddress implements java.io.Ser > pf.put("address", holder().getAddress()); > pf.put("family", holder().getFamily()); > s.writeFields(); > - s.flush(); > } > } > > > -Chris. From paul.sandoz at oracle.com Fri Aug 9 02:55:25 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 09 Aug 2013 09:55:25 +0000 Subject: hg: jdk8/tl/jdk: 8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED Message-ID: <20130809095620.E542848740@hg.openjdk.java.net> Changeset: c29ca19cb816 Author: psandoz Date: 2013-08-09 11:44 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c29ca19cb816 8022326: Spliterator for values of j.u.c.ConcurrentSkipListMap does not report ORDERED Reviewed-by: martin, chegar ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/concurrent/ConcurrentSkipListMap.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java From chris.hegarty at oracle.com Fri Aug 9 03:36:22 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 09 Aug 2013 11:36:22 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204B5F3.6000506@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> Message-ID: <5204C626.3000102@oracle.com> Firstly, I think the memory leak issue should be moved forward separately to this cleanup effort. They are unrelated, and I'm starting to get the feeling that this could take some time to reach conclusion. It seems reasonable to separate the issues. On 09/08/2013 10:27, Ivan Gerasimov wrote: > Chris, > > I would use this > > if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { > JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); > return NULL/JNI_False/-1; > } > > If I understand it correctly, JNU_ThrowOutOfMemoryError throws an > exception only if it hasn't been already thrown. JNU_ThrowOutOfMemoryError is simply a convenience wrapper for JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); ...and JNU_ThrowByName [1] is defined as... JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { class cls = (*env)->FindClass(env, name); if (cls != 0) /* Otherwise an exception has already been thrown */ (*env)->ThrowNew(env, cls, msg); } } Neither FindClass or ThrowNew is safe to call if there is a pending exception [1]. Now the issue comes down to; could there ever be a pending exception if GetStringUTFChars returns NULL? The latest specs doesn't indicate that there could be, but every copy of "The Java Native Interface Programmer's Guide and Specification" I can find does. There also appears to be an assumption of this if you look at the usages in the JDK. I would really like to get a definitive answer on the JNI specification for GetStringUTFChars before making any changes here. -Chris. [1] http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c [2] http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 > > Sincerely yours, > Ivan > > > On 09.08.2013 11:25, Chris Hegarty wrote: >> On 09/08/2013 06:47, David Holmes wrote: >>> Sorry I messed this up. The JNI book says GetStringUTFChars will return >>> NULL and post OOME but the JNI spec (latest version 6.0) does not - it >>> only says it will return NULL on failure. >> >> This is indeed strange. Most usages of this function in the jdk expect >> the former. If this is not the case, then we may need to do an audit >> of all usages. >> >>> So your previous version was the more correct. Given we just failed to >>> allocate C-heap I think we are on thin ice anyway, but better to at >>> least attempt to do the right thing. >> >> I'm not sure what the right thing to do here is? It seems a little >> unwieldy! >> >> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { >> if ((*env)->ExceptionOccurred(env)) { >> return NULL/JNI_False/-1; >> } else { >> throwException(env, "java/lang/InternalError", "GetStringUTFChars >> failed"); >> return NULL/JNI_False/-1; >> } >> >> Given we have no idea why GetStringUTFChars may have failed, what >> exception do we throw? >> >> Also worth noting is that this bug fix has moved away from the >> original problem (memory leak), and is now focused on code cleanup. >> >> If we cannot get agreement on the cleanup, or it looks like more >> clarification is needed around the cleanup effort, then I would like >> to suggest that we proceed with the original fix for the memory leak >> and separate out the cleanup effort. >> >> -Chris. >> >>> FYI I filed 8022683 to fix GetStringUTFChars. >>> >>> David >>> ----- >>> >>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>> Thumbs up! >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>> Thanks David! >>>>> >>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>> Main fix looks good to me. >>>>>> >>>>>> Regression test may need some tweaking eg I think othervm will be >>>>>> needed. >>>>>> >>>>> Yes, it's a good point. >>>>> Since there may be a memory leak in the test, it'd better not >>>>> interfere >>>>> with other tests in jtreg. >>>>> >>>>>> Also this: >>>>>> >>>>>> System.out.println("WARNING: Cannot perform memory leak detection on >>>>>> this OS"); >>>>>> >>>>>> should probably just say something like "Test skipped on this OS" - >>>>>> there are other tests that do this so just check if there is common >>>>>> terminology. (In the future we may have keyword tags to flag this as >>>>>> linux only etc.) >>>>>> >>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>> >>>>> Updated webrev is here: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>> >>>>> Updated export is at the same place: >>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>>> fix. >>>>>>> >>>>>>> Here's webrev that includes the test: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>> >>>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>>>>> jdk7 >>>>>>> as expected. >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>> Hello Chris! >>>>>>>>> >>>>>>>>> Here's the update: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>> >>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>> Here's the hg-export >>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>> >>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>> Alan ( >>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>> GetStringUTFChars >>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into jdk8 >>>>>>>>>> for >>>>>>>>>> you. >>>>>>>>>> >>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>> Ivan, >>>>>>>>>>> >>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>> David, Alan, >>>>>>>>>>>> >>>>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>>>> necessary. >>>>>>>>>>> >>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>> >>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>> >>>>>>>>>>> Assuming a correct VM implementation if NULL is returned then an >>>>>>>>>>> OOME >>>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>>> native >>>>>>>>>>> code >>>>>>>>>>> returns to Java. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>> indentation. >>>>>>>>>>>> >>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>>> cannot >>>>>>>>>>>>>> return >>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>>>> with >>>>>>>>>>>>>> the >>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>>> stops >>>>>>>>>>>>>> VM. >>>>>>>>>>>>> >>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>>>>> throw >>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>>> >>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>> exception. >>>>>>>>>>>>> >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >> >> > From Alan.Bateman at oracle.com Fri Aug 9 03:59:34 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 09 Aug 2013 03:59:34 -0700 Subject: RFR 8022661: InetAddress.writeObject() performs flush() on object output stream In-Reply-To: <5204B4F6.9090102@oracle.com> References: <5204B4F6.9090102@oracle.com> Message-ID: <5204CB96.5050300@oracle.com> On 09/08/2013 02:23, Chris Hegarty wrote: > This is a trivial change to remove the unnecessary flush from > InetAddress.writeObject(). The flush can have a negative affect if the > ObjectOutputStream is wrapping an underlying Socket stream. > > diff -r 662115496d6b src/share/classes/java/net/InetAddress.java > --- a/src/share/classes/java/net/InetAddress.java Thu Aug 08 > 17:28:00 2013 +0400 > +++ b/src/share/classes/java/net/InetAddress.java Fri Aug 09 > 10:17:11 2013 +0100 > @@ -1601,7 +1601,6 @@ class InetAddress implements java.io.Ser > pf.put("address", holder().getAddress()); > pf.put("family", holder().getFamily()); > s.writeFields(); > - s.flush(); > } > } This looks okay to me, looks like the flush is completely unnecessary. -Alan From michael.x.mcmahon at oracle.com Fri Aug 9 04:31:30 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 09 Aug 2013 12:31:30 +0100 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52046FF3.1040903@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> Message-ID: <5204D312.4030209@oracle.com> I don't see how this fixes the original problem as the SNIHostName spec still doesn't like hostnames with a trailing '.' I'd prefer to check first where that requirement is coming from, if it is actually necessary, and if not consider removing it from SNIHostName. If it is necessary, then the check should be implemented in SNIHostName. Michael On 09/08/13 05:28, Xuelei Fan wrote: > Thanks for your feedback and suggestions. > > Here is the new webrev: > http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ > > "." is regarded as valid IDN in this update. > > Thanks, > Xuelei > > On 8/9/2013 10:50 AM, Xuelei Fan wrote: >> On 8/9/2013 10:14 AM, Weijun Wang wrote: >>> >>> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>>> I tried nslookup. Those with ".." inside are illegal, >>>>> >>>>> $ nslookup com.. >>>>> nslookup: 'com..' is not a legal name (empty label) >>>>> >>>>> but >>>>> >>>>> $ nslookup . >>>>> Server: 192.168.10.1 >>>>> Address: 192.168.10.1#53 >>>>> >>>>> Non-authoritative answer: >>>>> *** Can't find .: No answer >>>>> >>>> Thanks for the testing. The behaviors are the same as this fix now. >>> No exactly. It seems nslookup still regards "." legal but just cannot >>> find an IP for it. >>> >> I'm not sure whether a root domain name can be stand alone. Root label >> is not considered as a label in IDN. I think it is safe to regard that >> "." is not a valid IDN as it contains no label. Anyway, it is a corner >> case. >> >> There are many online IDN conversion web services, some of them can >> convert ".", some of the cannot. In the present implementation, we >> cannot recognize ".", and IDN.toASCII(".") throws >> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is >> a better exception for IDN.toASCII("."). >> >>>> Learn something new today to use nslookup. >>>> >>>>> Also, since this bug was originally about SNIHostName, do you need to >>>>> add some extra restriction there to reject "oracle.com." things? >>>>> >>>> No, we cannot restrict the format of IDN in SNIHostName more than in >>>> IDN. However, we may need to rethink about the comparing of two IDN, for >>>> example, "example.com." should equal to "example.com". I want to >>>> consider it in another bug. >>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? And >>> it's not one is another's subset? >>> >> Per TLS specification, host name in SNI is an IDN. The spec of >> SNIHostname says, "hostname is not a valid Internationalized Domain Name >> (IDN) compliant with the RFC 3490 specification". The spec in >> SNIHostName has the same means as IDN. I won't want to add additional >> restrict beyond the specification of an IDN. >> >> Xuelei >> >>>> Can I push the changeset? >>> I think it's better to ask someone in the networking team to make the >>> suggestion. From what I read Michael in this thread, he does not seem >>> totally agreed with your code changes (at least not the 00 version). >>> >>> Thanks >>> Max >>> >>>> Thanks, >>>> Xuelei >>>> >>>>> Thanks >>>>> Max >>>>> >>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>>> Ping. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>>> Please review the new update: >>>>>>> >>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>>> >>>>>>> With this update, "com." is valid (return "com."); "." and >>>>>>> "example..com" are invalid. And IAE will be thrown for invalid IDN. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> From david.holmes at oracle.com Fri Aug 9 05:18:48 2013 From: david.holmes at oracle.com (David Holmes) Date: Fri, 09 Aug 2013 22:18:48 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204C626.3000102@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> Message-ID: <5204DE28.5090805@oracle.com> Hi Chris, On 9/08/2013 8:36 PM, Chris Hegarty wrote: > Firstly, I think the memory leak issue should be moved forward > separately to this cleanup effort. They are unrelated, and I'm starting > to get the feeling that this could take some time to reach conclusion. > It seems reasonable to separate the issues. I agree. I'm sure when Alan suggested to check the return he didn't expect it to unravel like this :) As we know hotspot will never actually return NULL there is no urgency to add this in. > On 09/08/2013 10:27, Ivan Gerasimov wrote: >> Chris, >> >> I would use this >> >> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == NULL) { >> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); >> return NULL/JNI_False/-1; >> } >> >> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an >> exception only if it hasn't been already thrown. > > JNU_ThrowOutOfMemoryError is simply a convenience wrapper for > JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); > > ...and JNU_ThrowByName [1] is defined as... > > JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { > class cls = (*env)->FindClass(env, name); > if (cls != 0) /* Otherwise an exception has already been thrown */ > (*env)->ThrowNew(env, cls, msg); > } > } > > Neither FindClass or ThrowNew is safe to call if there is a pending > exception [1]. Right - we have to check for a pending exception before trying to throw one. > Now the issue comes down to; could there ever be a pending exception if > GetStringUTFChars returns NULL? The latest specs doesn't indicate that > there could be, but every copy of "The Java Native Interface > Programmer's Guide and Specification" I can find does. There also > appears to be an assumption of this if you look at the usages in the JDK. AFAIK there is only one version of the JNI spec book and it never got updated. The official spec says no throw, but when people have the book on their bookshelf that is what they tend to rely on. I looked at some of the usages and they seem exception agnostic - many of them don't even check for NULL :( The implementation as it stands will not throw and will not return NULL. > I would really like to get a definitive answer on the JNI specification > for GetStringUTFChars before making any changes here. The JNI spec (as opposed to the book) is definitive. If we don't like what is there then it requires a spec change. I can't find any reference to this particular issue being raised before. Cheers, David > -Chris. > > [1] > http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c > > [2] > http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 > > >> >> Sincerely yours, >> Ivan >> >> >> On 09.08.2013 11:25, Chris Hegarty wrote: >>> On 09/08/2013 06:47, David Holmes wrote: >>>> Sorry I messed this up. The JNI book says GetStringUTFChars will return >>>> NULL and post OOME but the JNI spec (latest version 6.0) does not - it >>>> only says it will return NULL on failure. >>> >>> This is indeed strange. Most usages of this function in the jdk expect >>> the former. If this is not the case, then we may need to do an audit >>> of all usages. >>> >>>> So your previous version was the more correct. Given we just failed to >>>> allocate C-heap I think we are on thin ice anyway, but better to at >>>> least attempt to do the right thing. >>> >>> I'm not sure what the right thing to do here is? It seems a little >>> unwieldy! >>> >>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>> NULL) { >>> if ((*env)->ExceptionOccurred(env)) { >>> return NULL/JNI_False/-1; >>> } else { >>> throwException(env, "java/lang/InternalError", "GetStringUTFChars >>> failed"); >>> return NULL/JNI_False/-1; >>> } >>> >>> Given we have no idea why GetStringUTFChars may have failed, what >>> exception do we throw? >>> >>> Also worth noting is that this bug fix has moved away from the >>> original problem (memory leak), and is now focused on code cleanup. >>> >>> If we cannot get agreement on the cleanup, or it looks like more >>> clarification is needed around the cleanup effort, then I would like >>> to suggest that we proceed with the original fix for the memory leak >>> and separate out the cleanup effort. >>> >>> -Chris. >>> >>>> FYI I filed 8022683 to fix GetStringUTFChars. >>>> >>>> David >>>> ----- >>>> >>>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>>> Thumbs up! >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>>> Thanks David! >>>>>> >>>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>>> Main fix looks good to me. >>>>>>> >>>>>>> Regression test may need some tweaking eg I think othervm will be >>>>>>> needed. >>>>>>> >>>>>> Yes, it's a good point. >>>>>> Since there may be a memory leak in the test, it'd better not >>>>>> interfere >>>>>> with other tests in jtreg. >>>>>> >>>>>>> Also this: >>>>>>> >>>>>>> System.out.println("WARNING: Cannot perform memory leak detection on >>>>>>> this OS"); >>>>>>> >>>>>>> should probably just say something like "Test skipped on this OS" - >>>>>>> there are other tests that do this so just check if there is common >>>>>>> terminology. (In the future we may have keyword tags to flag this as >>>>>>> linux only etc.) >>>>>>> >>>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>>> >>>>>> Updated webrev is here: >>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>>> >>>>>> Updated export is at the same place: >>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Sincerely yours, >>>>>> Ivan >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>>>> fix. >>>>>>>> >>>>>>>> Here's webrev that includes the test: >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>>> >>>>>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 and >>>>>>>> jdk7 >>>>>>>> as expected. >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>>> >>>>>>>>> -Chris. >>>>>>>>> >>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>>> Hello Chris! >>>>>>>>>> >>>>>>>>>> Here's the update: >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>>> >>>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>>> Here's the hg-export >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>>> >>>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>>> Alan ( >>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>>> GetStringUTFChars >>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>>>>> jdk8 >>>>>>>>>>> for >>>>>>>>>>> you. >>>>>>>>>>> >>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>>> >>>>>>>>>>> -Chris. >>>>>>>>>>> >>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>>> Ivan, >>>>>>>>>>>> >>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>> David, Alan, >>>>>>>>>>>>> >>>>>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>>>>> necessary. >>>>>>>>>>>> >>>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>>> >>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>>> >>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned >>>>>>>>>>>> then an >>>>>>>>>>>> OOME >>>>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>>>> native >>>>>>>>>>>> code >>>>>>>>>>>> returns to Java. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>>> indentation. >>>>>>>>>>>>> >>>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>> return >>>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>>>>> with >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>>>> stops >>>>>>>>>>>>>>> VM. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed to >>>>>>>>>>>>>> throw >>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>>>> >>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>>> exception. >>>>>>>>>>>>>> >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not >>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>> >>> >> From chris.hegarty at oracle.com Fri Aug 9 05:50:52 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 09 Aug 2013 12:50:52 +0000 Subject: hg: jdk8/tl/jdk: 8022661: InetAddress.writeObject() performs flush() on object output stream Message-ID: <20130809125140.B289D48748@hg.openjdk.java.net> Changeset: 84004d0e3fdd Author: chegar Date: 2013-08-09 13:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84004d0e3fdd 8022661: InetAddress.writeObject() performs flush() on object output stream Reviewed-by: michaelm, alanb ! src/share/classes/java/net/InetAddress.java From xuelei.fan at oracle.com Fri Aug 9 08:25:53 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Fri, 09 Aug 2013 23:25:53 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5204D312.4030209@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> Message-ID: <52050A01.3030503@oracle.com> On 8/9/2013 7:31 PM, Michael McMahon wrote: > I don't see how this fixes the original problem as the SNIHostName spec > still doesn't like hostnames with a trailing '.' > The bug description did not reflect the IDN specification correctly. If "com." is a valid IDN, SNIHostName should accept it an an valid hostname. The host name in SNIHostName is nothing more or less than an standard IDN. I added a comment in the bug: "com." and "." are valid IDN according the IDN and domain name specifications. I will contact the bug reporter about this point. Xuelei > I'd prefer to check first where that requirement is coming from, if it is > actually necessary, and if not consider removing it from SNIHostName. > If it is necessary, then the check should be implemented in SNIHostName. > > Michael > > On 09/08/13 05:28, Xuelei Fan wrote: >> Thanks for your feedback and suggestions. >> >> Here is the new webrev: >> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >> >> "." is regarded as valid IDN in this update. >> >> Thanks, >> Xuelei >> >> On 8/9/2013 10:50 AM, Xuelei Fan wrote: >>> On 8/9/2013 10:14 AM, Weijun Wang wrote: >>>> >>>> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>>>> I tried nslookup. Those with ".." inside are illegal, >>>>>> >>>>>> $ nslookup com.. >>>>>> nslookup: 'com..' is not a legal name (empty label) >>>>>> >>>>>> but >>>>>> >>>>>> $ nslookup . >>>>>> Server: 192.168.10.1 >>>>>> Address: 192.168.10.1#53 >>>>>> >>>>>> Non-authoritative answer: >>>>>> *** Can't find .: No answer >>>>>> >>>>> Thanks for the testing. The behaviors are the same as this fix now. >>>> No exactly. It seems nslookup still regards "." legal but just cannot >>>> find an IP for it. >>>> >>> I'm not sure whether a root domain name can be stand alone. Root label >>> is not considered as a label in IDN. I think it is safe to regard that >>> "." is not a valid IDN as it contains no label. Anyway, it is a corner >>> case. >>> >>> There are many online IDN conversion web services, some of them can >>> convert ".", some of the cannot. In the present implementation, we >>> cannot recognize ".", and IDN.toASCII(".") throws >>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is >>> a better exception for IDN.toASCII("."). >>> >>>>> Learn something new today to use nslookup. >>>>> >>>>>> Also, since this bug was originally about SNIHostName, do you need to >>>>>> add some extra restriction there to reject "oracle.com." things? >>>>>> >>>>> No, we cannot restrict the format of IDN in SNIHostName more than in >>>>> IDN. However, we may need to rethink about the comparing of two >>>>> IDN, for >>>>> example, "example.com." should equal to "example.com". I want to >>>>> consider it in another bug. >>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? >>>> And >>>> it's not one is another's subset? >>>> >>> Per TLS specification, host name in SNI is an IDN. The spec of >>> SNIHostname says, "hostname is not a valid Internationalized Domain Name >>> (IDN) compliant with the RFC 3490 specification". The spec in >>> SNIHostName has the same means as IDN. I won't want to add additional >>> restrict beyond the specification of an IDN. >>> >>> Xuelei >>> >>>>> Can I push the changeset? >>>> I think it's better to ask someone in the networking team to make the >>>> suggestion. From what I read Michael in this thread, he does not seem >>>> totally agreed with your code changes (at least not the 00 version). >>>> >>>> Thanks >>>> Max >>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>>>> Ping. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>>>> Please review the new update: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>>>> >>>>>>>> With this update, "com." is valid (return "com."); "." and >>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid >>>>>>>> IDN. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> > From sean.coffey at oracle.com Fri Aug 9 09:26:27 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Fri, 09 Aug 2013 17:26:27 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <52041965.3090808@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52040FDA.2040600@oracle.com> <52041895.9010706@oracle.com> <52041965.3090808@oracle.com> Message-ID: <52051833.5090204@oracle.com> On the regression testcase theme, it got me thinking as to whether we've any java APIs which can query what the native heap usage of the JVM. Is that available over JMX ? I tried the MBeanServer approach but didn't get the expected results. Queried the "NonHeapMemoryUsage" object. something like. MBeanServer server = ManagementFactory.getPlatformMBeanServer(); ObjectName memory = new ObjectName(MEMORY_MXBEAN_NAME); Object ob = server.getAttribute(memory, "NonHeapMemoryUsage"); MemoryUsage mu = MemoryUsage.from((CompositeData) ob); System.out.println("Nonheap : " + mu.getUsed()); What exactly is JMX measuring in "NonHeapMemoryUsage" mode ? Any pointers ? regards, Sean. On 08/08/13 23:19, Michael McMahon wrote: > Ivan, > > Right, it's not worth trying to do the equivalent, whatever it is, for > Windows. > The test is fine with me. > > Thanks > Michael > > On 08/08/13 23:15, Ivan Gerasimov wrote: >> Michael, >> >> The test uses /proc/self/stat file to detect changes in virtual >> memory usage. >> This approach is specific for Linux. >> That's why I included the check of OS in the test. >> >> Sincerely yours, >> Ivan >> >> On 09.08.2013 1:38, Michael McMahon wrote: >>> Yes, definitely "othervm" would be required for the test. Also, why >>> skip other OS'es? >>> The fix is only for Linux, but it might catch future leaks on Windows. >>> >>> The trouble with tests like this, is they sometimes don't age well. >>> Future changes in OS kernel behavior could cause problems but I >>> guess 32MB is a fairly large difference. >>> So, it should be okay >>> >>> Michael >>> >>> On 08/08/13 22:15, David Holmes wrote: >>>> Main fix looks good to me. >>>> >>>> Regression test may need some tweaking eg I think othervm will be >>>> needed. >>>> >>>> Also this: >>>> >>>> System.out.println("WARNING: Cannot perform memory leak detection >>>> on this OS"); >>>> >>>> should probably just say something like "Test skipped on this OS" - >>>> there are other tests that do this so just check if there is common >>>> terminology. (In the future we may have keyword tags to flag this >>>> as linux only etc.) >>>> >>>> Thanks, >>>> David >>>> >>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>> fix. >>>>> >>>>> Here's webrev that includes the test: >>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>> >>>>> The test gets past with the fixed jdk8 and fails with jdk8-b101 >>>>> and jdk7 >>>>> as expected. >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>> Looks good to me. Thanks Ivan. >>>>>> >>>>>> -Chris. >>>>>> >>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>> Hello Chris! >>>>>>> >>>>>>> Here's the update: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>> >>>>>>> Thanks for offering the sponsorship! >>>>>>> Here's the hg-export >>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>> Thanks for taking this Ivan. >>>>>>>> >>>>>>>> Can you please make the changes suggested by both David and Alan ( >>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>> GetStringUTFChars >>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>> jdk8 for >>>>>>>> you. >>>>>>>> >>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>> >>>>>>>> -Chris. >>>>>>>> >>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>> Ivan, >>>>>>>>> >>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>> David, Alan, >>>>>>>>>> >>>>>>>>>> I added checking for NULL results and throwing OOMException if >>>>>>>>>> necessary. >>>>>>>>> >>>>>>>>> You don't need to throw it yourself: >>>>>>>>> >>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>> >>>>>>>>> Assuming a correct VM implementation if NULL is returned then >>>>>>>>> an OOME >>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>> native >>>>>>>>> code >>>>>>>>> returns to Java. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>> indentation. >>>>>>>>>> >>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>> >>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>> cannot >>>>>>>>>>>> return >>>>>>>>>>>> NULL. >>>>>>>>>>>> For allocation of the result string it calls AllocateHeap() >>>>>>>>>>>> with >>>>>>>>>>>> the >>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>> stops >>>>>>>>>>>> VM. >>>>>>>>>>> >>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is supposed >>>>>>>>>>> to throw >>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>> >>>>>>>>>>> I recommend that you check for NULL and/or a pending exception. >>>>>>>>>>> >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>> >>>>>>>>>>>>> The change looks okay to me. One suggestion (while you are >>>>>>>>>>>>> there) is >>>>>>>>>>>>> to check the return from GetStringUTFChars so that the name >>>>>>>>>>>>> returns >>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>> >>>>>>>>>>>>> -Alan. >>>>>>>>>>>>> >>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to leak >>>>>>>>>>>>>> memory. >>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not yet >>>>>>>>>>>>>> available.) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >>> >> > From chris.hegarty at oracle.com Fri Aug 9 09:57:08 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 09 Aug 2013 16:57:08 +0000 Subject: hg: jdk8/tl/jdk: 8022724: lint warnings in j.u.concurrent packages Message-ID: <20130809165838.A48BB48759@hg.openjdk.java.net> Changeset: ce1c874903cb Author: dl Date: 2013-08-09 17:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ce1c874903cb 8022724: lint warnings in j.u.concurrent packages Reviewed-by: chegar, lancea, darcy ! src/share/classes/java/util/concurrent/CompletableFuture.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/atomic/Striped64.java From dan.xu at oracle.com Fri Aug 9 10:55:59 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 09 Aug 2013 17:55:59 +0000 Subject: hg: jdk8/tl/jdk: 8021977: Opening a file using java.io can throw IOException on Windows Message-ID: <20130809175620.B80534875C@hg.openjdk.java.net> Changeset: 03822f2389bf Author: dxu Date: 2013-08-09 10:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/03822f2389bf 8021977: Opening a file using java.io can throw IOException on Windows Summary: Remove IOException related error-handling code for backward compatibility Reviewed-by: alanb, lancea, mr ! src/windows/native/java/io/io_util_md.c From xueming.shen at oracle.com Fri Aug 9 12:38:03 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Fri, 09 Aug 2013 19:38:03 +0000 Subject: hg: jdk8/tl/jdk: 8020054: (tz) Support tzdata2013d Message-ID: <20130809193841.0F87148762@hg.openjdk.java.net> Changeset: a7c341f30747 Author: sherman Date: 2013-08-09 12:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7c341f30747 8020054: (tz) Support tzdata2013d Summary: update the jdk8 tz data to version 2013d Reviewed-by: coffeys, peytoia ! make/sun/javazic/tzdata/VERSION ! make/sun/javazic/tzdata/africa ! make/sun/javazic/tzdata/antarctica ! make/sun/javazic/tzdata/asia ! make/sun/javazic/tzdata/australasia ! make/sun/javazic/tzdata/backward ! make/sun/javazic/tzdata/etcetera ! make/sun/javazic/tzdata/europe ! make/sun/javazic/tzdata/factory ! make/sun/javazic/tzdata/iso3166.tab ! make/sun/javazic/tzdata/leapseconds ! make/sun/javazic/tzdata/northamerica ! make/sun/javazic/tzdata/pacificnew ! make/sun/javazic/tzdata/solar87 ! make/sun/javazic/tzdata/solar88 ! make/sun/javazic/tzdata/solar89 ! make/sun/javazic/tzdata/southamerica ! make/sun/javazic/tzdata/systemv ! make/sun/javazic/tzdata/zone.tab ! test/sun/util/calendar/zi/tzdata/VERSION ! test/sun/util/calendar/zi/tzdata/africa ! test/sun/util/calendar/zi/tzdata/antarctica ! test/sun/util/calendar/zi/tzdata/asia ! test/sun/util/calendar/zi/tzdata/australasia ! test/sun/util/calendar/zi/tzdata/backward ! test/sun/util/calendar/zi/tzdata/etcetera ! test/sun/util/calendar/zi/tzdata/europe ! test/sun/util/calendar/zi/tzdata/factory ! test/sun/util/calendar/zi/tzdata/iso3166.tab ! test/sun/util/calendar/zi/tzdata/leapseconds ! test/sun/util/calendar/zi/tzdata/northamerica ! test/sun/util/calendar/zi/tzdata/pacificnew ! test/sun/util/calendar/zi/tzdata/solar87 ! test/sun/util/calendar/zi/tzdata/solar88 ! test/sun/util/calendar/zi/tzdata/solar89 ! test/sun/util/calendar/zi/tzdata/southamerica ! test/sun/util/calendar/zi/tzdata/systemv ! test/sun/util/calendar/zi/tzdata/zone.tab From kumar.x.srinivasan at oracle.com Fri Aug 9 15:36:04 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Fri, 09 Aug 2013 22:36:04 +0000 Subject: hg: jdk8/tl/langtools: 8022161: javac Null Pointer Exception in Enter.visitTopLevel Message-ID: <20130809223615.468C748776@hg.openjdk.java.net> Changeset: d601238641e6 Author: ksrini Date: 2013-08-09 15:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/d601238641e6 8022161: javac Null Pointer Exception in Enter.visitTopLevel Reviewed-by: jjg, vromero, jlahoda ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! test/tools/javac/TestPkgInfo.java From xuelei.fan at oracle.com Fri Aug 9 18:13:48 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 10 Aug 2013 09:13:48 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52050A01.3030503@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> Message-ID: <520593CC.4010608@oracle.com> Hi Michael, I plan to address this issue in SNIHostName. I have filled another two the potential bugs in IDN. Thank you, and other people, for the feedback. Thanks, Xuelei On 8/9/2013 11:25 PM, Xuelei Fan wrote: > On 8/9/2013 7:31 PM, Michael McMahon wrote: >> I don't see how this fixes the original problem as the SNIHostName spec >> still doesn't like hostnames with a trailing '.' >> > The bug description did not reflect the IDN specification correctly. If > "com." is a valid IDN, SNIHostName should accept it an an valid > hostname. The host name in SNIHostName is nothing more or less than an > standard IDN. > > I added a comment in the bug: "com." and "." are valid IDN according the > IDN and domain name specifications. I will contact the bug reporter > about this point. > > Xuelei > >> I'd prefer to check first where that requirement is coming from, if it is >> actually necessary, and if not consider removing it from SNIHostName. >> If it is necessary, then the check should be implemented in SNIHostName. >> >> Michael >> >> On 09/08/13 05:28, Xuelei Fan wrote: >>> Thanks for your feedback and suggestions. >>> >>> Here is the new webrev: >>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >>> >>> "." is regarded as valid IDN in this update. >>> >>> Thanks, >>> Xuelei >>> >>> On 8/9/2013 10:50 AM, Xuelei Fan wrote: >>>> On 8/9/2013 10:14 AM, Weijun Wang wrote: >>>>> >>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>>>>> I tried nslookup. Those with ".." inside are illegal, >>>>>>> >>>>>>> $ nslookup com.. >>>>>>> nslookup: 'com..' is not a legal name (empty label) >>>>>>> >>>>>>> but >>>>>>> >>>>>>> $ nslookup . >>>>>>> Server: 192.168.10.1 >>>>>>> Address: 192.168.10.1#53 >>>>>>> >>>>>>> Non-authoritative answer: >>>>>>> *** Can't find .: No answer >>>>>>> >>>>>> Thanks for the testing. The behaviors are the same as this fix now. >>>>> No exactly. It seems nslookup still regards "." legal but just cannot >>>>> find an IP for it. >>>>> >>>> I'm not sure whether a root domain name can be stand alone. Root label >>>> is not considered as a label in IDN. I think it is safe to regard that >>>> "." is not a valid IDN as it contains no label. Anyway, it is a corner >>>> case. >>>> >>>> There are many online IDN conversion web services, some of them can >>>> convert ".", some of the cannot. In the present implementation, we >>>> cannot recognize ".", and IDN.toASCII(".") throws >>>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is >>>> a better exception for IDN.toASCII("."). >>>> >>>>>> Learn something new today to use nslookup. >>>>>> >>>>>>> Also, since this bug was originally about SNIHostName, do you need to >>>>>>> add some extra restriction there to reject "oracle.com." things? >>>>>>> >>>>>> No, we cannot restrict the format of IDN in SNIHostName more than in >>>>>> IDN. However, we may need to rethink about the comparing of two >>>>>> IDN, for >>>>>> example, "example.com." should equal to "example.com". I want to >>>>>> consider it in another bug. >>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? >>>>> And >>>>> it's not one is another's subset? >>>>> >>>> Per TLS specification, host name in SNI is an IDN. The spec of >>>> SNIHostname says, "hostname is not a valid Internationalized Domain Name >>>> (IDN) compliant with the RFC 3490 specification". The spec in >>>> SNIHostName has the same means as IDN. I won't want to add additional >>>> restrict beyond the specification of an IDN. >>>> >>>> Xuelei >>>> >>>>>> Can I push the changeset? >>>>> I think it's better to ask someone in the networking team to make the >>>>> suggestion. From what I read Michael in this thread, he does not seem >>>>> totally agreed with your code changes (at least not the 00 version). >>>>> >>>>> Thanks >>>>> Max >>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>>>>> Ping. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>>>>> Please review the new update: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>>>>> >>>>>>>>> With this update, "com." is valid (return "com."); "." and >>>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid >>>>>>>>> IDN. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >> > From xuelei.fan at oracle.com Fri Aug 9 19:49:59 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Sat, 10 Aug 2013 10:49:59 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <520593CC.4010608@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> Message-ID: <5205AA57.6050704@oracle.com> Hi Michael, It is pretty hard to get the issue solved in SNIHostName in a good sharp. Here is my try to state why we should fix the issue in IDN. In SNIHostName, the following hostname are not accepted as valid hostname: 1. empty hostname 2. hostname ends with a trailing dot 3. hostname does not comply to RFC 3490. The process in SNIHostName looks like: 1. call IDN.toASCII() to convert a string hostname 2. check that the return value of #1 is an valid hostname (non-empty, non-end-with-tailing-dot). At present, the IDN cannot handle the following IDN properly. 1. returns "com" for "com." the trailing dot is swallowed. 2. throws StringIndexOutOfBoundsException for "." If "." is an valid IDN that comply to RFC 3490, IDN.toASCII() should be able to handle it; otherwise, IDN.toASCII() should throw IAE as the specification suggested. However, IDN.toASCII(".") throws StringIndexOutOfBoundsException, this behavior does not comply the the specification: 3. throws StringIndexOutOfBoundsException for "example...net" As #2. We can address #1 and #2 in SNIHostName, but the checking is overloaded as IDN also need to address the issue. And SNIHostName has to know what's the separators (".", "\u3002, etc) of IDN in order to check the dot character. It is not a good encapsulation, and involved in too much about the details of domain name, I think. It is a little big hard to address #3 in SNIHostName. Both all of above issue can be easily addressed in IDN. And once IDN addressed these issues, the current SNIHostName is able to handle invalid hostname (empty, trailing dot, etc) correctly. We won't need to touch SNIHostName any more. Please consider it. The latest webrev is at: http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ Thanks, Xuelei On 8/10/2013 9:13 AM, Xuelei Fan wrote: > Hi Michael, > > I plan to address this issue in SNIHostName. I have filled another two > the potential bugs in IDN. > > Thank you, and other people, for the feedback. > > Thanks, > Xuelei > > On 8/9/2013 11:25 PM, Xuelei Fan wrote: >> On 8/9/2013 7:31 PM, Michael McMahon wrote: >>> I don't see how this fixes the original problem as the SNIHostName spec >>> still doesn't like hostnames with a trailing '.' >>> >> The bug description did not reflect the IDN specification correctly. If >> "com." is a valid IDN, SNIHostName should accept it an an valid >> hostname. The host name in SNIHostName is nothing more or less than an >> standard IDN. >> >> I added a comment in the bug: "com." and "." are valid IDN according the >> IDN and domain name specifications. I will contact the bug reporter >> about this point. >> >> Xuelei >> >>> I'd prefer to check first where that requirement is coming from, if it is >>> actually necessary, and if not consider removing it from SNIHostName. >>> If it is necessary, then the check should be implemented in SNIHostName. >>> >>> Michael >>> >>> On 09/08/13 05:28, Xuelei Fan wrote: >>>> Thanks for your feedback and suggestions. >>>> >>>> Here is the new webrev: >>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >>>> >>>> "." is regarded as valid IDN in this update. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote: >>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote: >>>>>> >>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>>>>>> I tried nslookup. Those with ".." inside are illegal, >>>>>>>> >>>>>>>> $ nslookup com.. >>>>>>>> nslookup: 'com..' is not a legal name (empty label) >>>>>>>> >>>>>>>> but >>>>>>>> >>>>>>>> $ nslookup . >>>>>>>> Server: 192.168.10.1 >>>>>>>> Address: 192.168.10.1#53 >>>>>>>> >>>>>>>> Non-authoritative answer: >>>>>>>> *** Can't find .: No answer >>>>>>>> >>>>>>> Thanks for the testing. The behaviors are the same as this fix now. >>>>>> No exactly. It seems nslookup still regards "." legal but just cannot >>>>>> find an IP for it. >>>>>> >>>>> I'm not sure whether a root domain name can be stand alone. Root label >>>>> is not considered as a label in IDN. I think it is safe to regard that >>>>> "." is not a valid IDN as it contains no label. Anyway, it is a corner >>>>> case. >>>>> >>>>> There are many online IDN conversion web services, some of them can >>>>> convert ".", some of the cannot. In the present implementation, we >>>>> cannot recognize ".", and IDN.toASCII(".") throws >>>>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is >>>>> a better exception for IDN.toASCII("."). >>>>> >>>>>>> Learn something new today to use nslookup. >>>>>>> >>>>>>>> Also, since this bug was originally about SNIHostName, do you need to >>>>>>>> add some extra restriction there to reject "oracle.com." things? >>>>>>>> >>>>>>> No, we cannot restrict the format of IDN in SNIHostName more than in >>>>>>> IDN. However, we may need to rethink about the comparing of two >>>>>>> IDN, for >>>>>>> example, "example.com." should equal to "example.com". I want to >>>>>>> consider it in another bug. >>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? >>>>>> And >>>>>> it's not one is another's subset? >>>>>> >>>>> Per TLS specification, host name in SNI is an IDN. The spec of >>>>> SNIHostname says, "hostname is not a valid Internationalized Domain Name >>>>> (IDN) compliant with the RFC 3490 specification". The spec in >>>>> SNIHostName has the same means as IDN. I won't want to add additional >>>>> restrict beyond the specification of an IDN. >>>>> >>>>> Xuelei >>>>> >>>>>>> Can I push the changeset? >>>>>> I think it's better to ask someone in the networking team to make the >>>>>> suggestion. From what I read Michael in this thread, he does not seem >>>>>> totally agreed with your code changes (at least not the 00 version). >>>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>>>>>> Ping. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>>>>>> Please review the new update: >>>>>>>>>> >>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>>>>>> >>>>>>>>>> With this update, "com." is valid (return "com."); "." and >>>>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid >>>>>>>>>> IDN. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>> >> > From vicente.romero at oracle.com Sat Aug 10 05:28:55 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 10 Aug 2013 12:28:55 +0000 Subject: hg: jdk8/tl/langtools: 8009640: -profile does not work when -bootclasspath specified Message-ID: <20130810122858.15F1748789@hg.openjdk.java.net> Changeset: 0d9bc764cac7 Author: vromero Date: 2013-08-10 13:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0d9bc764cac7 8009640: -profile does not work when -bootclasspath specified Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/T8009640/CheckRejectProfileBCPOptionsIfUsedTogetherTest.java From vicente.romero at oracle.com Sat Aug 10 08:27:28 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 10 Aug 2013 15:27:28 +0000 Subject: hg: jdk8/tl/langtools: 8022622: javac, two tests are failing with compile time error after class Collector was modified Message-ID: <20130810152735.353B74878B@hg.openjdk.java.net> Changeset: 8f282dc58dfc Author: vromero Date: 2013-08-10 16:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/8f282dc58dfc 8022622: javac, two tests are failing with compile time error after class Collector was modified Reviewed-by: mcimadamore ! test/tools/javac/lambda/TargetType59.java ! test/tools/javac/lambda/TargetType62.java From vicente.romero at oracle.com Sat Aug 10 08:30:27 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Sat, 10 Aug 2013 15:30:27 +0000 Subject: hg: jdk8/tl/langtools: 6983297: methods missing from NewArrayTree Message-ID: <20130810153030.01FCA4878C@hg.openjdk.java.net> Changeset: aa6c6f8b5622 Author: vromero Date: 2013-08-10 16:29 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/aa6c6f8b5622 6983297: methods missing from NewArrayTree Reviewed-by: jjg ! src/share/classes/com/sun/source/tree/NewArrayTree.java ! src/share/classes/com/sun/source/util/TreeScanner.java ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! test/tools/javac/tree/SourceTreeScannerTest.java From xuelei.fan at oracle.com Sun Aug 11 18:09:33 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 12 Aug 2013 09:09:33 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5205AA57.6050704@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> Message-ID: <520835CD.5090402@oracle.com> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/ Added a new test to test illegal hostname in SNIHostName. Xuelei On 8/10/2013 10:49 AM, Xuelei Fan wrote: > Hi Michael, > > It is pretty hard to get the issue solved in SNIHostName in a good > sharp. Here is my try to state why we should fix the issue in IDN. > > In SNIHostName, the following hostname are not accepted as valid hostname: > 1. empty hostname > 2. hostname ends with a trailing dot > 3. hostname does not comply to RFC 3490. > > The process in SNIHostName looks like: > 1. call IDN.toASCII() to convert a string hostname > 2. check that the return value of #1 is an valid hostname (non-empty, > non-end-with-tailing-dot). > > At present, the IDN cannot handle the following IDN properly. > 1. returns "com" for "com." > the trailing dot is swallowed. > > 2. throws StringIndexOutOfBoundsException for "." > If "." is an valid IDN that comply to RFC 3490, IDN.toASCII() should > be able to handle it; otherwise, IDN.toASCII() should throw IAE as the > specification suggested. However, IDN.toASCII(".") throws > StringIndexOutOfBoundsException, this behavior does not comply the the > specification: > > 3. throws StringIndexOutOfBoundsException for "example...net" > As #2. > > We can address #1 and #2 in SNIHostName, but the checking is overloaded > as IDN also need to address the issue. And SNIHostName has to know > what's the separators (".", "\u3002, etc) of IDN in order to check the > dot character. It is not a good encapsulation, and involved in too much > about the details of domain name, I think. > > It is a little big hard to address #3 in SNIHostName. > > Both all of above issue can be easily addressed in IDN. And once IDN > addressed these issues, the current SNIHostName is able to handle > invalid hostname (empty, trailing dot, etc) correctly. We won't need to > touch SNIHostName any more. > > Please consider it. > > The latest webrev is at: > http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ > > Thanks, > Xuelei > > On 8/10/2013 9:13 AM, Xuelei Fan wrote: >> Hi Michael, >> >> I plan to address this issue in SNIHostName. I have filled another two >> the potential bugs in IDN. >> >> Thank you, and other people, for the feedback. >> >> Thanks, >> Xuelei >> >> On 8/9/2013 11:25 PM, Xuelei Fan wrote: >>> On 8/9/2013 7:31 PM, Michael McMahon wrote: >>>> I don't see how this fixes the original problem as the SNIHostName spec >>>> still doesn't like hostnames with a trailing '.' >>>> >>> The bug description did not reflect the IDN specification correctly. If >>> "com." is a valid IDN, SNIHostName should accept it an an valid >>> hostname. The host name in SNIHostName is nothing more or less than an >>> standard IDN. >>> >>> I added a comment in the bug: "com." and "." are valid IDN according the >>> IDN and domain name specifications. I will contact the bug reporter >>> about this point. >>> >>> Xuelei >>> >>>> I'd prefer to check first where that requirement is coming from, if it is >>>> actually necessary, and if not consider removing it from SNIHostName. >>>> If it is necessary, then the check should be implemented in SNIHostName. >>>> >>>> Michael >>>> >>>> On 09/08/13 05:28, Xuelei Fan wrote: >>>>> Thanks for your feedback and suggestions. >>>>> >>>>> Here is the new webrev: >>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >>>>> >>>>> "." is regarded as valid IDN in this update. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote: >>>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote: >>>>>>> >>>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>>>>>>> I tried nslookup. Those with ".." inside are illegal, >>>>>>>>> >>>>>>>>> $ nslookup com.. >>>>>>>>> nslookup: 'com..' is not a legal name (empty label) >>>>>>>>> >>>>>>>>> but >>>>>>>>> >>>>>>>>> $ nslookup . >>>>>>>>> Server: 192.168.10.1 >>>>>>>>> Address: 192.168.10.1#53 >>>>>>>>> >>>>>>>>> Non-authoritative answer: >>>>>>>>> *** Can't find .: No answer >>>>>>>>> >>>>>>>> Thanks for the testing. The behaviors are the same as this fix now. >>>>>>> No exactly. It seems nslookup still regards "." legal but just cannot >>>>>>> find an IP for it. >>>>>>> >>>>>> I'm not sure whether a root domain name can be stand alone. Root label >>>>>> is not considered as a label in IDN. I think it is safe to regard that >>>>>> "." is not a valid IDN as it contains no label. Anyway, it is a corner >>>>>> case. >>>>>> >>>>>> There are many online IDN conversion web services, some of them can >>>>>> convert ".", some of the cannot. In the present implementation, we >>>>>> cannot recognize ".", and IDN.toASCII(".") throws >>>>>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is >>>>>> a better exception for IDN.toASCII("."). >>>>>> >>>>>>>> Learn something new today to use nslookup. >>>>>>>> >>>>>>>>> Also, since this bug was originally about SNIHostName, do you need to >>>>>>>>> add some extra restriction there to reject "oracle.com." things? >>>>>>>>> >>>>>>>> No, we cannot restrict the format of IDN in SNIHostName more than in >>>>>>>> IDN. However, we may need to rethink about the comparing of two >>>>>>>> IDN, for >>>>>>>> example, "example.com." should equal to "example.com". I want to >>>>>>>> consider it in another bug. >>>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? >>>>>>> And >>>>>>> it's not one is another's subset? >>>>>>> >>>>>> Per TLS specification, host name in SNI is an IDN. The spec of >>>>>> SNIHostname says, "hostname is not a valid Internationalized Domain Name >>>>>> (IDN) compliant with the RFC 3490 specification". The spec in >>>>>> SNIHostName has the same means as IDN. I won't want to add additional >>>>>> restrict beyond the specification of an IDN. >>>>>> >>>>>> Xuelei >>>>>> >>>>>>>> Can I push the changeset? >>>>>>> I think it's better to ask someone in the networking team to make the >>>>>>> suggestion. From what I read Michael in this thread, he does not seem >>>>>>> totally agreed with your code changes (at least not the 00 version). >>>>>>> >>>>>>> Thanks >>>>>>> Max >>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>>>>>>> Ping. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>>>>>>> Please review the new update: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> With this update, "com." is valid (return "com."); "." and >>>>>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid >>>>>>>>>>> IDN. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Xuelei >>>>>>>>>>> >>>> >>> >> > From xuelei.fan at oracle.com Sun Aug 11 18:22:09 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Mon, 12 Aug 2013 01:22:09 +0000 Subject: hg: jdk8/tl/jdk: 8022487: DEREncodedKeyValue.supportedKeyTypes should be private Message-ID: <20130812012258.BACF2487A1@hg.openjdk.java.net> Changeset: ea4f4164422e Author: xuelei Date: 2013-08-11 18:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ea4f4164422e 8022487: DEREncodedKeyValue.supportedKeyTypes should be private Reviewed-by: mullan ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java From weijun.wang at oracle.com Sun Aug 11 20:11:42 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Aug 2013 11:11:42 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <520835CD.5090402@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> Message-ID: <5208526E.5020808@oracle.com> I think the fix is adequate and necessary. One problem: lines 367-373 adds a new IAE to ToUnicode but the method should not fail forever. And some small comments on styles etc. On 8/12/13 9:09 AM, Xuelei Fan wrote: > new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/ Lines 123 and 185: 184 p = q + 1; 185 if (p < input.length() || q == (input.length() - 1)) { 186 // has more labels, or keep the trailing dot as at present 187 out.append('.'); 188 } I prefer if (q < input.length()) { // Ah, a dot! out.append('.'); } p = q + 1; Lines 282, 335, 270: Insert a blank after "if". Lines 284 and 372: nslookup uses "empty label", which I like better. Lines 453 and 460: Personally I don't like the parenthesis for the whole return value, but you have your choice. Lines 280 and 333: How about we call them steps 8a and 8b? > > Added a new test to test illegal hostname in SNIHostName. Excellent. Otherwise I will be wondering why the fix in IDN could solve the problem as described in the bug description. Thanks Max > > Xuelei > > On 8/10/2013 10:49 AM, Xuelei Fan wrote: >> Hi Michael, >> >> It is pretty hard to get the issue solved in SNIHostName in a good >> sharp. Here is my try to state why we should fix the issue in IDN. >> >> In SNIHostName, the following hostname are not accepted as valid hostname: >> 1. empty hostname >> 2. hostname ends with a trailing dot >> 3. hostname does not comply to RFC 3490. >> >> The process in SNIHostName looks like: >> 1. call IDN.toASCII() to convert a string hostname >> 2. check that the return value of #1 is an valid hostname (non-empty, >> non-end-with-tailing-dot). >> >> At present, the IDN cannot handle the following IDN properly. >> 1. returns "com" for "com." >> the trailing dot is swallowed. >> >> 2. throws StringIndexOutOfBoundsException for "." >> If "." is an valid IDN that comply to RFC 3490, IDN.toASCII() should >> be able to handle it; otherwise, IDN.toASCII() should throw IAE as the >> specification suggested. However, IDN.toASCII(".") throws >> StringIndexOutOfBoundsException, this behavior does not comply the the >> specification: >> >> 3. throws StringIndexOutOfBoundsException for "example...net" >> As #2. >> >> We can address #1 and #2 in SNIHostName, but the checking is overloaded >> as IDN also need to address the issue. And SNIHostName has to know >> what's the separators (".", "\u3002, etc) of IDN in order to check the >> dot character. It is not a good encapsulation, and involved in too much >> about the details of domain name, I think. >> >> It is a little big hard to address #3 in SNIHostName. >> >> Both all of above issue can be easily addressed in IDN. And once IDN >> addressed these issues, the current SNIHostName is able to handle >> invalid hostname (empty, trailing dot, etc) correctly. We won't need to >> touch SNIHostName any more. >> >> Please consider it. >> >> The latest webrev is at: >> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >> >> Thanks, >> Xuelei >> >> On 8/10/2013 9:13 AM, Xuelei Fan wrote: >>> Hi Michael, >>> >>> I plan to address this issue in SNIHostName. I have filled another two >>> the potential bugs in IDN. >>> >>> Thank you, and other people, for the feedback. >>> >>> Thanks, >>> Xuelei >>> >>> On 8/9/2013 11:25 PM, Xuelei Fan wrote: >>>> On 8/9/2013 7:31 PM, Michael McMahon wrote: >>>>> I don't see how this fixes the original problem as the SNIHostName spec >>>>> still doesn't like hostnames with a trailing '.' >>>>> >>>> The bug description did not reflect the IDN specification correctly. If >>>> "com." is a valid IDN, SNIHostName should accept it an an valid >>>> hostname. The host name in SNIHostName is nothing more or less than an >>>> standard IDN. >>>> >>>> I added a comment in the bug: "com." and "." are valid IDN according the >>>> IDN and domain name specifications. I will contact the bug reporter >>>> about this point. >>>> >>>> Xuelei >>>> >>>>> I'd prefer to check first where that requirement is coming from, if it is >>>>> actually necessary, and if not consider removing it from SNIHostName. >>>>> If it is necessary, then the check should be implemented in SNIHostName. >>>>> >>>>> Michael >>>>> >>>>> On 09/08/13 05:28, Xuelei Fan wrote: >>>>>> Thanks for your feedback and suggestions. >>>>>> >>>>>> Here is the new webrev: >>>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >>>>>> >>>>>> "." is regarded as valid IDN in this update. >>>>>> >>>>>> Thanks, >>>>>> Xuelei >>>>>> >>>>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote: >>>>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote: >>>>>>>> >>>>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>>>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>>>>>>>> I tried nslookup. Those with ".." inside are illegal, >>>>>>>>>> >>>>>>>>>> $ nslookup com.. >>>>>>>>>> nslookup: 'com..' is not a legal name (empty label) >>>>>>>>>> >>>>>>>>>> but >>>>>>>>>> >>>>>>>>>> $ nslookup . >>>>>>>>>> Server: 192.168.10.1 >>>>>>>>>> Address: 192.168.10.1#53 >>>>>>>>>> >>>>>>>>>> Non-authoritative answer: >>>>>>>>>> *** Can't find .: No answer >>>>>>>>>> >>>>>>>>> Thanks for the testing. The behaviors are the same as this fix now. >>>>>>>> No exactly. It seems nslookup still regards "." legal but just cannot >>>>>>>> find an IP for it. >>>>>>>> >>>>>>> I'm not sure whether a root domain name can be stand alone. Root label >>>>>>> is not considered as a label in IDN. I think it is safe to regard that >>>>>>> "." is not a valid IDN as it contains no label. Anyway, it is a corner >>>>>>> case. >>>>>>> >>>>>>> There are many online IDN conversion web services, some of them can >>>>>>> convert ".", some of the cannot. In the present implementation, we >>>>>>> cannot recognize ".", and IDN.toASCII(".") throws >>>>>>> StringIndexOutOfBoundsException. With this fix, I was wondering IAE is >>>>>>> a better exception for IDN.toASCII("."). >>>>>>> >>>>>>>>> Learn something new today to use nslookup. >>>>>>>>> >>>>>>>>>> Also, since this bug was originally about SNIHostName, do you need to >>>>>>>>>> add some extra restriction there to reject "oracle.com." things? >>>>>>>>>> >>>>>>>>> No, we cannot restrict the format of IDN in SNIHostName more than in >>>>>>>>> IDN. However, we may need to rethink about the comparing of two >>>>>>>>> IDN, for >>>>>>>>> example, "example.com." should equal to "example.com". I want to >>>>>>>>> consider it in another bug. >>>>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent sets? >>>>>>>> And >>>>>>>> it's not one is another's subset? >>>>>>>> >>>>>>> Per TLS specification, host name in SNI is an IDN. The spec of >>>>>>> SNIHostname says, "hostname is not a valid Internationalized Domain Name >>>>>>> (IDN) compliant with the RFC 3490 specification". The spec in >>>>>>> SNIHostName has the same means as IDN. I won't want to add additional >>>>>>> restrict beyond the specification of an IDN. >>>>>>> >>>>>>> Xuelei >>>>>>> >>>>>>>>> Can I push the changeset? >>>>>>>> I think it's better to ask someone in the networking team to make the >>>>>>>> suggestion. From what I read Michael in this thread, he does not seem >>>>>>>> totally agreed with your code changes (at least not the 00 version). >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>>>>>>>> Ping. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Xuelei >>>>>>>>>>> >>>>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>>>>>>>> Please review the new update: >>>>>>>>>>>> >>>>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>>>>>>>> >>>>>>>>>>>> With this update, "com." is valid (return "com."); "." and >>>>>>>>>>>> "example..com" are invalid. And IAE will be thrown for invalid >>>>>>>>>>>> IDN. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Xuelei >>>>>>>>>>>> >>>>> >>>> >>> >> > From weijun.wang at oracle.com Sun Aug 11 20:15:13 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Aug 2013 11:15:13 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5208526E.5020808@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com> Message-ID: <52085341.5070603@oracle.com> > if (q < input.length()) { // Ah, a dot! > out.append('.'); > } > p = q + 1; Using if (q != input.length()) should be even better. The searchDots method clearly specifies that "or if there is no dots, return the length of input string". --Max From xuelei.fan at oracle.com Sun Aug 11 22:45:12 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 12 Aug 2013 13:45:12 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5208526E.5020808@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com> Message-ID: <52087668.9080500@oracle.com> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/ > Lines 280 and 333: How about we call them steps 8a and 8b? Step 8 is referring to the steps in RFC 3490. Let's use "step 8". Thanks, Xuelei On 8/12/2013 11:11 AM, Weijun Wang wrote: > I think the fix is adequate and necessary. > > One problem: lines 367-373 adds a new IAE to ToUnicode but the method > should not fail forever. > > And some small comments on styles etc. > > On 8/12/13 9:09 AM, Xuelei Fan wrote: >> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/ > > Lines 123 and 185: > > 184 p = q + 1; > 185 if (p < input.length() || q == (input.length() - 1)) { > 186 // has more labels, or keep the trailing dot as at > present > 187 out.append('.'); > 188 } > > I prefer > > if (q < input.length()) { // Ah, a dot! > out.append('.'); > } > p = q + 1; > > Lines 282, 335, 270: Insert a blank after "if". > > Lines 284 and 372: nslookup uses "empty label", which I like better. > > Lines 453 and 460: Personally I don't like the parenthesis for the whole > return value, but you have your choice. > > Lines 280 and 333: How about we call them steps 8a and 8b? > >> >> Added a new test to test illegal hostname in SNIHostName. > > Excellent. Otherwise I will be wondering why the fix in IDN could solve > the problem as described in the bug description. > > Thanks > Max > >> >> Xuelei >> >> On 8/10/2013 10:49 AM, Xuelei Fan wrote: >>> Hi Michael, >>> >>> It is pretty hard to get the issue solved in SNIHostName in a good >>> sharp. Here is my try to state why we should fix the issue in IDN. >>> >>> In SNIHostName, the following hostname are not accepted as valid >>> hostname: >>> 1. empty hostname >>> 2. hostname ends with a trailing dot >>> 3. hostname does not comply to RFC 3490. >>> >>> The process in SNIHostName looks like: >>> 1. call IDN.toASCII() to convert a string hostname >>> 2. check that the return value of #1 is an valid hostname (non-empty, >>> non-end-with-tailing-dot). >>> >>> At present, the IDN cannot handle the following IDN properly. >>> 1. returns "com" for "com." >>> the trailing dot is swallowed. >>> >>> 2. throws StringIndexOutOfBoundsException for "." >>> If "." is an valid IDN that comply to RFC 3490, IDN.toASCII() >>> should >>> be able to handle it; otherwise, IDN.toASCII() should throw IAE as the >>> specification suggested. However, IDN.toASCII(".") throws >>> StringIndexOutOfBoundsException, this behavior does not comply the the >>> specification: >>> >>> 3. throws StringIndexOutOfBoundsException for "example...net" >>> As #2. >>> >>> We can address #1 and #2 in SNIHostName, but the checking is overloaded >>> as IDN also need to address the issue. And SNIHostName has to know >>> what's the separators (".", "\u3002, etc) of IDN in order to check the >>> dot character. It is not a good encapsulation, and involved in too much >>> about the details of domain name, I think. >>> >>> It is a little big hard to address #3 in SNIHostName. >>> >>> Both all of above issue can be easily addressed in IDN. And once IDN >>> addressed these issues, the current SNIHostName is able to handle >>> invalid hostname (empty, trailing dot, etc) correctly. We won't need to >>> touch SNIHostName any more. >>> >>> Please consider it. >>> >>> The latest webrev is at: >>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >>> >>> Thanks, >>> Xuelei >>> >>> On 8/10/2013 9:13 AM, Xuelei Fan wrote: >>>> Hi Michael, >>>> >>>> I plan to address this issue in SNIHostName. I have filled another two >>>> the potential bugs in IDN. >>>> >>>> Thank you, and other people, for the feedback. >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/9/2013 11:25 PM, Xuelei Fan wrote: >>>>> On 8/9/2013 7:31 PM, Michael McMahon wrote: >>>>>> I don't see how this fixes the original problem as the SNIHostName >>>>>> spec >>>>>> still doesn't like hostnames with a trailing '.' >>>>>> >>>>> The bug description did not reflect the IDN specification >>>>> correctly. If >>>>> "com." is a valid IDN, SNIHostName should accept it an an valid >>>>> hostname. The host name in SNIHostName is nothing more or less >>>>> than an >>>>> standard IDN. >>>>> >>>>> I added a comment in the bug: "com." and "." are valid IDN >>>>> according the >>>>> IDN and domain name specifications. I will contact the bug reporter >>>>> about this point. >>>>> >>>>> Xuelei >>>>> >>>>>> I'd prefer to check first where that requirement is coming from, >>>>>> if it is >>>>>> actually necessary, and if not consider removing it from SNIHostName. >>>>>> If it is necessary, then the check should be implemented in >>>>>> SNIHostName. >>>>>> >>>>>> Michael >>>>>> >>>>>> On 09/08/13 05:28, Xuelei Fan wrote: >>>>>>> Thanks for your feedback and suggestions. >>>>>>> >>>>>>> Here is the new webrev: >>>>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >>>>>>> >>>>>>> "." is regarded as valid IDN in this update. >>>>>>> >>>>>>> Thanks, >>>>>>> Xuelei >>>>>>> >>>>>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote: >>>>>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote: >>>>>>>>> >>>>>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>>>>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>>>>>>>>> I tried nslookup. Those with ".." inside are illegal, >>>>>>>>>>> >>>>>>>>>>> $ nslookup com.. >>>>>>>>>>> nslookup: 'com..' is not a legal name (empty label) >>>>>>>>>>> >>>>>>>>>>> but >>>>>>>>>>> >>>>>>>>>>> $ nslookup . >>>>>>>>>>> Server: 192.168.10.1 >>>>>>>>>>> Address: 192.168.10.1#53 >>>>>>>>>>> >>>>>>>>>>> Non-authoritative answer: >>>>>>>>>>> *** Can't find .: No answer >>>>>>>>>>> >>>>>>>>>> Thanks for the testing. The behaviors are the same as this >>>>>>>>>> fix now. >>>>>>>>> No exactly. It seems nslookup still regards "." legal but just >>>>>>>>> cannot >>>>>>>>> find an IP for it. >>>>>>>>> >>>>>>>> I'm not sure whether a root domain name can be stand alone. >>>>>>>> Root label >>>>>>>> is not considered as a label in IDN. I think it is safe to >>>>>>>> regard that >>>>>>>> "." is not a valid IDN as it contains no label. Anyway, it is a >>>>>>>> corner >>>>>>>> case. >>>>>>>> >>>>>>>> There are many online IDN conversion web services, some of them can >>>>>>>> convert ".", some of the cannot. In the present implementation, we >>>>>>>> cannot recognize ".", and IDN.toASCII(".") throws >>>>>>>> StringIndexOutOfBoundsException. With this fix, I was wondering >>>>>>>> IAE is >>>>>>>> a better exception for IDN.toASCII("."). >>>>>>>> >>>>>>>>>> Learn something new today to use nslookup. >>>>>>>>>> >>>>>>>>>>> Also, since this bug was originally about SNIHostName, do you >>>>>>>>>>> need to >>>>>>>>>>> add some extra restriction there to reject "oracle.com." things? >>>>>>>>>>> >>>>>>>>>> No, we cannot restrict the format of IDN in SNIHostName more >>>>>>>>>> than in >>>>>>>>>> IDN. However, we may need to rethink about the comparing of two >>>>>>>>>> IDN, for >>>>>>>>>> example, "example.com." should equal to "example.com". I want to >>>>>>>>>> consider it in another bug. >>>>>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent >>>>>>>>> sets? >>>>>>>>> And >>>>>>>>> it's not one is another's subset? >>>>>>>>> >>>>>>>> Per TLS specification, host name in SNI is an IDN. The spec of >>>>>>>> SNIHostname says, "hostname is not a valid Internationalized >>>>>>>> Domain Name >>>>>>>> (IDN) compliant with the RFC 3490 specification". The spec in >>>>>>>> SNIHostName has the same means as IDN. I won't want to add >>>>>>>> additional >>>>>>>> restrict beyond the specification of an IDN. >>>>>>>> >>>>>>>> Xuelei >>>>>>>> >>>>>>>>>> Can I push the changeset? >>>>>>>>> I think it's better to ask someone in the networking team to >>>>>>>>> make the >>>>>>>>> suggestion. From what I read Michael in this thread, he does >>>>>>>>> not seem >>>>>>>>> totally agreed with your code changes (at least not the 00 >>>>>>>>> version). >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> Max >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Xuelei >>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>>>>>>>>> Ping. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Xuelei >>>>>>>>>>>> >>>>>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>>>>>>>>> Please review the new update: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> With this update, "com." is valid (return "com."); "." and >>>>>>>>>>>>> "example..com" are invalid. And IAE will be thrown for >>>>>>>>>>>>> invalid >>>>>>>>>>>>> IDN. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Xuelei >>>>>>>>>>>>> >>>>>> >>>>> >>>> >>> >> From weijun.wang at oracle.com Sun Aug 11 23:07:08 2013 From: weijun.wang at oracle.com (Weijun Wang) Date: Mon, 12 Aug 2013 14:07:08 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52087668.9080500@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com> <52087668.9080500@oracle.com> Message-ID: <52087B8C.5080105@oracle.com> On 8/12/13 1:45 PM, Xuelei Fan wrote: > new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/ > >> Lines 280 and 333: How about we call them steps 8a and 8b? > > Step 8 is referring to the steps in RFC 3490. Let's use "step 8". You break the 1 <= len <= 63 check into two parts, that's why I say 8a and 8b. --Max > > Thanks, > Xuelei > > On 8/12/2013 11:11 AM, Weijun Wang wrote: >> I think the fix is adequate and necessary. >> >> One problem: lines 367-373 adds a new IAE to ToUnicode but the method >> should not fail forever. >> >> And some small comments on styles etc. >> >> On 8/12/13 9:09 AM, Xuelei Fan wrote: >>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.05/ >> >> Lines 123 and 185: >> >> 184 p = q + 1; >> 185 if (p < input.length() || q == (input.length() - 1)) { >> 186 // has more labels, or keep the trailing dot as at >> present >> 187 out.append('.'); >> 188 } >> >> I prefer >> >> if (q < input.length()) { // Ah, a dot! >> out.append('.'); >> } >> p = q + 1; >> >> Lines 282, 335, 270: Insert a blank after "if". >> >> Lines 284 and 372: nslookup uses "empty label", which I like better. >> >> Lines 453 and 460: Personally I don't like the parenthesis for the whole >> return value, but you have your choice. >> >> Lines 280 and 333: How about we call them steps 8a and 8b? >> >>> >>> Added a new test to test illegal hostname in SNIHostName. >> >> Excellent. Otherwise I will be wondering why the fix in IDN could solve >> the problem as described in the bug description. >> >> Thanks >> Max >> >>> >>> Xuelei >>> >>> On 8/10/2013 10:49 AM, Xuelei Fan wrote: >>>> Hi Michael, >>>> >>>> It is pretty hard to get the issue solved in SNIHostName in a good >>>> sharp. Here is my try to state why we should fix the issue in IDN. >>>> >>>> In SNIHostName, the following hostname are not accepted as valid >>>> hostname: >>>> 1. empty hostname >>>> 2. hostname ends with a trailing dot >>>> 3. hostname does not comply to RFC 3490. >>>> >>>> The process in SNIHostName looks like: >>>> 1. call IDN.toASCII() to convert a string hostname >>>> 2. check that the return value of #1 is an valid hostname (non-empty, >>>> non-end-with-tailing-dot). >>>> >>>> At present, the IDN cannot handle the following IDN properly. >>>> 1. returns "com" for "com." >>>> the trailing dot is swallowed. >>>> >>>> 2. throws StringIndexOutOfBoundsException for "." >>>> If "." is an valid IDN that comply to RFC 3490, IDN.toASCII() >>>> should >>>> be able to handle it; otherwise, IDN.toASCII() should throw IAE as the >>>> specification suggested. However, IDN.toASCII(".") throws >>>> StringIndexOutOfBoundsException, this behavior does not comply the the >>>> specification: >>>> >>>> 3. throws StringIndexOutOfBoundsException for "example...net" >>>> As #2. >>>> >>>> We can address #1 and #2 in SNIHostName, but the checking is overloaded >>>> as IDN also need to address the issue. And SNIHostName has to know >>>> what's the separators (".", "\u3002, etc) of IDN in order to check the >>>> dot character. It is not a good encapsulation, and involved in too much >>>> about the details of domain name, I think. >>>> >>>> It is a little big hard to address #3 in SNIHostName. >>>> >>>> Both all of above issue can be easily addressed in IDN. And once IDN >>>> addressed these issues, the current SNIHostName is able to handle >>>> invalid hostname (empty, trailing dot, etc) correctly. We won't need to >>>> touch SNIHostName any more. >>>> >>>> Please consider it. >>>> >>>> The latest webrev is at: >>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >>>> >>>> Thanks, >>>> Xuelei >>>> >>>> On 8/10/2013 9:13 AM, Xuelei Fan wrote: >>>>> Hi Michael, >>>>> >>>>> I plan to address this issue in SNIHostName. I have filled another two >>>>> the potential bugs in IDN. >>>>> >>>>> Thank you, and other people, for the feedback. >>>>> >>>>> Thanks, >>>>> Xuelei >>>>> >>>>> On 8/9/2013 11:25 PM, Xuelei Fan wrote: >>>>>> On 8/9/2013 7:31 PM, Michael McMahon wrote: >>>>>>> I don't see how this fixes the original problem as the SNIHostName >>>>>>> spec >>>>>>> still doesn't like hostnames with a trailing '.' >>>>>>> >>>>>> The bug description did not reflect the IDN specification >>>>>> correctly. If >>>>>> "com." is a valid IDN, SNIHostName should accept it an an valid >>>>>> hostname. The host name in SNIHostName is nothing more or less >>>>>> than an >>>>>> standard IDN. >>>>>> >>>>>> I added a comment in the bug: "com." and "." are valid IDN >>>>>> according the >>>>>> IDN and domain name specifications. I will contact the bug reporter >>>>>> about this point. >>>>>> >>>>>> Xuelei >>>>>> >>>>>>> I'd prefer to check first where that requirement is coming from, >>>>>>> if it is >>>>>>> actually necessary, and if not consider removing it from SNIHostName. >>>>>>> If it is necessary, then the check should be implemented in >>>>>>> SNIHostName. >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> On 09/08/13 05:28, Xuelei Fan wrote: >>>>>>>> Thanks for your feedback and suggestions. >>>>>>>> >>>>>>>> Here is the new webrev: >>>>>>>> http://cr.openjdk.java.net/~xuelei/8020842/webrev.02/ >>>>>>>> >>>>>>>> "." is regarded as valid IDN in this update. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Xuelei >>>>>>>> >>>>>>>> On 8/9/2013 10:50 AM, Xuelei Fan wrote: >>>>>>>>> On 8/9/2013 10:14 AM, Weijun Wang wrote: >>>>>>>>>> >>>>>>>>>> On 8/9/13 9:37 AM, Xuelei Fan wrote: >>>>>>>>>>> On 8/9/2013 9:22 AM, Weijun Wang wrote: >>>>>>>>>>>> I tried nslookup. Those with ".." inside are illegal, >>>>>>>>>>>> >>>>>>>>>>>> $ nslookup com.. >>>>>>>>>>>> nslookup: 'com..' is not a legal name (empty label) >>>>>>>>>>>> >>>>>>>>>>>> but >>>>>>>>>>>> >>>>>>>>>>>> $ nslookup . >>>>>>>>>>>> Server: 192.168.10.1 >>>>>>>>>>>> Address: 192.168.10.1#53 >>>>>>>>>>>> >>>>>>>>>>>> Non-authoritative answer: >>>>>>>>>>>> *** Can't find .: No answer >>>>>>>>>>>> >>>>>>>>>>> Thanks for the testing. The behaviors are the same as this >>>>>>>>>>> fix now. >>>>>>>>>> No exactly. It seems nslookup still regards "." legal but just >>>>>>>>>> cannot >>>>>>>>>> find an IP for it. >>>>>>>>>> >>>>>>>>> I'm not sure whether a root domain name can be stand alone. >>>>>>>>> Root label >>>>>>>>> is not considered as a label in IDN. I think it is safe to >>>>>>>>> regard that >>>>>>>>> "." is not a valid IDN as it contains no label. Anyway, it is a >>>>>>>>> corner >>>>>>>>> case. >>>>>>>>> >>>>>>>>> There are many online IDN conversion web services, some of them can >>>>>>>>> convert ".", some of the cannot. In the present implementation, we >>>>>>>>> cannot recognize ".", and IDN.toASCII(".") throws >>>>>>>>> StringIndexOutOfBoundsException. With this fix, I was wondering >>>>>>>>> IAE is >>>>>>>>> a better exception for IDN.toASCII("."). >>>>>>>>> >>>>>>>>>>> Learn something new today to use nslookup. >>>>>>>>>>> >>>>>>>>>>>> Also, since this bug was originally about SNIHostName, do you >>>>>>>>>>>> need to >>>>>>>>>>>> add some extra restriction there to reject "oracle.com." things? >>>>>>>>>>>> >>>>>>>>>>> No, we cannot restrict the format of IDN in SNIHostName more >>>>>>>>>>> than in >>>>>>>>>>> IDN. However, we may need to rethink about the comparing of two >>>>>>>>>>> IDN, for >>>>>>>>>>> example, "example.com." should equal to "example.com". I want to >>>>>>>>>>> consider it in another bug. >>>>>>>>>> Not sure. Does the spec say IDN and SNIHostName are equivalent >>>>>>>>>> sets? >>>>>>>>>> And >>>>>>>>>> it's not one is another's subset? >>>>>>>>>> >>>>>>>>> Per TLS specification, host name in SNI is an IDN. The spec of >>>>>>>>> SNIHostname says, "hostname is not a valid Internationalized >>>>>>>>> Domain Name >>>>>>>>> (IDN) compliant with the RFC 3490 specification". The spec in >>>>>>>>> SNIHostName has the same means as IDN. I won't want to add >>>>>>>>> additional >>>>>>>>> restrict beyond the specification of an IDN. >>>>>>>>> >>>>>>>>> Xuelei >>>>>>>>> >>>>>>>>>>> Can I push the changeset? >>>>>>>>>> I think it's better to ask someone in the networking team to >>>>>>>>>> make the >>>>>>>>>> suggestion. From what I read Michael in this thread, he does >>>>>>>>>> not seem >>>>>>>>>> totally agreed with your code changes (at least not the 00 >>>>>>>>>> version). >>>>>>>>>> >>>>>>>>>> Thanks >>>>>>>>>> Max >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Xuelei >>>>>>>>>>> >>>>>>>>>>>> Thanks >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>>>> On 8/9/13 8:41 AM, Xuelei Fan wrote: >>>>>>>>>>>>> Ping. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Xuelei >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/7/2013 11:17 PM, Xuelei Fan wrote: >>>>>>>>>>>>>> Please review the new update: >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://cr.openjdk.java.net./~xuelei/8020842/webrev.01/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> With this update, "com." is valid (return "com."); "." and >>>>>>>>>>>>>> "example..com" are invalid. And IAE will be thrown for >>>>>>>>>>>>>> invalid >>>>>>>>>>>>>> IDN. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Xuelei >>>>>>>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From ivan.gerasimov at oracle.com Mon Aug 12 05:33:48 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 Aug 2013 16:33:48 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204DE28.5090805@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> <5204DE28.5090805@oracle.com> Message-ID: <5208D62C.3030107@oracle.com> David, Chris, I reverted back NULL-checking. Now the change consists of one line removal and a regression test. Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/ Hg export: http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch Sincerely yours, Ivan On 09.08.2013 16:18, David Holmes wrote: > Hi Chris, > > On 9/08/2013 8:36 PM, Chris Hegarty wrote: >> Firstly, I think the memory leak issue should be moved forward >> separately to this cleanup effort. They are unrelated, and I'm starting >> to get the feeling that this could take some time to reach conclusion. >> It seems reasonable to separate the issues. > > I agree. I'm sure when Alan suggested to check the return he didn't > expect it to unravel like this :) As we know hotspot will never > actually return NULL there is no urgency to add this in. > >> On 09/08/2013 10:27, Ivan Gerasimov wrote: >>> Chris, >>> >>> I would use this >>> >>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>> NULL) { >>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); >>> return NULL/JNI_False/-1; >>> } >>> >>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an >>> exception only if it hasn't been already thrown. >> >> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for >> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); >> >> ...and JNU_ThrowByName [1] is defined as... >> >> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { >> class cls = (*env)->FindClass(env, name); >> if (cls != 0) /* Otherwise an exception has already been thrown */ >> (*env)->ThrowNew(env, cls, msg); >> } >> } >> >> Neither FindClass or ThrowNew is safe to call if there is a pending >> exception [1]. > > Right - we have to check for a pending exception before trying to > throw one. > >> Now the issue comes down to; could there ever be a pending exception if >> GetStringUTFChars returns NULL? The latest specs doesn't indicate that >> there could be, but every copy of "The Java Native Interface >> Programmer's Guide and Specification" I can find does. There also >> appears to be an assumption of this if you look at the usages in the >> JDK. > > AFAIK there is only one version of the JNI spec book and it never got > updated. The official spec says no throw, but when people have the > book on their bookshelf that is what they tend to rely on. I looked at > some of the usages and they seem exception agnostic - many of them > don't even check for NULL :( > > The implementation as it stands will not throw and will not return NULL. > >> I would really like to get a definitive answer on the JNI specification >> for GetStringUTFChars before making any changes here. > > The JNI spec (as opposed to the book) is definitive. If we don't like > what is there then it requires a spec change. > > I can't find any reference to this particular issue being raised before. > > Cheers, > David > >> -Chris. >> >> [1] >> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c >> >> >> [2] >> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 >> >> >> >>> >>> Sincerely yours, >>> Ivan >>> >>> >>> On 09.08.2013 11:25, Chris Hegarty wrote: >>>> On 09/08/2013 06:47, David Holmes wrote: >>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will >>>>> return >>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not >>>>> - it >>>>> only says it will return NULL on failure. >>>> >>>> This is indeed strange. Most usages of this function in the jdk expect >>>> the former. If this is not the case, then we may need to do an audit >>>> of all usages. >>>> >>>>> So your previous version was the more correct. Given we just >>>>> failed to >>>>> allocate C-heap I think we are on thin ice anyway, but better to at >>>>> least attempt to do the right thing. >>>> >>>> I'm not sure what the right thing to do here is? It seems a little >>>> unwieldy! >>>> >>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>> NULL) { >>>> if ((*env)->ExceptionOccurred(env)) { >>>> return NULL/JNI_False/-1; >>>> } else { >>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars >>>> failed"); >>>> return NULL/JNI_False/-1; >>>> } >>>> >>>> Given we have no idea why GetStringUTFChars may have failed, what >>>> exception do we throw? >>>> >>>> Also worth noting is that this bug fix has moved away from the >>>> original problem (memory leak), and is now focused on code cleanup. >>>> >>>> If we cannot get agreement on the cleanup, or it looks like more >>>> clarification is needed around the cleanup effort, then I would like >>>> to suggest that we proceed with the original fix for the memory leak >>>> and separate out the cleanup effort. >>>> >>>> -Chris. >>>> >>>>> FYI I filed 8022683 to fix GetStringUTFChars. >>>>> >>>>> David >>>>> ----- >>>>> >>>>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>>>> Thumbs up! >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>>>> Thanks David! >>>>>>> >>>>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>>>> Main fix looks good to me. >>>>>>>> >>>>>>>> Regression test may need some tweaking eg I think othervm will be >>>>>>>> needed. >>>>>>>> >>>>>>> Yes, it's a good point. >>>>>>> Since there may be a memory leak in the test, it'd better not >>>>>>> interfere >>>>>>> with other tests in jtreg. >>>>>>> >>>>>>>> Also this: >>>>>>>> >>>>>>>> System.out.println("WARNING: Cannot perform memory leak >>>>>>>> detection on >>>>>>>> this OS"); >>>>>>>> >>>>>>>> should probably just say something like "Test skipped on this >>>>>>>> OS" - >>>>>>>> there are other tests that do this so just check if there is >>>>>>>> common >>>>>>>> terminology. (In the future we may have keyword tags to flag >>>>>>>> this as >>>>>>>> linux only etc.) >>>>>>>> >>>>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>>>> >>>>>>> Updated webrev is here: >>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>>>> >>>>>>> Updated export is at the same place: >>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Sincerely yours, >>>>>>> Ivan >>>>>>> >>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>>>>> fix. >>>>>>>>> >>>>>>>>> Here's webrev that includes the test: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>>>> >>>>>>>>> The test gets past with the fixed jdk8 and fails with >>>>>>>>> jdk8-b101 and >>>>>>>>> jdk7 >>>>>>>>> as expected. >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>>>> >>>>>>>>>> -Chris. >>>>>>>>>> >>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>>>> Hello Chris! >>>>>>>>>>> >>>>>>>>>>> Here's the update: >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>>>> >>>>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>>>> Here's the hg-export >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>>>> >>>>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>>>> Alan ( >>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>>>> GetStringUTFChars >>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>>>>>> jdk8 >>>>>>>>>>>> for >>>>>>>>>>>> you. >>>>>>>>>>>> >>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>>>> >>>>>>>>>>>> -Chris. >>>>>>>>>>>> >>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>>>> Ivan, >>>>>>>>>>>>> >>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>>> David, Alan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I added checking for NULL results and throwing >>>>>>>>>>>>>> OOMException if >>>>>>>>>>>>>> necessary. >>>>>>>>>>>>> >>>>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>>>> >>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>>>> >>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned >>>>>>>>>>>>> then an >>>>>>>>>>>>> OOME >>>>>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>>>>> native >>>>>>>>>>>>> code >>>>>>>>>>>>> returns to Java. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>>>> indentation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>>>> For allocation of the result string it calls >>>>>>>>>>>>>>>> AllocateHeap() >>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>>>>> stops >>>>>>>>>>>>>>>> VM. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is >>>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>>> throw >>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>>>> exception. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you >>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the >>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not >>>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>> >>>> >>> > > From chris.hegarty at oracle.com Mon Aug 12 05:43:09 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 Aug 2013 13:43:09 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5208D62C.3030107@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> <5204DE28.5090805@oracle.com> <5208D62C.3030107@oracle.com> Message-ID: <5208D85D.1090606@oracle.com> Thank you Ivan. This looks good to me. -Chris. P.S. I will give others a chance to comment. If no objections, I will push this tomorrow for you. On 12/08/2013 13:33, Ivan Gerasimov wrote: > David, Chris, > > I reverted back NULL-checking. > Now the change consists of one line removal and a regression test. > > Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/ > Hg export: > http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch > > > Sincerely yours, > Ivan > > On 09.08.2013 16:18, David Holmes wrote: >> Hi Chris, >> >> On 9/08/2013 8:36 PM, Chris Hegarty wrote: >>> Firstly, I think the memory leak issue should be moved forward >>> separately to this cleanup effort. They are unrelated, and I'm starting >>> to get the feeling that this could take some time to reach conclusion. >>> It seems reasonable to separate the issues. >> >> I agree. I'm sure when Alan suggested to check the return he didn't >> expect it to unravel like this :) As we know hotspot will never >> actually return NULL there is no urgency to add this in. >> >>> On 09/08/2013 10:27, Ivan Gerasimov wrote: >>>> Chris, >>>> >>>> I would use this >>>> >>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>> NULL) { >>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); >>>> return NULL/JNI_False/-1; >>>> } >>>> >>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an >>>> exception only if it hasn't been already thrown. >>> >>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for >>> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); >>> >>> ...and JNU_ThrowByName [1] is defined as... >>> >>> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { >>> class cls = (*env)->FindClass(env, name); >>> if (cls != 0) /* Otherwise an exception has already been thrown */ >>> (*env)->ThrowNew(env, cls, msg); >>> } >>> } >>> >>> Neither FindClass or ThrowNew is safe to call if there is a pending >>> exception [1]. >> >> Right - we have to check for a pending exception before trying to >> throw one. >> >>> Now the issue comes down to; could there ever be a pending exception if >>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that >>> there could be, but every copy of "The Java Native Interface >>> Programmer's Guide and Specification" I can find does. There also >>> appears to be an assumption of this if you look at the usages in the >>> JDK. >> >> AFAIK there is only one version of the JNI spec book and it never got >> updated. The official spec says no throw, but when people have the >> book on their bookshelf that is what they tend to rely on. I looked at >> some of the usages and they seem exception agnostic - many of them >> don't even check for NULL :( >> >> The implementation as it stands will not throw and will not return NULL. >> >>> I would really like to get a definitive answer on the JNI specification >>> for GetStringUTFChars before making any changes here. >> >> The JNI spec (as opposed to the book) is definitive. If we don't like >> what is there then it requires a spec change. >> >> I can't find any reference to this particular issue being raised before. >> >> Cheers, >> David >> >>> -Chris. >>> >>> [1] >>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c >>> >>> >>> [2] >>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 >>> >>> >>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 09.08.2013 11:25, Chris Hegarty wrote: >>>>> On 09/08/2013 06:47, David Holmes wrote: >>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will >>>>>> return >>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not >>>>>> - it >>>>>> only says it will return NULL on failure. >>>>> >>>>> This is indeed strange. Most usages of this function in the jdk expect >>>>> the former. If this is not the case, then we may need to do an audit >>>>> of all usages. >>>>> >>>>>> So your previous version was the more correct. Given we just >>>>>> failed to >>>>>> allocate C-heap I think we are on thin ice anyway, but better to at >>>>>> least attempt to do the right thing. >>>>> >>>>> I'm not sure what the right thing to do here is? It seems a little >>>>> unwieldy! >>>>> >>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>>> NULL) { >>>>> if ((*env)->ExceptionOccurred(env)) { >>>>> return NULL/JNI_False/-1; >>>>> } else { >>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars >>>>> failed"); >>>>> return NULL/JNI_False/-1; >>>>> } >>>>> >>>>> Given we have no idea why GetStringUTFChars may have failed, what >>>>> exception do we throw? >>>>> >>>>> Also worth noting is that this bug fix has moved away from the >>>>> original problem (memory leak), and is now focused on code cleanup. >>>>> >>>>> If we cannot get agreement on the cleanup, or it looks like more >>>>> clarification is needed around the cleanup effort, then I would like >>>>> to suggest that we proceed with the original fix for the memory leak >>>>> and separate out the cleanup effort. >>>>> >>>>> -Chris. >>>>> >>>>>> FYI I filed 8022683 to fix GetStringUTFChars. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>>>>> Thumbs up! >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>>>>> Thanks David! >>>>>>>> >>>>>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>>>>> Main fix looks good to me. >>>>>>>>> >>>>>>>>> Regression test may need some tweaking eg I think othervm will be >>>>>>>>> needed. >>>>>>>>> >>>>>>>> Yes, it's a good point. >>>>>>>> Since there may be a memory leak in the test, it'd better not >>>>>>>> interfere >>>>>>>> with other tests in jtreg. >>>>>>>> >>>>>>>>> Also this: >>>>>>>>> >>>>>>>>> System.out.println("WARNING: Cannot perform memory leak >>>>>>>>> detection on >>>>>>>>> this OS"); >>>>>>>>> >>>>>>>>> should probably just say something like "Test skipped on this >>>>>>>>> OS" - >>>>>>>>> there are other tests that do this so just check if there is >>>>>>>>> common >>>>>>>>> terminology. (In the future we may have keyword tags to flag >>>>>>>>> this as >>>>>>>>> linux only etc.) >>>>>>>>> >>>>>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>>>>> >>>>>>>> Updated webrev is here: >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>>>>> >>>>>>>> Updated export is at the same place: >>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>>>>>> fix. >>>>>>>>>> >>>>>>>>>> Here's webrev that includes the test: >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>>>>> >>>>>>>>>> The test gets past with the fixed jdk8 and fails with >>>>>>>>>> jdk8-b101 and >>>>>>>>>> jdk7 >>>>>>>>>> as expected. >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>>>>> >>>>>>>>>>> -Chris. >>>>>>>>>>> >>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>>>>> Hello Chris! >>>>>>>>>>>> >>>>>>>>>>>> Here's the update: >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>>>>> Here's the hg-export >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>>>>> >>>>>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>>>>> Alan ( >>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>>>>> GetStringUTFChars >>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>>>>>>> jdk8 >>>>>>>>>>>>> for >>>>>>>>>>>>> you. >>>>>>>>>>>>> >>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>>>>> >>>>>>>>>>>>> -Chris. >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>>>>> Ivan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>> David, Alan, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I added checking for NULL results and throwing >>>>>>>>>>>>>>> OOMException if >>>>>>>>>>>>>>> necessary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>>>>> >>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>>>>> >>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned >>>>>>>>>>>>>> then an >>>>>>>>>>>>>> OOME >>>>>>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>>>>>> native >>>>>>>>>>>>>> code >>>>>>>>>>>>>> returns to Java. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>>>>> indentation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>>>>> For allocation of the result string it calls >>>>>>>>>>>>>>>>> AllocateHeap() >>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>>>>>> stops >>>>>>>>>>>>>>>>> VM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is >>>>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>>>> throw >>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>>>>> exception. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the >>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not >>>>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>>>> >>>> >> >> > From ivan.gerasimov at oracle.com Mon Aug 12 05:44:26 2013 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 Aug 2013 16:44:26 +0400 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5208D85D.1090606@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> <5204DE28.5090805@oracle.com> <5208D62C.3030107@oracle.com> <5208D85D.1090606@oracle.com> Message-ID: <5208D8AA.5090302@oracle.com> Thank you Chris! On 12.08.2013 16:43, Chris Hegarty wrote: > Thank you Ivan. This looks good to me. > > -Chris. > > P.S. I will give others a chance to comment. If no objections, I will > push this tomorrow for you. > > On 12/08/2013 13:33, Ivan Gerasimov wrote: >> David, Chris, >> >> I reverted back NULL-checking. >> Now the change consists of one line removal and a regression test. >> >> Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/ >> Hg export: >> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >> >> >> >> Sincerely yours, >> Ivan >> >> On 09.08.2013 16:18, David Holmes wrote: >>> Hi Chris, >>> >>> On 9/08/2013 8:36 PM, Chris Hegarty wrote: >>>> Firstly, I think the memory leak issue should be moved forward >>>> separately to this cleanup effort. They are unrelated, and I'm >>>> starting >>>> to get the feeling that this could take some time to reach conclusion. >>>> It seems reasonable to separate the issues. >>> >>> I agree. I'm sure when Alan suggested to check the return he didn't >>> expect it to unravel like this :) As we know hotspot will never >>> actually return NULL there is no urgency to add this in. >>> >>>> On 09/08/2013 10:27, Ivan Gerasimov wrote: >>>>> Chris, >>>>> >>>>> I would use this >>>>> >>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>>> NULL) { >>>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); >>>>> return NULL/JNI_False/-1; >>>>> } >>>>> >>>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an >>>>> exception only if it hasn't been already thrown. >>>> >>>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for >>>> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); >>>> >>>> ...and JNU_ThrowByName [1] is defined as... >>>> >>>> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { >>>> class cls = (*env)->FindClass(env, name); >>>> if (cls != 0) /* Otherwise an exception has already been thrown */ >>>> (*env)->ThrowNew(env, cls, msg); >>>> } >>>> } >>>> >>>> Neither FindClass or ThrowNew is safe to call if there is a pending >>>> exception [1]. >>> >>> Right - we have to check for a pending exception before trying to >>> throw one. >>> >>>> Now the issue comes down to; could there ever be a pending >>>> exception if >>>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that >>>> there could be, but every copy of "The Java Native Interface >>>> Programmer's Guide and Specification" I can find does. There also >>>> appears to be an assumption of this if you look at the usages in the >>>> JDK. >>> >>> AFAIK there is only one version of the JNI spec book and it never got >>> updated. The official spec says no throw, but when people have the >>> book on their bookshelf that is what they tend to rely on. I looked at >>> some of the usages and they seem exception agnostic - many of them >>> don't even check for NULL :( >>> >>> The implementation as it stands will not throw and will not return >>> NULL. >>> >>>> I would really like to get a definitive answer on the JNI >>>> specification >>>> for GetStringUTFChars before making any changes here. >>> >>> The JNI spec (as opposed to the book) is definitive. If we don't like >>> what is there then it requires a spec change. >>> >>> I can't find any reference to this particular issue being raised >>> before. >>> >>> Cheers, >>> David >>> >>>> -Chris. >>>> >>>> [1] >>>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c >>>> >>>> >>>> >>>> [2] >>>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 >>>> >>>> >>>> >>>> >>>>> >>>>> Sincerely yours, >>>>> Ivan >>>>> >>>>> >>>>> On 09.08.2013 11:25, Chris Hegarty wrote: >>>>>> On 09/08/2013 06:47, David Holmes wrote: >>>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will >>>>>>> return >>>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not >>>>>>> - it >>>>>>> only says it will return NULL on failure. >>>>>> >>>>>> This is indeed strange. Most usages of this function in the jdk >>>>>> expect >>>>>> the former. If this is not the case, then we may need to do an audit >>>>>> of all usages. >>>>>> >>>>>>> So your previous version was the more correct. Given we just >>>>>>> failed to >>>>>>> allocate C-heap I think we are on thin ice anyway, but better to at >>>>>>> least attempt to do the right thing. >>>>>> >>>>>> I'm not sure what the right thing to do here is? It seems a little >>>>>> unwieldy! >>>>>> >>>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>>>> NULL) { >>>>>> if ((*env)->ExceptionOccurred(env)) { >>>>>> return NULL/JNI_False/-1; >>>>>> } else { >>>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars >>>>>> failed"); >>>>>> return NULL/JNI_False/-1; >>>>>> } >>>>>> >>>>>> Given we have no idea why GetStringUTFChars may have failed, what >>>>>> exception do we throw? >>>>>> >>>>>> Also worth noting is that this bug fix has moved away from the >>>>>> original problem (memory leak), and is now focused on code cleanup. >>>>>> >>>>>> If we cannot get agreement on the cleanup, or it looks like more >>>>>> clarification is needed around the cleanup effort, then I would like >>>>>> to suggest that we proceed with the original fix for the memory leak >>>>>> and separate out the cleanup effort. >>>>>> >>>>>> -Chris. >>>>>> >>>>>>> FYI I filed 8022683 to fix GetStringUTFChars. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>>>>>> Thumbs up! >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>>>>>> Thanks David! >>>>>>>>> >>>>>>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>>>>>> Main fix looks good to me. >>>>>>>>>> >>>>>>>>>> Regression test may need some tweaking eg I think othervm >>>>>>>>>> will be >>>>>>>>>> needed. >>>>>>>>>> >>>>>>>>> Yes, it's a good point. >>>>>>>>> Since there may be a memory leak in the test, it'd better not >>>>>>>>> interfere >>>>>>>>> with other tests in jtreg. >>>>>>>>> >>>>>>>>>> Also this: >>>>>>>>>> >>>>>>>>>> System.out.println("WARNING: Cannot perform memory leak >>>>>>>>>> detection on >>>>>>>>>> this OS"); >>>>>>>>>> >>>>>>>>>> should probably just say something like "Test skipped on this >>>>>>>>>> OS" - >>>>>>>>>> there are other tests that do this so just check if there is >>>>>>>>>> common >>>>>>>>>> terminology. (In the future we may have keyword tags to flag >>>>>>>>>> this as >>>>>>>>>> linux only etc.) >>>>>>>>>> >>>>>>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>>>>>> >>>>>>>>> Updated webrev is here: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>>>>>> >>>>>>>>> Updated export is at the same place: >>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Sincerely yours, >>>>>>>>> Ivan >>>>>>>>> >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest >>>>>>>>>>> in the >>>>>>>>>>> fix. >>>>>>>>>>> >>>>>>>>>>> Here's webrev that includes the test: >>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>>>>>> >>>>>>>>>>> The test gets past with the fixed jdk8 and fails with >>>>>>>>>>> jdk8-b101 and >>>>>>>>>>> jdk7 >>>>>>>>>>> as expected. >>>>>>>>>>> >>>>>>>>>>> Sincerely yours, >>>>>>>>>>> Ivan >>>>>>>>>>> >>>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>>>>>> >>>>>>>>>>>> -Chris. >>>>>>>>>>>> >>>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>> Hello Chris! >>>>>>>>>>>>> >>>>>>>>>>>>> Here's the update: >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>>>>>> Here's the hg-export >>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>> Ivan >>>>>>>>>>>>> >>>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>>>>>> Alan ( >>>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>>>>>> GetStringUTFChars >>>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>>>>>>>> jdk8 >>>>>>>>>>>>>> for >>>>>>>>>>>>>> you. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Chris. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>>>>>> Ivan, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>> David, Alan, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I added checking for NULL results and throwing >>>>>>>>>>>>>>>> OOMException if >>>>>>>>>>>>>>>> necessary. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned >>>>>>>>>>>>>>> then an >>>>>>>>>>>>>>> OOME >>>>>>>>>>>>>>> should already be pending and will be thrown as soon as >>>>>>>>>>>>>>> your >>>>>>>>>>>>>>> native >>>>>>>>>>>>>>> code >>>>>>>>>>>>>>> returns to Java. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> David >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>>>>>> indentation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I've checked that and it turns out that >>>>>>>>>>>>>>>>>> GetStringUTFChars >>>>>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>>>>>> For allocation of the result string it calls >>>>>>>>>>>>>>>>>> AllocateHeap() >>>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it >>>>>>>>>>>>>>>>>> simply >>>>>>>>>>>>>>>>>> stops >>>>>>>>>>>>>>>>>> VM. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is >>>>>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>>>>> throw >>>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort >>>>>>>>>>>>>>>>> the VM! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>>>>>> exception. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you >>>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the >>>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were >>>>>>>>>>>>>>>>>>>> reported to >>>>>>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 >>>>>>>>>>>>>>>>>>>> (not >>>>>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>> >>>>>> >>>>> >>> >>> >> > > From sean.mullan at oracle.com Mon Aug 12 06:54:59 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 12 Aug 2013 13:54:59 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130812135553.CEA46487BD@hg.openjdk.java.net> Changeset: ffacf3e7a130 Author: mullan Date: 2013-08-12 09:03 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ffacf3e7a130 8016848: javax_security/auth/login tests fail in compact 1 and 2 profiles Summary: Change the default value of the "login.configuration.provider" security property to sun.security.provider.ConfigFile Reviewed-by: xuelei ! src/share/classes/com/sun/security/auth/login/ConfigFile.java ! src/share/classes/javax/security/auth/login/Configuration.java + src/share/classes/sun/security/provider/ConfigFile.java - src/share/classes/sun/security/provider/ConfigSpiFile.java ! src/share/classes/sun/security/provider/SunEntries.java ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: d73fbf005f5f Author: mullan Date: 2013-08-12 09:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d73fbf005f5f Merge - src/share/classes/java/net/package.html - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh From maurizio.cimadamore at oracle.com Mon Aug 12 09:29:08 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Mon, 12 Aug 2013 16:29:08 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130812162917.4FA16487C5@hg.openjdk.java.net> Changeset: f7f271bd74a2 Author: mcimadamore Date: 2013-08-12 17:25 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f7f271bd74a2 6537020: JCK tests: a compile-time error should be given in case of ambiguously imported fields (types, methods) Summary: Hiding check does not support interface multiple inheritance 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/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/4980495/static/Test.out ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/AlreadDefinedStaticImport.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E1.java ! test/tools/javac/diags/examples/AlreadyDefinedStaticImport/p/E2.java + test/tools/javac/staticImport/6537020/T6537020.java + test/tools/javac/staticImport/6537020/T6537020.out Changeset: af80273f630a Author: mcimadamore Date: 2013-08-12 17:28 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/af80273f630a 8021567: Javac doesn't report \"java: reference to method is ambiguous\" any more Summary: Javac incorrectly forgets about constant folding results within lambdas Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/lambda/8021567/T8021567.java + test/tools/javac/lambda/8021567/T8021567.out + test/tools/javac/lambda/8021567/T8021567b.java From Alan.Bateman at oracle.com Mon Aug 12 09:32:37 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Aug 2013 17:32:37 +0100 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5204DE28.5090805@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> <5204DE28.5090805@oracle.com> Message-ID: <52090E25.6050300@oracle.com> On 09/08/2013 13:18, David Holmes wrote: > > I agree. I'm sure when Alan suggested to check the return he didn't > expect it to unravel like this :) As we know hotspot will never > actually return NULL there is no urgency to add this in. Sorry about this, I wasn't aware of the issue in the JNI spec, we should follow up on that. Ivan's latest webrev (which limits the change to just removing the GetStringUTFChars is fine). The test is okay but it might need time to bed down. -Alan From vicente.romero at oracle.com Mon Aug 12 09:41:24 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Mon, 12 Aug 2013 16:41:24 +0000 Subject: hg: jdk8/tl/jdk: 8015780: java/lang/reflect/Method/GenericStringTest.java failing Message-ID: <20130812164149.C5B8B487C9@hg.openjdk.java.net> Changeset: 70c8f4a4b8d6 Author: vromero Date: 2013-08-12 17:40 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/70c8f4a4b8d6 8015780: java/lang/reflect/Method/GenericStringTest.java failing Reviewed-by: darcy, jfranck ! test/ProblemList.txt ! test/java/lang/reflect/Method/GenericStringTest.java From lance.andersen at oracle.com Mon Aug 12 13:09:57 2013 From: lance.andersen at oracle.com (lance.andersen at oracle.com) Date: Mon, 12 Aug 2013 20:09:57 +0000 Subject: hg: jdk8/tl/jdk: 8022753: SQLXML javadoc example typo Message-ID: <20130812201011.0221F487E1@hg.openjdk.java.net> Changeset: cc64a05836a7 Author: lancea Date: 2013-08-12 16:09 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cc64a05836a7 8022753: SQLXML javadoc example typo Reviewed-by: alanb, mchung ! src/share/classes/java/sql/SQLXML.java From david.holmes at oracle.com Mon Aug 12 22:33:04 2013 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Aug 2013 15:33:04 +1000 Subject: RFR [8022584] Memory leak in some NetworkInterface methods In-Reply-To: <5208D62C.3030107@oracle.com> References: <5202EA83.70207@oracle.com> <5202EEC6.8050106@oracle.com> <5202F244.6070006@oracle.com> <5202F5D4.7070806@oracle.com> <520318F3.7080609@oracle.com> <52032625.3000501@oracle.com> <52035A18.8020803@oracle.com> <52039E2E.6090504@oracle.com> <5203A243.60505@oracle.com> <5203E642.40005@oracle.com> <52040A76.3060602@oracle.com> <52041988.80705@oracle.com> <52047C66.2080001@oracle.com> <52048269.7000501@oracle.com> <5204997B.3090601@oracle.com> <5204B5F3.6000506@oracle.com> <5204C626.3000102@oracle.com> <5204DE28.5090805@oracle.com> <5208D62C.3030107@oracle.com> Message-ID: <5209C510.5000001@oracle.com> Thanks Ivan. David On 12/08/2013 10:33 PM, Ivan Gerasimov wrote: > David, Chris, > > I reverted back NULL-checking. > Now the change consists of one line removal and a regression test. > > Webrev: http://cr.openjdk.java.net/~igerasim/8022584/6/webrev/ > Hg export: > http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch > > > Sincerely yours, > Ivan > > On 09.08.2013 16:18, David Holmes wrote: >> Hi Chris, >> >> On 9/08/2013 8:36 PM, Chris Hegarty wrote: >>> Firstly, I think the memory leak issue should be moved forward >>> separately to this cleanup effort. They are unrelated, and I'm starting >>> to get the feeling that this could take some time to reach conclusion. >>> It seems reasonable to separate the issues. >> >> I agree. I'm sure when Alan suggested to check the return he didn't >> expect it to unravel like this :) As we know hotspot will never >> actually return NULL there is no urgency to add this in. >> >>> On 09/08/2013 10:27, Ivan Gerasimov wrote: >>>> Chris, >>>> >>>> I would use this >>>> >>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>> NULL) { >>>> JNU_ThrowOutOfMemoryError(env, "GetStringUTFChars failed"); >>>> return NULL/JNI_False/-1; >>>> } >>>> >>>> If I understand it correctly, JNU_ThrowOutOfMemoryError throws an >>>> exception only if it hasn't been already thrown. >>> >>> JNU_ThrowOutOfMemoryError is simply a convenience wrapper for >>> JNU_ThrowByName(env, "java/lang/OutOfMemoryError", msg); >>> >>> ...and JNU_ThrowByName [1] is defined as... >>> >>> JNU_ThrowByName(JNIEnv *env, const char *name, const char *msg) { >>> class cls = (*env)->FindClass(env, name); >>> if (cls != 0) /* Otherwise an exception has already been thrown */ >>> (*env)->ThrowNew(env, cls, msg); >>> } >>> } >>> >>> Neither FindClass or ThrowNew is safe to call if there is a pending >>> exception [1]. >> >> Right - we have to check for a pending exception before trying to >> throw one. >> >>> Now the issue comes down to; could there ever be a pending exception if >>> GetStringUTFChars returns NULL? The latest specs doesn't indicate that >>> there could be, but every copy of "The Java Native Interface >>> Programmer's Guide and Specification" I can find does. There also >>> appears to be an assumption of this if you look at the usages in the >>> JDK. >> >> AFAIK there is only one version of the JNI spec book and it never got >> updated. The official spec says no throw, but when people have the >> book on their bookshelf that is what they tend to rely on. I looked at >> some of the usages and they seem exception agnostic - many of them >> don't even check for NULL :( >> >> The implementation as it stands will not throw and will not return NULL. >> >>> I would really like to get a definitive answer on the JNI specification >>> for GetStringUTFChars before making any changes here. >> >> The JNI spec (as opposed to the book) is definitive. If we don't like >> what is there then it requires a spec change. >> >> I can't find any reference to this particular issue being raised before. >> >> Cheers, >> David >> >>> -Chris. >>> >>> [1] >>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/54f0ccdd9ad7/src/share/native/common/jni_util.c >>> >>> >>> [2] >>> http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/design.html#wp17626 >>> >>> >>> >>>> >>>> Sincerely yours, >>>> Ivan >>>> >>>> >>>> On 09.08.2013 11:25, Chris Hegarty wrote: >>>>> On 09/08/2013 06:47, David Holmes wrote: >>>>>> Sorry I messed this up. The JNI book says GetStringUTFChars will >>>>>> return >>>>>> NULL and post OOME but the JNI spec (latest version 6.0) does not >>>>>> - it >>>>>> only says it will return NULL on failure. >>>>> >>>>> This is indeed strange. Most usages of this function in the jdk expect >>>>> the former. If this is not the case, then we may need to do an audit >>>>> of all usages. >>>>> >>>>>> So your previous version was the more correct. Given we just >>>>>> failed to >>>>>> allocate C-heap I think we are on thin ice anyway, but better to at >>>>>> least attempt to do the right thing. >>>>> >>>>> I'm not sure what the right thing to do here is? It seems a little >>>>> unwieldy! >>>>> >>>>> if ((name_utf = (*env)->GetStringUTFChars(env, name, &isCopy)) == >>>>> NULL) { >>>>> if ((*env)->ExceptionOccurred(env)) { >>>>> return NULL/JNI_False/-1; >>>>> } else { >>>>> throwException(env, "java/lang/InternalError", "GetStringUTFChars >>>>> failed"); >>>>> return NULL/JNI_False/-1; >>>>> } >>>>> >>>>> Given we have no idea why GetStringUTFChars may have failed, what >>>>> exception do we throw? >>>>> >>>>> Also worth noting is that this bug fix has moved away from the >>>>> original problem (memory leak), and is now focused on code cleanup. >>>>> >>>>> If we cannot get agreement on the cleanup, or it looks like more >>>>> clarification is needed around the cleanup effort, then I would like >>>>> to suggest that we proceed with the original fix for the memory leak >>>>> and separate out the cleanup effort. >>>>> >>>>> -Chris. >>>>> >>>>>> FYI I filed 8022683 to fix GetStringUTFChars. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> On 9/08/2013 3:21 PM, David Holmes wrote: >>>>>>> Thumbs up! >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 9/08/2013 8:19 AM, Ivan Gerasimov wrote: >>>>>>>> Thanks David! >>>>>>>> >>>>>>>> On 09.08.2013 1:15, David Holmes wrote: >>>>>>>>> Main fix looks good to me. >>>>>>>>> >>>>>>>>> Regression test may need some tweaking eg I think othervm will be >>>>>>>>> needed. >>>>>>>>> >>>>>>>> Yes, it's a good point. >>>>>>>> Since there may be a memory leak in the test, it'd better not >>>>>>>> interfere >>>>>>>> with other tests in jtreg. >>>>>>>> >>>>>>>>> Also this: >>>>>>>>> >>>>>>>>> System.out.println("WARNING: Cannot perform memory leak >>>>>>>>> detection on >>>>>>>>> this OS"); >>>>>>>>> >>>>>>>>> should probably just say something like "Test skipped on this >>>>>>>>> OS" - >>>>>>>>> there are other tests that do this so just check if there is >>>>>>>>> common >>>>>>>>> terminology. (In the future we may have keyword tags to flag >>>>>>>>> this as >>>>>>>>> linux only etc.) >>>>>>>>> >>>>>>>> OK, I changed the phrase to "Test only runs on Linux". >>>>>>>> >>>>>>>> Updated webrev is here: >>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/4/webrev/ >>>>>>>> >>>>>>>> Updated export is at the same place: >>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Sincerely yours, >>>>>>>> Ivan >>>>>>>> >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> On 9/08/2013 4:41 AM, Ivan Gerasimov wrote: >>>>>>>>>> Chris, if it's not too late, I'd like to include a regtest in the >>>>>>>>>> fix. >>>>>>>>>> >>>>>>>>>> Here's webrev that includes the test: >>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/3/webrev/ >>>>>>>>>> >>>>>>>>>> The test gets past with the fixed jdk8 and fails with >>>>>>>>>> jdk8-b101 and >>>>>>>>>> jdk7 >>>>>>>>>> as expected. >>>>>>>>>> >>>>>>>>>> Sincerely yours, >>>>>>>>>> Ivan >>>>>>>>>> >>>>>>>>>> On 08.08.2013 17:50, Chris Hegarty wrote: >>>>>>>>>>> Looks good to me. Thanks Ivan. >>>>>>>>>>> >>>>>>>>>>> -Chris. >>>>>>>>>>> >>>>>>>>>>> On 08/08/2013 02:33 PM, Ivan Gerasimov wrote: >>>>>>>>>>>> Hello Chris! >>>>>>>>>>>> >>>>>>>>>>>> Here's the update: >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/2/webrev/ >>>>>>>>>>>> >>>>>>>>>>>> Thanks for offering the sponsorship! >>>>>>>>>>>> Here's the hg-export >>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/2commit/8022584-jdk8-Memleak-in-NetworkInterface.patch >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>> Ivan >>>>>>>>>>>> >>>>>>>>>>>> On 08.08.2013 12:43, Chris Hegarty wrote: >>>>>>>>>>>>> Thanks for taking this Ivan. >>>>>>>>>>>>> >>>>>>>>>>>>> Can you please make the changes suggested by both David and >>>>>>>>>>>>> Alan ( >>>>>>>>>>>>> simply return NULL/-1/JNI_FALSE, as appropriate, if >>>>>>>>>>>>> GetStringUTFChars >>>>>>>>>>>>> fails ( returns NULL ), then I will sponsor this change into >>>>>>>>>>>>> jdk8 >>>>>>>>>>>>> for >>>>>>>>>>>>> you. >>>>>>>>>>>>> >>>>>>>>>>>>> Please post an update webrev to cr.openjdk.java.net. >>>>>>>>>>>>> >>>>>>>>>>>>> -Chris. >>>>>>>>>>>>> >>>>>>>>>>>>> On 08/08/2013 06:01 AM, David Holmes wrote: >>>>>>>>>>>>>> Ivan, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/08/2013 2:05 PM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>> David, Alan, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I added checking for NULL results and throwing >>>>>>>>>>>>>>> OOMException if >>>>>>>>>>>>>>> necessary. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You don't need to throw it yourself: >>>>>>>>>>>>>> >>>>>>>>>>>>>> JNU_ThrowOutOfMemoryError(env, NULL); >>>>>>>>>>>>>> >>>>>>>>>>>>>> Assuming a correct VM implementation if NULL is returned >>>>>>>>>>>>>> then an >>>>>>>>>>>>>> OOME >>>>>>>>>>>>>> should already be pending and will be thrown as soon as your >>>>>>>>>>>>>> native >>>>>>>>>>>>>> code >>>>>>>>>>>>>> returns to Java. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've also added some spaces along the code to improve >>>>>>>>>>>>>>> indentation. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Would you please review the updated webrev? >>>>>>>>>>>>>>> http://washi.ru.oracle.com/~igerasim/webrevs/8022584/1/webrev/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 08.08.2013 5:35, David Holmes wrote: >>>>>>>>>>>>>>>> On 8/08/2013 11:20 AM, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>> Thanks Alan! >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I've checked that and it turns out that GetStringUTFChars >>>>>>>>>>>>>>>>> cannot >>>>>>>>>>>>>>>>> return >>>>>>>>>>>>>>>>> NULL. >>>>>>>>>>>>>>>>> For allocation of the result string it calls >>>>>>>>>>>>>>>>> AllocateHeap() >>>>>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> default EXIT_OOM fail strategy. >>>>>>>>>>>>>>>>> Thus, in case of being unable to allocate memory it simply >>>>>>>>>>>>>>>>> stops >>>>>>>>>>>>>>>>> VM. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ouch! That is a hotspot bug. GetStringUTFChars is >>>>>>>>>>>>>>>> supposed to >>>>>>>>>>>>>>>> throw >>>>>>>>>>>>>>>> OutOfMemoryError if it has memory issues, not abort the VM! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I recommend that you check for NULL and/or a pending >>>>>>>>>>>>>>>> exception. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> David >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 08.08.2013 5:05, Alan Bateman wrote: >>>>>>>>>>>>>>>>>> (cc'ing net-dev). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> The change looks okay to me. One suggestion (while you >>>>>>>>>>>>>>>>>> are >>>>>>>>>>>>>>>>>> there) is >>>>>>>>>>>>>>>>>> to check the return from GetStringUTFChars so that the >>>>>>>>>>>>>>>>>> name >>>>>>>>>>>>>>>>>> returns >>>>>>>>>>>>>>>>>> when it fails with NULL. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Alan. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 07/08/2013 17:46, Ivan Gerasimov wrote: >>>>>>>>>>>>>>>>>>> Hello everybody! >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Some methods of NetworkInterface class were reported to >>>>>>>>>>>>>>>>>>> leak >>>>>>>>>>>>>>>>>>> memory. >>>>>>>>>>>>>>>>>>> http://bugs.sun.com/view_bug.do?bug_id=JDK-8022584 (not >>>>>>>>>>>>>>>>>>> yet >>>>>>>>>>>>>>>>>>> available.) >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Examples are isUp() and isLoopback(). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Affected versions of jdk are 6, 7 and 8 >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Would you please review a simple fix that removes the >>>>>>>>>>>>>>>>>>> unnecessary >>>>>>>>>>>>>>>>>>> allocation? >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~igerasim/8022584/0/webrev/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Sincerely yours, >>>>>>>>>>>>>>>>>>> Ivan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>>>> >>>> >> >> > From xuelei.fan at oracle.com Tue Aug 13 01:29:32 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 13 Aug 2013 16:29:32 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <52087B8C.5080105@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com> <52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com> Message-ID: <5209EE6C.3050604@oracle.com> Can I get an additional code review from networking team? Thanks, Xuelei On 8/12/2013 2:07 PM, Weijun Wang wrote: > new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/ From sean.mullan at oracle.com Tue Aug 13 06:05:47 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 13 Aug 2013 13:05:47 +0000 Subject: hg: jdk8/tl/jdk: 8020081: Cipher with OAEPPadding and OAEPParameterSpec can't be created Message-ID: <20130813130623.337D448806@hg.openjdk.java.net> Changeset: 5b14d702b0b8 Author: ascarpino Date: 2013-08-12 11:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b14d702b0b8 8020081: Cipher with OAEPPadding and OAEPParameterSpec can't be created Reviewed-by: mullan ! src/share/classes/com/sun/crypto/provider/SunJCE.java + test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java From vincent.x.ryan at oracle.com Tue Aug 13 06:19:13 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Tue, 13 Aug 2013 13:19:13 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130813131940.272B248807@hg.openjdk.java.net> Changeset: 818c3f82269c Author: vinnie Date: 2013-08-13 14:15 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/818c3f82269c 8013170: Spec for PBEParameterSpec does not specify behavior when paramSpec is null Reviewed-by: mullan ! src/share/classes/javax/crypto/spec/PBEParameterSpec.java Changeset: 26753a05859a Author: vinnie Date: 2013-08-13 14:18 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/26753a05859a Merge From alan.bateman at oracle.com Tue Aug 13 06:46:41 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Tue, 13 Aug 2013 13:46:41 +0000 Subject: hg: jdk8/tl/jdk: 8022180: BigInteger Burnikel-Ziegler quotient and remainder calculation assumes quotient parameter is zero Message-ID: <20130813134655.5EFA14880A@hg.openjdk.java.net> Changeset: 834faf2081b3 Author: bpb Date: 2013-08-12 16:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/834faf2081b3 8022180: BigInteger Burnikel-Ziegler quotient and remainder calculation assumes quotient parameter is zero Summary: Clear the quotient in divideAndRemainderBurnikelZiegler() if the divisor is larger than the dividend. Reviewed-by: alanb, bpb Contributed-by: Timothy Buktu ! src/share/classes/java/math/MutableBigInteger.java ! test/java/math/BigInteger/BigIntegerTest.java From daniel.fuchs at oracle.com Tue Aug 13 07:01:14 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Tue, 13 Aug 2013 14:01:14 +0000 Subject: hg: jdk8/tl/jdk: 8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is failing intermittently Message-ID: <20130813140126.A06E14880E@hg.openjdk.java.net> Changeset: 78c102c3eefc Author: dfuchs Date: 2013-08-13 16:00 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/78c102c3eefc 8019948: java/util/logging/bundlesearch/ResourceBundleSearchTest.java is failing intermittently Reviewed-by: mchung, dholmes ! test/java/util/logging/bundlesearch/ResourceBundleSearchTest.java From sean.mullan at oracle.com Tue Aug 13 07:10:00 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 13 Aug 2013 14:10:00 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130813141024.7A95E4880F@hg.openjdk.java.net> Changeset: 412b2f0950a9 Author: mullan Date: 2013-08-13 10:06 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/412b2f0950a9 8022897: Add test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java to ProblemList Reviewed-by: vinnie, chegar ! test/ProblemList.txt Changeset: 19133b3af95f Author: mullan Date: 2013-08-13 10:07 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/19133b3af95f Merge ! test/ProblemList.txt From chris.hegarty at oracle.com Tue Aug 13 06:57:59 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Tue, 13 Aug 2013 13:57:59 +0000 Subject: hg: jdk8/tl/jdk: 8022779: ProblemList.txt updates (8/2013) Message-ID: <20130813135811.2FB3A4880C@hg.openjdk.java.net> Changeset: 18e15d92610b Author: chegar Date: 2013-08-13 14:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18e15d92610b 8022779: ProblemList.txt updates (8/2013) Summary: Update ProblemList and remove AggressiveOpts MOAT test run Reviewed-by: chegar, alanb Contributed-by: Amy Lu ! test/ProblemList.txt ! test/java/util/Collection/MOAT.java From joe.darcy at oracle.com Tue Aug 13 10:12:46 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 13 Aug 2013 17:12:46 +0000 Subject: hg: jdk8/tl/jdk: 8022959: Fix new doclint issues in java.util.zip Message-ID: <20130813171336.4A95548827@hg.openjdk.java.net> Changeset: cd9379e348d0 Author: darcy Date: 2013-08-13 10:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cd9379e348d0 8022959: Fix new doclint issues in java.util.zip Reviewed-by: chegar ! src/share/classes/java/util/zip/ZipEntry.java From rob.mckenna at oracle.com Tue Aug 13 11:09:34 2013 From: rob.mckenna at oracle.com (rob.mckenna at oracle.com) Date: Tue, 13 Aug 2013 18:09:34 +0000 Subject: hg: jdk8/tl/jdk: 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion Message-ID: <20130813181025.5211F4882B@hg.openjdk.java.net> Changeset: a4b0be7341ef Author: robm Date: 2013-08-13 19:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a4b0be7341ef 5049299: (process) Use posix_spawn, not fork, on S10 to avoid swap exhaustion Reviewed-by: alanb, dholmes, martin, erikj, coffeys ! make/java/java/Exportedfiles.gmk ! make/java/java/Makefile ! makefiles/CompileLaunchers.gmk ! makefiles/CompileNativeLibraries.gmk ! src/solaris/classes/java/lang/UNIXProcess.java.bsd ! src/solaris/classes/java/lang/UNIXProcess.java.linux ! src/solaris/classes/java/lang/UNIXProcess.java.solaris ! src/solaris/native/java/lang/UNIXProcess_md.c + src/solaris/native/java/lang/childproc.c + src/solaris/native/java/lang/childproc.h + src/solaris/native/java/lang/jspawnhelper.c ! test/java/lang/ProcessBuilder/Basic.java From lana.steuck at oracle.com Tue Aug 13 19:47:11 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 14 Aug 2013 02:47:11 +0000 Subject: hg: jdk8/tl/nashorn: 3 new changesets Message-ID: <20130814024719.4B06448856@hg.openjdk.java.net> Changeset: 795cff5c1b5c Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/795cff5c1b5c Added tag jdk8-b102 for changeset e966ff0a3ffe ! .hgtags Changeset: 414203de4374 Author: lana Date: 2013-08-13 10:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/414203de4374 Merge Changeset: 8ecf68b292d0 Author: lana Date: 2013-08-13 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/8ecf68b292d0 Merge From lana.steuck at oracle.com Tue Aug 13 19:47:11 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 14 Aug 2013 02:47:11 +0000 Subject: hg: jdk8/tl/jaxp: 2 new changesets Message-ID: <20130814024727.1676748858@hg.openjdk.java.net> Changeset: b1ceab582fc6 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/b1ceab582fc6 Added tag jdk8-b102 for changeset 7cffafa606e9 ! .hgtags Changeset: 9800647936dd Author: lana Date: 2013-08-13 18:28 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/9800647936dd Merge From lana.steuck at oracle.com Tue Aug 13 19:47:03 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 14 Aug 2013 02:47:03 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130814024709.852E048855@hg.openjdk.java.net> Changeset: f8ed09af1df6 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/f8ed09af1df6 Added tag jdk8-b102 for changeset 528c7e76eaee ! .hgtags Changeset: 49c4a777fdfd Author: lana Date: 2013-08-13 10:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/49c4a777fdfd Merge From lana.steuck at oracle.com Tue Aug 13 19:47:08 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 14 Aug 2013 02:47:08 +0000 Subject: hg: jdk8/tl: Added tag jdk8-b102 for changeset 5eb3c1dc348f Message-ID: <20130814024709.7C73148854@hg.openjdk.java.net> Changeset: b7e64be81c8a Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/b7e64be81c8a Added tag jdk8-b102 for changeset 5eb3c1dc348f ! .hgtags From lana.steuck at oracle.com Tue Aug 13 19:47:11 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 14 Aug 2013 02:47:11 +0000 Subject: hg: jdk8/tl/langtools: 3 new changesets Message-ID: <20130814024733.007B548859@hg.openjdk.java.net> Changeset: 6718df4cd616 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/6718df4cd616 Added tag jdk8-b102 for changeset 453a305e1165 ! .hgtags Changeset: 76cfe7c61f25 Author: lana Date: 2013-08-13 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/76cfe7c61f25 Merge Changeset: 32b6a99cc74e Author: lana Date: 2013-08-13 18:34 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/32b6a99cc74e Merge From lana.steuck at oracle.com Tue Aug 13 19:47:20 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 14 Aug 2013 02:47:20 +0000 Subject: hg: jdk8/tl/hotspot: 25 new changesets Message-ID: <20130814024823.802374885A@hg.openjdk.java.net> Changeset: b9a927798f12 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b9a927798f12 Added tag jdk8-b102 for changeset c4697c1c4484 ! .hgtags Changeset: 79ce055063e9 Author: amurillo Date: 2013-08-02 03:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79ce055063e9 8022124: new hotspot build - hs25-b45 Reviewed-by: jcoomes ! make/hotspot_version Changeset: 9bd314787fad Author: mseledtsov Date: 2013-08-01 22:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9bd314787fad 8020614: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output Summary: OutputAnalyzer.shouldHaveExitValue() should print stdout/stderr output Reviewed-by: kvn, ctornqvi, dholmes + test/testlibrary/OutputAnalyzerReportingTest.java ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java ! test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java Changeset: c01913206da5 Author: ctornqvi Date: 2013-08-01 22:20 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c01913206da5 8014294: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle Summary: Assert in ThreadTimesClosure::do_thread() due to use of naked oop instead of handle Reviewed-by: coleenp, sspitsyn ! src/share/vm/services/management.cpp Changeset: 81e0f17ade64 Author: ctornqvi Date: 2013-08-01 22:25 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/81e0f17ade64 8009407: runtime/8000968/Test8000968.sh has incorrect check for proper config Summary: runtime/8000968/Test8000968.sh has incorrect check for proper config Reviewed-by: coleenp, mseledtsov, sspitsyn, hseigel - test/runtime/8000968/Test8000968.sh + test/runtime/CompressedOops/CompressedKlassPointerAndOops.java Changeset: 32e3bada0978 Author: kevinw Date: 2013-08-02 12:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/32e3bada0978 8020943: Memory leak when GCNotifier uses create_from_platform_dependent_str() Reviewed-by: mgerdin, fparain, dcubed ! src/share/vm/services/gcNotifier.cpp Changeset: dee4c330acd4 Author: dcubed Date: 2013-08-02 08:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dee4c330acd4 Merge - test/runtime/8000968/Test8000968.sh Changeset: fa57c8104b76 Author: ctornqvi Date: 2013-08-02 18:12 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/fa57c8104b76 8009585: test/runtime/7196045 times out Summary: test/runtime/7196045 times out Reviewed-by: dholmes, mseledtsov - test/runtime/7196045/Test7196045.java + test/runtime/InternalApi/ThreadCpuTimesDeadlock.java Changeset: 0f209afdfcf8 Author: ctornqvi Date: 2013-08-02 18:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0f209afdfcf8 Merge Changeset: d02de8cac823 Author: ctornqvi Date: 2013-08-02 22:34 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d02de8cac823 Merge - test/runtime/7196045/Test7196045.java Changeset: e0379d5ba5d2 Author: kevinw Date: 2013-08-05 10:27 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/e0379d5ba5d2 8021444: SA: ClassDump.run() should not ignore existing ClassFilter. Reviewed-by: minqi, poonam ! agent/src/share/classes/sun/jvm/hotspot/tools/jcore/ClassDump.java Changeset: b67604b59546 Author: hseigel Date: 2013-08-04 16:30 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/b67604b59546 7073961: [TESTBUG] closed/runtime/4845371/DBB.java failed on solaris 10 X65 Summary: Added a x86 64-bit Solaris shared library and rewrote test in Java Reviewed-by: dholmes, ctornqvi ! test/testlibrary/com/oracle/java/testlibrary/Platform.java Changeset: 9064e3a19525 Author: hseigel Date: 2013-08-05 08:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9064e3a19525 Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 22a5aff0df0b Author: dsamersoff Date: 2013-08-06 14:28 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/22a5aff0df0b 8019396: SA-JDI OSThread class initialization throws an exception Summary: Method sun.jvm.hotspot.runtime.OSThread.initialize throws a sun.jvm.hotspot.types.WrongTypeException Reviewed-by: dholmes, mgerdin ! agent/src/share/classes/sun/jvm/hotspot/jdi/JVMTIThreadState.java ! agent/src/share/classes/sun/jvm/hotspot/runtime/OSThread.java Changeset: cd25d3be91c5 Author: vladidan Date: 2013-08-06 20:01 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/cd25d3be91c5 8012144: multiple SIGSEGVs fails on staxf Summary: Forward port of 7u change to add additional fence() on RMO platforms, with a load_acquire on all platforms Reviewed-by: dholmes, kvn ! src/share/vm/utilities/taskqueue.hpp Changeset: f5bed20f2492 Author: dholmes Date: 2013-08-08 08:29 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/f5bed20f2492 Merge Changeset: 79a5283f4595 Author: iignatyev Date: 2013-07-29 11:54 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/79a5283f4595 8021120: TieredCompilation can be enabled even if TIERED is undefined Reviewed-by: kvn, dholmes ! src/share/vm/runtime/arguments.cpp Changeset: 8d77d02828d9 Author: twisti Date: 2013-07-29 16:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/8d77d02828d9 8016474: Crash in sun.reflect.UnsafeObjectFieldAccessorImpl.get Summary: C1's GetUnsafeObject G1 pre-barrier uses the wrong type to read the klass pointer. Reviewed-by: iveresov, kvn ! src/share/vm/c1/c1_LIRGenerator.cpp + test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java Changeset: 446cb5d25d03 Author: anoll Date: 2013-08-01 16:01 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/446cb5d25d03 8020531: Test compiler/codecache/CheckUpperLimit.java fails when memory limited Summary: Removed part of the test that required the VM to start up with -XX:ReservedCodeCacheSize=2048m Reviewed-by: kvn, rbackman ! test/compiler/codecache/CheckUpperLimit.java Changeset: 6e04c193845f Author: anoll Date: 2013-08-02 10:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6e04c193845f 8021301: better event messages Summary: made event messages better readable Reviewed-by: kvn, rbackman ! src/share/vm/classfile/classLoader.cpp ! src/share/vm/utilities/exceptions.cpp Changeset: 5e0b3d7df485 Author: rbackman Date: 2013-08-05 17:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5e0b3d7df485 Merge ! src/share/vm/runtime/arguments.cpp Changeset: 71526a36ebb4 Author: twisti Date: 2013-08-05 15:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/71526a36ebb4 8022029: GetUnsafeObjectG1PreBarrier fails on 32-bit with: Unrecognized VM option 'ObjectAlignmentInBytes=32' Reviewed-by: kvn ! test/compiler/unsafe/GetUnsafeObjectG1PreBarrier.java Changeset: dadf62510ae4 Author: rbackman Date: 2013-08-08 23:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/dadf62510ae4 Merge Changeset: 7f55137d6aa8 Author: amurillo Date: 2013-08-09 01:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7f55137d6aa8 Merge - test/runtime/7196045/Test7196045.java - test/runtime/8000968/Test8000968.sh Changeset: 6f9be7f87b96 Author: amurillo Date: 2013-08-09 01:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6f9be7f87b96 Added tag hs25-b45 for changeset 7f55137d6aa8 ! .hgtags From lana.steuck at oracle.com Tue Aug 13 19:47:11 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 14 Aug 2013 02:47:11 +0000 Subject: hg: jdk8/tl/jaxws: Added tag jdk8-b102 for changeset 988a5f2ac559 Message-ID: <20130814024722.7F86B48857@hg.openjdk.java.net> Changeset: 6cdc6ed98780 Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/6cdc6ed98780 Added tag jdk8-b102 for changeset 988a5f2ac559 ! .hgtags From lana.steuck at oracle.com Tue Aug 13 19:48:48 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 14 Aug 2013 02:48:48 +0000 Subject: hg: jdk8/tl/jdk: 21 new changesets Message-ID: <20130814025338.ABC014885B@hg.openjdk.java.net> Changeset: e057cddf0d6c Author: cl Date: 2013-08-08 10:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e057cddf0d6c Added tag jdk8-b102 for changeset 8ed8e2b4b90e ! .hgtags Changeset: 1c6bfb303ffc Author: prr Date: 2013-08-06 13:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1c6bfb303ffc 8022175: Fix doclint warnings in javax.print Reviewed-by: darcy ! src/share/classes/javax/print/DocFlavor.java ! src/share/classes/javax/print/MultiDocPrintJob.java ! src/share/classes/javax/print/PrintService.java ! src/share/classes/javax/print/ServiceUI.java ! src/share/classes/javax/print/ServiceUIFactory.java ! src/share/classes/javax/print/attribute/AttributeSet.java ! src/share/classes/javax/print/attribute/DateTimeSyntax.java ! src/share/classes/javax/print/attribute/DocAttributeSet.java ! src/share/classes/javax/print/attribute/EnumSyntax.java ! src/share/classes/javax/print/attribute/HashAttributeSet.java ! src/share/classes/javax/print/attribute/IntegerSyntax.java ! src/share/classes/javax/print/attribute/PrintJobAttributeSet.java ! src/share/classes/javax/print/attribute/PrintRequestAttributeSet.java ! src/share/classes/javax/print/attribute/PrintServiceAttributeSet.java ! src/share/classes/javax/print/attribute/ResolutionSyntax.java ! src/share/classes/javax/print/attribute/Size2DSyntax.java ! src/share/classes/javax/print/attribute/standard/Chromaticity.java ! src/share/classes/javax/print/attribute/standard/Compression.java ! src/share/classes/javax/print/attribute/standard/Finishings.java ! src/share/classes/javax/print/attribute/standard/JobKOctets.java ! src/share/classes/javax/print/attribute/standard/MediaPrintableArea.java ! src/share/classes/javax/print/attribute/standard/MediaSize.java ! src/share/classes/javax/print/attribute/standard/PresentationDirection.java ! src/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java ! src/share/classes/javax/print/attribute/standard/PrinterResolution.java Changeset: c3b91dc2504a Author: jgodinez Date: 2013-08-06 14:22 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c3b91dc2504a 8021583: test/javax/print/autosense/PrintAutoSenseData.java throwing NPE Reviewed-by: jchen, prr ! src/solaris/classes/sun/print/UnixPrintJob.java ! src/windows/classes/sun/print/Win32PrintJob.java ! test/javax/print/attribute/autosense/PrintAutoSenseData.java + test/javax/print/attribute/autosense/sample.txt Changeset: fe04f40cf469 Author: prr Date: 2013-08-06 17:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fe04f40cf469 8022455: Fix doclint warnings in javax.imageio Reviewed-by: darcy ! src/share/classes/javax/imageio/ImageIO.java ! src/share/classes/javax/imageio/ImageReadParam.java ! src/share/classes/javax/imageio/ImageReader.java ! src/share/classes/javax/imageio/ImageTypeSpecifier.java ! src/share/classes/javax/imageio/ImageWriteParam.java ! src/share/classes/javax/imageio/ImageWriter.java ! src/share/classes/javax/imageio/metadata/IIOMetadataFormatImpl.java ! src/share/classes/javax/imageio/plugins/bmp/BMPImageWriteParam.java ! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageReadParam.java ! src/share/classes/javax/imageio/plugins/jpeg/JPEGImageWriteParam.java ! src/share/classes/javax/imageio/spi/ImageReaderSpi.java ! src/share/classes/javax/imageio/spi/ImageWriterSpi.java ! src/share/classes/javax/imageio/spi/ServiceRegistry.java ! src/share/classes/javax/imageio/stream/ImageInputStream.java ! src/share/classes/javax/imageio/stream/ImageInputStreamImpl.java ! src/share/classes/javax/imageio/stream/ImageOutputStream.java Changeset: c827ad8c1101 Author: prr Date: 2013-08-06 17:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c827ad8c1101 8022447: Fix doclint warnings in java.awt.image Reviewed-by: darcy ! src/share/classes/java/awt/image/BufferStrategy.java ! src/share/classes/java/awt/image/BufferedImage.java ! src/share/classes/java/awt/image/ByteLookupTable.java ! src/share/classes/java/awt/image/ColorModel.java ! src/share/classes/java/awt/image/DirectColorModel.java ! src/share/classes/java/awt/image/ImageProducer.java ! src/share/classes/java/awt/image/IndexColorModel.java ! src/share/classes/java/awt/image/MemoryImageSource.java ! src/share/classes/java/awt/image/MultiPixelPackedSampleModel.java ! src/share/classes/java/awt/image/PixelGrabber.java ! src/share/classes/java/awt/image/RGBImageFilter.java ! src/share/classes/java/awt/image/ShortLookupTable.java ! src/share/classes/java/awt/image/SinglePixelPackedSampleModel.java ! src/share/classes/java/awt/image/WritableRaster.java Changeset: 9314c199003d Author: lana Date: 2013-08-06 22:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9314c199003d Merge - src/share/classes/java/net/package.html Changeset: ab64c138d5bd Author: prr Date: 2013-08-07 18:24 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ab64c138d5bd 8014883: java.awt.container.add(component comp object constraints) doesn't work as expected on some linux platforms Reviewed-by: jgodinez ! makefiles/CompileNativeLibraries.gmk ! src/solaris/native/sun/java2d/x11/XRBackendNative.c Changeset: 645a37a3559f Author: leonidr Date: 2013-08-01 01:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/645a37a3559f 8021815: Add regression test for JDK-8007267 Reviewed-by: serb + test/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java Changeset: 495ca130cbde Author: alexsch Date: 2013-08-01 17:09 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/495ca130cbde 7161568: [macosx] api/javax_swing/JTabbedPane/index2.html#varios fails Reviewed-by: malenkov, serb ! src/macosx/classes/com/apple/laf/AquaTabbedPaneCopyFromBasicUI.java ! src/macosx/classes/com/apple/laf/AquaTabbedPaneUI.java + test/javax/swing/JTabbedPane/4361477/bug4361477.java + test/javax/swing/JTabbedPane/6495408/bug6495408.java + test/javax/swing/JTabbedPane/7161568/bug7161568.java Changeset: e76b1568d002 Author: leonidr Date: 2013-08-02 15:42 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e76b1568d002 8021381: JavaFX scene included in Swing JDialog not starting from Web Start Reviewed-by: art, dcherepanov ! src/share/classes/sun/awt/AppContext.java Changeset: 07abddc1d7f2 Author: leonidr Date: 2013-08-06 17:07 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07abddc1d7f2 8022247: java/awt/EventDispatchThread/LoopRobustness/LoopRobustness throws NPE Reviewed-by: art ! test/java/awt/EventDispatchThread/LoopRobustness/LoopRobustness.java Changeset: 27d1bdf2f7d9 Author: mcherkas Date: 2013-08-06 17:29 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/27d1bdf2f7d9 8016833: Underlines and strikethrough not rendering correctly Reviewed-by: alexsch, serb Contributed-by: anton.nashatyrev at oracle.com ! src/share/classes/javax/swing/text/GlyphView.java + test/javax/swing/text/StyledEditorKit/8016833/bug8016833.java Changeset: f8ed88f5ed87 Author: alexsch Date: 2013-08-07 18:32 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8ed88f5ed87 8022532: [parfait] Potential memory leak in gtk2_interface.c Reviewed-by: art, serb ! src/solaris/native/sun/awt/gtk2_interface.c Changeset: 7706a622d35f Author: alexsch Date: 2013-08-07 18:58 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7706a622d35f 8013849: Awt assert on Hashtable.cpp:124 Reviewed-by: serb ! src/windows/native/sun/windows/awt_Component.cpp + test/java/awt/event/KeyEvent/DeadKey/DeadKeySystemAssertionDialog.java Changeset: f70492d969e7 Author: serb Date: 2013-08-07 19:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f70492d969e7 7124339: [macosx] setIconImage is not endlessly tolerant to the broken image-arguments Reviewed-by: alexsch, leonidr ! src/macosx/classes/sun/lwawt/macosx/CPlatformWindow.java Changeset: 540192229a69 Author: art Date: 2013-08-07 21:31 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/540192229a69 6551589: ContainerListener Documentation may be incorrect Reviewed-by: serb ! src/share/classes/java/awt/event/ContainerListener.java Changeset: 9bcc3f2af980 Author: lana Date: 2013-08-07 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9bcc3f2af980 Merge - src/share/classes/java/net/package.html Changeset: e193c4ad940a Author: lana Date: 2013-08-07 19:52 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e193c4ad940a Merge Changeset: 23e68a8e4b91 Author: lana Date: 2013-08-07 19:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/23e68a8e4b91 Merge - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: e0f6039c0290 Author: lana Date: 2013-08-13 10:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e0f6039c0290 Merge Changeset: 18ce880b5fb4 Author: lana Date: 2013-08-13 18:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/18ce880b5fb4 Merge ! makefiles/CompileNativeLibraries.gmk From vicente.romero at oracle.com Wed Aug 14 02:56:50 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Wed, 14 Aug 2013 09:56:50 +0000 Subject: hg: jdk8/tl/langtools: 8013394: compile of iterator use fails with error \"defined in an inaccessible class or interface\" Message-ID: <20130814095656.1A4184886E@hg.openjdk.java.net> Changeset: 0ad781399706 Author: vromero Date: 2013-08-14 10:53 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0ad781399706 8013394: compile of iterator use fails with error \"defined in an inaccessible class or interface\" Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T8013394/CompileErrorWithIteratorTest.java From kumar.x.srinivasan at oracle.com Wed Aug 14 07:12:00 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 14 Aug 2013 14:12:00 +0000 Subject: hg: jdk8/tl/langtools: 8007517: DefaultMethodRegressionTests.java fail in TL Message-ID: <20130814141207.40C9548882@hg.openjdk.java.net> Changeset: 3ab468194f11 Author: ksrini Date: 2013-08-14 07:07 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3ab468194f11 8007517: DefaultMethodRegressionTests.java fail in TL Reviewed-by: jjg, vromero - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java From kumar.x.srinivasan at oracle.com Wed Aug 14 08:14:11 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Wed, 14 Aug 2013 15:14:11 +0000 Subject: hg: jdk8/tl/jdk: 8022547: [verifier] move DefaultMethodRegressionTests.java to jdk Message-ID: <20130814151438.4906648890@hg.openjdk.java.net> Changeset: bc3cafb17c09 Author: ksrini Date: 2013-08-14 08:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bc3cafb17c09 8022547: [verifier] move DefaultMethodRegressionTests.java to jdk Reviewed-by: acorn + test/vm/verifier/defaultMethods/DefaultMethodRegressionTests.java + test/vm/verifier/defaultMethods/DefaultMethodRegressionTestsRun.java From xueming.shen at oracle.com Wed Aug 14 11:40:18 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 14 Aug 2013 18:40:18 +0000 Subject: hg: jdk8/tl/jdk: 8022178: System.console() throws IOE on some Windows Message-ID: <20130814184030.A190B48897@hg.openjdk.java.net> Changeset: c138d1b608e0 Author: sherman Date: 2013-08-14 11:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c138d1b608e0 8022178: System.console() throws IOE on some Windows Summary: to remove the IOE throwing code Reviewed-by: alanb ! src/windows/native/java/io/Console_md.c From joe.darcy at oracle.com Wed Aug 14 11:27:21 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Wed, 14 Aug 2013 18:27:21 +0000 Subject: hg: jdk8/tl/jdk: 8022990: Fix dep_ann lint warnings in swing code Message-ID: <20130814182745.46DDC48895@hg.openjdk.java.net> Changeset: 444a7edcf367 Author: darcy Date: 2013-08-14 11:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/444a7edcf367 8022990: Fix dep_ann lint warnings in swing code Reviewed-by: alexsch ! src/share/classes/com/sun/java/swing/Painter.java ! src/share/classes/com/sun/java/swing/plaf/nimbus/AbstractRegionPainter.java ! src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java From mike.duigou at oracle.com Wed Aug 14 13:38:36 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 14 Aug 2013 20:38:36 +0000 Subject: hg: jdk8/tl/jdk: 8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math Message-ID: <20130814203859.9BC0F4889C@hg.openjdk.java.net> Changeset: 17dfbb3f60d3 Author: bpb Date: 2013-08-12 10:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/17dfbb3f60d3 8022109: Evaluate adding incrementExact, decrementExact, negateExact to java.lang.Math Summary: Add the methods for parameter types int and long. Reviewed-by: mduigou Contributed-by: Brian Burkhalter ! src/share/classes/java/lang/Math.java ! test/java/lang/Math/ExactArithTests.java From jonathan.gibbons at oracle.com Wed Aug 14 16:41:29 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 14 Aug 2013 23:41:29 +0000 Subject: hg: jdk8/tl/langtools: 8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages Message-ID: <20130814234134.907F4488A5@hg.openjdk.java.net> Changeset: 14faef2b51eb Author: jjg Date: 2013-08-14 16:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/14faef2b51eb 8017191: Javadoc is confused by @link to imported classes outside of the set of generated packages Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/LinkFactoryImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java + test/com/sun/javadoc/testSeeTag/TestSeeTag.java + test/com/sun/javadoc/testSeeTag/pkg/Test.java From kumar.x.srinivasan at oracle.com Wed Aug 14 18:59:33 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Thu, 15 Aug 2013 01:59:33 +0000 Subject: hg: jdk8/tl/langtools: 6840442: JavaCompiler.getTask() has incomplete specification for IllegalArgumentException Message-ID: <20130815015938.49FDB488A8@hg.openjdk.java.net> Changeset: fac0d1bb87f2 Author: ksrini Date: 2013-08-14 18:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/fac0d1bb87f2 6840442: JavaCompiler.getTask() has incomplete specification for IllegalArgumentException Reviewed-by: jjg ! src/share/classes/javax/tools/JavaCompiler.java From bradford.wetmore at oracle.com Wed Aug 14 19:21:36 2013 From: bradford.wetmore at oracle.com (bradford.wetmore at oracle.com) Date: Thu, 15 Aug 2013 02:21:36 +0000 Subject: hg: jdk8/tl/jdk: 8023075: JDK-5049299 has broken old make in jdk8 Message-ID: <20130815022202.8E3A8488AA@hg.openjdk.java.net> Changeset: f8af3499c1fb Author: wetmore Date: 2013-08-14 19:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8af3499c1fb 8023075: JDK-5049299 has broken old make in jdk8 Reviewed-by: katleman ! make/java/java/Makefile From chris.hegarty at oracle.com Thu Aug 15 02:46:02 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 15 Aug 2013 10:46:02 +0100 Subject: RFR 8023090: Additional debug info for java/net/NetworkInterface/Equals.java Message-ID: <520CA35A.3090405@oracle.com> Another NetworkInterface test failed for an unexplainable reason, and is not readily reproducible on the same machine. Similar to IndexTest.java I would like to add some additional diagnostic information so we can try to determine the cause of the failure, if seen again. Additionaly, this test captures all the network interface configuration and displays it, along with the failure, only if the test fails. There are no functional changes to the test itself. diff -r bca19fdd875a test/java/net/NetworkInterface/Equals.java --- a/test/java/net/NetworkInterface/Equals.java Tue Aug 13 13:04:21 2013 +0400 +++ b/test/java/net/NetworkInterface/Equals.java Thu Aug 15 10:38:17 2013 +0100 @@ -25,41 +25,82 @@ * @bug 7003398 * @run main/othervm Equals */ + +import java.io.ByteArrayOutputStream; +import java.io.PrintStream; +import java.net.InetAddress; import java.net.NetworkInterface; -import java.net.InetAddress; +import java.net.SocketException; +import java.util.Arrays; +import java.util.Collections; import java.util.Enumeration; import java.util.HashMap; public class Equals { public static void main(String args[]) throws Exception { + ByteArrayOutputStream baos = new ByteArrayOutputStream(); + PrintStream bufferedOut = new PrintStream(baos); - Enumeration nifs1 = NetworkInterface.getNetworkInterfaces(); + Enumeration nifs1 = NetworkInterface.getNetworkInterfaces(); HashMap hashes = new HashMap<>(); HashMap nicMap = new HashMap<>(); while (nifs1.hasMoreElements()) { - NetworkInterface ni = (NetworkInterface)nifs1.nextElement(); + NetworkInterface ni = nifs1.nextElement(); hashes.put(ni.getName(),ni.hashCode()); nicMap.put(ni.getName(),ni); + displayInterfaceInformation(ni, bufferedOut); + bufferedOut.flush(); } System.setSecurityManager(new SecurityManager()); - Enumeration nifs2 = NetworkInterface.getNetworkInterfaces(); + Enumeration nifs2 = NetworkInterface.getNetworkInterfaces(); while (nifs2.hasMoreElements()) { - NetworkInterface ni = (NetworkInterface)nifs2.nextElement(); + NetworkInterface ni = nifs2.nextElement(); NetworkInterface niOrig = nicMap.get(ni.getName()); - int h = hashes.get(ni.getName()); - if (h != ni.hashCode()) { + int h = ni.hashCode(); + if (h == hashes.get(ni.getName())) { + System.out.printf("%nSystem information:%n"); + System.out.printf("%s", baos.toString("UTF8")); + System.out.printf("%nni.hashCode() returned %d, expected %d, for:%n", + h, hashes.get(ni.getName())); + displayInterfaceInformation(ni,System.out); throw new RuntimeException ("Hashcodes different for " + ni.getName()); } if (!ni.equals(niOrig)) { + System.out.printf("%nSystem information:%n"); + System.out.printf("%s", baos.toString("UTF8")); + System.out.printf("%nExpected the following interfaces to be the same:%n"); + displayInterfaceInformation(niOrig, System.out); + displayInterfaceInformation(ni,System.out); throw new RuntimeException ("equality different for " + ni.getName()); } } } + + static void displayInterfaceInformation(NetworkInterface netint, + PrintStream out) throws SocketException { + out.printf("Display name: %s%n", netint.getDisplayName()); + out.printf("Name: %s%n", netint.getName()); + Enumeration inetAddresses = netint.getInetAddresses(); + + for (InetAddress inetAddress : Collections.list(inetAddresses)) + out.printf("InetAddress: %s%n", inetAddress); + + out.printf("Up? %s%n", netint.isUp()); + out.printf("Loopback? %s%n", netint.isLoopback()); + out.printf("PointToPoint? %s%n", netint.isPointToPoint()); + out.printf("Supports multicast? %s%n", netint.supportsMulticast()); + out.printf("Virtual? %s%n", netint.isVirtual()); + out.printf("Hardware address: %s%n", + Arrays.toString(netint.getHardwareAddress())); + out.printf("MTU: %s%n", netint.getMTU()); + out.printf("Index: %s%n", netint.getIndex()); + out.printf("%n"); + } } -Chris. From Alan.Bateman at oracle.com Thu Aug 15 03:05:22 2013 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Aug 2013 11:05:22 +0100 Subject: RFR 8023090: Additional debug info for java/net/NetworkInterface/Equals.java In-Reply-To: <520CA35A.3090405@oracle.com> References: <520CA35A.3090405@oracle.com> Message-ID: <520CA7E2.1050807@oracle.com> On 15/08/2013 10:46, Chris Hegarty wrote: > Another NetworkInterface test failed for an unexplainable reason, and > is not readily reproducible on the same machine. Similar to > IndexTest.java I would like to add some additional diagnostic > information so we can try to determine the cause of the failure, if > seen again. > > Additionaly, this test captures all the network interface > configuration and displays it, along with the failure, only if the > test fails. There are no functional changes to the test itself. Looks okay, I've often wondered if wifi interfaces on a test machines might contribute to problems with these tests. -Alan. From alan.bateman at oracle.com Thu Aug 15 03:59:11 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Aug 2013 10:59:11 +0000 Subject: hg: jdk8/tl/jdk: 8022921: Remove experimental Profile attribute Message-ID: <20130815105950.DE270488BB@hg.openjdk.java.net> Changeset: 5ff3b55df2d4 Author: alanb Date: 2013-08-15 11:54 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ff3b55df2d4 8022921: Remove experimental Profile attribute Reviewed-by: mchung, chegar ! src/share/classes/java/net/URLClassLoader.java ! src/share/classes/java/util/jar/Attributes.java ! src/share/classes/java/util/jar/JarFile.java ! src/share/classes/java/util/jar/JavaUtilJarAccessImpl.java - src/share/classes/java/util/jar/UnsupportedProfileException.java ! src/share/classes/sun/launcher/LauncherHelper.java ! src/share/classes/sun/launcher/resources/launcher.properties ! src/share/classes/sun/misc/JavaUtilJarAccess.java ! src/share/classes/sun/misc/URLClassPath.java ! src/share/classes/sun/misc/Version.java.template ! src/share/classes/sun/tools/jar/Main.java ! src/share/classes/sun/tools/jar/resources/jar.properties - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java From alan.bateman at oracle.com Thu Aug 15 05:47:15 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Thu, 15 Aug 2013 12:47:15 +0000 Subject: hg: jdk8/tl/jdk: 8015765: TEST_BUG: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failing intermittently Message-ID: <20130815124748.AA4E2488BC@hg.openjdk.java.net> Changeset: b7b0beef5ded Author: alanb Date: 2013-08-15 13:42 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7b0beef5ded 8015765: TEST_BUG: java/nio/channels/ServerSocketChannel/AdaptServerSocket.java failing intermittently Reviewed-by: chegar, dholmes, alanb Contributed-by: yiming.wang at oracle.com ! test/java/nio/channels/ServerSocketChannel/AdaptServerSocket.java From chris.hegarty at oracle.com Thu Aug 15 06:52:27 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 15 Aug 2013 13:52:27 +0000 Subject: hg: jdk8/tl/jdk: 8022584: Memory leak in some NetworkInterface methods Message-ID: <20130815135302.BDDF0488C0@hg.openjdk.java.net> Changeset: 7d7d553a8c61 Author: igerasim Date: 2013-08-13 13:04 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7d7d553a8c61 8022584: Memory leak in some NetworkInterface methods Reviewed-by: alanb, dholmes, chegar, michaelm ! src/solaris/native/java/net/NetworkInterface.c + test/java/net/NetworkInterface/MemLeakTest.java From chris.hegarty at oracle.com Thu Aug 15 07:01:52 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 15 Aug 2013 14:01:52 +0000 Subject: hg: jdk8/tl/jdk: 8023103: FJ parallelism zero; ... Message-ID: <20130815140204.0D5EE488C1@hg.openjdk.java.net> Changeset: 3223342fb76e Author: dl Date: 2013-08-15 15:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3223342fb76e 8023103: FJ parallelism zero 8020537: java/util/concurrent/forkjoin/ThrowingRunnable.java Reviewed-by: chegar, mduigou, alanb ! src/share/classes/java/util/concurrent/ForkJoinPool.java From chris.hegarty at oracle.com Thu Aug 15 07:05:14 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 15 Aug 2013 14:05:14 +0000 Subject: hg: jdk8/tl/jdk: 8023104: ConcurrentHashMap typo Message-ID: <20130815140526.9587B488C2@hg.openjdk.java.net> Changeset: b07b19182e40 Author: dl Date: 2013-08-15 15:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b07b19182e40 8023104: ConcurrentHashMap typo Reviewed-by: chegar, mduigou ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java From chris.hegarty at oracle.com Thu Aug 15 07:16:47 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Thu, 15 Aug 2013 14:16:47 +0000 Subject: hg: jdk8/tl/jdk: 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress Message-ID: <20130815141659.619C8488C3@hg.openjdk.java.net> Changeset: e7137695dce3 Author: chegar Date: 2013-08-15 15:16 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e7137695dce3 8022126: Remove throws SocketException from DatagramPacket constructors accepting SocketAddress Reviewed-by: smarks, alanb, michaelm, darcy ! src/share/classes/java/net/DatagramPacket.java From mike.duigou at oracle.com Thu Aug 15 10:08:35 2013 From: mike.duigou at oracle.com (Mike Duigou) Date: Thu, 15 Aug 2013 10:08:35 -0700 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5209EE6C.3050604@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com> <52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com> <5209EE6C.3050604@oracle.com> Message-ID: I've been confused through this discussion as to why a trailing dot would be regarded as illegal. Historically a trailing dot has been frequently (though not universally) used to denote a fully qualified domain name. https://en.wikipedia.org/wiki/Fully_qualified_domain_name Is this use now illegal/unsupported/invalid? Does having a trailing dot conflict with other parts of the IDN specification? Mike On Aug 13 2013, at 01:29 , Xuelei Fan wrote: > Can I get an additional code review from networking team? > > Thanks, > Xuelei > > On 8/12/2013 2:07 PM, Weijun Wang wrote: >> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/ > From xueming.shen at oracle.com Thu Aug 15 10:39:16 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Thu, 15 Aug 2013 17:39:16 +0000 Subject: hg: jdk8/tl/jdk: 7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException Message-ID: <20130815173953.E887D488DF@hg.openjdk.java.net> Changeset: 6c307b4d0dd8 Author: sherman Date: 2013-08-15 10:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6c307b4d0dd8 7154662: {CRC32, Adler32}.update(byte[] b, int off, int len): undocumented ArrayIndexOutOfBoundsException Summary: to add the throws clause Reviewed-by: alanb, chegar ! src/share/classes/java/util/zip/Adler32.java ! src/share/classes/java/util/zip/CRC32.java From Xuelei.Fan at Oracle.Com Thu Aug 15 10:40:27 2013 From: Xuelei.Fan at Oracle.Com (Xuelei Fan) Date: Fri, 16 Aug 2013 01:40:27 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com> <52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com> <5209EE6C.3050604@oracle.com> Message-ID: On Aug 16, 2013, at 1:08, Mike Duigou wrote: > I've been confused through this discussion as to why a trailing dot would be regarded as illegal. > The discussion is too long to find the final decision easily. A IDN with trailing dot should be regarded as legal IDN. This update is trying to fix this. For example, "." and "example.com." are legal IDN, and IDN.toASCII() should be return the legal name accordingly. However, per the specification of Server Name Indication of TLS extension, a hostname should not end with trailing dot. So in SNIHostName, we will check the return value of IDN.toASCII() to filter out hostnames with trailing dots. This fix is trying to have IDN working with tailing dot and empty label correctly. The previous code of SNIHostName will work as expected if IDN can handle trailing dot properly. Thanks, Xuelei > Historically a trailing dot has been frequently (though not universally) used to denote a fully qualified domain name. > > https://en.wikipedia.org/wiki/Fully_qualified_domain_name > > Is this use now illegal/unsupported/invalid? Does having a trailing dot conflict with other parts of the IDN specification? > > Mike > > On Aug 13 2013, at 01:29 , Xuelei Fan wrote: > >> Can I get an additional code review from networking team? >> >> Thanks, >> Xuelei >> >> On 8/12/2013 2:07 PM, Weijun Wang wrote: >>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/ > From mhall at mhcomputing.net Thu Aug 15 10:40:19 2013 From: mhall at mhcomputing.net (Matthew Hall) Date: Thu, 15 Aug 2013 10:40:19 -0700 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: References: <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com> <52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com> <5209EE6C.3050604@oracle.com> Message-ID: <20130815174019.GA21965@mhcomputing.net> On Thu, Aug 15, 2013 at 10:08:35AM -0700, Mike Duigou wrote: > I've been confused through this discussion as to why a trailing dot would be regarded as illegal. > > Historically a trailing dot has been frequently (though not universally) used to denote a fully qualified domain name. > > https://en.wikipedia.org/wiki/Fully_qualified_domain_name > > Is this use now illegal/unsupported/invalid? Does having a trailing dot conflict with other parts of the IDN specification? > > Mike This is why some of us were protesting the code which disallowed the trailing '.', and eventually the code was changed to allow it to be present. Matthew. From vincent.x.ryan at oracle.com Thu Aug 15 11:57:28 2013 From: vincent.x.ryan at oracle.com (vincent.x.ryan at oracle.com) Date: Thu, 15 Aug 2013 18:57:28 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130815185828.D4AEB488F8@hg.openjdk.java.net> Changeset: b4645069238a Author: vinnie Date: 2013-08-15 19:49 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b4645069238a 8023108: Remove ShortRSAKey1024.sh from ProblemList.txt Reviewed-by: mullan ! test/ProblemList.txt Changeset: 3211caab58ba Author: vinnie Date: 2013-08-15 19:56 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3211caab58ba Merge From dan.xu at oracle.com Thu Aug 15 12:37:01 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 15 Aug 2013 19:37:01 +0000 Subject: hg: jdk8/tl/jdk: 4858457: File.getCanonicalPath() throws IOException when invoked with "nul" (win) Message-ID: <20130815193727.9F60848905@hg.openjdk.java.net> Changeset: 5bb196aa183c Author: dxu Date: 2013-08-15 12:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bb196aa183c 4858457: File.getCanonicalPath() throws IOException when invoked with "nul" (win) Reviewed-by: alanb ! src/windows/native/java/io/canonicalize_md.c ! test/java/io/File/WinDeviceName.java From dan.xu at oracle.com Thu Aug 15 14:11:34 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 15 Aug 2013 21:11:34 +0000 Subject: hg: jdk8/tl/jdk: 8017109: Cleanup overrides warning in src/solaris/classes/sun/print/AttributeClass.java Message-ID: <20130815211147.0FDCE48913@hg.openjdk.java.net> Changeset: 0d27309a87e0 Author: dxu Date: 2013-08-15 14:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0d27309a87e0 8017109: Cleanup overrides warning in src/solaris/classes/sun/print/AttributeClass.java Reviewed-by: jgodinez ! src/solaris/classes/sun/print/AttributeClass.java From vicente.romero at oracle.com Fri Aug 16 02:33:30 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Fri, 16 Aug 2013 09:33:30 +0000 Subject: hg: jdk8/tl/langtools: 8022053: javac generates unverifiable initializer for nested subclass of local class Message-ID: <20130816093341.F3A3D48927@hg.openjdk.java.net> Changeset: a6378c19836b Author: vromero Date: 2013-08-16 10:32 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a6378c19836b 8022053: javac generates unverifiable initializer for nested subclass of local class Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Lower.java + test/tools/javac/T8022053/UnverifiableInitForNestedLocalClassTest.java From paul.sandoz at oracle.com Fri Aug 16 03:41:09 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 16 Aug 2013 10:41:09 +0000 Subject: hg: jdk8/tl/jdk: 8023150: java/util/stream tests no longer compiling following JDK-8019401 Message-ID: <20130816104126.AC1FD4892A@hg.openjdk.java.net> Changeset: 5fe19566b6f0 Author: psandoz Date: 2013-08-16 12:29 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5fe19566b6f0 8023150: java/util/stream tests no longer compiling following JDK-8019401 Reviewed-by: alanb ! test/java/util/stream/test/org/openjdk/tests/java/util/stream/TabulatorsTest.java From paul.sandoz at oracle.com Fri Aug 16 03:50:51 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 16 Aug 2013 10:50:51 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130816105116.052784892B@hg.openjdk.java.net> Changeset: 2eebaff52a94 Author: psandoz Date: 2013-08-16 12:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2eebaff52a94 8012940: More than 50 tests failed in Serialization/DeSerialization testing (test-mangled) Reviewed-by: ksrini + test/java/util/stream/bootlib/java/util/stream/LambdaTestMode.java ! test/java/util/stream/bootlib/java/util/stream/StreamTestDataProvider.java Changeset: 02ce5a0e4b98 Author: psandoz Date: 2013-08-16 12:46 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/02ce5a0e4b98 8022898: java/util/Spliterator/SpliteratorCollisions.java fails in HashableIntSpliteratorWithNull data provider Reviewed-by: henryjen, alanb, rriggs ! test/java/util/Spliterator/SpliteratorCollisions.java From maurizio.cimadamore at oracle.com Fri Aug 16 04:02:10 2013 From: maurizio.cimadamore at oracle.com (maurizio.cimadamore at oracle.com) Date: Fri, 16 Aug 2013 11:02:10 +0000 Subject: hg: jdk8/tl/langtools: 2 new changesets Message-ID: <20130816110219.73A474892C@hg.openjdk.java.net> Changeset: ec77c7b46c37 Author: jlahoda Date: 2013-08-15 22:33 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/ec77c7b46c37 8015809: More user friendly compile-time errors for uncaught exceptions in lambda expression Summary: Producing individual errors for uncaught undeclared exceptions inside lambda expressions, rather than one error for the whole lambda Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/code/Type.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java + test/tools/javac/lambda/ExceptionsInLambda.java + test/tools/javac/lambda/ExceptionsInLambda.out ! test/tools/javac/lambda/TargetType21.out Changeset: f657d400c736 Author: jlahoda Date: 2013-08-15 22:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f657d400c736 8022508: javac crashes if the generics arity of a base class is wrong Reviewed-by: mcimadamore, vromero ! src/share/classes/com/sun/tools/javac/comp/Check.java ! test/tools/javac/generics/8016640/T8016640.java From paul.sandoz at oracle.com Fri Aug 16 04:24:39 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Fri, 16 Aug 2013 11:24:39 +0000 Subject: hg: jdk8/tl/jdk: 8022797: Clarify spliterator characteristics for collections containing no elements Message-ID: <20130816112450.C13654892E@hg.openjdk.java.net> Changeset: 737b6c298d81 Author: psandoz Date: 2013-08-13 11:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/737b6c298d81 8022797: Clarify spliterator characteristics for collections containing no elements Reviewed-by: alanb, mduigou ! src/share/classes/java/util/Collection.java From roger.riggs at oracle.com Fri Aug 16 09:50:21 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 16 Aug 2013 16:50:21 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130816165100.1B3C04893F@hg.openjdk.java.net> Changeset: 53819fd0ab61 Author: rriggs Date: 2013-08-16 11:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53819fd0ab61 8022770: java/time/tck/java/time/chrono/TCKChronology.java start failing 8022766: java/time/test/java/time/chrono/TestUmmAlQuraChronology.java failed. Summary: TCKChronology: corrected display name to match update from JDK-8015986 Reviewed-by: alanb ! test/java/time/tck/java/time/chrono/TCKChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java Changeset: d7fc4e149bb8 Author: rriggs Date: 2013-08-16 11:11 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7fc4e149bb8 8022193: java/time/test/java/util/TestFormatter.java failed in th locale. Summary: Tests corrected to use fixed locale and not dependent on the environment Reviewed-by: sherman ! src/share/classes/java/util/Formatter.java ! test/java/time/test/java/util/TestFormatter.java From roger.riggs at oracle.com Fri Aug 16 11:00:01 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 16 Aug 2013 18:00:01 +0000 Subject: hg: jdk8/tl/jdk: 8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate Message-ID: <20130816180013.E79D848946@hg.openjdk.java.net> Changeset: acaa256e3f7c Author: rriggs Date: 2013-08-16 13:58 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/acaa256e3f7c 8019185: Inconsistency between JapaneseEra start dates and java.util.JapaneseImperialDate Summary: align Meiji start date with lib/calendar.properties to avoid any confusion Reviewed-by: sherman ! src/share/classes/java/time/chrono/JapaneseEra.java From xuelei.fan at oracle.com Sun Aug 18 22:56:51 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 19 Aug 2013 13:56:51 +0800 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5209EE6C.3050604@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com> <52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com> <5209EE6C.3050604@oracle.com> Message-ID: <5211B3A3.2050506@oracle.com> If no objections, I will push the change by COB Monday. Thanks, Xuelei On 8/13/2013 4:29 PM, Xuelei Fan wrote: > Can I get an additional code review from networking team? > > Thanks, > Xuelei > > On 8/12/2013 2:07 PM, Weijun Wang wrote: >> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/ > From paul.sandoz at oracle.com Mon Aug 19 01:54:44 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 19 Aug 2013 08:54:44 +0000 Subject: hg: jdk8/tl/jdk: 8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls Message-ID: <20130819085531.8707F48988@hg.openjdk.java.net> Changeset: 9e9f5713b26d Author: psandoz Date: 2013-08-06 14:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e9f5713b26d 8022318: Document Spliterator characteristics and binding policy of java util concurrent collection impls Reviewed-by: chegar Contributed-by: Martin Buchholz , Paul Sandoz ! src/share/classes/java/util/concurrent/ArrayBlockingQueue.java ! src/share/classes/java/util/concurrent/ConcurrentHashMap.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedDeque.java ! src/share/classes/java/util/concurrent/ConcurrentLinkedQueue.java ! src/share/classes/java/util/concurrent/ConcurrentNavigableMap.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/CopyOnWriteArraySet.java ! src/share/classes/java/util/concurrent/DelayQueue.java ! src/share/classes/java/util/concurrent/LinkedBlockingDeque.java ! src/share/classes/java/util/concurrent/LinkedBlockingQueue.java ! src/share/classes/java/util/concurrent/LinkedTransferQueue.java ! src/share/classes/java/util/concurrent/PriorityBlockingQueue.java ! src/share/classes/java/util/concurrent/SynchronousQueue.java ! src/share/classes/java/util/concurrent/package-info.java From chris.hegarty at oracle.com Mon Aug 19 02:45:33 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 19 Aug 2013 09:45:33 +0000 Subject: hg: jdk8/tl: 8021820: Number of opened files used in select() is limited to 1024 [macosx] Message-ID: <20130819094534.30D3F4898B@hg.openjdk.java.net> Changeset: 00dcfaa6bc01 Author: aefimov Date: 2013-08-16 18:40 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/rev/00dcfaa6bc01 8021820: Number of opened files used in select() is limited to 1024 [macosx] Reviewed-by: alanb, chegar, tbell, smarks ! common/autoconf/generated-configure.sh ! common/autoconf/toolchain.m4 From chris.hegarty at oracle.com Mon Aug 19 02:47:17 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Mon, 19 Aug 2013 09:47:17 +0000 Subject: hg: jdk8/tl/jdk: 8021820: Number of opened files used in select() is limited to 1024 [macosx] Message-ID: <20130819094817.B3DE94898E@hg.openjdk.java.net> Changeset: 11ccaabdb2a8 Author: aefimov Date: 2013-08-16 18:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/11ccaabdb2a8 8021820: Number of opened files used in select() is limited to 1024 [macosx] Reviewed-by: alanb, chegar, tbell, smarks + test/java/net/ServerSocket/SelectFdsLimit.java From alan.bateman at oracle.com Mon Aug 19 03:07:04 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 19 Aug 2013 10:07:04 +0000 Subject: hg: jdk8/tl/jdk: 8023215: test/java/util/Comparator/TypeTest.java not running (failing but reported as passing) Message-ID: <20130819100719.3AF2648991@hg.openjdk.java.net> Changeset: f580728b08b4 Author: alanb Date: 2013-08-19 11:04 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f580728b08b4 8023215: test/java/util/Comparator/TypeTest.java not running (failing but reported as passing) Reviewed-by: psandoz ! test/java/util/Comparator/TypeTest.java From paul.sandoz at oracle.com Mon Aug 19 07:15:56 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 19 Aug 2013 14:15:56 +0000 Subject: hg: jdk8/tl/jdk: 8014824: Document Spliterator characteristics and binding policy of java util collection impls Message-ID: <20130819141634.3910A4899C@hg.openjdk.java.net> Changeset: 3647aab7b1d5 Author: psandoz Date: 2013-08-06 14:26 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3647aab7b1d5 8014824: Document Spliterator characteristics and binding policy of java util collection impls Reviewed-by: chegar ! src/share/classes/java/util/ArrayDeque.java ! src/share/classes/java/util/ArrayList.java ! src/share/classes/java/util/HashSet.java ! src/share/classes/java/util/LinkedHashMap.java ! src/share/classes/java/util/LinkedHashSet.java ! src/share/classes/java/util/LinkedList.java ! src/share/classes/java/util/List.java ! src/share/classes/java/util/PriorityQueue.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! src/share/classes/java/util/Spliterator.java ! src/share/classes/java/util/TreeMap.java ! src/share/classes/java/util/TreeSet.java ! src/share/classes/java/util/Vector.java From michael.x.mcmahon at oracle.com Mon Aug 19 08:12:22 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Mon, 19 Aug 2013 16:12:22 +0100 Subject: Code review request, 8020842 IDN do not throw IAE when hostname ends with a trailing dot In-Reply-To: <5211B3A3.2050506@oracle.com> References: <5200E1B9.7070002@oracle.com> <520127A3.3060405@oracle.com> <520133C7.20401@oracle.com> <5202411F.2010706@oracle.com> <52025434.8070200@oracle.com> <5202561A.5040908@oracle.com> <52025726.8060203@oracle.com> <520264F1.1090802@oracle.com> <52043AB3.6060704@oracle.com> <5204446D.7030603@oracle.com> <520447BD.30206@oracle.com> <52045070.1000506@oracle.com> <520458DF.1030502@oracle.com> <52046FF3.1040903@oracle.com> <5204D312.4030209@oracle.com> <52050A01.3030503@oracle.com> <520593CC.4010608@oracle.com> <5205AA57.6050704@oracle.com> <520835CD.5090402@oracle.com> <5208526E.5020808@oracle.com> <52087668.9080500@oracle.com> <52087B8C.5080105@oracle.com> <5209EE6C.3050604@oracle.com> <5211B3A3.2050506@oracle.com> Message-ID: <521235D6.2070308@oracle.com> Seems fine to me Xuelei. - Michael On 19/08/13 06:56, Xuelei Fan wrote: > If no objections, I will push the change by COB Monday. > > Thanks, > Xuelei > > On 8/13/2013 4:29 PM, Xuelei Fan wrote: >> Can I get an additional code review from networking team? >> >> Thanks, >> Xuelei >> >> On 8/12/2013 2:07 PM, Weijun Wang wrote: >>> new webrev: http://cr.openjdk.java.net/~xuelei/8020842/webrev.06/ From kumar.x.srinivasan at oracle.com Mon Aug 19 09:42:45 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Mon, 19 Aug 2013 16:42:45 +0000 Subject: hg: jdk8/tl/langtools: 7071377: Exception when javac -processor is given a class name with invalid postfix Message-ID: <20130819164255.72E15489A4@hg.openjdk.java.net> Changeset: 389eaf6ed973 Author: ksrini Date: 2013-08-19 07:47 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/389eaf6ed973 7071377: Exception when javac -processor is given a class name with invalid postfix Reviewed-by: jjg, vromero ! src/share/classes/com/sun/tools/javac/comp/Attr.java + test/tools/javac/processing/errors/TestClassNames.java From sean.mullan at oracle.com Mon Aug 19 12:13:44 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 19 Aug 2013 19:13:44 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130819191422.3915D489A7@hg.openjdk.java.net> Changeset: bce5205dbe84 Author: ascarpino Date: 2013-08-14 10:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bce5205dbe84 8022669: OAEPParameterSpec does not work if MGF1ParameterSpec is set to SHA2 algorithms Reviewed-by: mullan ! src/share/classes/sun/security/rsa/RSAPadding.java ! test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java Changeset: b40d246d4d81 Author: ascarpino Date: 2013-08-16 12:31 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b40d246d4d81 8022896: test/com/sun/crypto/provider/Cipher/RSA/TestOAEPPadding.java fails Reviewed-by: mullan ! test/ProblemList.txt From dan.xu at oracle.com Mon Aug 19 12:39:13 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Mon, 19 Aug 2013 19:39:13 +0000 Subject: hg: jdk8/tl/jdk: 8023203: Wrap RandomAccessFile.seek native method into a Java helper method Message-ID: <20130819193934.17B0D489B2@hg.openjdk.java.net> Changeset: 2fd841fccb2e Author: dxu Date: 2013-08-19 12:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2fd841fccb2e 8023203: Wrap RandomAccessFile.seek native method into a Java helper method Reviewed-by: alanb, chegar ! make/java/java/mapfile-vers ! makefiles/mapfiles/libjava/mapfile-vers ! src/share/classes/java/io/RandomAccessFile.java ! src/share/native/java/io/RandomAccessFile.c From sean.mullan at oracle.com Mon Aug 19 14:19:17 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Mon, 19 Aug 2013 21:19:17 +0000 Subject: hg: jdk8/tl/jdk: 8016850: JCK javax.security.auth.Policy tests fail when run in Profiles mode Message-ID: <20130819211951.B52AD489C1@hg.openjdk.java.net> Changeset: f120e2c4b4b1 Author: mullan Date: 2013-08-19 17:17 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f120e2c4b4b1 8016850: JCK javax.security.auth.Policy tests fail when run in Profiles mode Summary: Move default javax.security.auth.Policy implementation to compact1 profile Reviewed-by: vinnie ! src/share/classes/com/sun/security/auth/PolicyFile.java - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java ! src/share/classes/javax/security/auth/Policy.java + src/share/classes/sun/security/provider/AuthPolicyFile.java + src/share/classes/sun/security/provider/SubjectCodeSource.java From xuelei.fan at oracle.com Mon Aug 19 17:43:43 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 20 Aug 2013 00:43:43 +0000 Subject: hg: jdk8/tl/jdk: 8020842: IDN do not throw IAE when hostname ends with a trailing dot Message-ID: <20130820004420.A5A84489CB@hg.openjdk.java.net> Changeset: 096e7c665857 Author: xuelei Date: 2013-08-19 17:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/096e7c665857 8020842: IDN do not throw IAE when hostname ends with a trailing dot Reviewed-by: weijun, michaelm ! src/share/classes/java/net/IDN.java + test/java/net/IDN/IllegalArg.java + test/sun/security/ssl/javax/net/ssl/ServerName/IllegalSNIName.java From xuelei.fan at oracle.com Mon Aug 19 18:51:26 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Tue, 20 Aug 2013 01:51:26 +0000 Subject: hg: jdk8/tl/jdk: 8023230: The impl of KerberosClientKeyExchange maybe not exist Message-ID: <20130820015148.C0D5F489CE@hg.openjdk.java.net> Changeset: 21a25911f7f7 Author: xuelei Date: 2013-08-19 18:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/21a25911f7f7 8023230: The impl of KerberosClientKeyExchange maybe not exist Reviewed-by: weijun ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java From staffan.larsen at oracle.com Mon Aug 19 23:59:36 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 20 Aug 2013 06:59:36 +0000 Subject: hg: jdk8/tl/jdk: 8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual machine Message-ID: <20130820070010.F0E36489D2@hg.openjdk.java.net> Changeset: 53ea4b5cef9b Author: sla Date: 2013-08-20 08:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/53ea4b5cef9b 8022071: Some vm/jvmti tests fail because cannot attach to the Java virtual machine Reviewed-by: erikj, sspitsyn ! makefiles/CompileNativeLibraries.gmk + makefiles/mapfiles/libattach/reorder-windows-x86 + makefiles/mapfiles/libattach/reorder-windows-x86_64 ! src/windows/native/sun/tools/attach/WindowsVirtualMachine.c From david.holmes at oracle.com Tue Aug 20 00:19:32 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 20 Aug 2013 07:19:32 +0000 Subject: hg: jdk8/tl/jdk: 8023311: Clean up profile-includes.txt Message-ID: <20130820071955.810B7489D5@hg.openjdk.java.net> Changeset: e17da8b09f5e Author: dholmes Date: 2013-08-20 03:18 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e17da8b09f5e 8023311: Clean up profile-includes.txt Reviewed-by: alanb ! makefiles/profile-includes.txt From staffan.larsen at oracle.com Tue Aug 20 07:56:12 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 20 Aug 2013 14:56:12 +0000 Subject: hg: jdk8/tl/jdk: 8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently Message-ID: <20130820145635.5C28E489E3@hg.openjdk.java.net> Changeset: 961cdea684b5 Author: sla Date: 2013-08-20 16:53 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/961cdea684b5 8016727: test/com/sun/jdi/sde/TemperatureTableTest.java failing intermittently Reviewed-by: alanb ! test/com/sun/jdi/sde/TemperatureTableTest.java From paul.sandoz at oracle.com Tue Aug 20 09:47:20 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Tue, 20 Aug 2013 16:47:20 +0000 Subject: hg: jdk8/tl/jdk: 8023367: Collections.emptyList().sort((Comparator)null) throws NPE Message-ID: <20130820164747.1CD50489ED@hg.openjdk.java.net> Changeset: c17d6543b30f Author: psandoz Date: 2013-08-20 17:36 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c17d6543b30f 8023367: Collections.emptyList().sort((Comparator)null) throws NPE Reviewed-by: alanb, mduigou ! src/share/classes/java/util/Collections.java ! test/java/util/Collection/ListDefaults.java From staffan.larsen at oracle.com Tue Aug 20 10:07:41 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Tue, 20 Aug 2013 17:07:41 +0000 Subject: hg: jdk8/tl/jdk: 8023250: Update JavaScript code in JDK for changes in iteration over Java arrays Message-ID: <20130820170753.D7C43489F1@hg.openjdk.java.net> Changeset: 1ccc7bbee0bb Author: attila Date: 2013-08-20 11:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1ccc7bbee0bb 8023250: Update JavaScript code in JDK for changes in iteration over Java arrays Reviewed-by: sundar, sla ! src/share/classes/com/sun/tools/hat/resources/hat.js From joe.darcy at oracle.com Tue Aug 20 12:16:27 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 20 Aug 2013 19:16:27 +0000 Subject: hg: jdk8/tl/langtools: 8011043: Warn about use of 1.5 and earlier source and target values Message-ID: <20130820191632.B7F59489F6@hg.openjdk.java.net> Changeset: 58da1296c6b3 Author: darcy Date: 2013-08-20 12:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/58da1296c6b3 8011043: Warn about use of 1.5 and earlier source and target values Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javadoc/Start.java + test/tools/javac/diags/examples/ObsoleteSourceAndTarget.java From jonathan.gibbons at oracle.com Tue Aug 20 14:48:34 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 20 Aug 2013 21:48:34 +0000 Subject: hg: jdk8/tl/langtools: 8020663: Restructure some properties to facilitate better translation Message-ID: <20130820214837.9671E48A07@hg.openjdk.java.net> Changeset: a76dc1b4c299 Author: jjg Date: 2013-08-20 14:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/a76dc1b4c299 8020663: Restructure some properties to facilitate better translation Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclets.properties ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java From kumar.x.srinivasan at oracle.com Tue Aug 20 14:18:34 2013 From: kumar.x.srinivasan at oracle.com (kumar.x.srinivasan at oracle.com) Date: Tue, 20 Aug 2013 21:18:34 +0000 Subject: hg: jdk8/tl/langtools: 7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against JDK 7 and JDK 8 Message-ID: <20130820211839.BB48A48A01@hg.openjdk.java.net> Changeset: 0f88e3d3d250 Author: ksrini Date: 2013-08-20 14:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0f88e3d3d250 7179455: tools/javac/processing/model/testgetallmembers/Main.java fails against JDK 7 and JDK 8 Reviewed-by: jjg ! test/tools/javac/processing/model/testgetallmembers/Main.java From jonathan.gibbons at oracle.com Tue Aug 20 14:55:32 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 20 Aug 2013 21:55:32 +0000 Subject: hg: jdk8/tl/langtools: 8022080: javadoc generates invalid HTML in Turkish locale Message-ID: <20130820215535.36BC748A08@hg.openjdk.java.net> Changeset: 79e341614c50 Author: jjg Date: 2013-08-20 14:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/79e341614c50 8022080: javadoc generates invalid HTML in Turkish locale Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlTag.java ! src/share/classes/com/sun/tools/doclint/HtmlTag.java From jonathan.gibbons at oracle.com Tue Aug 20 15:13:02 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Tue, 20 Aug 2013 22:13:02 +0000 Subject: hg: jdk8/tl/langtools: 8013887: In class use, some tables are randomly unsorted Message-ID: <20130820221305.33B1448A09@hg.openjdk.java.net> Changeset: 720992953d43 Author: jjg Date: 2013-08-20 15:12 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/720992953d43 8013887: In class use, some tables are randomly unsorted Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java From mike.duigou at oracle.com Tue Aug 20 17:51:30 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 21 Aug 2013 00:51:30 +0000 Subject: hg: jdk8/tl: 8023433: Improve 'make help' Message-ID: <20130821005130.7CC5C48A18@hg.openjdk.java.net> Changeset: c8da1b6a9762 Author: mduigou Date: 2013-08-20 17:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c8da1b6a9762 8023433: Improve 'make help' Reviewed-by: tbell ! NewMakefile.gmk From alan.bateman at oracle.com Wed Aug 21 02:02:07 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 21 Aug 2013 09:02:07 +0000 Subject: hg: jdk8/tl/jdk: 8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile Message-ID: <20130821090221.72AF148A34@hg.openjdk.java.net> Changeset: eb18a483e772 Author: alanb Date: 2013-08-21 09:59 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/eb18a483e772 8023351: Add TEST.groups in preparation to simplify rules in jdk/test/Makefile Reviewed-by: lancea, mduigou ! test/TEST.ROOT + test/TEST.groups From staffan.larsen at oracle.com Wed Aug 21 02:43:40 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 21 Aug 2013 09:43:40 +0000 Subject: hg: jdk8/tl/jdk: 4 new changesets Message-ID: <20130821094503.9A16C48A37@hg.openjdk.java.net> Changeset: 68be998c2596 Author: egahlin Date: 2013-08-19 12:57 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/68be998c2596 6358357: Division by zero in Threads tab when shrinking jconsole window Reviewed-by: mchung, leifs, jbachorik ! src/share/classes/sun/tools/jconsole/Plotter.java Changeset: bddf55211ed8 Author: egahlin Date: 2013-08-19 16:21 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bddf55211ed8 6417721: Thread list should not allow multiple selection Reviewed-by: alanb, jbachorik, sjiang ! src/share/classes/sun/tools/jconsole/ThreadTab.java Changeset: 2636d337a1ed Author: egahlin Date: 2013-08-19 16:41 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2636d337a1ed 6800801: NPE in JConsole when using Nimbus L&F Reviewed-by: alanb, sjiang ! src/share/classes/sun/tools/jconsole/ConnectDialog.java ! src/share/classes/sun/tools/jconsole/VMPanel.java Changeset: ba943fc47fc8 Author: egahlin Date: 2013-08-19 13:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ba943fc47fc8 7042707: Un-needed mnemonic in JConsole resource file Reviewed-by: mfang, jbachorik ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties ! src/share/classes/sun/tools/jconsole/resources/messages_ja.properties ! src/share/classes/sun/tools/jconsole/resources/messages_zh_CN.properties From david.holmes at oracle.com Wed Aug 21 02:57:16 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Wed, 21 Aug 2013 09:57:16 +0000 Subject: hg: jdk8/tl/jdk: 8023460: OPENJDK build fails due to missing jfr.jar Message-ID: <20130821095728.7866948A38@hg.openjdk.java.net> Changeset: 3b8fed46b2a8 Author: dholmes Date: 2013-08-21 05:56 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3b8fed46b2a8 8023460: OPENJDK build fails due to missing jfr.jar Reviewed-by: alanb ! makefiles/Profiles.gmk From mark.sheppard at oracle.com Wed Aug 21 06:37:21 2013 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 21 Aug 2013 14:37:21 +0100 Subject: RFR: 8023326 [TESTBUG] java/net/CookieHandler/LocalHostCookie.java misplaced try/finally Message-ID: <5214C291.5050500@oracle.com> Hi please oblige and review the fix below to address the issue in JDK-8023326 which makes the test more robust to certain exceptions thrown. http://cr.openjdk.java.net/~msheppar/8023326/webrev/ regards Mark --- old/test/java/net/CookieHandler/LocalHostCookie.java Wed Aug 21 12:23:21 2013 +++ new/test/java/net/CookieHandler/LocalHostCookie.java Wed Aug 21 12:23:21 2013 @@ -72,7 +72,9 @@ } } } finally { - s.stopServer(); + if (s != null) { + s.stopServer(); + } } } @@ -96,7 +98,9 @@ } public void stopServer() { - server.stop(0); + if (server != null) { + server.stop(0); + } } } From staffan.larsen at oracle.com Wed Aug 21 08:33:42 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Wed, 21 Aug 2013 15:33:42 +0000 Subject: hg: jdk8/tl/jdk: 8023485: Remove com/sun/jdi/DoubleAgentTest.java and com/sun/jdi/FieldWatchpoints.java from ProblemList.txt Message-ID: <20130821153409.DC15048A46@hg.openjdk.java.net> Changeset: 8996f47f738d Author: sla Date: 2013-08-21 17:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8996f47f738d 8023485: Remove com/sun/jdi/DoubleAgentTest.java and com/sun/jdi/FieldWatchpoints.java from ProblemList.txt Reviewed-by: chegar, mgronlun ! test/ProblemList.txt From kurchisubhra at gmail.com Wed Aug 21 11:23:31 2013 From: kurchisubhra at gmail.com (Kurchi Subhra Hazra) Date: Wed, 21 Aug 2013 11:23:31 -0700 Subject: RFR: 8023326 [TESTBUG] java/net/CookieHandler/LocalHostCookie.java misplaced try/finally In-Reply-To: <5214C291.5050500@oracle.com> References: <5214C291.5050500@oracle.com> Message-ID: I guess we could have changed class Server to implement AutoCloseable too, but this looks fine to me. Thanks, - Kurchi On Wed, Aug 21, 2013 at 6:37 AM, Mark Sheppard wrote: > Hi > please oblige and review the fix below to address the issue in JDK-8023326 > which makes the test more robust to certain exceptions thrown. > > http://cr.openjdk.java.net/~**msheppar/8023326/webrev/ > > regards > Mark > > --- old/test/java/net/**CookieHandler/LocalHostCookie.**java Wed > Aug 21 12:23:21 2013 > +++ new/test/java/net/**CookieHandler/LocalHostCookie.**java Wed > Aug 21 12:23:21 2013 > @@ -72,7 +72,9 @@ > } > } > } finally { > - s.stopServer(); > + if (s != null) { > + s.stopServer(); > + } > } > } > @@ -96,7 +98,9 @@ > } > public void stopServer() { > - server.stop(0); > + if (server != null) { > + server.stop(0); > + } > } > } > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/net-dev/attachments/20130821/7180739e/attachment.html From mike.duigou at oracle.com Wed Aug 21 12:49:20 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Wed, 21 Aug 2013 19:49:20 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130821194944.A99FD48A5B@hg.openjdk.java.net> Changeset: fad3b6673159 Author: mduigou Date: 2013-08-21 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fad3b6673159 8023306: Add replace() implementations to TreeMap Reviewed-by: psandoz, alanb, chegar, bpb ! src/share/classes/java/util/TreeMap.java Changeset: 91a31c77be5b Author: mduigou Date: 2013-08-21 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/91a31c77be5b 8023395: Remove sun.misc.Sort and sun.misc.Compare Reviewed-by: alanb, smarks, darcy, mr - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java From jonathan.gibbons at oracle.com Wed Aug 21 16:14:14 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 21 Aug 2013 23:14:14 +0000 Subject: hg: jdk8/tl/langtools: 8023515: import type-annotations updates Message-ID: <20130821231417.A145A48A61@hg.openjdk.java.net> Changeset: 7de231613e4a Author: jjg Date: 2013-08-21 16:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7de231613e4a 8023515: import type-annotations updates Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/source/tree/MethodTree.java ! src/share/classes/com/sun/source/tree/TypeParameterTree.java ! src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/TypeAnnotations.java ! src/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java ! src/share/classes/com/sun/tools/javac/processing/JavacProcessingEnvironment.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/tree/Pretty.java ! test/tools/javac/annotations/typeAnnotations/classfile/CombinationsTargetTest2.java + test/tools/javac/annotations/typeAnnotations/failures/DummyProcessor.java + test/tools/javac/annotations/typeAnnotations/failures/T8020715.java ! test/tools/javac/annotations/typeAnnotations/referenceinfos/Constructors.java + test/tools/javac/tree/TypeAnnotationsPretty.java From jonathan.gibbons at oracle.com Wed Aug 21 17:29:36 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 22 Aug 2013 00:29:36 +0000 Subject: hg: jdk8/tl/langtools: 8022287: javac.sym.Profiles uses a static Map when it should not Message-ID: <20130822002939.8336848A65@hg.openjdk.java.net> Changeset: 57e1266527dd Author: jjg Date: 2013-08-21 17:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/57e1266527dd 8022287: javac.sym.Profiles uses a static Map when it should not Reviewed-by: ksrini ! src/share/classes/com/sun/tools/javac/sym/Profiles.java + test/tools/javac/profiles/ProfileTest.java From xuelei.fan at oracle.com Wed Aug 21 19:46:51 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Thu, 22 Aug 2013 02:46:51 +0000 Subject: hg: jdk8/tl/jdk: 8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs Message-ID: <20130822024717.B922548A76@hg.openjdk.java.net> Changeset: ec827a62070a Author: xuelei Date: 2013-08-21 19:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec827a62070a 8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs Reviewed-by: weijun ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java ! test/sun/security/ssl/templates/SSLSocketTemplate.java From staffan.larsen at oracle.com Wed Aug 21 23:29:14 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 22 Aug 2013 06:29:14 +0000 Subject: hg: jdk8/tl/jdk: 8023101: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails Message-ID: <20130822062937.A47CB48A7B@hg.openjdk.java.net> Changeset: a0896634ab46 Author: sla Date: 2013-08-22 08:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a0896634ab46 8023101: java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java fails Reviewed-by: ysr ! test/java/lang/management/MemoryMXBean/ResetPeakMemoryUsage.java From xuelei.fan at oracle.com Thu Aug 22 00:03:10 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 22 Aug 2013 15:03:10 +0800 Subject: hg: jdk8/tl/jdk: 8022228: Intermittent test failures in sun/security/ssl/javax/net/ssl/NewAPIs In-Reply-To: References: <20130822024717.B922548A76@hg.openjdk.java.net> Message-ID: <5215B7AE.2040406@oracle.com> On 8/22/2013 11:37 AM, Laxmi Narayan NIT DGP wrote: > is there are any chances of contribution for outsider of oracle and even > student developers ?? > Sure. Please see the following page about how to contribute: http://openjdk.java.net/contribute/ And The OpenJDK Developers' Guide: http://openjdk.java.net/guide/ Thanks, Xuelei > * > > > > > Laxmi Narayan Patel > * > * > MCA NIT Durgapur (Pre final year) > * > * > mob:- 8345847473 > * > > > On Thu, Aug 22, 2013 at 8:16 AM, > wrote: > > Changeset: ec827a62070a > Author: xuelei > Date: 2013-08-21 19:44 -0700 > URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ec827a62070a > > 8022228: Intermittent test failures in > sun/security/ssl/javax/net/ssl/NewAPIs > Reviewed-by: weijun > > ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionCacheSizeTests.java > ! test/sun/security/ssl/javax/net/ssl/NewAPIs/SessionTimeOutTests.java > ! test/sun/security/ssl/templates/SSLSocketTemplate.java > > From vicente.romero at oracle.com Thu Aug 22 02:23:48 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 22 Aug 2013 09:23:48 +0000 Subject: hg: jdk8/tl/langtools: 8022316: Generic throws, overriding and method reference Message-ID: <20130822092359.E724B48A80@hg.openjdk.java.net> Changeset: 7a4717f3ea7b Author: vromero Date: 2013-08-22 10:22 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7a4717f3ea7b 8022316: Generic throws, overriding and method reference Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.java + test/tools/javac/T8022316/CompilerErrorGenericThrowPlusMethodRefTest.out From vicente.romero at oracle.com Thu Aug 22 05:13:31 2013 From: vicente.romero at oracle.com (vicente.romero at oracle.com) Date: Thu, 22 Aug 2013 12:13:31 +0000 Subject: hg: jdk8/tl/langtools: 8023112: javac should not use lazy constant evaluation approach for method references Message-ID: <20130822121336.74ABE48A86@hg.openjdk.java.net> Changeset: 25aaff78d754 Author: vromero Date: 2013-08-22 13:12 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/25aaff78d754 8023112: javac should not use lazy constant evaluation approach for method references Reviewed-by: jjg, mcimadamore ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/MemberEnter.java + test/tools/javac/T8023112/SkipLazyConstantCreationForMethodRefTest.java From joe.darcy at oracle.com Thu Aug 22 09:41:33 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Thu, 22 Aug 2013 16:41:33 +0000 Subject: hg: jdk8/tl/jdk: 8023587: Fix lone remaining doclint issue in java.util.regex Message-ID: <20130822164212.2D00B48AA0@hg.openjdk.java.net> Changeset: b7c4094be729 Author: darcy Date: 2013-08-22 09:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b7c4094be729 8023587: Fix lone remaining doclint issue in java.util.regex Reviewed-by: jjg ! src/share/classes/java/util/regex/Pattern.java From dan.xu at oracle.com Thu Aug 22 11:43:40 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 22 Aug 2013 18:43:40 +0000 Subject: hg: jdk8/tl/jdk: 8023430: Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details Message-ID: <20130822184414.54EE348ACC@hg.openjdk.java.net> Changeset: 8a7d9cc2f41c Author: dxu Date: 2013-08-22 11:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a7d9cc2f41c 8023430: Replace File.mkdirs with Files.createDirectories to get MaxPathLength.java failure details Reviewed-by: alanb ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java From jonathan.gibbons at oracle.com Thu Aug 22 12:53:39 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 22 Aug 2013 19:53:39 +0000 Subject: hg: jdk8/tl/langtools: 8022173: Relax some warnings in doclint Message-ID: <20130822195344.ABB5648AD2@hg.openjdk.java.net> Changeset: b77381d99056 Author: jjg Date: 2013-08-22 12:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b77381d99056 8022173: Relax some warnings in doclint Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclint/HtmlTag.java ! test/tools/doclint/html/ListTagsTest.java ! test/tools/doclint/html/OtherTagsTest.java ! test/tools/doclint/html/OtherTagsTest.out ! test/tools/doclint/html/TableTagsTest.java From stuart.marks at oracle.com Thu Aug 22 15:53:20 2013 From: stuart.marks at oracle.com (stuart.marks at oracle.com) Date: Thu, 22 Aug 2013 22:53:20 +0000 Subject: hg: jdk8/tl/jdk: 8022445: fix RMISocketFactory example to avoid using localhost Message-ID: <20130822225333.EBC9548ADD@hg.openjdk.java.net> Changeset: 7496ec8bab76 Author: smarks Date: 2013-08-22 15:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7496ec8bab76 8022445: fix RMISocketFactory example to avoid using localhost Reviewed-by: chegar, alanb ! src/share/classes/java/rmi/server/RMISocketFactory.java From staffan.larsen at oracle.com Thu Aug 22 22:55:36 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Fri, 23 Aug 2013 05:55:36 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130823055615.9B27648AE6@hg.openjdk.java.net> Changeset: 7b6211cd8d76 Author: egahlin Date: 2013-08-21 17:15 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/7b6211cd8d76 6417649: -interval=0 is accepted and jconsole doesn't update window content at all Reviewed-by: alanb, jbachorik ! src/share/classes/sun/tools/jconsole/JConsole.java Changeset: 77a32e5df365 Author: egahlin Date: 2013-08-21 17:17 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/77a32e5df365 6359971: Threads tab: Simple text to explain that one can click on a thread to get stack trace Reviewed-by: alanb, jbachorik ! src/share/classes/sun/tools/jconsole/Messages.java ! src/share/classes/sun/tools/jconsole/ThreadTab.java ! src/share/classes/sun/tools/jconsole/resources/messages.properties From chris.hegarty at oracle.com Fri Aug 23 02:03:01 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 23 Aug 2013 09:03:01 +0000 Subject: hg: jdk8/tl/jdk: 6470700: Math.random() / Math.initRNG() uses "double checked locking" Message-ID: <20130823090333.C8F7F48AF2@hg.openjdk.java.net> Changeset: 223be1d3494f Author: bpb Date: 2013-08-22 13:32 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/223be1d3494f 6470700: Math.random() / Math.initRNG() uses "double checked locking" Summary: Replace class Random variable with a static final holder class Reviewed-by: alanb, mduigou, chegar Contributed-by: Brian Burkhalter ! src/share/classes/java/lang/Math.java ! src/share/classes/java/lang/StrictMath.java From chris.hegarty at oracle.com Fri Aug 23 01:58:15 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 23 Aug 2013 08:58:15 +0000 Subject: hg: jdk8/tl/jaxws: 8022885: Update JAX-WS RI integration to 2.2.9-b14140; ... Message-ID: <20130823085819.860EF48AF0@hg.openjdk.java.net> Changeset: b99d7e355d4b Author: mkos Date: 2013-08-23 09:57 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/b99d7e355d4b 8022885: Update JAX-WS RI integration to 2.2.9-b14140 8013016: Rebase 8009009 against the latest jdk8/jaxws Reviewed-by: alanb, chegar ! src/share/jaxws_classes/com/sun/istack/internal/tools/ParallelWorldClassLoader.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/probe/provider/annotations/Probe.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/AverageRangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundaryStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/BoundedRangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/CountStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/RangeStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/StringStatisticImpl.java ! src/share/jaxws_classes/com/sun/org/glassfish/external/statistics/impl/TimeStatisticImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/AttributesImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Classes.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Config.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventReceiver.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCEventSource.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCHandler.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCInterleaveFilter.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/NGCCRuntime.java ! src/share/jaxws_classes/com/sun/tools/internal/jxc/gen/config/Schema.java ! src/share/jaxws_classes/com/sun/tools/internal/ws/version.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_de.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_es.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_fr.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_it.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ja.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_ko.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_pt_BR.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_CN.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/MessageBundle_zh_TW.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/SchemaCache.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorOrderWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAccessorTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyAttributeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAnyElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttachmentRefWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlAttributeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementDeclWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementRefsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWrapperWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlElementsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumValueWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlEnumWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDREFWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlIDWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlInlineBinaryDataWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlJavaTypeAdapterWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlListWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMimeTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlMixedWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlNsWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRegistryWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlRootElementWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaTypesWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSchemaWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlSeeAlsoWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTransientWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlTypeWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/annotation/spec/XmlValueWriter.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/generator/bean/MessageBundle.properties ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CPropertyInfo.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/CTypeRef.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/model/package-info.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/AbstractReferenceFinderImpl.java ! src/share/jaxws_classes/com/sun/tools/internal/xjc/reader/internalizer/DOMForest.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/Util.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/Init.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlAttributeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementDeclQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlElementRefsQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlEnumQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlRootElementQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlSchemaTypeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTransientQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlTypeQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/annotation/XmlValueQuick.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/core/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/model/impl/RuntimeBuiltinLeafInfoImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/package-info.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/BridgeAdapter.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/Coordinator.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/XMLSerializer.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerBoolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerCharacter.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerDouble.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerFloat.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerInteger.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerLong.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/PrimitiveArrayListerShort.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Boolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Character.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Integer.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/FieldAccessor_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Boolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Character.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Integer.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/MethodAccessor_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_field_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Boolean.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Double.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Float.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Long.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/reflect/opt/TransducedAccessor_method_Short.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Loader.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/SAXConnector.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/UnmarshallingContext.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/runtime/unmarshaller/XsiTypeLoader.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotated.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Annotation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Any.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Appinfo.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttrDecls.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/AttributeType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexContent.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexRestriction.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ComplexTypeModel.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Documentation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Element.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExplicitGroup.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/ExtensionType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/FixedOrDefault.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Import.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/List.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalAttribute.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/LocalElement.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NestedParticle.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/NoFixedFacet.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Occurs.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Redefinable.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Schema.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SchemaTop.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleContent.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleDerivation.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestriction.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleRestrictionModel.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleType.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/SimpleTypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelAttribute.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TopLevelElement.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeDefParticle.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/TypeHost.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Union.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/schemagen/xmlschema/Wildcard.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/EditDistance.java ! src/share/jaxws_classes/com/sun/xml/internal/bind/v2/util/XmlFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDEventListener.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDHandlerBase.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/DTDParser.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EndOfInputException.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/EntityDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/ExternalEntity.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InputEntity.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/InternalEntity.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/MessageCatalog.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/Resolver.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/SimpleHashtable.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlChars.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlNames.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/XmlReader.java ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/package.html ! src/share/jaxws_classes/com/sun/xml/internal/dtdparser/resources/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractCreatorProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AbstractProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/AttributesHolder.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/FragmentedArray.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/MutableXMLStreamBuffer.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBuffer.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferException.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferMark.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferResult.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/XMLStreamBufferSource.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/DefaultWithLexicalHandler.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Features.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/Properties.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/sax/SAXBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamReaderBufferProcessor.java ! src/share/jaxws_classes/com/sun/xml/internal/stream/buffer/stax/StreamWriterBufferCreator.java ! src/share/jaxws_classes/com/sun/xml/internal/txw2/output/XMLWriter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/Packet.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/Container.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/server/ThreadLocalContainerResolver.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/streaming/XMLStreamReaderFactory.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/api/wsdl/writer/WSDLGeneratorExtension.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/commons/xmlutil/Converter.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/MtomCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP11Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAP12Codec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/StreamSOAPCodec.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/encoding/TagInfoset.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/AbstractMessageImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBHeader.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/jaxb/JAXBMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/saaj/SAAJMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/message/stream/StreamMessage.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/StreamingMessages.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/resources/streaming.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/server/SDDocumentImpl.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/spi/db/BindingContext.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/pipe/AbstractSchemaValidationTube.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/resources/Messages_en.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/version.properties ! src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XmlUtil.java ! src/share/jaxws_classes/com/sun/xml/internal/ws/wsdl/writer/WSDLGenerator.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/Messages.properties ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/SAXParserFactoryAdaptor.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/Schema.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_List.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Restriction.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/SimpleType_Union.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/annotation.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeDeclBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeGroupDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/attributeUses.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/complexType_complexContent_body.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/elementDeclBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/erSet.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/ersSet.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/facet.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/group.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/identityConstraint.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/importDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/includeDecl.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/modelGroupBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/notation.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/occurs.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/particle.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/qname.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/redefine.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/simpleType.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/wildcardBody.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/impl/parser/state/xpath.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/JAXPParser.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/parser/XSOMParser.java ! src/share/jaxws_classes/com/sun/xml/internal/xsom/util/DomAnnotationParserFactory.java ! src/share/jaxws_classes/javax/xml/bind/Binder.java ! src/share/jaxws_classes/javax/xml/bind/ContextFinder.java ! src/share/jaxws_classes/javax/xml/bind/DataBindingException.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverter.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterImpl.java ! src/share/jaxws_classes/javax/xml/bind/DatatypeConverterInterface.java ! src/share/jaxws_classes/javax/xml/bind/Element.java ! src/share/jaxws_classes/javax/xml/bind/GetPropertyAction.java ! src/share/jaxws_classes/javax/xml/bind/JAXB.java ! src/share/jaxws_classes/javax/xml/bind/JAXBContext.java ! src/share/jaxws_classes/javax/xml/bind/JAXBElement.java ! src/share/jaxws_classes/javax/xml/bind/JAXBException.java ! src/share/jaxws_classes/javax/xml/bind/JAXBIntrospector.java ! src/share/jaxws_classes/javax/xml/bind/JAXBPermission.java ! src/share/jaxws_classes/javax/xml/bind/MarshalException.java ! src/share/jaxws_classes/javax/xml/bind/Messages.java ! src/share/jaxws_classes/javax/xml/bind/Messages.properties ! src/share/jaxws_classes/javax/xml/bind/NotIdentifiableEvent.java ! src/share/jaxws_classes/javax/xml/bind/ParseConversionEvent.java ! src/share/jaxws_classes/javax/xml/bind/PrintConversionEvent.java ! src/share/jaxws_classes/javax/xml/bind/PropertyException.java ! src/share/jaxws_classes/javax/xml/bind/SchemaOutputResolver.java ! src/share/jaxws_classes/javax/xml/bind/TypeConstraintException.java ! src/share/jaxws_classes/javax/xml/bind/UnmarshalException.java ! src/share/jaxws_classes/javax/xml/bind/Unmarshaller.java ! src/share/jaxws_classes/javax/xml/bind/UnmarshallerHandler.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEvent.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEventHandler.java ! src/share/jaxws_classes/javax/xml/bind/ValidationEventLocator.java ! src/share/jaxws_classes/javax/xml/bind/ValidationException.java ! src/share/jaxws_classes/javax/xml/bind/Validator.java ! src/share/jaxws_classes/javax/xml/bind/WhiteSpaceProcessor.java ! src/share/jaxws_classes/javax/xml/bind/annotation/DomHandler.java ! src/share/jaxws_classes/javax/xml/bind/annotation/W3CDomHandler.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessOrder.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorOrder.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAccessorType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyAttribute.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAnyElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttachmentRef.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlAttribute.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementDecl.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRef.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementRefs.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElementWrapper.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlElements.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnum.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlEnumValue.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlID.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlIDREF.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlList.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlMixed.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNs.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlNsForm.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRegistry.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlRootElement.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchema.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSchemaTypes.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlSeeAlso.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlTransient.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlType.java ! src/share/jaxws_classes/javax/xml/bind/annotation/XmlValue.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/CollapsedStringAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/HexBinaryAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/NormalizedStringAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapter.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/XmlJavaTypeAdapters.java ! src/share/jaxws_classes/javax/xml/bind/annotation/adapters/package.html ! src/share/jaxws_classes/javax/xml/bind/annotation/package.html ! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentMarshaller.java ! src/share/jaxws_classes/javax/xml/bind/attachment/AttachmentUnmarshaller.java ! src/share/jaxws_classes/javax/xml/bind/attachment/package.html ! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractMarshallerImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/AbstractUnmarshallerImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/DefaultValidationEventHandler.java ! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.java ! src/share/jaxws_classes/javax/xml/bind/helpers/Messages.properties ! src/share/jaxws_classes/javax/xml/bind/helpers/NotIdentifiableEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ParseConversionEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/PrintConversionEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/ValidationEventLocatorImpl.java ! src/share/jaxws_classes/javax/xml/bind/helpers/package.html ! src/share/jaxws_classes/javax/xml/bind/package.html ! src/share/jaxws_classes/javax/xml/bind/util/JAXBResult.java ! src/share/jaxws_classes/javax/xml/bind/util/JAXBSource.java ! src/share/jaxws_classes/javax/xml/bind/util/Messages.java ! src/share/jaxws_classes/javax/xml/bind/util/Messages.properties ! src/share/jaxws_classes/javax/xml/bind/util/ValidationEventCollector.java ! src/share/jaxws_classes/javax/xml/bind/util/package.html From chris.hegarty at oracle.com Fri Aug 23 03:11:40 2013 From: chris.hegarty at oracle.com (chris.hegarty at oracle.com) Date: Fri, 23 Aug 2013 10:11:40 +0000 Subject: hg: jdk8/tl/jaxws: 8023636: Missing files from 8022885 Message-ID: <20130823101142.65C0348AF4@hg.openjdk.java.net> Changeset: d8593d8581df Author: mkos Date: 2013-08-23 11:10 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/d8593d8581df 8023636: Missing files from 8022885 Reviewed-by: alanb, chegar + src/share/jaxws_classes/com/sun/xml/internal/ws/api/message/StreamingSOAP.java + src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/NamespaceContextExAdaper.java + src/share/jaxws_classes/com/sun/xml/internal/ws/util/xml/XMLReaderComposite.java From daniel.fuchs at oracle.com Fri Aug 23 12:02:10 2013 From: daniel.fuchs at oracle.com (daniel.fuchs at oracle.com) Date: Fri, 23 Aug 2013 19:02:10 +0000 Subject: hg: jdk8/tl/jdk: 8005899: Logger.getLogger(name, null) should not allow to reset a non-null resource bundle Message-ID: <20130823190232.AE95C48B16@hg.openjdk.java.net> Changeset: 4ef82445ea20 Author: dfuchs Date: 2013-08-23 20:59 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4ef82445ea20 8005899: Logger.getLogger(name, null) should not allow to reset a non-null resource bundle Reviewed-by: mchung, lancea ! src/share/classes/java/util/logging/Logger.java + test/java/util/logging/Logger/getLogger/TestLogger.java + test/java/util/logging/Logger/getLogger/testlogger/MyResource.java From alan.bateman at oracle.com Sat Aug 24 13:11:53 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Sat, 24 Aug 2013 20:11:53 +0000 Subject: hg: jdk8/tl/jdk: 6378503: In java.math.BigDecimal, division by one returns zero; ... Message-ID: <20130824201246.F01CE48B32@hg.openjdk.java.net> Changeset: 216a4b93cee8 Author: bpb Date: 2013-08-23 14:15 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/216a4b93cee8 6378503: In java.math.BigDecimal, division by one returns zero 6446965: Using BigDecimal.divideToIntegralValue with extreme scales can lead to an incorrect result Summary: Fix overflow of ints and ensure appropriate values passed to checkScaleNonZero() Reviewed-by: darcy, martin Contributed-by: Brian Burkhalter ! src/share/classes/java/math/BigDecimal.java ! src/share/classes/java/math/BigInteger.java ! test/java/math/BigDecimal/IntegralDivisionTests.java From chris.hegarty at oracle.com Sun Aug 25 01:31:38 2013 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 25 Aug 2013 09:31:38 +0100 Subject: RFR: 8023326 [TESTBUG] java/net/CookieHandler/LocalHostCookie.java misplaced try/finally In-Reply-To: <5214C291.5050500@oracle.com> References: <5214C291.5050500@oracle.com> Message-ID: <5219C0EA.9030605@oracle.com> Looks ok to me Mark. -Chris. On 08/21/2013 02:37 PM, Mark Sheppard wrote: > Hi > please oblige and review the fix below to address the issue in JDK-8023326 > which makes the test more robust to certain exceptions thrown. > > http://cr.openjdk.java.net/~msheppar/8023326/webrev/ > > regards > Mark > > --- old/test/java/net/CookieHandler/LocalHostCookie.java Wed Aug 21 > 12:23:21 2013 > +++ new/test/java/net/CookieHandler/LocalHostCookie.java Wed Aug 21 > 12:23:21 2013 > @@ -72,7 +72,9 @@ > } > } > } finally { > - s.stopServer(); > + if (s != null) { > + s.stopServer(); > + } > } > } > > @@ -96,7 +98,9 @@ > } > > public void stopServer() { > - server.stop(0); > + if (server != null) { > + server.stop(0); > + } > } > } > > > From alan.bateman at oracle.com Mon Aug 26 02:04:09 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Aug 2013 09:04:09 +0000 Subject: hg: jdk8/tl/jdk: 8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8) Message-ID: <20130826090449.47C6448B54@hg.openjdk.java.net> Changeset: 0ee3b995d63b Author: alanb Date: 2013-08-26 10:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0ee3b995d63b 8023139: java/nio/file/WatchService/SensitivityModifier.java failing intermittently (win8) Reviewed-by: alanb Contributed-by: yiming.wang at oracle.com ! test/java/nio/file/WatchService/SensitivityModifier.java From alan.bateman at oracle.com Mon Aug 26 03:35:06 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Mon, 26 Aug 2013 10:35:06 +0000 Subject: hg: jdk8/tl/jdk: 7129312: BufferedInputStream calculates negative array size with large streams and mark Message-ID: <20130826103531.1189748B56@hg.openjdk.java.net> Changeset: 67a1a031876a Author: igerasim Date: 2013-08-25 23:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/67a1a031876a 7129312: BufferedInputStream calculates negative array size with large streams and mark Reviewed-by: alanb ! src/share/classes/java/io/BufferedInputStream.java + test/java/io/BufferedInputStream/LargeCopyWithMark.java From paul.sandoz at oracle.com Mon Aug 26 07:20:29 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 26 Aug 2013 14:20:29 +0000 Subject: hg: jdk8/tl/jdk: 8023234: StampedLock serializes readers on writer unlock Message-ID: <20130826142104.159D148B60@hg.openjdk.java.net> Changeset: 8a36fc7f494c Author: shade Date: 2013-08-26 17:50 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8a36fc7f494c 8023234: StampedLock serializes readers on writer unlock Summary: Sync-up the fix from jsr166 CVS, signal more readers on writer unlock Reviewed-by: martin, shade Contributed-by: Doug Lea

! src/share/classes/java/util/concurrent/locks/StampedLock.java + test/java/util/concurrent/locks/StampedLock/ReadersUnlockAfterWriteUnlock.java From roger.riggs at oracle.com Mon Aug 26 09:00:48 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Mon, 26 Aug 2013 16:00:48 +0000 Subject: hg: jdk8/tl/jdk: 8011944: Sort fails with ArrayIndexOutOfBoundsException Message-ID: <20130826160109.BC73D48B69@hg.openjdk.java.net> Changeset: 07585a2483fa Author: rriggs Date: 2013-08-26 11:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/07585a2483fa 8011944: Sort fails with ArrayIndexOutOfBoundsException Summary: Increase the size of pending stack and add test cases Reviewed-by: alanb ! src/share/classes/java/util/ComparableTimSort.java ! src/share/classes/java/util/TimSort.java + test/java/util/Arrays/TimSortStackSize.java From sean.coffey at oracle.com Mon Aug 26 10:34:36 2013 From: sean.coffey at oracle.com (sean.coffey at oracle.com) Date: Mon, 26 Aug 2013 17:34:36 +0000 Subject: hg: jdk8/tl/jdk: 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions Message-ID: <20130826173447.BBEA048B6F@hg.openjdk.java.net> Changeset: 92a66af7f834 Author: igerasim Date: 2013-08-26 18:26 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92a66af7f834 8016018: Typo in AbstractStringBuilder#indexOf and #lastIndexOf descriptions Reviewed-by: alanb, chegar ! src/share/classes/java/lang/AbstractStringBuilder.java From mike.duigou at oracle.com Mon Aug 26 11:38:22 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Mon, 26 Aug 2013 18:38:22 +0000 Subject: hg: jdk8/tl: 8023491: Remove target names from test/Makefile and defer to sub-repo makefiles. Message-ID: <20130826183822.7C91C48B79@hg.openjdk.java.net> Changeset: f643fee2b40f Author: mduigou Date: 2013-08-26 10:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f643fee2b40f 8023491: Remove target names from test/Makefile and defer to sub-repo makefiles. Reviewed-by: erikj ! common/makefiles/Main.gmk ! test/Makefile From jonathan.gibbons at oracle.com Mon Aug 26 11:49:13 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 26 Aug 2013 18:49:13 +0000 Subject: hg: jdk8/tl/langtools: 8023701: Fix badly named test Message-ID: <20130826184916.B9D5B48B7B@hg.openjdk.java.net> Changeset: 60f156c653d3 Author: jjg Date: 2013-08-26 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/60f156c653d3 8023701: Fix badly named test Reviewed-by: bpatel - test/com/sun/javadoc/testNavagation/TestNavagation.java - test/com/sun/javadoc/testNavagation/pkg/A.java - test/com/sun/javadoc/testNavagation/pkg/C.java - test/com/sun/javadoc/testNavagation/pkg/E.java - test/com/sun/javadoc/testNavagation/pkg/I.java + test/com/sun/javadoc/testNavigation/TestNavigation.java + test/com/sun/javadoc/testNavigation/pkg/A.java + test/com/sun/javadoc/testNavigation/pkg/C.java + test/com/sun/javadoc/testNavigation/pkg/E.java + test/com/sun/javadoc/testNavigation/pkg/I.java From paul.sandoz at oracle.com Mon Aug 26 13:55:36 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Mon, 26 Aug 2013 20:55:36 +0000 Subject: hg: jdk8/tl/jdk: 8020292: j.u.SplittableRandom Message-ID: <20130826205600.268B448B83@hg.openjdk.java.net> Changeset: 5ce9025c9e1a Author: psandoz Date: 2013-08-26 22:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ce9025c9e1a 8020292: j.u.SplittableRandom Reviewed-by: mduigou Contributed-by: Guy Steele , Doug Lea
, Brian Goetz , Paul Sandoz + src/share/classes/java/util/SplittableRandom.java + test/java/util/SplittableRandom/SplittableRandomTest.java + test/java/util/stream/test/org/openjdk/tests/java/util/SplittableRandomTest.java From jonathan.gibbons at oracle.com Mon Aug 26 15:56:30 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Mon, 26 Aug 2013 22:56:30 +0000 Subject: hg: jdk8/tl/langtools: 8023768: Use the unannotatedType in cyclicity checks. Message-ID: <20130826225633.9D81D48B89@hg.openjdk.java.net> Changeset: 7bf6313e1ced Author: jjg Date: 2013-08-26 15:55 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7bf6313e1ced 8023768: Use the unannotatedType in cyclicity checks. Reviewed-by: jjg Contributed-by: wdietl at gmail.com ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/annotations/typeAnnotations/failures/TypeVariableCycleTest.java From david.holmes at oracle.com Mon Aug 26 17:12:08 2013 From: david.holmes at oracle.com (david.holmes at oracle.com) Date: Tue, 27 Aug 2013 00:12:08 +0000 Subject: hg: jdk8/tl/jdk: 8014135: The JVMTI specification does not conform to recent changes in JNI specification Message-ID: <20130827001233.54B4148B8C@hg.openjdk.java.net> Changeset: 9586ca82bd8b Author: bpittore Date: 2013-08-26 11:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9586ca82bd8b 8014135: The JVMTI specification does not conform to recent changes in JNI specification Summary: Added support for statically linked agents Reviewed-by: alanb, sspitsyn, bobv, coleenp ! src/share/classes/com/sun/tools/attach/VirtualMachine.java From lana.steuck at oracle.com Mon Aug 26 22:20:16 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 27 Aug 2013 05:20:16 +0000 Subject: hg: jdk8/tl/corba: 2 new changesets Message-ID: <20130827052022.CF0A448BA2@hg.openjdk.java.net> Changeset: d411c60a8c2f Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/d411c60a8c2f Added tag jdk8-b103 for changeset 49c4a777fdfd ! .hgtags Changeset: 4e38de7c767e Author: cl Date: 2013-08-22 09:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/4e38de7c767e Added tag jdk8-b104 for changeset d411c60a8c2f ! .hgtags From lana.steuck at oracle.com Mon Aug 26 22:20:26 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 27 Aug 2013 05:20:26 +0000 Subject: hg: jdk8/tl: 9 new changesets Message-ID: <20130827052027.B374E48BA3@hg.openjdk.java.net> Changeset: ceefd94ef326 Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/ceefd94ef326 Added tag jdk8-b103 for changeset b7e64be81c8a ! .hgtags Changeset: 4fb877dfe5c4 Author: erikj Date: 2013-08-15 17:14 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/4fb877dfe5c4 8020411: lin32 - JDK 8 build for Linux-i586 on Oracle Linux 6.4 64-bit machines does not generate the bundles directory in the build directory Reviewed-by: tbell ! common/autoconf/generated-configure.sh ! common/autoconf/platform.m4 ! common/autoconf/spec.gmk.in Changeset: f10f673d9b17 Author: igerasim Date: 2013-08-16 14:43 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/f10f673d9b17 8023156: make dist-clean should remove javacservers directory Reviewed-by: erikj ! common/makefiles/Main.gmk Changeset: dadf49495ab4 Author: erikj Date: 2013-08-19 10:31 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/rev/dadf49495ab4 8021430: 64 bit JDK build fails on windows 7 due to missing corba source files Reviewed-by: tbell, katleman ! common/makefiles/IdlCompilation.gmk Changeset: 96c1b9b7524b Author: katleman Date: 2013-08-20 15:42 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/96c1b9b7524b Merge Changeset: c3b5197f2851 Author: cl Date: 2013-08-22 09:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/c3b5197f2851 Added tag jdk8-b104 for changeset 96c1b9b7524b ! .hgtags Changeset: e8a3edda1f60 Author: lana Date: 2013-08-20 17:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/e8a3edda1f60 Merge Changeset: 056398db9dcb Author: lana Date: 2013-08-23 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/056398db9dcb Merge ! common/autoconf/generated-configure.sh Changeset: 163091288aeb Author: lana Date: 2013-08-26 14:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/163091288aeb Merge ! common/makefiles/Main.gmk From lana.steuck at oracle.com Mon Aug 26 22:20:31 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 27 Aug 2013 05:20:31 +0000 Subject: hg: jdk8/tl/jaxp: 4 new changesets Message-ID: <20130827052056.027AB48BA4@hg.openjdk.java.net> Changeset: a22fe9bd01e6 Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/a22fe9bd01e6 Added tag jdk8-b103 for changeset b1ceab582fc6 ! .hgtags Changeset: af28b93bfb6f Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/af28b93bfb6f Added tag jdk8-b104 for changeset a22fe9bd01e6 ! .hgtags Changeset: d4d6422ec564 Author: lana Date: 2013-08-20 17:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/d4d6422ec564 Merge Changeset: 09a46ec11f88 Author: lana Date: 2013-08-23 14:09 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/09a46ec11f88 Merge From lana.steuck at oracle.com Mon Aug 26 22:20:35 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 27 Aug 2013 05:20:35 +0000 Subject: hg: jdk8/tl/jaxws: 3 new changesets Message-ID: <20130827052056.7DA8C48BA5@hg.openjdk.java.net> Changeset: 42211ab0ab1c Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/42211ab0ab1c Added tag jdk8-b103 for changeset 6cdc6ed98780 ! .hgtags Changeset: 88390df7ed2c Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/88390df7ed2c Added tag jdk8-b104 for changeset 42211ab0ab1c ! .hgtags Changeset: 533c1032337c Author: lana Date: 2013-08-26 14:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/533c1032337c Merge From lana.steuck at oracle.com Mon Aug 26 22:20:46 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 27 Aug 2013 05:20:46 +0000 Subject: hg: jdk8/tl/nashorn: 5 new changesets Message-ID: <20130827052057.0813148BA6@hg.openjdk.java.net> Changeset: afc100513451 Author: cl Date: 2013-08-15 09:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/afc100513451 Added tag jdk8-b103 for changeset 414203de4374 ! .hgtags Changeset: 74244f43c577 Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/74244f43c577 Added tag jdk8-b104 for changeset afc100513451 ! .hgtags Changeset: 1f2394beecf7 Author: lana Date: 2013-08-20 17:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/1f2394beecf7 Merge - src/jdk/internal/dynalink/support/Backport.java - src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/MapIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java Changeset: f484bfb624dd Author: lana Date: 2013-08-23 14:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/f484bfb624dd Merge - src/jdk/internal/dynalink/support/Backport.java - src/jdk/nashorn/internal/runtime/arrays/ArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/MapIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseArrayIterator.java - src/jdk/nashorn/internal/runtime/arrays/ReverseMapIterator.java Changeset: a18f92a0a910 Author: lana Date: 2013-08-26 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/a18f92a0a910 Merge From lana.steuck at oracle.com Mon Aug 26 22:20:47 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 27 Aug 2013 05:20:47 +0000 Subject: hg: jdk8/tl/langtools: 6 new changesets Message-ID: <20130827052114.E6B9448BA7@hg.openjdk.java.net> Changeset: dd4a00c220c6 Author: cl Date: 2013-08-15 09:26 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/dd4a00c220c6 Added tag jdk8-b103 for changeset 76cfe7c61f25 ! .hgtags Changeset: f2ee3a4e7927 Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f2ee3a4e7927 Added tag jdk8-b104 for changeset dd4a00c220c6 ! .hgtags Changeset: b59a0b4675c9 Author: lana Date: 2013-08-20 17:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b59a0b4675c9 Merge - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java Changeset: 375834b5cf08 Author: lana Date: 2013-08-23 14:17 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/375834b5cf08 Merge - test/tools/javac/defaultMethods/defaultMethodExecution/DefaultMethodRegressionTests.java - test/tools/javac/diags/examples/IncompatibleThrownTypesInLambda.java Changeset: 00ca54ceca1b Author: lana Date: 2013-08-26 14:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/00ca54ceca1b Merge Changeset: cc3fb73f5e08 Author: lana Date: 2013-08-26 22:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/cc3fb73f5e08 Merge From lana.steuck at oracle.com Mon Aug 26 22:20:56 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 27 Aug 2013 05:20:56 +0000 Subject: hg: jdk8/tl/hotspot: 32 new changesets Message-ID: <20130827052233.5940E48BA8@hg.openjdk.java.net> Changeset: 0bbd1c775bef Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/0bbd1c775bef Added tag jdk8-b103 for changeset 6f9be7f87b96 ! .hgtags Changeset: 39127bb12d32 Author: amurillo Date: 2013-08-09 01:39 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/39127bb12d32 8022688: new hotspot build - hs25-b46 Reviewed-by: jcoomes ! make/hotspot_version Changeset: ca0165daa6ec Author: sspitsyn Date: 2013-08-06 16:33 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ca0165daa6ec 7187554: JSR 292: JVMTI PopFrame needs to handle appendix arguments Summary: Restore the appendix argument after PopFrame() call Reviewed-by: twisti, coleenp Contributed-by: serguei.spitsyn at oracle.com ! src/cpu/sparc/vm/templateInterpreter_sparc.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/interpreter/interpreterRuntime.hpp Changeset: c54a3122f9c8 Author: omajid Date: 2013-08-06 12:28 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c54a3122f9c8 8022188: Make zero compile after 8016131 and 8016697 Reviewed-by: dholmes, twisti ! src/cpu/zero/vm/entryFrame_zero.hpp ! src/cpu/zero/vm/frame_zero.inline.hpp ! src/cpu/zero/vm/stubGenerator_zero.cpp ! src/os_cpu/linux_zero/vm/os_linux_zero.cpp Changeset: 196aa14f9f29 Author: dholmes Date: 2013-08-06 21:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/196aa14f9f29 Merge Changeset: 195ff07bc7f6 Author: dsamersoff Date: 2013-08-07 19:02 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/195ff07bc7f6 8021771: warning stat64 is deprecated - when building on OSX 10.7.5 Summary: stat64 have to be replaced with stat Reviewed-by: dholmes, kmo Contributed-by: rednaxelafx at gmail.com ! src/os/bsd/vm/attachListener_bsd.cpp Changeset: 31f3b1e1c5e5 Author: dcubed Date: 2013-08-08 09:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/31f3b1e1c5e5 8016601: Unable to build hsx24 on Windows using project creator and Visual Studio Summary: ProjectCreator tool is modified to support two new options: '-relativeAltSrcInclude' and '-altRelativeInclude' which prevents IDE linker errors. Also fixed some cmd line build linker warnings. Misc cleanups. Reviewed-by: rdurbin, coleenp ! make/windows/create.bat ! make/windows/create_obj_files.sh ! make/windows/makefiles/projectcreator.make ! make/windows/makefiles/trace.make ! make/windows/makefiles/vm.make ! src/share/tools/ProjectCreator/BuildConfig.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java ! src/share/tools/ProjectCreator/ProjectCreator.java ! src/share/tools/ProjectCreator/WinGammaPlatform.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC10.java Changeset: c661fa2e5189 Author: iklam Date: 2013-08-08 14:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c661fa2e5189 8022093: syntax error near "umpiconninfo_t" -- when building on Solaris 10 Summary: Added extra help message in make/solaris/makefiles/dtrace.make Reviewed-by: dholmes, sspitsyn ! make/solaris/makefiles/dtrace.make Changeset: 57ac7245594c Author: minqi Date: 2013-08-08 15:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/57ac7245594c 8019583: [TESTBUG] runtime/7107135 always passes Summary: If java test return none zero, the value will be override by 'if' statement, the exit value will always '0' and pass. Fix by recording the result in a variable. Reviewed-by: coleenp, dholmes, iklam Contributed-by: yumin.qi at oracle.com ! test/runtime/7107135/Test7107135.sh Changeset: 6222a021d582 Author: minqi Date: 2013-08-08 20:13 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/6222a021d582 Merge Changeset: 98aa538fd97e Author: mikael Date: 2013-08-09 09:51 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/98aa538fd97e 8022452: Hotspot needs to know about Windows 8.1 and Windows Server 2012 R2 Summary: Add support for recognizing Windows 8.1 and Server 2012 R2 and minor cleanup Reviewed-by: coleenp, dsamersoff ! src/os/windows/vm/os_windows.cpp Changeset: ed7c17e7d45b Author: dcubed Date: 2013-08-09 13:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ed7c17e7d45b Merge Changeset: 7b03590c334b Author: dcubed Date: 2013-08-09 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/7b03590c334b Merge Changeset: bd0e82136b03 Author: iklam Date: 2013-08-10 10:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd0e82136b03 8022740: Visual 2008 IDE build is broken Summary: Fixed project generation code, and added warning to upgrade to VS 2008 SP1. Reviewed-by: dcubed, ccheung ! make/windows/projectfiles/common/Makefile ! src/share/tools/ProjectCreator/FileTreeCreator.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC10.java ! src/share/tools/ProjectCreator/FileTreeCreatorVC7.java ! src/share/tools/ProjectCreator/WinGammaPlatformVC7.java Changeset: 85147f28faba Author: coleenp Date: 2013-08-12 17:24 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/85147f28faba 8009728: nsk/jvmti/AttachOnDemand/attach030 crashes on Win32 Summary: ActiveMethodOopsCache was used to keep track of old versions of some methods that are cached in Universe but is buggy with permgen removal and not needed anymore Reviewed-by: sspitsyn, dcubed, mseledtsov ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/method.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! test/runtime/RedefineObject/Agent.java ! test/runtime/RedefineObject/TestRedefineObject.java + test/runtime/RedefineObject/WalkThroughInvoke.java Changeset: d1034bd8cefc Author: adlertz Date: 2013-08-07 17:56 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/d1034bd8cefc 8022284: Hide internal data structure in PhaseCFG Summary: Hide private node to block mapping using public interface Reviewed-by: kvn, roland ! agent/src/share/classes/sun/jvm/hotspot/opto/PhaseCFG.java ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/output.hpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/runtime/vmStructs.cpp Changeset: ce8969c36762 Author: adlertz Date: 2013-08-07 18:04 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/ce8969c36762 8022475: Remove unneeded ad-files Summary: Remove .ad files that are not used Reviewed-by: kvn ! make/bsd/makefiles/adlc.make ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! make/windows/makefiles/adlc.make - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 5394ec69f112 Author: rbackman Date: 2013-08-09 18:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5394ec69f112 Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 11237ee74aae Author: iignatyev Date: 2013-08-10 10:01 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/11237ee74aae 8019915: whitebox testClearMethodStateTest fails with tiered on sparc Summary: 'compileonly' directive has beens added to each 'compiler/whitebox' test Reviewed-by: kvn ! test/compiler/whitebox/ClearMethodStateTest.java ! test/compiler/whitebox/CompilerWhiteBoxTest.java ! test/compiler/whitebox/DeoptimizeAllTest.java ! test/compiler/whitebox/DeoptimizeMethodTest.java ! test/compiler/whitebox/EnqueueMethodForCompilationTest.java ! test/compiler/whitebox/IsMethodCompilableTest.java ! test/compiler/whitebox/MakeMethodNotCompilableTest.java ! test/compiler/whitebox/SetDontInlineMethodTest.java ! test/compiler/whitebox/SetForceInlineMethodTest.java Changeset: bcc4f6f54d83 Author: kvn Date: 2013-08-14 10:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bcc4f6f54d83 8022993: Convert MAX_UNROLL constant to LoopMaxUnroll C2 flag Summary: Replace MAX_UNROLL constant with new C2 LoopMaxUnroll flag. Reviewed-by: roland ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/loopTransform.cpp Changeset: 56b94e55267a Author: rbackman Date: 2013-08-15 15:26 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/56b94e55267a Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 9766f73e770d Author: stefank Date: 2013-05-31 14:32 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/9766f73e770d 8022880: False sharing between PSPromotionManager instances Summary: Pad the PSPromotionManager instances in the manager array. Reviewed-by: brutisso, jmasa ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parNew/parOopClosures.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp + src/share/vm/memory/padded.hpp + src/share/vm/memory/padded.inline.hpp ! src/share/vm/utilities/debug.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 330dfb0476f4 Author: brutisso Date: 2013-08-14 09:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/330dfb0476f4 8022800: Use specific generations rather than generation iteration Reviewed-by: jmasa, ehelin ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/defNewGeneration.cpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genRemSet.hpp Changeset: 3f22cbf5275d Author: brutisso Date: 2013-08-14 10:55 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3f22cbf5275d Merge Changeset: 5d9995d16b26 Author: ehelin Date: 2013-08-14 13:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5d9995d16b26 8022899: SunStudio compiler can not handle EXCEPTION_MARK and inlining Reviewed-by: coleenp, mgerdin ! src/share/vm/utilities/exceptions.hpp Changeset: bd902affe102 Author: brutisso Date: 2013-08-15 10:05 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/bd902affe102 8023021: Unnecessary clearing of the card table introduced by the fix for JDK-8023013 Reviewed-by: stefank, ehelin ! src/share/vm/memory/cardTableRS.cpp ! src/share/vm/memory/cardTableRS.hpp ! src/share/vm/memory/genMarkSweep.cpp ! src/share/vm/memory/genRemSet.hpp Changeset: 274ce305e5b9 Author: ehelin Date: 2013-08-13 18:16 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/274ce305e5b9 8020598: ObjectCountEventSender::send needs INCLUDE_TRACE guards when building OpenJDK with INCLUDE_TRACE=0 Reviewed-by: stefank, brutisso, sjohanss ! src/share/vm/gc_implementation/shared/objectCountEventSender.cpp Changeset: 33d39b75663f Author: ehelin Date: 2013-08-15 06:20 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/33d39b75663f Merge Changeset: 5a62937e55b3 Author: brutisso Date: 2013-08-16 09:02 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/5a62937e55b3 Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 580430d131cc Author: amurillo Date: 2013-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/580430d131cc Merge - src/os_cpu/bsd_x86/vm/bsd_x86_32.ad - src/os_cpu/bsd_x86/vm/bsd_x86_64.ad - src/os_cpu/linux_x86/vm/linux_x86_32.ad - src/os_cpu/linux_x86/vm/linux_x86_64.ad - src/os_cpu/solaris_sparc/vm/solaris_sparc.ad - src/os_cpu/solaris_x86/vm/solaris_x86_32.ad - src/os_cpu/solaris_x86/vm/solaris_x86_64.ad - src/os_cpu/windows_x86/vm/windows_x86_32.ad - src/os_cpu/windows_x86/vm/windows_x86_64.ad Changeset: 104743074675 Author: amurillo Date: 2013-08-16 04:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/104743074675 Added tag hs25-b46 for changeset 580430d131cc ! .hgtags Changeset: c93e0a210e1b Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/c93e0a210e1b Added tag jdk8-b104 for changeset 104743074675 ! .hgtags From lana.steuck at oracle.com Mon Aug 26 22:22:10 2013 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Tue, 27 Aug 2013 05:22:10 +0000 Subject: hg: jdk8/tl/jdk: 23 new changesets Message-ID: <20130827052721.2B1BC48BA9@hg.openjdk.java.net> Changeset: f1d8d15bfcb5 Author: cl Date: 2013-08-15 09:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f1d8d15bfcb5 Added tag jdk8-b103 for changeset e0f6039c0290 ! .hgtags Changeset: c982f579b67e Author: cl Date: 2013-08-22 09:10 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c982f579b67e Added tag jdk8-b104 for changeset f1d8d15bfcb5 ! .hgtags Changeset: 2722f4000b65 Author: jgodinez Date: 2013-08-15 11:56 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2722f4000b65 8023045: [MacOSX] PrinterIOException when printing a JComponent Reviewed-by: bae, jchen ! src/share/classes/sun/print/PSPrinterJob.java Changeset: b44ce67c0565 Author: vadim Date: 2013-08-16 15:57 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b44ce67c0565 8013446: [parfait] Memory leak in jdk/src/windows/native/sun/java2d/opengl/WGLSurfaceData.c Reviewed-by: bae, prr ! src/windows/native/sun/java2d/opengl/WGLSurfaceData.c Changeset: dadd43e02a79 Author: prr Date: 2013-08-19 03:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/dadd43e02a79 8017580: Crash in font loading code on Linux (due to use of reflection) Reviewed-by: bae, vadim ! src/share/native/sun/font/sunFont.c ! src/share/native/sun/font/sunfontids.h Changeset: 0c950b2be7ab Author: jgodinez Date: 2013-08-19 11:21 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/0c950b2be7ab 8022241: [macosx] [PIT] lookupPrintServices() returns one too long array Reviewed-by: prr, jchen ! src/solaris/classes/sun/print/UnixPrintServiceLookup.java Changeset: 64be71ae6185 Author: lana Date: 2013-08-20 17:35 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64be71ae6185 Merge Changeset: 903a279f1fce Author: ant Date: 2013-08-09 05:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/903a279f1fce 8013611: Modal dialog fails to obtain keyboard focus Reviewed-by: leonidr ! src/share/classes/java/awt/KeyboardFocusManager.java + test/java/awt/Focus/8013611/JDK8013611.java Changeset: 2cd1a041381b Author: alexsch Date: 2013-08-09 14:16 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2cd1a041381b 7121409: Two conformance tests for AccessibleText.getCharacterBounds(int i) fail Reviewed-by: serb ! src/share/classes/javax/swing/JLabel.java Changeset: 4702ab74b70a Author: serb Date: 2013-08-13 15:41 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4702ab74b70a 7027045: (doc) java/awt/Window.java has several typos in javadoc Reviewed-by: art, serb Contributed-by: konstantin.perikov at gmail.com ! src/share/classes/java/awt/Window.java Changeset: 149bf2400fa1 Author: lana Date: 2013-08-13 15:49 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/149bf2400fa1 Merge - test/java/lang/System/MacJNUEncoding/ExpectedEncoding.java - test/java/lang/System/MacJNUEncoding/MacJNUEncoding.sh Changeset: c5db3ec83cba Author: pchelko Date: 2013-08-14 16:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c5db3ec83cba 8013454: [parfait] Memory leak in jdk/src/windows/native/sun/windows/awt_Cursor.cpp 8012079: [parfait] possible null pointer dereference in jdk/src/windows/native/sun/windows/awt_Font.cpp Reviewed-by: art, serb ! src/windows/native/sun/windows/awt_Cursor.cpp ! src/windows/native/sun/windows/awt_Font.cpp Changeset: 1d6ce0070fd3 Author: pchelko Date: 2013-08-14 17:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1d6ce0070fd3 7173464: Clipboard.getAvailableDataFlavors: Comparison method violates contract Reviewed-by: anthony, art, serb ! src/share/classes/sun/awt/datatransfer/ClipboardTransferable.java ! src/share/classes/sun/awt/datatransfer/DataTransferer.java + test/sun/awt/datatransfer/DataFlavorComparatorTest.java Changeset: 3930a827160a Author: leonidr Date: 2013-08-15 01:17 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3930a827160a 8022997: [macosx] Remaining duplicated key events Reviewed-by: anthony, serb ! src/macosx/native/sun/awt/CMenuItem.m ! test/javax/swing/JMenuItem/ActionListenerCalledTwice/ActionListenerCalledTwiceTest.java Changeset: d7a34d7e7f22 Author: alitvinov Date: 2013-08-15 14:20 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d7a34d7e7f22 7191018: Manual test closed/java/awt/JAWT causes JVM to crash starting from JDK 5 Reviewed-by: anthony, serb ! src/solaris/native/sun/awt/awt_DrawingSurface.c Changeset: c089e93e6444 Author: serb Date: 2013-08-16 16:52 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c089e93e6444 8020051: [TEST_BUG] Testcase for 8004859 has a typo Reviewed-by: anthony ! test/java/awt/Graphics2D/Test8004859/Test8004859.java Changeset: e3316cd6ca47 Author: serb Date: 2013-08-16 20:56 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e3316cd6ca47 8006085: [findbugs] a warning on javax.sound.sampled.DataLine$Info constructor Reviewed-by: art, prr ! src/share/classes/javax/sound/sampled/DataLine.java Changeset: 64dc24e0d577 Author: serb Date: 2013-08-16 21:18 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/64dc24e0d577 8005980: [findbugs] More com.sun.media.sound.* warnings Reviewed-by: art, prr ! src/share/classes/com/sun/media/sound/DataPusher.java ! src/share/classes/com/sun/media/sound/ModelStandardDirector.java ! src/share/classes/com/sun/media/sound/ModelStandardIndexedDirector.java ! src/share/classes/com/sun/media/sound/SoftMixingClip.java ! src/share/classes/sun/audio/AudioData.java Changeset: fefa29e15a14 Author: lana Date: 2013-08-20 17:38 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/fefa29e15a14 Merge Changeset: a79fcf53195f Author: lana Date: 2013-08-20 17:44 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a79fcf53195f Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: 9626ba160e3d Author: lana Date: 2013-08-23 14:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9626ba160e3d Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/java/util/jar/UnsupportedProfileException.java - src/share/classes/sun/security/provider/ConfigSpiFile.java - test/java/net/URLClassLoader/profiles/Basic.java - test/java/net/URLClassLoader/profiles/Lib.java - test/java/net/URLClassLoader/profiles/basic.sh - test/tools/jar/AddAndUpdateProfile.java - test/tools/launcher/profiles/Basic.java - test/tools/launcher/profiles/Logging.java - test/tools/launcher/profiles/Main.java - test/tools/launcher/profiles/VersionCheck.java Changeset: c58e39bb5d62 Author: lana Date: 2013-08-26 14:53 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c58e39bb5d62 Merge Changeset: 6cdc679e3412 Author: lana Date: 2013-08-26 22:18 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6cdc679e3412 Merge From weijun.wang at oracle.com Tue Aug 27 02:51:22 2013 From: weijun.wang at oracle.com (weijun.wang at oracle.com) Date: Tue, 27 Aug 2013 09:51:22 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130827095225.1083C48BB4@hg.openjdk.java.net> Changeset: ca53110f1c74 Author: weijun Date: 2013-08-27 17:50 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/ca53110f1c74 8015669: KerberosPrincipal::equals should ignore name-type Reviewed-by: mullan ! src/share/classes/javax/security/auth/kerberos/KerberosPrincipal.java + test/sun/security/krb5/auto/KPEquals.java Changeset: 4bddc344848e Author: weijun Date: 2013-08-27 17:50 +0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/4bddc344848e 8022761: regression: SecurityException is NOT thrown while trying to pack a wrongly signed Indexed Jar file Reviewed-by: sherman ! src/share/classes/java/util/jar/JarVerifier.java + test/sun/security/tools/jarsigner/jvindex.sh From sean.mullan at oracle.com Tue Aug 27 07:47:34 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 27 Aug 2013 14:47:34 +0000 Subject: hg: jdk8/tl/jdk: 8023769: JDK-8016850 broke the old build Message-ID: <20130827144802.7A91E48BC4@hg.openjdk.java.net> Changeset: 134283a88499 Author: mullan Date: 2013-08-27 10:46 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/134283a88499 8023769: JDK-8016850 broke the old build Summary: remove files that were moved/removed from com/sun/security/auth/FILES_java.gmk Reviewed-by: chegar, xuelei ! make/com/sun/security/auth/FILES_java.gmk From sean.mullan at oracle.com Tue Aug 27 10:00:32 2013 From: sean.mullan at oracle.com (sean.mullan at oracle.com) Date: Tue, 27 Aug 2013 17:00:32 +0000 Subject: hg: jdk8/tl/jdk: 2 new changesets Message-ID: <20130827170114.3E4EF48BD4@hg.openjdk.java.net> Changeset: 6a1bfcde4d4d Author: mullan Date: 2013-08-27 12:04 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6a1bfcde4d4d 8019830: Add com.sun.media.sound to the list of restricted package Reviewed-by: vinnie ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! test/java/lang/SecurityManager/CheckPackageAccess.java Changeset: 3575263eefab Author: mullan Date: 2013-08-27 12:27 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3575263eefab Merge - src/share/classes/com/sun/security/auth/PolicyParser.java - src/share/classes/com/sun/security/auth/SubjectCodeSource.java - src/share/classes/sun/misc/Compare.java - src/share/classes/sun/misc/Sort.java From joe.darcy at oracle.com Tue Aug 27 11:46:44 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 27 Aug 2013 18:46:44 +0000 Subject: hg: jdk8/tl/jdk: 8023827: Fix doclint issues in javax.net.ssl Message-ID: <20130827184707.54C9948BE2@hg.openjdk.java.net> Changeset: 51151b440e95 Author: darcy Date: 2013-08-27 11:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/51151b440e95 8023827: Fix doclint issues in javax.net.ssl Reviewed-by: wetmore, xuelei ! src/share/classes/javax/net/ssl/SNIHostName.java ! src/share/classes/javax/net/ssl/X509KeyManager.java From joe.darcy at oracle.com Tue Aug 27 11:59:39 2013 From: joe.darcy at oracle.com (joe.darcy at oracle.com) Date: Tue, 27 Aug 2013 18:59:39 +0000 Subject: hg: jdk8/tl/langtools: 8023826: Typo in warning about obsolete source / target values Message-ID: <20130827185942.4591C48BE3@hg.openjdk.java.net> Changeset: 662a5188bded Author: darcy Date: 2013-08-27 11:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/662a5188bded 8023826: Typo in warning about obsolete source / target values Reviewed-by: jjg, wmdietl ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java From xueming.shen at oracle.com Tue Aug 27 12:51:41 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Tue, 27 Aug 2013 19:51:41 +0000 Subject: hg: jdk8/tl/jdk: 8023647: "abc1c".matches("(\\w)+1\\1")) returns false Message-ID: <20130827195214.B335F48BEF@hg.openjdk.java.net> Changeset: 3f6777cbfe69 Author: sherman Date: 2013-08-27 12:54 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3f6777cbfe69 8023647: "abc1c".matches("(\\w)+1\\1")) returns false Summary: to correct the wrong GroupCurly group index backoff code Reviewed-by: alanb ! src/share/classes/java/util/regex/Pattern.java ! test/java/util/regex/RegExTest.java From alan.bateman at oracle.com Wed Aug 28 07:33:51 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 28 Aug 2013 14:33:51 +0000 Subject: hg: jdk8/tl/jdk: 8023717: (process) ProcessBuilder should catch SecurityException rather than AccessControlException Message-ID: <20130828143416.D038248C29@hg.openjdk.java.net> Changeset: 2efa310226f7 Author: alanb Date: 2013-08-28 14:07 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/2efa310226f7 8023717: (process) ProcessBuilder should catch SecurityException rather than AccessControlException Reviewed-by: wetmore, alanb Contributed-by: martinrb at google.com ! src/share/classes/java/lang/ProcessBuilder.java From alan.bateman at oracle.com Wed Aug 28 07:53:08 2013 From: alan.bateman at oracle.com (alan.bateman at oracle.com) Date: Wed, 28 Aug 2013 14:53:08 +0000 Subject: hg: jdk8/tl/jdk: 8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil Message-ID: <20130828145330.265AB48C2B@hg.openjdk.java.net> Changeset: 378acd4d03c8 Author: alanb Date: 2013-08-28 15:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/378acd4d03c8 8022594: Potential deadlock in of sun.nio.ch.Util/IOUtil Reviewed-by: chegar ! src/macosx/classes/sun/nio/ch/KQueueArrayWrapper.java ! src/macosx/classes/sun/nio/ch/KQueueSelectorImpl.java ! src/share/classes/sun/nio/ch/AbstractPollSelectorImpl.java ! src/share/classes/sun/nio/ch/DatagramChannelImpl.java ! src/share/classes/sun/nio/ch/FileChannelImpl.java ! src/share/classes/sun/nio/ch/IOUtil.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/share/classes/sun/nio/ch/Util.java ! src/solaris/classes/sun/nio/ch/DatagramDispatcher.java ! src/solaris/classes/sun/nio/ch/DevPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/DevPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/EPoll.java ! src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/EPollPort.java ! src/solaris/classes/sun/nio/ch/EPollSelectorImpl.java ! src/solaris/classes/sun/nio/ch/FileDispatcherImpl.java ! src/solaris/classes/sun/nio/ch/InheritedChannel.java ! src/solaris/classes/sun/nio/ch/KQueue.java ! src/solaris/classes/sun/nio/ch/KQueuePort.java ! src/solaris/classes/sun/nio/ch/NativeThread.java ! src/solaris/classes/sun/nio/ch/PollArrayWrapper.java ! src/solaris/classes/sun/nio/ch/SinkChannelImpl.java ! src/solaris/classes/sun/nio/ch/SolarisEventPort.java ! src/solaris/classes/sun/nio/ch/SourceChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousServerSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/UnixAsynchronousSocketChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpMultiChannelImpl.java ! src/solaris/classes/sun/nio/ch/sctp/SctpServerChannelImpl.java ! src/windows/classes/sun/nio/ch/DatagramDispatcher.java ! src/windows/classes/sun/nio/ch/FileDispatcherImpl.java ! src/windows/classes/sun/nio/ch/FileKey.java ! src/windows/classes/sun/nio/ch/Iocp.java ! src/windows/classes/sun/nio/ch/PipeImpl.java ! src/windows/classes/sun/nio/ch/SocketDispatcher.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousServerSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsAsynchronousSocketChannelImpl.java ! src/windows/classes/sun/nio/ch/WindowsSelectorImpl.java From xueming.shen at oracle.com Wed Aug 28 09:43:58 2013 From: xueming.shen at oracle.com (xueming.shen at oracle.com) Date: Wed, 28 Aug 2013 16:43:58 +0000 Subject: hg: jdk8/tl/jdk: 8023713: ZipFileSystem crashes on old zip file Message-ID: <20130828164438.79F9A6236B@hg.openjdk.java.net> Changeset: 690b2931baef Author: sherman Date: 2013-08-28 09:46 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/690b2931baef 8023713: ZipFileSystem crashes on old zip file Summary: to handle extra data field copy correctly even the extra data does not follow the spec Reviewed-by: alanb, martin, chegar ! src/share/classes/java/util/zip/ZipOutputStream.java ! test/java/util/zip/TestExtraTime.java From paul.sandoz at oracle.com Wed Aug 28 13:13:49 2013 From: paul.sandoz at oracle.com (paul.sandoz at oracle.com) Date: Wed, 28 Aug 2013 20:13:49 +0000 Subject: hg: jdk8/tl/jdk: 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom Message-ID: <20130828201419.3B4096237E@hg.openjdk.java.net> Changeset: b1f41565b806 Author: psandoz Date: 2013-08-28 22:11 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/b1f41565b806 8023155: Ensure functional consistency across Random, ThreadLocalRandom, SplittableRandom Reviewed-by: mduigou Contributed-by: Doug Lea
, Paul Sandoz ! src/share/classes/java/util/Random.java ! src/share/classes/java/util/concurrent/ThreadLocalRandom.java ! test/java/util/Random/RandomStreamTest.java + test/java/util/Random/RandomTest.java ! test/java/util/SplittableRandom/SplittableRandomTest.java + test/java/util/concurrent/ThreadLocalRandom/ThreadLocalRandomTest.java From jonathan.gibbons at oracle.com Wed Aug 28 15:41:21 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Wed, 28 Aug 2013 22:41:21 +0000 Subject: hg: jdk8/tl/langtools: 8010310: [javadoc] Error processing sources with -private Message-ID: <20130828224126.38AC562385@hg.openjdk.java.net> Changeset: 189942cdf585 Author: jjg Date: 2013-08-28 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/189942cdf585 8010310: [javadoc] Error processing sources with -private Reviewed-by: vromero, mcimadamore ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javadoc/JavadocMemberEnter.java + test/tools/javadoc/nonConstExprs/Test.java From staffan.larsen at oracle.com Thu Aug 29 02:26:05 2013 From: staffan.larsen at oracle.com (staffan.larsen at oracle.com) Date: Thu, 29 Aug 2013 09:26:05 +0000 Subject: hg: jdk8/tl/jdk: 8023786: (jdk) setjmp/longjmp changes the process signal mask on OS X Message-ID: <20130829093110.91F276239C@hg.openjdk.java.net> Changeset: 779ff9f3b2e3 Author: sla Date: 2013-08-29 11:22 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/779ff9f3b2e3 8023786: (jdk) setjmp/longjmp changes the process signal mask on OS X Reviewed-by: dholmes ! src/share/back/SDE.c ! src/share/native/common/check_code.c From xuelei.fan at oracle.com Thu Aug 29 05:46:51 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 29 Aug 2013 20:46:51 +0800 Subject: [JDK 8] Code review request JDK-8023881, IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII Message-ID: <521F42BB.9020309@oracle.com> Hi, Please review the fix of JDK-8023881. webrev: http://cr.openjdk.java.net/~xuelei/8023881/webrev.00/ This bug has not been ported to bugs.sun.com. The following is the descirption of the issue. -------------------------------------------------------- IDN.toASCII("??.com", IDN.USE_STD3_ASCII_RULES) throws: Exception ... java.lang.IllegalArgumentException: Contains non-LDH characters at java.net.IDN.toASCIIInternal(IDN.java:275) at java.net.IDN.toASCII(IDN.java:118) However, the "idn" tool is able to handle above IDN properly: $ idn --usestd3asciirules www.??.com www.xn--fsq092h.com Per step 3, section 4.1, RFC 3490: 3. If the UseSTD3ASCIIRules flag is set, then perform these checks: (a) Verify the absence of non-LDH ASCII code points; that is, the absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. (b) Verify the absence of leading and trailing hyphen-minus; that is, the absence of U+002D at the beginning and end of the sequence. However, in the impl of IDN is checking far more strictly than above. Unicode point bigger than 0x007A is not acceptable. It is too strict to convert Unicode with IDN.toASCII() if IDN.USE_STD3_ASCII_RULES option is set. -------------------------------------------------------- Thanks, Xuelei From michael.x.mcmahon at oracle.com Thu Aug 29 07:57:30 2013 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Thu, 29 Aug 2013 15:57:30 +0100 Subject: [JDK 8] Code review request JDK-8023881, IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII In-Reply-To: <521F42BB.9020309@oracle.com> References: <521F42BB.9020309@oracle.com> Message-ID: <521F615A.8080002@oracle.com> Xuelei, This looks fine. I would add a comment to line 408-409 that says something like: Non LDH refers to characters in the ASCII range, but which are not letters, digits or the hypen. That explains what exactly was fixed here. Michael On 29/08/13 13:46, Xuelei Fan wrote: > Hi, > > Please review the fix of JDK-8023881. > > webrev: http://cr.openjdk.java.net/~xuelei/8023881/webrev.00/ > > This bug has not been ported to bugs.sun.com. The following is the > descirption of the issue. > > -------------------------------------------------------- > IDN.toASCII("??.com", IDN.USE_STD3_ASCII_RULES) throws: > > Exception ... java.lang.IllegalArgumentException: Contains non-LDH > characters > at java.net.IDN.toASCIIInternal(IDN.java:275) > at java.net.IDN.toASCII(IDN.java:118) > > However, the "idn" tool is able to handle above IDN properly: > $ idn --usestd3asciirules www.??.com > www.xn--fsq092h.com > > Per step 3, section 4.1, RFC 3490: > > 3. If the UseSTD3ASCIIRules flag is set, then perform these checks: > > (a) Verify the absence of non-LDH ASCII code points; that is, the > absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. > > (b) Verify the absence of leading and trailing hyphen-minus; that > is, the absence of U+002D at the beginning and end of the > sequence. > > However, in the impl of IDN is checking far more strictly than above. > Unicode point bigger than 0x007A is not acceptable. It is too strict to > convert Unicode with IDN.toASCII() if IDN.USE_STD3_ASCII_RULES option is > set. > -------------------------------------------------------- > > Thanks, > Xuelei From xuelei.fan at oracle.com Thu Aug 29 08:20:29 2013 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 29 Aug 2013 23:20:29 +0800 Subject: [JDK 8] Code review request JDK-8023881, IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII In-Reply-To: <521F615A.8080002@oracle.com> References: <521F42BB.9020309@oracle.com> <521F615A.8080002@oracle.com> Message-ID: <521F66BD.9080404@oracle.com> On 8/29/2013 10:57 PM, Michael McMahon wrote: > Xuelei, > > This looks fine. > > I would add a comment to line 408-409 that says something like: > > Non LDH refers to characters in the ASCII range, but which > are not letters, digits or the hypen. > I will add the comment. Thanks for the quick code review. Xuelei > That explains what exactly was fixed here. > > Michael > > On 29/08/13 13:46, Xuelei Fan wrote: >> Hi, >> >> Please review the fix of JDK-8023881. >> >> webrev: http://cr.openjdk.java.net/~xuelei/8023881/webrev.00/ >> >> This bug has not been ported to bugs.sun.com. The following is the >> descirption of the issue. >> >> -------------------------------------------------------- >> IDN.toASCII("??.com", IDN.USE_STD3_ASCII_RULES) throws: >> >> Exception ... java.lang.IllegalArgumentException: Contains non-LDH >> characters >> at java.net.IDN.toASCIIInternal(IDN.java:275) >> at java.net.IDN.toASCII(IDN.java:118) >> >> However, the "idn" tool is able to handle above IDN properly: >> $ idn --usestd3asciirules www.??.com >> www.xn--fsq092h.com >> >> Per step 3, section 4.1, RFC 3490: >> >> 3. If the UseSTD3ASCIIRules flag is set, then perform these checks: >> >> (a) Verify the absence of non-LDH ASCII code points; that is, the >> absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F. >> >> (b) Verify the absence of leading and trailing hyphen-minus; that >> is, the absence of U+002D at the beginning and end of the >> sequence. >> >> However, in the impl of IDN is checking far more strictly than above. >> Unicode point bigger than 0x007A is not acceptable. It is too strict to >> convert Unicode with IDN.toASCII() if IDN.USE_STD3_ASCII_RULES option is >> set. >> -------------------------------------------------------- >> >> Thanks, >> Xuelei > From dan.xu at oracle.com Thu Aug 29 10:44:20 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Thu, 29 Aug 2013 17:44:20 +0000 Subject: hg: jdk8/tl/jdk: 4792059: test/java/io/pathNames/GeneralSolaris.java fails on symbolic links Message-ID: <20130829174445.5008B623C7@hg.openjdk.java.net> Changeset: 5bf4f2eeee85 Author: dxu Date: 2013-08-29 10:43 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5bf4f2eeee85 4792059: test/java/io/pathNames/GeneralSolaris.java fails on symbolic links Summary: Exclude the possible usage of linked files or directories in the test Reviewed-by: alanb ! test/java/io/pathNames/General.java From jonathan.gibbons at oracle.com Thu Aug 29 11:42:43 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 29 Aug 2013 18:42:43 +0000 Subject: hg: jdk8/tl/langtools: 8001669: javadoc internal DocletAbortException should set cause when appropriate Message-ID: <20130829184250.9071D623CF@hg.openjdk.java.net> Changeset: 0e6577980181 Author: jjg Date: 2013-08-29 11:41 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/0e6577980181 8001669: javadoc internal DocletAbortException should set cause when appropriate Reviewed-by: darcy ! src/share/classes/com/sun/tools/doclets/formats/html/AllClassesFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/DeprecatedListWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/FrameOutputWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HelpWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDoclet.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageUseWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfileIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/ProfilePackageIndexFrameWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SingleIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/SplitIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/Comment.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/DocType.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocument.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/RawHtml.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/StringContent.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Content.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/AbstractMemberBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/LayoutParser.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/taglets/ValueTaglet.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/ClassUseMapper.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocFile.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PackageListWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/PathDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SimpleDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/StandardDocFileFactory.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java From jonathan.gibbons at oracle.com Thu Aug 29 11:58:03 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 29 Aug 2013 18:58:03 +0000 Subject: hg: jdk8/tl/langtools: 8023522: tools/javac/tree/TypeAnnotationsPretty.java test cases with @TA newline fail on windows only Message-ID: <20130829185809.5FF98623D3@hg.openjdk.java.net> Changeset: b0b25c1f6cbd Author: jjg Date: 2013-08-29 11:57 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/b0b25c1f6cbd 8023522: tools/javac/tree/TypeAnnotationsPretty.java test cases with @TA newline fail on windows only Reviewed-by: darcy ! test/tools/javac/tree/TypeAnnotationsPretty.java From jonathan.gibbons at oracle.com Thu Aug 29 12:04:23 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 29 Aug 2013 19:04:23 +0000 Subject: hg: jdk8/tl/langtools: 8013384: Potential infinite loop in javadoc Message-ID: <20130829190432.B1D57623D8@hg.openjdk.java.net> Changeset: 9c0e192c0926 Author: jjg Date: 2013-08-29 12:03 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/9c0e192c0926 8013384: Potential infinite loop in javadoc Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java From jonathan.gibbons at oracle.com Thu Aug 29 12:12:25 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Thu, 29 Aug 2013 19:12:25 +0000 Subject: hg: jdk8/tl/langtools: 8022744: javac -Xpkginfo command's documentation is sparse Message-ID: <20130829191232.EF632623DA@hg.openjdk.java.net> Changeset: 96b6865eda94 Author: jjg Date: 2013-08-29 12:11 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/96b6865eda94 8022744: javac -Xpkginfo command's documentation is sparse Reviewed-by: darcy ! src/share/classes/com/sun/tools/javac/main/Option.java From mike.duigou at oracle.com Thu Aug 29 16:05:12 2013 From: mike.duigou at oracle.com (mike.duigou at oracle.com) Date: Thu, 29 Aug 2013 23:05:12 +0000 Subject: hg: jdk8/tl: 8023892: test/Makefile shouldn't try to tell langtools/test/Makefile where to put output. Message-ID: <20130829230512.8E950623FC@hg.openjdk.java.net> Changeset: 51a61778a99d Author: mduigou Date: 2013-08-29 16:04 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/rev/51a61778a99d 8023892: test/Makefile shouldn't try to tell langtools/test/Makefile where to put output. Reviewed-by: erikj, vromero, henryjen ! test/Makefile From jonathan.gibbons at oracle.com Thu Aug 29 19:20:32 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 30 Aug 2013 02:20:32 +0000 Subject: hg: jdk8/tl/langtools: 8023833: Replace direct use of AnnotatedType in javadoc code Message-ID: <20130830022040.35E3D62403@hg.openjdk.java.net> Changeset: 23f0f3c9c44a Author: jjg Date: 2013-08-29 19:19 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/23f0f3c9c44a 8023833: Replace direct use of AnnotatedType in javadoc code Reviewed-by: darcy ! src/share/classes/com/sun/tools/javadoc/AnnotatedTypeImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javadoc/TypeVariableImpl.java From xuelei.fan at oracle.com Thu Aug 29 18:59:41 2013 From: xuelei.fan at oracle.com (xuelei.fan at oracle.com) Date: Fri, 30 Aug 2013 01:59:41 +0000 Subject: hg: jdk8/tl/jdk: 8023881: IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII Message-ID: <20130830015953.C9E4362401@hg.openjdk.java.net> Changeset: cdf68747b0fb Author: xuelei Date: 2013-08-29 18:58 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/cdf68747b0fb 8023881: IDN.USE_STD3_ASCII_RULES option is too strict to use Unicode in IDN.toASCII Reviewed-by: michaelm ! src/share/classes/java/net/IDN.java + test/java/net/IDN/UseSTD3ASCIIRules.java From jonathan.gibbons at oracle.com Fri Aug 30 11:50:05 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 30 Aug 2013 18:50:05 +0000 Subject: hg: jdk8/tl/langtools: 8023700: Use non breaking space in various labels Message-ID: <20130830185013.C200E6243A@hg.openjdk.java.net> Changeset: 240f424cc0d5 Author: jjg Date: 2013-08-30 11:48 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/240f424cc0d5 8023700: Use non breaking space in various labels Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! test/com/sun/javadoc/testNavigation/TestNavigation.java ! test/com/sun/javadoc/testProfiles/TestProfiles.java From jonathan.gibbons at oracle.com Fri Aug 30 15:16:09 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 30 Aug 2013 22:16:09 +0000 Subject: hg: jdk8/tl/langtools: 8024093: Two *.rej files checked in to langtools/test directory Message-ID: <20130830221612.C01AF62443@hg.openjdk.java.net> Changeset: 3dd40e5715fb Author: jjg Date: 2013-08-30 15:14 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/3dd40e5715fb 8024093: Two *.rej files checked in to langtools/test directory Reviewed-by: mchung - test/tools/javac/diags/examples/MrefStat.java.rej - test/tools/javac/diags/examples/MrefStat1.java.rej From jonathan.gibbons at oracle.com Fri Aug 30 16:27:42 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Fri, 30 Aug 2013 23:27:42 +0000 Subject: hg: jdk8/tl/langtools: 8008367: Sub-packages missing from Profiles javadoc Message-ID: <20130830232747.8DC6E6244C@hg.openjdk.java.net> Changeset: f050c714b556 Author: jjg Date: 2013-08-30 16:27 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f050c714b556 8008367: Sub-packages missing from Profiles javadoc Reviewed-by: bpatel ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java From jonathan.gibbons at oracle.com Fri Aug 30 17:37:22 2013 From: jonathan.gibbons at oracle.com (jonathan.gibbons at oracle.com) Date: Sat, 31 Aug 2013 00:37:22 +0000 Subject: hg: jdk8/tl/langtools: 8015663: Need to supply tests to provide javadoc for profiles support code coverage Message-ID: <20130831003729.303AE62453@hg.openjdk.java.net> Changeset: 7993cfab8610 Author: jjg Date: 2013-08-30 17:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/7993cfab8610 8015663: Need to supply tests to provide javadoc for profiles support code coverage Reviewed-by: jjg Contributed-by: evgeniya.stepanova at oracle.com ! test/com/sun/javadoc/testProfiles/TestProfiles.java + test/com/sun/javadoc/testProfiles/TestProfilesConfiguration.java ! test/com/sun/javadoc/testProfiles/pkg2/Class1Pkg2.java + test/com/sun/javadoc/testProfiles/pkg2/ClassError.java + test/com/sun/javadoc/testProfiles/pkg2/ClassException.java + test/com/sun/javadoc/testProfiles/pkgDeprecated/Class1PkgDeprecated.java + test/com/sun/javadoc/testProfiles/pkgDeprecated/package-info.java ! test/com/sun/javadoc/testProfiles/profile-rtjar-includes.txt From dan.xu at oracle.com Fri Aug 30 16:46:11 2013 From: dan.xu at oracle.com (dan.xu at oracle.com) Date: Fri, 30 Aug 2013 23:46:11 +0000 Subject: hg: jdk8/tl/jdk: 8023765: Improve MaxPathLength.java testcase and reduce its test load; ... Message-ID: <20130830234645.ED4336244F@hg.openjdk.java.net> Changeset: 5b01c851bb1d Author: dxu Date: 2013-08-30 16:45 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5b01c851bb1d 8023765: Improve MaxPathLength.java testcase and reduce its test load 7160013: java/io/File/MaxPathLength.java fails Reviewed-by: alanb ! test/ProblemList.txt ! test/java/io/File/MaxPathLength.java