From chris.hegarty at oracle.com Thu May 1 08:01:49 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 1 May 2014 09:01:49 +0100 Subject: RFR [9] 8022450: Fix deprecation warnings in UCharacterDirection.java Message-ID: <7C221E41-2CE6-40A6-BF0C-0896F05C4F05@oracle.com> 8022473 has been logged to request replacements for the deprecated UCharacterEnums, but for now the deprecated warnings from UCharacterDirection should be suppressed. diff --git a/src/share/classes/sun/net/idn/UCharacterDirection.java b/src/share/classes/sun/net/idn/UCharacterDirection.java --- a/src/share/classes/sun/net/idn/UCharacterDirection.java +++ b/src/share/classes/sun/net/idn/UCharacterDirection.java @@ -32,7 +32,8 @@ // 2005-05-19 Edward Wang // - copy this file from icu4jsrc_3_2/src/com/ibm/icu/lang/UCharacterDirection.java // - move from package com.ibm.icu.lang to package sun.net.idn -// +// 2014-05-01 Chris Hegarty +// - add class level @SuppressWarnings("deprecation") package sun.net.idn; @@ -45,7 +46,7 @@ * @author Syn Wee Quek * @stable ICU 2.1 */ - + at SuppressWarnings("deprecation") final class UCharacterDirection implements UCharacterEnums.ECharacterDirection { // private constructor ========================================= -Chris. From Alan.Bateman at oracle.com Thu May 1 08:16:27 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 01 May 2014 09:16:27 +0100 Subject: RFR [9] 8022450: Fix deprecation warnings in UCharacterDirection.java In-Reply-To: <7C221E41-2CE6-40A6-BF0C-0896F05C4F05@oracle.com> References: <7C221E41-2CE6-40A6-BF0C-0896F05C4F05@oracle.com> Message-ID: <536202DB.8040205@oracle.com> On 01/05/2014 09:01, Chris Hegarty wrote: > 8022473 has been logged to request replacements for the deprecated UCharacterEnums, but for now the deprecated warnings from UCharacterDirection should be suppressed. > > diff --git a/src/share/classes/sun/net/idn/UCharacterDirection.java b/src/share/classes/sun/net/idn/UCharacterDirection.java > --- a/src/share/classes/sun/net/idn/UCharacterDirection.java > +++ b/src/share/classes/sun/net/idn/UCharacterDirection.java > @@ -32,7 +32,8 @@ > // 2005-05-19 Edward Wang > // - copy this file from icu4jsrc_3_2/src/com/ibm/icu/lang/UCharacterDirection.java > // - move from package com.ibm.icu.lang to package sun.net.idn > -// > +// 2014-05-01 Chris Hegarty > +// - add class level @SuppressWarnings("deprecation") > > package sun.net.idn; > > @@ -45,7 +46,7 @@ > * @author Syn Wee Quek > * @stable ICU 2.1 > */ > - > + at SuppressWarnings("deprecation") > final class UCharacterDirection implements UCharacterEnums.ECharacterDirection { > > // private constructor ========================================= > > The @SuppressWarnings looks fine, I just wonder about the change log, shouldn't that be removed as it duplicates the hg logs. -Alan From chris.hegarty at oracle.com Thu May 1 08:50:37 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 1 May 2014 09:50:37 +0100 Subject: RFR [9] 8022450: Fix deprecation warnings in UCharacterDirection.java In-Reply-To: <536202DB.8040205@oracle.com> References: <7C221E41-2CE6-40A6-BF0C-0896F05C4F05@oracle.com> <536202DB.8040205@oracle.com> Message-ID: On 1 May 2014, at 09:16, Alan Bateman wrote: > On 01/05/2014 09:01, Chris Hegarty wrote: >> 8022473 has been logged to request replacements for the deprecated UCharacterEnums, but for now the deprecated warnings from UCharacterDirection should be suppressed. >> >> diff --git a/src/share/classes/sun/net/idn/UCharacterDirection.java b/src/share/classes/sun/net/idn/UCharacterDirection.java >> --- a/src/share/classes/sun/net/idn/UCharacterDirection.java >> +++ b/src/share/classes/sun/net/idn/UCharacterDirection.java >> @@ -32,7 +32,8 @@ >> // 2005-05-19 Edward Wang >> // - copy this file from icu4jsrc_3_2/src/com/ibm/icu/lang/UCharacterDirection.java >> // - move from package com.ibm.icu.lang to package sun.net.idn >> -// >> +// 2014-05-01 Chris Hegarty >> +// - add class level @SuppressWarnings("deprecation") >> package sun.net.idn; >> @@ -45,7 +46,7 @@ >> * @author Syn Wee Quek >> * @stable ICU 2.1 >> */ >> - >> + at SuppressWarnings("deprecation") >> final class UCharacterDirection implements UCharacterEnums.ECharacterDirection { >> // private constructor ========================================= >> >> > The @SuppressWarnings looks fine, I just wonder about the change log, shouldn't that be removed as it duplicates the hg logs. All the other five java sources files in this package contain a complete change log, I just added this note for consistency. Also, since there is a shared copyright on this file, I felt it safer to continue the practice of adding to the explicit change log, rather than replying on mercurial history. -Chris. > > -Alan From michael.x.mcmahon at oracle.com Fri May 9 11:46:58 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Fri, 09 May 2014 12:46:58 +0100 Subject: RFR: 8034170: Digest authentication interop issue Message-ID: <536CC032.6010200@oracle.com> Could I get the following change reviewed please for JDK 9 (same change will apply later to 8u-dev)? In JDK 8 we fixed a problem with Digest authentication where some parameters were being enclosed in double quotes incorrectly. It seems some old versions of Tomcat expect this behavior. So, the fix is to provide a flag that restores the old behavior. The (qop and algorithm parameters are affected) http://cr.openjdk.java.net/~michaelm/8034170/webrev.1/ Thanks Michael From chris.hegarty at oracle.com Fri May 9 17:18:12 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 9 May 2014 18:18:12 +0100 Subject: RFR: 8034170: Digest authentication interop issue In-Reply-To: <536CC032.6010200@oracle.com> References: <536CC032.6010200@oracle.com> Message-ID: <4DA5FE20-2312-4386-BBFE-F8A3FA2ED3A2@oracle.com> Michael, So this change adds a net/system property to revert to the old behaviour, which makes sense. And the name is in line with the other http.auth.digest.* properties. I agree with this approach. Specifically on the changes, just a few comments: 1) delimCompatFlag can be made final, by removing the default false value. 2) The test copyright header needs to be updated. Otherwise it looks ok. -Chris. On 9 May 2014, at 12:46, Michael McMahon wrote: > Could I get the following change reviewed please for JDK 9 > (same change will apply later to 8u-dev)? > > In JDK 8 we fixed a problem with Digest authentication > where some parameters were being enclosed in double quotes > incorrectly. It seems some old versions of Tomcat expect this > behavior. So, the fix is to provide a flag that restores the old > behavior. The (qop and algorithm parameters are affected) > > http://cr.openjdk.java.net/~michaelm/8034170/webrev.1/ > > Thanks > Michael From paul.sandoz at oracle.com Mon May 12 10:03:03 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 May 2014 12:03:03 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK Message-ID: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Hi, This is a request for review of Otavio's patch replacing StringBuffer with StringBuilder within OpenJDK. (I also need to review it.) It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. Jtreg tests showed no regressions, but when reviewing we need to be mindful of the context e.g. if the buffer escapes and can cross thread boundaries. This is also an experiment to see if we can review the whole thing under one bug :-) if things prove problematic and slow we can split it out. Many files are touched but there are not many changes to each file and changes are very formulaic. I have also included ASM related changes, but i suspect we may have to leave those alone since such changes will make it more difficult to pull in ASM from upstream. - Otavio, for the record can you reply to this thread posting your single ("uber") patch as textual attachment? (IIUC such attachments should now be supported by the email server). Paul. - core http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ - io http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ - management http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ - rmi http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ - security http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ - tools http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ - graphics/media http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ - asm http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ivan.gerasimov at oracle.com Mon May 12 10:37:08 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 May 2014 14:37:08 +0400 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370A454.2080402@oracle.com> Wouldn't it be a little bit more efficient to replace a string concatenation with yet another StringBuilder operation? src/share/classes/com/sun/java/util/jar/pack/BandStructure.java 631 StringBuilder sb = new StringBuilder(); ... 636 Utils.log.fine(" meta-coding "+sb); => 631 StringBuilder sb = new StringBuilder(" meta-coding "); ... 636 Utils.log.fine(sb); and 759 StringBuilder sb = new StringBuilder(); ... 764 ps.print(" //header: "+sb); => 759 StringBuilder sb = new StringBuilder(" //header: "); ... 764 ps.print(sb); Sincerely yours, Ivan On 12.05.2014 14:03, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be mindful of the context e.g. if the buffer escapes and can cross thread boundaries. > > This is also an experiment to see if we can review the whole thing under one bug :-) if things prove problematic and slow we can split it out. Many files are touched but there are not many changes to each file and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to leave those alone since such changes will make it more difficult to pull in ASM from upstream. > > - > > Otavio, for the record can you reply to this thread posting your single ("uber") patch as textual attachment? (IIUC such attachments should now be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alan.Bateman at oracle.com Mon May 12 10:42:54 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 May 2014 11:42:54 +0100 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370A5AE.4080909@oracle.com> On 12/05/2014 11:03, Paul Sandoz wrote: > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. The groupings are a bit odd but I looked through the -core, -io, -management and -rmi patches and don't see any issues. Nothing jumped out to suggest that the StringBuffer could be leaked to other threads. There are a few cases where additional work could be done but I assume you want to focus on s/StringBuffer/StringBuilder/g. You might want to hear from Remi or Kumar before including asm. I mention it because there might be preference to get changes to ASM done upstream to avoid the copy in OpenJDK from diverging. As a general point then I don't see any reason why this can't be one change-set. Periodically it makes sense to do a coarse grain split, say core + client but shouldn't be necessary here, unless of course there is some major refactoring or other big changes in, or coming soon to, jdk9/client. A coarse grain split just reduced the need for merging when sync'ing up integration forests. One minor comment is that refactoring where you change the name of the local can sometimes impact the alignment of statement that span several lines. VMID.toString is the only one that I noticed here and it's no big deal. -Alan. From paul.sandoz at oracle.com Mon May 12 10:55:13 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 May 2014 12:55:13 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370A5AE.4080909@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A5AE.4080909@oracle.com> Message-ID: <424F5797-258F-4DD8-A0FD-BFE5DFA6FC74@oracle.com> On May 12, 2014, at 12:42 PM, Alan Bateman wrote: > On 12/05/2014 11:03, Paul Sandoz wrote: >> >> It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. > The groupings are a bit odd Yeah, definitely idiosyncratic, i tried to lump 'em in terms of areas where people could focus their expertise without creating too few or too many webrevs. > but I looked through the -core, -io, -management and -rmi patches and don't see any issues. Thanks! > Nothing jumped out to suggest that the StringBuffer could be leaked to other threads. There are a few cases where additional work could be done but I assume you want to focus on s/StringBuffer/StringBuilder/g. > It might be worth fixing those if they are not too disruptive. > You might want to hear from Remi or Kumar before including asm. I mention it because there might be preference to get changes to ASM done upstream to avoid the copy in OpenJDK from diverging. > Yes. > As a general point then I don't see any reason why this can't be one change-set. Periodically it makes sense to do a coarse grain split, say core + client but shouldn't be necessary here, unless of course there is some major refactoring or other big changes in, or coming soon to, jdk9/client. A coarse grain split just reduced the need for merging when sync'ing up integration forests. > Ok. > One minor comment is that refactoring where you change the name of the local can sometimes impact the alignment of statement that span several lines. VMID.toString is the only one that I noticed here and it's no big deal. > I fixed that. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From ivan.gerasimov at oracle.com Mon May 12 11:00:04 2014 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 May 2014 15:00:04 +0400 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370A9B4.80809@oracle.com> src/share/classes/sun/misc/UUDecoder.java 126 StringBuilder x = new StringBuilder(); Is only filled, but doesn't seem to be used anyhow. Maybe just delete it? Sincerely yours, Ivan On 12.05.2014 14:03, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing > under one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each > file and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to > pull in ASM from upstream. > - > > Otavio, for the record can you reply to this thread posting your > single ("uber") patch as textual attachment? (IIUC such attachments > should now be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xuelei.fan at oracle.com Mon May 12 11:17:43 2014 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Mon, 12 May 2014 19:17:43 +0800 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370ADD7.4070208@oracle.com> > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ Looks fine to me. Thanks for making this update. Xuelei On 5/12/2014 6:03 PM, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing under > one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each file > and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to pull > in ASM from upstream. > > - > > Otavio, for the record can you reply to this thread posting your single > ("uber") patch as textual attachment? (IIUC such attachments should now > be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ From daniel.fuchs at oracle.com Mon May 12 14:07:57 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 12 May 2014 16:07:57 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> Message-ID: <5370D5BD.4030503@oracle.com> Hi Paul, I looked at -management and the changes there look good. There is just some two spaces vs four space formatting in line 99. best regards, -- daniel On 5/12/14 12:03 PM, Paul Sandoz wrote: > Hi, > > This is a request for review of Otavio's patch replacing StringBuffer > with StringBuilder within OpenJDK. (I also need to review it.) > > It covers many areas and i have grouped the patches into such areas to > aid reviewing. When commenting please including core-libs. > > Jtreg tests showed no regressions, but when reviewing we need to be > mindful of the context e.g. if the buffer escapes and can cross thread > boundaries. > > This is also an experiment to see if we can review the whole thing under > one bug :-) if things prove problematic and slow we can split it > out. Many files are touched but there are not many changes to each file > and changes are very formulaic. > > I have also included ASM related changes, but i suspect we may have to > leave those alone since such changes will make it more difficult to pull > in ASM from upstream. > - > > Otavio, for the record can you reply to this thread posting your single > ("uber") patch as textual attachment? (IIUC such attachments should now > be supported by the email server). > > Paul. > > - core > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-core/webrev/ > > - io > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-io/webrev/ > > - management > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-management/webrev/ > > - rmi > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-rmi/webrev/ > > - security > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-security/webrev/ > > > - tools > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-tools/webrev/ > > > - graphics/media > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-media/webrev/ > > > - asm > http://cr.openjdk.java.net/~psandoz/jdk9/sb/JDK-8041679-buffer-to-builder-asm/webrev/ From forax at univ-mlv.fr Mon May 12 16:43:05 2014 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 12 May 2014 18:43:05 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370A5AE.4080909@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A5AE.4080909@oracle.com> Message-ID: <5370FA19.9090107@univ-mlv.fr> On 05/12/2014 12:42 PM, Alan Bateman wrote: > On 12/05/2014 11:03, Paul Sandoz wrote: >> >> It covers many areas and i have grouped the patches into such areas >> to aid reviewing. When commenting please including core-libs. > The groupings are a bit odd but I looked through the -core, -io, > -management and -rmi patches and don't see any issues. Nothing jumped > out to suggest that the StringBuffer could be leaked to other threads. > There are a few cases where additional work could be done but I assume > you want to focus on s/StringBuffer/StringBuilder/g. > > You might want to hear from Remi or Kumar before including asm. I > mention it because there might be preference to get changes to ASM > done upstream to avoid the copy in OpenJDK from diverging. Hi all, I've applied the changes to the ASM trunk so Kumar can sync when he wants, the current revision of the trunk is 1745 cheers, R?mi From akash.delhite at gmail.com Tue May 13 03:56:59 2014 From: akash.delhite at gmail.com (Akash Jain) Date: Mon, 12 May 2014 20:56:59 -0700 Subject: DatagramSocket is not throwing socket exception In-Reply-To: References: Message-ID: Provide more details. On Tue, Apr 15, 2014 at 9:35 PM, aruna prabha wrote: > Hi All, > > I am using open JDK to build my java code and observed one of the jar > i am using uses Datagram Socket to bind to UPD port. With Java 6 i was > getting an exception when ever port is bind. But with Open JDK 7 i am > getting any exception > > can please let me know how i can resolve this issue. > > Thanks, > Aruna > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.sandoz at oracle.com Tue May 13 08:32:43 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 May 2014 10:32:43 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370A9B4.80809@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A9B4.80809@oracle.com> Message-ID: On May 12, 2014, at 1:00 PM, Ivan Gerasimov wrote: > src/share/classes/sun/misc/UUDecoder.java > 126 StringBuilder x = new StringBuilder(); > Is only filled, but doesn't seem to be used anyhow. > Maybe just delete it? > Thanks, i will take a look at this and your other change once s/StringBuffer/StringBuilder/g is out of the way. Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From paul.sandoz at oracle.com Tue May 13 08:35:18 2014 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 May 2014 10:35:18 +0200 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <5370D5BD.4030503@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370D5BD.4030503@oracle.com> Message-ID: On May 12, 2014, at 4:07 PM, Daniel Fuchs wrote: > Hi Paul, > > I looked at -management and the changes there look good. > > There is just some two spaces vs four space formatting in > > line 99. > Thanks, updated. Paul. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: Message signed with OpenPGP using GPGMail URL: From Alan.Bateman at oracle.com Tue May 13 08:45:34 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 13 May 2014 09:45:34 +0100 Subject: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK In-Reply-To: <424F5797-258F-4DD8-A0FD-BFE5DFA6FC74@oracle.com> References: <0CB20945-D7D7-4151-A546-80634F014A46@oracle.com> <5370A5AE.4080909@oracle.com> <424F5797-258F-4DD8-A0FD-BFE5DFA6FC74@oracle.com> Message-ID: <5371DBAE.8010109@oracle.com> On 12/05/2014 11:55, Paul Sandoz wrote: > On May 12, 2014, at 12:42 PM, Alan Bateman wrote: > >> On 12/05/2014 11:03, Paul Sandoz wrote: >>> It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. >> The groupings are a bit odd > Yeah, definitely idiosyncratic, i tried to lump 'em in terms of areas where people could focus their expertise without creating too few or too many webrevs. > I looked through the -tools and don't see anything escaping so looks good to me. Minor alignment issues in ExpressionParser and TokenMgrError. I also didn't see any takers for -media so I looked through those changes too. A lot of toString methods and I don't see anything obviously leaking to other threads. The s/retBuffer/sb/ in TreeModelEvent.toString is another multi-line statement, no big deal of course. Minor alignment issue in DefaultTreeSelectionModel and StandardTextSource. -Alan. From michael.x.mcmahon at oracle.com Wed May 14 10:35:01 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 14 May 2014 11:35:01 +0100 Subject: RFR: 8043118: update test/java/net/URLPermission/nstest/lookup.sh to use explicit @build target Message-ID: <537346D5.9080406@oracle.com> Could I get the following small test case change reviewed please? This fixes a sporadic test case failure due to incorrect use of @build tag in the script --- a/test/java/net/URLPermission/nstest/lookup.sh +++ b/test/java/net/URLPermission/nstest/lookup.sh @@ -26,7 +26,7 @@ # @library /lib/testlibrary # @compile -XDignore.symbol.file=true SimpleNameService.java # LookupTest.java SimpleNameServiceDescriptor.java -# @build jdk.testlibrary.* +# @build jdk.testlibrary.Utils # @run shell/timeout=50 lookup.sh # http://cr.openjdk.java.net/~michaelm/8043118/webrev.1/ Thanks Michae From Alan.Bateman at oracle.com Wed May 14 10:39:26 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 May 2014 11:39:26 +0100 Subject: RFR: 8043118: update test/java/net/URLPermission/nstest/lookup.sh to use explicit @build target In-Reply-To: <537346D5.9080406@oracle.com> References: <537346D5.9080406@oracle.com> Message-ID: <537347DE.6050508@oracle.com> On 14/05/2014 11:35, Michael McMahon wrote: > Could I get the following small test case change reviewed please? > > This fixes a sporadic test case failure due to incorrect use of @build > tag > in the script > > --- a/test/java/net/URLPermission/nstest/lookup.sh > +++ b/test/java/net/URLPermission/nstest/lookup.sh > @@ -26,7 +26,7 @@ > # @library /lib/testlibrary > # @compile -XDignore.symbol.file=true SimpleNameService.java > # LookupTest.java SimpleNameServiceDescriptor.java > -# @build jdk.testlibrary.* > +# @build jdk.testlibrary.Utils > # @run shell/timeout=50 lookup.sh > # > > http://cr.openjdk.java.net/~michaelm/8043118/webrev.1/ I think Katja changed this test very recently to use the wildcard. Is your jtreg up to date? The wildcard support is recent, b09 I think. If you are b09 then maybe there is something else doing on here. -Alan. From michael.x.mcmahon at oracle.com Wed May 14 11:11:06 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 14 May 2014 12:11:06 +0100 Subject: RFR: 8043118: update test/java/net/URLPermission/nstest/lookup.sh to use explicit @build target In-Reply-To: <537347DE.6050508@oracle.com> References: <537346D5.9080406@oracle.com> <537347DE.6050508@oracle.com> Message-ID: <53734F4A.8080402@oracle.com> On 14/05/14 11:39, Alan Bateman wrote: > On 14/05/2014 11:35, Michael McMahon wrote: >> Could I get the following small test case change reviewed please? >> >> This fixes a sporadic test case failure due to incorrect use of >> @build tag >> in the script >> >> --- a/test/java/net/URLPermission/nstest/lookup.sh >> +++ b/test/java/net/URLPermission/nstest/lookup.sh >> @@ -26,7 +26,7 @@ >> # @library /lib/testlibrary >> # @compile -XDignore.symbol.file=true SimpleNameService.java >> # LookupTest.java SimpleNameServiceDescriptor.java >> -# @build jdk.testlibrary.* >> +# @build jdk.testlibrary.Utils >> # @run shell/timeout=50 lookup.sh >> # >> >> http://cr.openjdk.java.net/~michaelm/8043118/webrev.1/ > I think Katja changed this test very recently to use the wildcard. Is > your jtreg up to date? The wildcard support is recent, b09 I think. If > you are b09 then maybe there is something else doing on here. > > -Alan. Okay. I just updated my jtreg and the test passes with the wildcard. I'm not sure why it was changed to use the wildcard, but there doesn't seem to be any point in me changing it back. Thanks, Michael From daniel.fuchs at oracle.com Wed May 14 13:20:16 2014 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 May 2014 15:20:16 +0200 Subject: RFR: 8043118: update test/java/net/URLPermission/nstest/lookup.sh to use explicit @build target In-Reply-To: <53734F4A.8080402@oracle.com> References: <537346D5.9080406@oracle.com> <537347DE.6050508@oracle.com> <53734F4A.8080402@oracle.com> Message-ID: <53736D90.2070904@oracle.com> Hi Michael, On 5/14/14 1:11 PM, Michael McMahon wrote: > On 14/05/14 11:39, Alan Bateman wrote: >> On 14/05/2014 11:35, Michael McMahon wrote: > Okay. I just updated my jtreg and the test passes with the wildcard. I'm > not sure why > it was changed to use the wildcard, but there doesn't seem to be any > point in me changing it back. I believe the issue is that you need to specify any of the library classes that might be referred to at run time on the @build command line - otherwise you risk getting a ClassNotFoundException depending on whether that class got compiled (or not) by the tests that ran before yours... So .* is more reliable. (that's my understanding - but I may be wrong) -- daniel > > Thanks, > Michael From michael.x.mcmahon at oracle.com Wed May 14 13:21:30 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 14 May 2014 14:21:30 +0100 Subject: RFR: 8043118: update test/java/net/URLPermission/nstest/lookup.sh to use explicit @build target In-Reply-To: <53736D90.2070904@oracle.com> References: <537346D5.9080406@oracle.com> <537347DE.6050508@oracle.com> <53734F4A.8080402@oracle.com> <53736D90.2070904@oracle.com> Message-ID: <53736DDA.1020601@oracle.com> On 14/05/14 14:20, Daniel Fuchs wrote: > Hi Michael, > > On 5/14/14 1:11 PM, Michael McMahon wrote: >> On 14/05/14 11:39, Alan Bateman wrote: >>> On 14/05/2014 11:35, Michael McMahon wrote: >> Okay. I just updated my jtreg and the test passes with the wildcard. I'm >> not sure why >> it was changed to use the wildcard, but there doesn't seem to be any >> point in me changing it back. > > I believe the issue is that you need to specify any of the library > classes that might be referred to at run time on the @build command > line - otherwise you risk getting a ClassNotFoundException depending > on whether that class got compiled (or not) by the tests that ran > before yours... > > So .* is more reliable. > > (that's my understanding - but I may be wrong) > No, I think that is correct. Katja explained this offline. Jtreg isn't able to work out dependencies the same way that javac does. So, you need to either explicitly list all sources to be built or provide the wildcard. My change would have worked, but given the above it's probably safer to stick with the wildcard. Thanks, Michael > -- daniel > >> >> Thanks, >> Michael > From pavel.rappo at oracle.com Tue May 27 09:40:23 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 27 May 2014 10:40:23 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound Message-ID: Hi everyone, Could you please review my change for JDK-8024832? http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ Thanks -Pavel From michael.x.mcmahon at oracle.com Tue May 27 09:49:22 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 27 May 2014 10:49:22 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: References: Message-ID: <53845FA2.7000406@oracle.com> On 27/05/14 10:40, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8024832? > > http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ > > Thanks > -Pavel Just wondering, what does ServerSocket.accept() throw in the same situation? Michael From chris.hegarty at oracle.com Tue May 27 09:56:31 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 27 May 2014 10:56:31 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: References: Message-ID: Looks good to me Pavel. I can sponsor this change for you. -Chris. On 27 May 2014, at 10:40, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8024832? > > http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ > > Thanks > -Pavel From michael.x.mcmahon at oracle.com Tue May 27 10:01:12 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 27 May 2014 11:01:12 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: References: Message-ID: <53846268.8080703@oracle.com> I think it should be throwing a SocketException rather than a NotYetBoundException to be consistent with ServerSocket.accept() Michael. On 27/05/14 10:56, Chris Hegarty wrote: > Looks good to me Pavel. I can sponsor this change for you. > > -Chris. > > On 27 May 2014, at 10:40, Pavel Rappo wrote: > >> Hi everyone, >> >> Could you please review my change for JDK-8024832? >> >> http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ >> >> Thanks >> -Pavel From Alan.Bateman at oracle.com Tue May 27 10:03:23 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 11:03:23 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: References: Message-ID: <538462EB.2050205@oracle.com> On 27/05/2014 10:40, Pavel Rappo wrote: > Hi everyone, > > Could you please review my change for JDK-8024832? > > http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ > Can you try just removing the isBound check? I ask because ssc.accept() will throw NotYetBoundException if the ServerSocketChannel is not bound and that should get mapped to the SocketException to match ServerSocket behavior. -Alan. From pavel.rappo at oracle.com Tue May 27 10:05:49 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 27 May 2014 11:05:49 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <53845FA2.7000406@oracle.com> References: <53845FA2.7000406@oracle.com> Message-ID: <1FDDA9BD-DB97-4B93-9CB7-F12F8FF6B2DE@oracle.com> Michael, java.net.ServerSocket.accept: if (!isBound()) throw new SocketException("Socket is not bound yet"); sun.nio.ch.ServerSocketAdaptor.accept will translate java.nio.channels.NotYetBoundException into an instance of SocketException with the text you see above. Basically that's what the attached test verifies. -Pavel On 27 May 2014, at 10:49, Michael McMahon wrote: > On 27/05/14 10:40, Pavel Rappo wrote: >> Hi everyone, >> >> Could you please review my change for JDK-8024832? >> >> http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ >> >> Thanks >> -Pavel > > Just wondering, what does ServerSocket.accept() throw in the same situation? > > Michael From michael.x.mcmahon at oracle.com Tue May 27 10:13:26 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 27 May 2014 11:13:26 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <1FDDA9BD-DB97-4B93-9CB7-F12F8FF6B2DE@oracle.com> References: <53845FA2.7000406@oracle.com> <1FDDA9BD-DB97-4B93-9CB7-F12F8FF6B2DE@oracle.com> Message-ID: <53846546.8000401@oracle.com> Okay, that's fine then. I didn't see the call to the translation method in the diff. Thanks, Michael. On 27/05/14 11:05, Pavel Rappo wrote: > Michael, > > java.net.ServerSocket.accept: > > if (!isBound()) > throw new SocketException("Socket is not bound yet"); > > sun.nio.ch.ServerSocketAdaptor.accept will translate java.nio.channels.NotYetBoundException into an instance of SocketException with the text you see above. Basically that's what the attached test verifies. > > -Pavel > > On 27 May 2014, at 10:49, Michael McMahon wrote: > >> On 27/05/14 10:40, Pavel Rappo wrote: >>> Hi everyone, >>> >>> Could you please review my change for JDK-8024832? >>> >>> http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ >>> >>> Thanks >>> -Pavel >> Just wondering, what does ServerSocket.accept() throw in the same situation? >> >> Michael From pavel.rappo at oracle.com Tue May 27 10:19:45 2014 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 27 May 2014 11:19:45 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <538462EB.2050205@oracle.com> References: <538462EB.2050205@oracle.com> Message-ID: <15048D49-1D85-486B-B925-D784A342E03F@oracle.com> Alan, I don't think it would be exactly the same behaviour since there's a conditional check (1) before the ssc.accept call: try { if (!ssc.isBound()) throw new NotYetBoundException(); (1) if (timeout == 0) { SocketChannel sc = ssc.accept(); if (sc == null && !ssc.isBlocking()) throw new IllegalBlockingModeException(); return sc.socket(); } (2) ssc.configureBlocking(false); try { SocketChannel sc; (3) if ((sc = ssc.accept()) != null) So if I remove this explicit check, than depending on condition (1) it can be the case that (3) will be executed after (2). And (2) can throw a bunch of different exceptions, hiding the otherwise initial NotYetBoundException. If it's not a concern I'm happy to remove this check. -Pavel On 27 May 2014, at 11:03, Alan Bateman wrote: > On 27/05/2014 10:40, Pavel Rappo wrote: >> Hi everyone, >> >> Could you please review my change for JDK-8024832? >> >> http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ >> > Can you try just removing the isBound check? I ask because ssc.accept() will throw NotYetBoundException if the ServerSocketChannel is not bound and that should get mapped to the SocketException to match ServerSocket behavior. > > -Alan. From Alan.Bateman at oracle.com Tue May 27 13:12:41 2014 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 27 May 2014 14:12:41 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <15048D49-1D85-486B-B925-D784A342E03F@oracle.com> References: <538462EB.2050205@oracle.com> <15048D49-1D85-486B-B925-D784A342E03F@oracle.com> Message-ID: <53848F49.7050809@oracle.com> On 27/05/2014 11:19, Pavel Rappo wrote: > Alan, > > I don't think it would be exactly the same behaviour since there's a conditional check (1) before the ssc.accept call: > > try { > if (!ssc.isBound()) > throw new NotYetBoundException(); > (1) if (timeout == 0) { > SocketChannel sc = ssc.accept(); > if (sc == null && !ssc.isBlocking()) > throw new IllegalBlockingModeException(); > return sc.socket(); > } > > (2) ssc.configureBlocking(false); > try { > SocketChannel sc; > (3) if ((sc = ssc.accept()) != null) > > So if I remove this explicit check, than depending on condition (1) it can be the case that (3) will be executed after (2). And (2) can throw a bunch of different exceptions, hiding the otherwise initial NotYetBoundException. > > If it's not a concern I'm happy to remove this check. > For the no-timeout case then it would be the same. For the timeout case it it just means that the channel might be changed to non-blocking before the exception is thrown. I don't think this is a problem as it will be restored anyway. What you have is fine, I think just removing is fine too. -Alan. From mark.reinhold at oracle.com Tue May 27 14:56:39 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 27 May 2014 07:56:39 -0700 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <53846268.8080703@oracle.com> References: , , <53846268.8080703@oracle.com> Message-ID: <20140527075639.259515@eggemoggin.niobe.net> 2014/5/26 20:01 -0700, michael.x.mcmahon at oracle.com: > I think it should be throwing a SocketException rather than a > NotYetBoundException to be consistent with ServerSocket.accept() No, NotYetBoundException is the correct exception here. The NIO exception hierarchy was intentionally designed to be richer than just "SocketException". Consistency with the exceptions thrown by the original java.net APIs is an anti-goal. - Mark From michael.x.mcmahon at oracle.com Tue May 27 15:10:12 2014 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Tue, 27 May 2014 16:10:12 +0100 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <20140527075639.259515@eggemoggin.niobe.net> References: , , <53846268.8080703@oracle.com> <20140527075639.259515@eggemoggin.niobe.net> Message-ID: <5384AAD4.5070104@oracle.com> On 27/05/14 15:56, mark.reinhold at oracle.com wrote: > 2014/5/26 20:01 -0700, michael.x.mcmahon at oracle.com: >> I think it should be throwing a SocketException rather than a >> NotYetBoundException to be consistent with ServerSocket.accept() > No, NotYetBoundException is the correct exception here. The NIO > exception hierarchy was intentionally designed to be richer than > just "SocketException". Consistency with the exceptions thrown > by the original java.net APIs is an anti-goal. > > - Mark Hi Mark, The point was clarified on a separate conversation on net-dev. The method in question refers to the channel's server socket adapter (ie an instance of java.net.ServerSocket) rather than the channel itself. What I overlooked was that the exception is being caught correctly and converted to the right exception expected by ServerSocket. Michael. From mark.reinhold at oracle.com Tue May 27 15:28:09 2014 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Tue, 27 May 2014 08:28:09 -0700 Subject: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound In-Reply-To: <5384AAD4.5070104@oracle.com> References: , <20140527075639.259515@eggemoggin.niobe.net>, <5384AAD4.5070104@oracle.com> Message-ID: <20140527082809.219902@eggemoggin.niobe.net> 2014/5/27 1:10 -0700, michael.x.mcmahon at oracle.com: > On 27/05/14 15:56, mark.reinhold at oracle.com wrote: >> 2014/5/26 20:01 -0700, michael.x.mcmahon at oracle.com: >>> I think it should be throwing a SocketException rather than a >>> NotYetBoundException to be consistent with ServerSocket.accept() >> No, NotYetBoundException is the correct exception here. The NIO >> exception hierarchy was intentionally designed to be richer than >> just "SocketException". Consistency with the exceptions thrown >> by the original java.net APIs is an anti-goal. > > The point was clarified on a separate conversation on net-dev. > The method in question refers to the channel's server socket adapter > (ie an instance of java.net.ServerSocket) rather than the channel itself. Ah, okay then -- I didn't realize that from the available context. - Mark From mark.sheppard at oracle.com Wed May 28 13:49:06 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Wed, 28 May 2014 14:49:06 +0100 Subject: RFR: 8044029 - JNI exception pending checks in java.net Message-ID: <5385E952.5080806@oracle.com> Hi, please oblige and review the following fix http://cr.openjdk.java.net/~msheppar/8044029/webrev/ for the issue https://bugs.openjdk.java.net/browse/JDK-8044029 which is a backport of https://bugs.openjdk.java.net/browse/JDK-8025293 the changeset didn't appear to apply cleanly, necessitating its application by hand regards Mark From chris.hegarty at oracle.com Wed May 28 15:26:50 2014 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 28 May 2014 16:26:50 +0100 Subject: RFR: 8044029 - JNI exception pending checks in java.net In-Reply-To: <5385E952.5080806@oracle.com> References: <5385E952.5080806@oracle.com> Message-ID: <5386003A.2070400@oracle.com> This looks ok to me Mark. Reviewed. -Chris. On 28/05/14 14:49, Mark Sheppard wrote: > Hi, > please oblige and review the following fix > http://cr.openjdk.java.net/~msheppar/8044029/webrev/ > > for the issue > https://bugs.openjdk.java.net/browse/JDK-8044029 > > which is a backport of > https://bugs.openjdk.java.net/browse/JDK-8025293 > > the changeset didn't appear to apply cleanly, necessitating its > application by hand > > regards > Mark From mark.sheppard at oracle.com Sat May 31 09:04:37 2014 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Sat, 31 May 2014 10:04:37 +0100 Subject: RFR: 8041609 - Check jdk/src/windows/native/java/io/WinNTFileSystem_md.c for JNI pending exceptions Message-ID: <53899B25.8070701@oracle.com> Hi please oblige review and approve the backport to jdk8u-dev, after the review of the following change http://cr.openjdk.java.net/~msheppar/8041609/webrev/ for the issue https://bugs.openjdk.java.net/browse/JDK-8041609 which is a backport of https://bugs.openjdk.java.net/browse/JDK-8035870 the hg import of changeset http://hg.openjdk.java.net/jdk9/dev/jdk/rev/56366827ebab didn't apply cleanly so was manually the regression test run was fine regards Mark