From kzr at jp.fujitsu.com Wed Jun 8 00:51:15 2016 From: kzr at jp.fujitsu.com (Kenji Kazumura) Date: Wed, 08 Jun 2016 09:51:15 +0900 (JST) Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: References: Message-ID: <20160608.095115.312676195.kzr@jp.fujitsu.com> Christoph, You should not remove conversion codes (platform string to Java String) at JNU_ThrowByNameWithLastError, and you have to add conversion codes at JNU_ThrowByNameWithMessageAndLastError. It seems that you assume strerror returns only ascii characters, but actually not. It depends on the locale of your environment where java programs runs. -Kenji Kazumura In message RFR 8158023: SocketExceptions contain too little information sometimes "Langer, Christoph" wrote: > Hi all, > > please review the following change: > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 > > During error analysis I stumbled over a place where I encountered a SocketException which was thrown along with some strerror information as message. I found it hard to find the originating code spot with that information. > > So I looked at the places where we throw exceptions, namely JNU_Throw... and NET_Throw... functions and came up with the following enhancement: > - NET_ThrowByNameWithLastError can go completely as it does not provide any benefit over JNU_ThrowByNameWithLastError. > - JNU_ThrowByNameWithLastError can be cleaned up. > > - I added JNU_ThrowByNameWithMessageAndLastError to print out a string like message + ": " + last error. > > - I went over all places where NET_ThrowByNameWithLastError is used and replaced it appropriately. > > Do you think this change is desirable/possible? > > Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as well as JNU_Throw... code affects all. > > Best regards > Christoph > From christoph.langer at sap.com Wed Jun 8 09:02:58 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 8 Jun 2016 09:02:58 +0000 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: <20160608.095115.312676195.kzr@jp.fujitsu.com> References: <20160608.095115.312676195.kzr@jp.fujitsu.com> Message-ID: <0daf6ca841fe4c03b9bb7a813b216498@DEWDFE13DE11.global.corp.sap> Hi Kenji, thanks for this very good point. I thought that JNU_ThrowByNameWithLastError just tries to throw the exception manually and if that fails it calls JNU_ThrowByName which basically does the same. But I missed the point that it does the conversion and tries JNU_ThrowByName only as fallback. So I'll revert/correct that. But now I think there are other places in the JDK which potentially miss a conversion of strerror result when they go through JNU_ThrowIOException for instance. I'll check that. Please note that the current thread of discussion of my change is this one: http://mail.openjdk.java.net/pipermail/net-dev/2016-June/009880.html There is an updated webrev but it obviously still contains this mistake. Thanks Christoph > -----Original Message----- > From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] > Sent: Mittwoch, 8. Juni 2016 02:51 > To: Langer, Christoph > Cc: net-dev at openjdk.java.net; nio-dev at openjdk.java.net; core-libs- > dev at openjdk.java.net > Subject: Re: RFR 8158023: SocketExceptions contain too little information > sometimes > > Christoph, > > You should not remove conversion codes (platform string to Java String) > at JNU_ThrowByNameWithLastError, > and you have to add conversion codes at > JNU_ThrowByNameWithMessageAndLastError. > > It seems that you assume strerror returns only ascii characters, but actually > not. > It depends on the locale of your environment where java programs runs. > > > -Kenji Kazumura > > > In message > > RFR 8158023: SocketExceptions contain too little information sometimes > "Langer, Christoph" wrote: > > > Hi all, > > > > please review the following change: > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 > > > > During error analysis I stumbled over a place where I encountered a > SocketException which was thrown along with some strerror information as > message. I found it hard to find the originating code spot with that information. > > > > So I looked at the places where we throw exceptions, namely JNU_Throw... > and NET_Throw... functions and came up with the following enhancement: > > - NET_ThrowByNameWithLastError can go completely as it does not provide > any benefit over JNU_ThrowByNameWithLastError. > > - JNU_ThrowByNameWithLastError can be cleaned up. > > > > - I added JNU_ThrowByNameWithMessageAndLastError to print out a string > like message + ": " + last error. > > > > - I went over all places where NET_ThrowByNameWithLastError is used and > replaced it appropriately. > > > > Do you think this change is desirable/possible? > > > > Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as > well as JNU_Throw... code affects all. > > > > Best regards > > Christoph > > From chris.hegarty at oracle.com Thu Jun 16 15:03:33 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 Jun 2016 16:03:33 +0100 Subject: RFR [9] 8157166: Update spec to account for platforms that do not support multicast Message-ID: <8E77BA75-21E8-4432-8327-7AF5E562FD77@oracle.com> Some platforms do not support multicasting, but the current spec requires that it is supported. It seems reasonable to relax this, somewhat, so that multicasting is effectively optional on these platforms. java.net.MulticastSocket.joinGroup and java.nio.channels.MulticastChannel.join method specifications should be updated to indicate that an exception will be thrown if invoked on a platform that does not support multicasting. http://cr.openjdk.java.net/~chegar/8157166/ https://bugs.openjdk.java.net/browse/JDK-8157166 -Chris. From Alan.Bateman at oracle.com Thu Jun 16 15:31:26 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jun 2016 16:31:26 +0100 Subject: RFR [9] 8157166: Update spec to account for platforms that do not support multicast In-Reply-To: <8E77BA75-21E8-4432-8327-7AF5E562FD77@oracle.com> References: <8E77BA75-21E8-4432-8327-7AF5E562FD77@oracle.com> Message-ID: <15fea9e8-5154-c9f5-2519-5078a2c2ce95@oracle.com> On 16/06/2016 16:03, Chris Hegarty wrote: > Some platforms do not support multicasting, but the current spec requires that > it is supported. It seems reasonable to relax this, somewhat, so that multicasting > is effectively optional on these platforms. > > java.net.MulticastSocket.joinGroup and java.nio.channels.MulticastChannel.join > method specifications should be updated to indicate that an exception will be > thrown if invoked on a platform that does not support multicasting. > > http://cr.openjdk.java.net/~chegar/8157166/ > https://bugs.openjdk.java.net/browse/JDK-8157166 > This looks okay. For MultlicastChannel then "When IGMPv2 is supported then it may" might be clearer as " When IGMPv2 is supported then the operating system may". -Alan From chris.hegarty at oracle.com Thu Jun 16 15:38:17 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 16 Jun 2016 16:38:17 +0100 Subject: RFR [9] 8157166: Update spec to account for platforms that do not support multicast In-Reply-To: <15fea9e8-5154-c9f5-2519-5078a2c2ce95@oracle.com> References: <8E77BA75-21E8-4432-8327-7AF5E562FD77@oracle.com> <15fea9e8-5154-c9f5-2519-5078a2c2ce95@oracle.com> Message-ID: <87BE52C9-8F36-436D-B797-D8828C23B622@oracle.com> > On 16 Jun 2016, at 16:31, Alan Bateman wrote: > > On 16/06/2016 16:03, Chris Hegarty wrote: > >> Some platforms do not support multicasting, but the current spec requires that >> it is supported. It seems reasonable to relax this, somewhat, so that multicasting >> is effectively optional on these platforms. >> >> java.net.MulticastSocket.joinGroup and java.nio.channels.MulticastChannel.join >> method specifications should be updated to indicate that an exception will be >> thrown if invoked on a platform that does not support multicasting. >> >> http://cr.openjdk.java.net/~chegar/8157166/ >> https://bugs.openjdk.java.net/browse/JDK-8157166 >> > This looks okay. For MultlicastChannel then "When IGMPv2 is supported then it may" might be clearer as " When IGMPv2 is supported then the operating system may". Yes, that is better. Webrev updated in-place. -Chris. From Alan.Bateman at oracle.com Thu Jun 16 15:40:23 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 16 Jun 2016 16:40:23 +0100 Subject: RFR [9] 8157166: Update spec to account for platforms that do not support multicast In-Reply-To: <87BE52C9-8F36-436D-B797-D8828C23B622@oracle.com> References: <8E77BA75-21E8-4432-8327-7AF5E562FD77@oracle.com> <15fea9e8-5154-c9f5-2519-5078a2c2ce95@oracle.com> <87BE52C9-8F36-436D-B797-D8828C23B622@oracle.com> Message-ID: On 16/06/2016 16:38, Chris Hegarty wrote: >> On 16 Jun 2016, at 16:31, Alan Bateman wrote: >> >> On 16/06/2016 16:03, Chris Hegarty wrote: >> >>> Some platforms do not support multicasting, but the current spec requires that >>> it is supported. It seems reasonable to relax this, somewhat, so that multicasting >>> is effectively optional on these platforms. >>> >>> java.net.MulticastSocket.joinGroup and java.nio.channels.MulticastChannel.join >>> method specifications should be updated to indicate that an exception will be >>> thrown if invoked on a platform that does not support multicasting. >>> >>> http://cr.openjdk.java.net/~chegar/8157166/ >>> https://bugs.openjdk.java.net/browse/JDK-8157166 >>> >> This looks okay. For MultlicastChannel then "When IGMPv2 is supported then it may" might be clearer as " When IGMPv2 is supported then the operating system may". > Yes, that is better. Webrev updated in-place. > Looks good. From Alan.Bateman at oracle.com Fri Jun 17 09:59:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jun 2016 10:59:33 +0100 Subject: 8140449: (fs) Paths.get("x").relativize("") return ..\ on Windows Message-ID: <5b846281-6cd6-7e85-5e4e-2b1269086f66@oracle.com> This issue relates to two corner cases on Windows that result in a leading slash. One is Paths.get("C:").toAbsolutePath(), the other is Paths.get("x").relativize(""). The changes are simple and I've expanded the test coverage to cover more cases. There is further work requires on relativize but that is for another issue. The proposed changes are here: http://cr.openjdk.java.net/~alanb/8140449/webrev/ Thanks, Alan From chris.hegarty at oracle.com Fri Jun 17 14:55:45 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 17 Jun 2016 15:55:45 +0100 Subject: 8140449: (fs) Paths.get("x").relativize("") return ..\ on Windows In-Reply-To: <5b846281-6cd6-7e85-5e4e-2b1269086f66@oracle.com> References: <5b846281-6cd6-7e85-5e4e-2b1269086f66@oracle.com> Message-ID: <57640F71.6010804@oracle.com> On 17/06/16 10:59, Alan Bateman wrote: > > This issue relates to two corner cases on Windows that result in a > leading slash. One is Paths.get("C:").toAbsolutePath(), the other is > Paths.get("x").relativize(""). The changes are simple and I've expanded > the test coverage to cover more cases. There is further work requires on > relativize but that is for another issue. The proposed changes are here: > > http://cr.openjdk.java.net/~alanb/8140449/webrev/ This looks fine Alan. -Chris. From Roger.Riggs at Oracle.com Fri Jun 17 14:58:30 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 17 Jun 2016 10:58:30 -0400 Subject: 8140449: (fs) Paths.get("x").relativize("") return ..\ on Windows In-Reply-To: <5b846281-6cd6-7e85-5e4e-2b1269086f66@oracle.com> References: <5b846281-6cd6-7e85-5e4e-2b1269086f66@oracle.com> Message-ID: <161ddcaa-489d-d833-b97e-fd74a7ebcfc1@Oracle.com> HI Alan, Looks ok, Roger On 6/17/2016 5:59 AM, Alan Bateman wrote: > > This issue relates to two corner cases on Windows that result in a > leading slash. One is Paths.get("C:").toAbsolutePath(), the other is > Paths.get("x").relativize(""). The changes are simple and I've > expanded the test coverage to cover more cases. There is further work > requires on relativize but that is for another issue. The proposed > changes are here: > > http://cr.openjdk.java.net/~alanb/8140449/webrev/ > > Thanks, > > Alan > From weijun.wang at oracle.com Fri Jun 17 15:02:13 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 17 Jun 2016 23:02:13 +0800 Subject: 8140449: (fs) Paths.get("x").relativize("") return ..\ on Windows In-Reply-To: <5b846281-6cd6-7e85-5e4e-2b1269086f66@oracle.com> References: <5b846281-6cd6-7e85-5e4e-2b1269086f66@oracle.com> Message-ID: <6CCDC521-475C-478F-A2E1-43A35AB2E6A7@oracle.com> 246 if (remaining.length() == 0) { 247 return defaultDirectory; What is defaultDirectory ends with \ above? Shall we remove it? 248 } else if (defaultDirectory.endsWith("\\")) { 249 return defaultDirectory + remaining; 250 } else { 251 return defaultDirectory + "\\" + remaining; 252 } --Max > On Jun 17, 2016, at 5:59 PM, Alan Bateman wrote: > > > This issue relates to two corner cases on Windows that result in a leading slash. One is Paths.get("C:").toAbsolutePath(), the other is Paths.get("x").relativize(""). The changes are simple and I've expanded the test coverage to cover more cases. There is further work requires on relativize but that is for another issue. The proposed changes are here: > > http://cr.openjdk.java.net/~alanb/8140449/webrev/ > > Thanks, > > Alan > From Alan.Bateman at oracle.com Fri Jun 17 15:28:47 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 17 Jun 2016 16:28:47 +0100 Subject: 8140449: (fs) Paths.get("x").relativize("") return ..\ on Windows In-Reply-To: <6CCDC521-475C-478F-A2E1-43A35AB2E6A7@oracle.com> References: <5b846281-6cd6-7e85-5e4e-2b1269086f66@oracle.com> <6CCDC521-475C-478F-A2E1-43A35AB2E6A7@oracle.com> Message-ID: On 17/06/2016 16:02, Wang Weijun wrote: > 246 if (remaining.length() == 0) { > 247 return defaultDirectory; > > What is defaultDirectory ends with \ above? Shall we remove it? > It will have a trailing slash when the default directory is the root directory (C:\) but that is okay. -Alan. From christoph.langer at sap.com Mon Jun 27 07:42:17 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 Jun 2016 07:42:17 +0000 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: <20160608.095115.312676195.kzr@jp.fujitsu.com> References: <20160608.095115.312676195.kzr@jp.fujitsu.com> Message-ID: <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> Hi, eventually here is the - hopefully final - version of this fix: http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ Now I leave JNU_ThrowByNameWithLastError untouched and I've also added conversion to the new function JNU_ThrowByNameWithMessageAndLastError. I've replaced JNU_ThrowByNameWithLastError with JNU_ThrowByNameWithMessageAndLastError in the java/net coding where I think it is appropriate (mostly in occasions when a SocketException is thrown kind of generically). @Paul: thanks for your suggestion regarding the output format but I would still prefer an output like "java.net.SocketException: ioctl SIOCGSIZIFCONF failed: Bad file number" vs. " java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF failed)" as I'm always handing down a message to the new throw routine. Hoping for a review :) Best regards Christoph > -----Original Message----- > From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] > Sent: Mittwoch, 8. Juni 2016 02:51 > To: Langer, Christoph > Cc: net-dev at openjdk.java.net; nio-dev at openjdk.java.net; core-libs- > dev at openjdk.java.net > Subject: Re: RFR 8158023: SocketExceptions contain too little information > sometimes > > Christoph, > > You should not remove conversion codes (platform string to Java String) > at JNU_ThrowByNameWithLastError, > and you have to add conversion codes at > JNU_ThrowByNameWithMessageAndLastError. > > It seems that you assume strerror returns only ascii characters, but actually > not. > It depends on the locale of your environment where java programs runs. > > > -Kenji Kazumura > > > In message > > RFR 8158023: SocketExceptions contain too little information sometimes > "Langer, Christoph" wrote: > > > Hi all, > > > > please review the following change: > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 > > > > During error analysis I stumbled over a place where I encountered a > SocketException which was thrown along with some strerror information as > message. I found it hard to find the originating code spot with that information. > > > > So I looked at the places where we throw exceptions, namely JNU_Throw... > and NET_Throw... functions and came up with the following enhancement: > > - NET_ThrowByNameWithLastError can go completely as it does not provide > any benefit over JNU_ThrowByNameWithLastError. > > - JNU_ThrowByNameWithLastError can be cleaned up. > > > > - I added JNU_ThrowByNameWithMessageAndLastError to print out a string > like message + ": " + last error. > > > > - I went over all places where NET_ThrowByNameWithLastError is used and > replaced it appropriately. > > > > Do you think this change is desirable/possible? > > > > Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as > well as JNU_Throw... code affects all. > > > > Best regards > > Christoph > > From mark.sheppard at oracle.com Mon Jun 27 12:44:48 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 27 Jun 2016 13:44:48 +0100 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> References: <20160608.095115.312676195.kzr@jp.fujitsu.com> <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> Message-ID: <0ce3711e-d121-37c4-c600-2d47e7305083@oracle.com> Hi, wrt JNU_ThrowByNameWithMessaheAndLastError, it would appear that it doesn't allow for malloc to fail and hence str1 could be null and a problematic input to jio_snprintf which could result in a de-referencing of zero. in the call flow would it not be more appropriate to manipulate native buffers first to produce the desired error string and then allocate the java string object? c.f. src/java.base/unic/native/libnet/net_util_md.c NET_ThrowUnknownHostExceptionWithGaiError should you allow for getLastErrorString not to return an error string or return an error result? as in JNU_ThrowByNameWithLastError regards Mark On 27/06/2016 08:42, Langer, Christoph wrote: > Hi, > > eventually here is the - hopefully final - version of this fix: > http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ > > Now I leave JNU_ThrowByNameWithLastError untouched and I've also added conversion to the new function JNU_ThrowByNameWithMessageAndLastError. I've replaced JNU_ThrowByNameWithLastError with JNU_ThrowByNameWithMessageAndLastError in the java/net coding where I think it is appropriate (mostly in occasions when a SocketException is thrown kind of generically). @Paul: thanks for your suggestion regarding the output format but I would still prefer an output like "java.net.SocketException: ioctl SIOCGSIZIFCONF failed: Bad file number" vs. " java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF failed)" as I'm always handing down a message to the new throw routine. > > Hoping for a review :) > > Best regards > Christoph > >> -----Original Message----- >> From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] >> Sent: Mittwoch, 8. Juni 2016 02:51 >> To: Langer, Christoph >> Cc: net-dev at openjdk.java.net; nio-dev at openjdk.java.net; core-libs- >> dev at openjdk.java.net >> Subject: Re: RFR 8158023: SocketExceptions contain too little information >> sometimes >> >> Christoph, >> >> You should not remove conversion codes (platform string to Java String) >> at JNU_ThrowByNameWithLastError, >> and you have to add conversion codes at >> JNU_ThrowByNameWithMessageAndLastError. >> >> It seems that you assume strerror returns only ascii characters, but actually >> not. >> It depends on the locale of your environment where java programs runs. >> >> >> -Kenji Kazumura >> >> >> In message >> >> RFR 8158023: SocketExceptions contain too little information sometimes >> "Langer, Christoph" wrote: >> >>> Hi all, >>> >>> please review the following change: >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 >>> >>> During error analysis I stumbled over a place where I encountered a >> SocketException which was thrown along with some strerror information as >> message. I found it hard to find the originating code spot with that information. >>> So I looked at the places where we throw exceptions, namely JNU_Throw... >> and NET_Throw... functions and came up with the following enhancement: >>> - NET_ThrowByNameWithLastError can go completely as it does not provide >> any benefit over JNU_ThrowByNameWithLastError. >>> - JNU_ThrowByNameWithLastError can be cleaned up. >>> >>> - I added JNU_ThrowByNameWithMessageAndLastError to print out a string >> like message + ": " + last error. >>> - I went over all places where NET_ThrowByNameWithLastError is used and >> replaced it appropriately. >>> Do you think this change is desirable/possible? >>> >>> Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as >> well as JNU_Throw... code affects all. >>> Best regards >>> Christoph >>> From christoph.langer at sap.com Mon Jun 27 13:28:16 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 27 Jun 2016 13:28:16 +0000 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: <0ce3711e-d121-37c4-c600-2d47e7305083@oracle.com> References: <20160608.095115.312676195.kzr@jp.fujitsu.com> <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> <0ce3711e-d121-37c4-c600-2d47e7305083@oracle.com> Message-ID: <3cc4feda40aa45ccbb6d142aabe9ef61@DEWDFE13DE11.global.corp.sap> Hi Mark, thanks for looking at this. Please see my comments inline. > wrt JNU_ThrowByNameWithMessaheAndLastError, it would appear that it > doesn't allow for malloc to fail and hence > str1 could be null and a problematic input to jio_snprintf which could > result in a de-referencing of zero. You are right, thanks. I should check for null and return "OutOfMemory" appropriately. I fixed that and updated the webrev in place. > in the call flow would it not be more appropriate to manipulate native > buffers first to produce the desired error string and > then allocate the java string object? > c.f. src/java.base/unic/native/libnet/net_util_md.c > NET_ThrowUnknownHostExceptionWithGaiError Well, in the case of NET_ThrowUnknownHostExceptionWithGaiError you will probably have the hostname as well as the error text encoded in platform encoding. So for that it is perfectly fine to do the native buffers first and then convert to a Java String. But in my case for JNU_ThrowByNameWithMessageAndLastError, the errno text will be in platform encoding but the other message and formatting will be UTF-8 strings from the executable. So I have to handle both parts differently when creating a String object out of it. Or am I wrong in my assumption here? > should you allow for getLastErrorString not to return an error string or > return an error result? > as in JNU_ThrowByNameWithLastError I do, don't I? I'm checking the return value of getLastErrorString: "if (n > 0)". Best regards Christoph > > On 27/06/2016 08:42, Langer, Christoph wrote: > > Hi, > > > > eventually here is the - hopefully final - version of this fix: > > http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ > > > > Now I leave JNU_ThrowByNameWithLastError untouched and I've also added > conversion to the new function JNU_ThrowByNameWithMessageAndLastError. > I've replaced JNU_ThrowByNameWithLastError with > JNU_ThrowByNameWithMessageAndLastError in the java/net coding where I > think it is appropriate (mostly in occasions when a SocketException is thrown > kind of generically). @Paul: thanks for your suggestion regarding the output > format but I would still prefer an output like "java.net.SocketException: ioctl > SIOCGSIZIFCONF failed: Bad file number" vs. " java.net.SocketException: Bad > file number (ioctl SIOCGSIZIFCONF failed)" as I'm always handing down a > message to the new throw routine. > > > > Hoping for a review :) > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] > >> Sent: Mittwoch, 8. Juni 2016 02:51 > >> To: Langer, Christoph > >> Cc: net-dev at openjdk.java.net; nio-dev at openjdk.java.net; core-libs- > >> dev at openjdk.java.net > >> Subject: Re: RFR 8158023: SocketExceptions contain too little information > >> sometimes > >> > >> Christoph, > >> > >> You should not remove conversion codes (platform string to Java String) > >> at JNU_ThrowByNameWithLastError, > >> and you have to add conversion codes at > >> JNU_ThrowByNameWithMessageAndLastError. > >> > >> It seems that you assume strerror returns only ascii characters, but actually > >> not. > >> It depends on the locale of your environment where java programs runs. > >> > >> > >> -Kenji Kazumura > >> > >> > >> In message > >> > >> RFR 8158023: SocketExceptions contain too little information sometimes > >> "Langer, Christoph" wrote: > >> > >>> Hi all, > >>> > >>> please review the following change: > >>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ > >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 > >>> > >>> During error analysis I stumbled over a place where I encountered a > >> SocketException which was thrown along with some strerror information as > >> message. I found it hard to find the originating code spot with that > information. > >>> So I looked at the places where we throw exceptions, namely JNU_Throw... > >> and NET_Throw... functions and came up with the following enhancement: > >>> - NET_ThrowByNameWithLastError can go completely as it does not > provide > >> any benefit over JNU_ThrowByNameWithLastError. > >>> - JNU_ThrowByNameWithLastError can be cleaned up. > >>> > >>> - I added JNU_ThrowByNameWithMessageAndLastError to print out a > string > >> like message + ": " + last error. > >>> - I went over all places where NET_ThrowByNameWithLastError is used > and > >> replaced it appropriately. > >>> Do you think this change is desirable/possible? > >>> > >>> Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as > >> well as JNU_Throw... code affects all. > >>> Best regards > >>> Christoph > >>> From mark.sheppard at oracle.com Mon Jun 27 13:48:07 2016 From: mark.sheppard at oracle.com (Mark Sheppard) Date: Mon, 27 Jun 2016 14:48:07 +0100 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: <3cc4feda40aa45ccbb6d142aabe9ef61@DEWDFE13DE11.global.corp.sap> References: <20160608.095115.312676195.kzr@jp.fujitsu.com> <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> <0ce3711e-d121-37c4-c600-2d47e7305083@oracle.com> <3cc4feda40aa45ccbb6d142aabe9ef61@DEWDFE13DE11.global.corp.sap> Message-ID: <7afe2f6a-f3b6-a756-ba88-8a1641bb91ba@oracle.com> Hi Christoph, thanks for the response ... yes, you do check the getLastErrorString return ... sorry about that! regards Mark On 27/06/2016 14:28, Langer, Christoph wrote: > Hi Mark, > > thanks for looking at this. Please see my comments inline. > >> wrt JNU_ThrowByNameWithMessaheAndLastError, it would appear that it >> doesn't allow for malloc to fail and hence >> str1 could be null and a problematic input to jio_snprintf which could >> result in a de-referencing of zero. > You are right, thanks. I should check for null and return "OutOfMemory" appropriately. I fixed that and updated the webrev in place. > >> in the call flow would it not be more appropriate to manipulate native >> buffers first to produce the desired error string and >> then allocate the java string object? >> c.f. src/java.base/unic/native/libnet/net_util_md.c >> NET_ThrowUnknownHostExceptionWithGaiError > Well, in the case of NET_ThrowUnknownHostExceptionWithGaiError you will probably have the hostname as well as the error text encoded in platform encoding. So for that it is perfectly fine to do the native buffers first and then convert to a Java String. But in my case for JNU_ThrowByNameWithMessageAndLastError, the errno text will be in platform encoding but the other message and formatting will be UTF-8 strings from the executable. So I have to handle both parts differently when creating a String object out of it. Or am I wrong in my assumption here? > >> should you allow for getLastErrorString not to return an error string or >> return an error result? >> as in JNU_ThrowByNameWithLastError > I do, don't I? I'm checking the return value of getLastErrorString: "if (n > 0)". > > Best regards > Christoph > >> On 27/06/2016 08:42, Langer, Christoph wrote: >>> Hi, >>> >>> eventually here is the - hopefully final - version of this fix: >>> http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ >>> >>> Now I leave JNU_ThrowByNameWithLastError untouched and I've also added >> conversion to the new function JNU_ThrowByNameWithMessageAndLastError. >> I've replaced JNU_ThrowByNameWithLastError with >> JNU_ThrowByNameWithMessageAndLastError in the java/net coding where I >> think it is appropriate (mostly in occasions when a SocketException is thrown >> kind of generically). @Paul: thanks for your suggestion regarding the output >> format but I would still prefer an output like "java.net.SocketException: ioctl >> SIOCGSIZIFCONF failed: Bad file number" vs. " java.net.SocketException: Bad >> file number (ioctl SIOCGSIZIFCONF failed)" as I'm always handing down a >> message to the new throw routine. >>> Hoping for a review :) >>> >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] >>>> Sent: Mittwoch, 8. Juni 2016 02:51 >>>> To: Langer, Christoph >>>> Cc: net-dev at openjdk.java.net; nio-dev at openjdk.java.net; core-libs- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR 8158023: SocketExceptions contain too little information >>>> sometimes >>>> >>>> Christoph, >>>> >>>> You should not remove conversion codes (platform string to Java String) >>>> at JNU_ThrowByNameWithLastError, >>>> and you have to add conversion codes at >>>> JNU_ThrowByNameWithMessageAndLastError. >>>> >>>> It seems that you assume strerror returns only ascii characters, but actually >>>> not. >>>> It depends on the locale of your environment where java programs runs. >>>> >>>> >>>> -Kenji Kazumura >>>> >>>> >>>> In message >>>> >>>> RFR 8158023: SocketExceptions contain too little information sometimes >>>> "Langer, Christoph" wrote: >>>> >>>>> Hi all, >>>>> >>>>> please review the following change: >>>>> Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 >>>>> >>>>> During error analysis I stumbled over a place where I encountered a >>>> SocketException which was thrown along with some strerror information as >>>> message. I found it hard to find the originating code spot with that >> information. >>>>> So I looked at the places where we throw exceptions, namely JNU_Throw... >>>> and NET_Throw... functions and came up with the following enhancement: >>>>> - NET_ThrowByNameWithLastError can go completely as it does not >> provide >>>> any benefit over JNU_ThrowByNameWithLastError. >>>>> - JNU_ThrowByNameWithLastError can be cleaned up. >>>>> >>>>> - I added JNU_ThrowByNameWithMessageAndLastError to print out a >> string >>>> like message + ": " + last error. >>>>> - I went over all places where NET_ThrowByNameWithLastError is used >> and >>>> replaced it appropriately. >>>>> Do you think this change is desirable/possible? >>>>> >>>>> Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as >>>> well as JNU_Throw... code affects all. >>>>> Best regards >>>>> Christoph >>>>> From christoph.langer at sap.com Tue Jun 28 20:45:29 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 28 Jun 2016 20:45:29 +0000 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: References: <20160608.095115.312676195.kzr@jp.fujitsu.com> <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> Message-ID: <35fd36320f0a4c5b82302525d4e859e9@DEWDFE13DE11.global.corp.sap> Hi Paul, Ok, you kind of got me convinced and it is also a quite simple modification. I changed from ?java.net.SocketException: ioctl SIOCGSIZIFCONF failed: Bad file number? to ?java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF failed)? like you suggested. The update is in place: http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ Now I finally need a review? Best regards Christoph From: Paul Benedict [mailto:pbenedict at apache.org] Sent: Montag, 27. Juni 2016 18:15 To: Langer, Christoph Cc: Kenji Kazumura ; Chris Hegarty ; nio-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; net-dev at openjdk.java.net Subject: Re: RFR 8158023: SocketExceptions contain too little information sometimes Christoph, I didn't understand your explanation on your message preference. Typically root cause information is printed last, not first. Another reason not to change the ordering of the exception message is that applications may be looking at existing strings. For this example, if I may presume "Bad file number" is an existing message, I would defer to the possibility applications may be exist that test for that message condition. Cheers, Paul On Mon, Jun 27, 2016 at 2:42 AM, Langer, Christoph > wrote: Hi, eventually here is the - hopefully final - version of this fix: http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ Now I leave JNU_ThrowByNameWithLastError untouched and I've also added conversion to the new function JNU_ThrowByNameWithMessageAndLastError. I've replaced JNU_ThrowByNameWithLastError with JNU_ThrowByNameWithMessageAndLastError in the java/net coding where I think it is appropriate (mostly in occasions when a SocketException is thrown kind of generically). @Paul: thanks for your suggestion regarding the output format but I would still prefer an output like "java.net.SocketException: ioctl SIOCGSIZIFCONF failed: Bad file number" vs. " java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF failed)" as I'm always handing down a message to the new throw routine. Hoping for a review :) Best regards Christoph > -----Original Message----- > From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] > Sent: Mittwoch, 8. Juni 2016 02:51 > To: Langer, Christoph > > Cc: net-dev at openjdk.java.net; nio-dev at openjdk.java.net; core-libs- > dev at openjdk.java.net > Subject: Re: RFR 8158023: SocketExceptions contain too little information > sometimes > > Christoph, > > You should not remove conversion codes (platform string to Java String) > at JNU_ThrowByNameWithLastError, > and you have to add conversion codes at > JNU_ThrowByNameWithMessageAndLastError. > > It seems that you assume strerror returns only ascii characters, but actually > not. > It depends on the locale of your environment where java programs runs. > > > -Kenji Kazumura > > > In message > > > RFR 8158023: SocketExceptions contain too little information sometimes > "Langer, Christoph" > wrote: > > > Hi all, > > > > please review the following change: > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 > > > > During error analysis I stumbled over a place where I encountered a > SocketException which was thrown along with some strerror information as > message. I found it hard to find the originating code spot with that information. > > > > So I looked at the places where we throw exceptions, namely JNU_Throw... > and NET_Throw... functions and came up with the following enhancement: > > - NET_ThrowByNameWithLastError can go completely as it does not provide > any benefit over JNU_ThrowByNameWithLastError. > > - JNU_ThrowByNameWithLastError can be cleaned up. > > > > - I added JNU_ThrowByNameWithMessageAndLastError to print out a string > like message + ": " + last error. > > > > - I went over all places where NET_ThrowByNameWithLastError is used and > replaced it appropriately. > > > > Do you think this change is desirable/possible? > > > > Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as > well as JNU_Throw... code affects all. > > > > Best regards > > Christoph > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roger.riggs at Oracle.com Wed Jun 29 18:19:43 2016 From: roger.riggs at Oracle.com (Roger Riggs) Date: Wed, 29 Jun 2016 14:19:43 -0400 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: <35fd36320f0a4c5b82302525d4e859e9@DEWDFE13DE11.global.corp.sap> References: <20160608.095115.312676195.kzr@jp.fujitsu.com> <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> <35fd36320f0a4c5b82302525d4e859e9@DEWDFE13DE11.global.corp.sap> Message-ID: <7631735f-263b-4609-7111-0af6da70220d@Oracle.com> Hi Christoph, Looking good, its unfortunate that the handling of mixed platform and utf string require jni up calls to invoke java methods. jni_util.c: line 216: You should not need to create an extra string; the string s is non-null and ready to use. jni_util.h: line 117-119, The original comment was just as informative as the replacement. The rest looks fine. Roger On 6/28/16 4:45 PM, Langer, Christoph wrote: > > Hi Paul, > > Ok, you kind of got me convinced and it is also a quite simple > modification. I changed from ?java.net.SocketException: ioctl > SIOCGSIZIFCONF failed: Bad file number? to ?java.net.SocketException: > Bad file number (ioctl SIOCGSIZIFCONF failed)? like you suggested. > > The update is in place: > http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ > > > Now I finally need a review? > > Best regards > > Christoph > > *From:*Paul Benedict [mailto:pbenedict at apache.org] > *Sent:* Montag, 27. Juni 2016 18:15 > *To:* Langer, Christoph > *Cc:* Kenji Kazumura ; Chris Hegarty > ; nio-dev at openjdk.java.net; > core-libs-dev at openjdk.java.net; net-dev at openjdk.java.net > *Subject:* Re: RFR 8158023: SocketExceptions contain too little > information sometimes > > Christoph, I didn't understand your explanation on your message > preference. Typically root cause information is printed last, not > first. Another reason not to change the ordering of the exception > message is that applications may be looking at existing strings. For > this example, if I may presume "Bad file number" is an existing > message, I would defer to the possibility applications may be exist > that test for that message condition. > > > Cheers, > Paul > > On Mon, Jun 27, 2016 at 2:42 AM, Langer, Christoph > > wrote: > > Hi, > > eventually here is the - hopefully final - version of this fix: > http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ > > > Now I leave JNU_ThrowByNameWithLastError untouched and I've also > added conversion to the new function > JNU_ThrowByNameWithMessageAndLastError. I've replaced > JNU_ThrowByNameWithLastError with > JNU_ThrowByNameWithMessageAndLastError in the java/net coding > where I think it is appropriate (mostly in occasions when a > SocketException is thrown kind of generically). @Paul: thanks for > your suggestion regarding the output format but I would still > prefer an output like "java.net.SocketException: ioctl > SIOCGSIZIFCONF failed: Bad file number" vs. " > java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF > failed)" as I'm always handing down a message to the new throw > routine. > > Hoping for a review :) > > Best regards > Christoph > > > -----Original Message----- > > From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] > > Sent: Mittwoch, 8. Juni 2016 02:51 > > To: Langer, Christoph > > Cc: net-dev at openjdk.java.net ; > nio-dev at openjdk.java.net ; core-libs- > > dev at openjdk.java.net > > Subject: Re: RFR 8158023: SocketExceptions contain too little > information > > sometimes > > > > Christoph, > > > > You should not remove conversion codes (platform string to Java > String) > > at JNU_ThrowByNameWithLastError, > > and you have to add conversion codes at > > JNU_ThrowByNameWithMessageAndLastError. > > > > It seems that you assume strerror returns only ascii characters, > but actually > > not. > > It depends on the locale of your environment where java programs > runs. > > > > > > -Kenji Kazumura > > > > > > In message > > > > > RFR 8158023: SocketExceptions contain too little information > sometimes > > "Langer, Christoph" > <christoph.langer at sap.com> wrote: > > > > > Hi all, > > > > > > please review the following change: > > > Webrev: > http://cr.openjdk.java.net/~clanger/webrevs/8158023.1/ > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 > > > > > > During error analysis I stumbled over a place where I > encountered a > > SocketException which was thrown along with some strerror > information as > > message. I found it hard to find the originating code spot with > that information. > > > > > > So I looked at the places where we throw exceptions, namely > JNU_Throw... > > and NET_Throw... functions and came up with the following > enhancement: > > > - NET_ThrowByNameWithLastError can go completely as it does > not provide > > any benefit over JNU_ThrowByNameWithLastError. > > > - JNU_ThrowByNameWithLastError can be cleaned up. > > > > > > - I added JNU_ThrowByNameWithMessageAndLastError to print out > a string > > like message + ": " + last error. > > > > > > - I went over all places where NET_ThrowByNameWithLastError is > used and > > replaced it appropriately. > > > > > > Do you think this change is desirable/possible? > > > > > > Though it's mainly a net topic, I'm posting it to nio-dev and > core-libs-dev as > > well as JNU_Throw... code affects all. > > > > > > Best regards > > > Christoph > > > > From christoph.langer at sap.com Wed Jun 29 21:18:21 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 29 Jun 2016 21:18:21 +0000 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: <7631735f-263b-4609-7111-0af6da70220d@Oracle.com> References: <20160608.095115.312676195.kzr@jp.fujitsu.com> <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> <35fd36320f0a4c5b82302525d4e859e9@DEWDFE13DE11.global.corp.sap> <7631735f-263b-4609-7111-0af6da70220d@Oracle.com> Message-ID: <9825c0d1f8294c86b26e576accceef67@DEWDFE13DE11.global.corp.sap> Hi Roger, thanks for reviewing. As for: > jni_util.c: line 216: There I don't create an extra String but the Exception Object to throw, similar to the old function JNU_ThrowByNameWithLastError. > jni_util.h: > > line 117-119, The original comment was just as informative as the I think you are right - I will restore the old comment. If no objections I consider this reviewed and will push it tomorrow with the reverted comment lines. Thanks Christoph > -----Original Message----- > From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Roger > Riggs > Sent: Mittwoch, 29. Juni 2016 20:20 > To: nio-dev at openjdk.java.net > Subject: Re: RFR 8158023: SocketExceptions contain too little information > sometimes > > Hi Christoph, > > Looking good, its unfortunate that the handling of mixed platform and > utf string require jni up calls to invoke java methods. > > jni_util.c: line 216: > > You should not need to create an extra string; the string s is > non-null and ready to use. > > jni_util.h: > > line 117-119, The original comment was just as informative as the > replacement. > > The rest looks fine. > > Roger > > On 6/28/16 4:45 PM, Langer, Christoph wrote: > > > > Hi Paul, > > > > Ok, you kind of got me convinced and it is also a quite simple > > modification. I changed from ?java.net.SocketException: ioctl > > SIOCGSIZIFCONF failed: Bad file number? to ?java.net.SocketException: > > Bad file number (ioctl SIOCGSIZIFCONF failed)? like you suggested. > > > > The update is in place: > > http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ > > > > > > Now I finally need a review? > > > > Best regards > > > > Christoph > > > > *From:*Paul Benedict [mailto:pbenedict at apache.org] > > *Sent:* Montag, 27. Juni 2016 18:15 > > *To:* Langer, Christoph > > *Cc:* Kenji Kazumura ; Chris Hegarty > > ; nio-dev at openjdk.java.net; > > core-libs-dev at openjdk.java.net; net-dev at openjdk.java.net > > *Subject:* Re: RFR 8158023: SocketExceptions contain too little > > information sometimes > > > > Christoph, I didn't understand your explanation on your message > > preference. Typically root cause information is printed last, not > > first. Another reason not to change the ordering of the exception > > message is that applications may be looking at existing strings. For > > this example, if I may presume "Bad file number" is an existing > > message, I would defer to the possibility applications may be exist > > that test for that message condition. > > > > > > Cheers, > > Paul > > > > On Mon, Jun 27, 2016 at 2:42 AM, Langer, Christoph > > > wrote: > > > > Hi, > > > > eventually here is the - hopefully final - version of this fix: > > http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ > > > > > > Now I leave JNU_ThrowByNameWithLastError untouched and I've also > > added conversion to the new function > > JNU_ThrowByNameWithMessageAndLastError. I've replaced > > JNU_ThrowByNameWithLastError with > > JNU_ThrowByNameWithMessageAndLastError in the java/net coding > > where I think it is appropriate (mostly in occasions when a > > SocketException is thrown kind of generically). @Paul: thanks for > > your suggestion regarding the output format but I would still > > prefer an output like "java.net.SocketException: ioctl > > SIOCGSIZIFCONF failed: Bad file number" vs. " > > java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF > > failed)" as I'm always handing down a message to the new throw > > routine. > > > > Hoping for a review :) > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] > > > Sent: Mittwoch, 8. Juni 2016 02:51 > > > To: Langer, Christoph > > > Cc: net-dev at openjdk.java.net ; > > nio-dev at openjdk.java.net ; core-libs- > > > dev at openjdk.java.net > > > Subject: Re: RFR 8158023: SocketExceptions contain too little > > information > > > sometimes > > > > > > Christoph, > > > > > > You should not remove conversion codes (platform string to Java > > String) > > > at JNU_ThrowByNameWithLastError, > > > and you have to add conversion codes at > > > JNU_ThrowByNameWithMessageAndLastError. > > > > > > It seems that you assume strerror returns only ascii characters, > > but actually > > > not. > > > It depends on the locale of your environment where java programs > > runs. > > > > > > > > > -Kenji Kazumura > > > > > > > > > In message > > > > > > p>> > > > RFR 8158023: SocketExceptions contain too little information > > sometimes > > > "Langer, Christoph" > > <christoph.langer at sap.com> wrote: > > > > > > > Hi all, > > > > > > > > please review the following change: > > > > Webrev: > > > http://cr.openjdk. > java.net/~clanger/webrevs/8158023.1/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 > > > > > > > > During error analysis I stumbled over a place where I > > encountered a > > > SocketException which was thrown along with some strerror > > information as > > > message. I found it hard to find the originating code spot with > > that information. > > > > > > > > So I looked at the places where we throw exceptions, namely > > JNU_Throw... > > > and NET_Throw... functions and came up with the following > > enhancement: > > > > - NET_ThrowByNameWithLastError can go completely as it does > > not provide > > > any benefit over JNU_ThrowByNameWithLastError. > > > > - JNU_ThrowByNameWithLastError can be cleaned up. > > > > > > > > - I added JNU_ThrowByNameWithMessageAndLastError to print out > > a string > > > like message + ": " + last error. > > > > > > > > - I went over all places where NET_ThrowByNameWithLastError is > > used and > > > replaced it appropriately. > > > > > > > > Do you think this change is desirable/possible? > > > > > > > > Though it's mainly a net topic, I'm posting it to nio-dev and > > core-libs-dev as > > > well as JNU_Throw... code affects all. > > > > > > > > Best regards > > > > Christoph > > > > > > From Roger.Riggs at Oracle.com Wed Jun 29 21:22:04 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 29 Jun 2016 17:22:04 -0400 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: <9825c0d1f8294c86b26e576accceef67@DEWDFE13DE11.global.corp.sap> References: <20160608.095115.312676195.kzr@jp.fujitsu.com> <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> <35fd36320f0a4c5b82302525d4e859e9@DEWDFE13DE11.global.corp.sap> <7631735f-263b-4609-7111-0af6da70220d@Oracle.com> <9825c0d1f8294c86b26e576accceef67@DEWDFE13DE11.global.corp.sap> Message-ID: <90dd289a-be20-b220-87f3-67d8b3190a08@Oracle.com> Hi Christph, fine, push when ready. On 6/29/2016 5:18 PM, Langer, Christoph wrote: > Hi Roger, > > thanks for reviewing. > > As for: >> jni_util.c: line 216: > There I don't create an extra String but the Exception Object to throw, similar to the old function JNU_ThrowByNameWithLastError. I misread line 216, thinking the exception class was fixed. > >> jni_util.h: >> >> line 117-119, The original comment was just as informative as the > I think you are right - I will restore the old comment. > > If no objections I consider this reviewed and will push it tomorrow with the reverted comment lines. Yep, Thanks, Roger > > Thanks > Christoph > >> -----Original Message----- >> From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Roger >> Riggs >> Sent: Mittwoch, 29. Juni 2016 20:20 >> To: nio-dev at openjdk.java.net >> Subject: Re: RFR 8158023: SocketExceptions contain too little information >> sometimes >> >> Hi Christoph, >> >> Looking good, its unfortunate that the handling of mixed platform and >> utf string require jni up calls to invoke java methods. >> >> jni_util.c: line 216: >> >> You should not need to create an extra string; the string s is >> non-null and ready to use. >> >> jni_util.h: >> >> line 117-119, The original comment was just as informative as the >> replacement. >> >> The rest looks fine. >> >> Roger >> >> On 6/28/16 4:45 PM, Langer, Christoph wrote: >>> Hi Paul, >>> >>> Ok, you kind of got me convinced and it is also a quite simple >>> modification. I changed from ?java.net.SocketException: ioctl >>> SIOCGSIZIFCONF failed: Bad file number? to ?java.net.SocketException: >>> Bad file number (ioctl SIOCGSIZIFCONF failed)? like you suggested. >>> >>> The update is in place: >>> http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ >>> >>> >>> Now I finally need a review? >>> >>> Best regards >>> >>> Christoph >>> >>> *From:*Paul Benedict [mailto:pbenedict at apache.org] >>> *Sent:* Montag, 27. Juni 2016 18:15 >>> *To:* Langer, Christoph >>> *Cc:* Kenji Kazumura ; Chris Hegarty >>> ; nio-dev at openjdk.java.net; >>> core-libs-dev at openjdk.java.net; net-dev at openjdk.java.net >>> *Subject:* Re: RFR 8158023: SocketExceptions contain too little >>> information sometimes >>> >>> Christoph, I didn't understand your explanation on your message >>> preference. Typically root cause information is printed last, not >>> first. Another reason not to change the ordering of the exception >>> message is that applications may be looking at existing strings. For >>> this example, if I may presume "Bad file number" is an existing >>> message, I would defer to the possibility applications may be exist >>> that test for that message condition. >>> >>> >>> Cheers, >>> Paul >>> >>> On Mon, Jun 27, 2016 at 2:42 AM, Langer, Christoph >>> > wrote: >>> >>> Hi, >>> >>> eventually here is the - hopefully final - version of this fix: >>> http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ >>> >>> >>> Now I leave JNU_ThrowByNameWithLastError untouched and I've also >>> added conversion to the new function >>> JNU_ThrowByNameWithMessageAndLastError. I've replaced >>> JNU_ThrowByNameWithLastError with >>> JNU_ThrowByNameWithMessageAndLastError in the java/net coding >>> where I think it is appropriate (mostly in occasions when a >>> SocketException is thrown kind of generically). @Paul: thanks for >>> your suggestion regarding the output format but I would still >>> prefer an output like "java.net.SocketException: ioctl >>> SIOCGSIZIFCONF failed: Bad file number" vs. " >>> java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF >>> failed)" as I'm always handing down a message to the new throw >>> routine. >>> >>> Hoping for a review :) >>> >>> Best regards >>> Christoph >>> >>> > -----Original Message----- >>> > From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] >>> > Sent: Mittwoch, 8. Juni 2016 02:51 >>> > To: Langer, Christoph >>> > Cc: net-dev at openjdk.java.net ; >>> nio-dev at openjdk.java.net ; core-libs- >>> > dev at openjdk.java.net >>> > Subject: Re: RFR 8158023: SocketExceptions contain too little >>> information >>> > sometimes >>> > >>> > Christoph, >>> > >>> > You should not remove conversion codes (platform string to Java >>> String) >>> > at JNU_ThrowByNameWithLastError, >>> > and you have to add conversion codes at >>> > JNU_ThrowByNameWithMessageAndLastError. >>> > >>> > It seems that you assume strerror returns only ascii characters, >>> but actually >>> > not. >>> > It depends on the locale of your environment where java programs >>> runs. >>> > >>> > >>> > -Kenji Kazumura >>> > >>> > >>> > In message >>> > >> > > p>> >>> > RFR 8158023: SocketExceptions contain too little information >>> sometimes >>> > "Langer, Christoph" >>> <christoph.langer at sap.com> wrote: >>> > >>> > > Hi all, >>> > > >>> > > please review the following change: >>> > > Webrev: >>> >> http://cr.openjdk. >> java.net/~clanger/webrevs/8158023.1/ >>> > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 >>> > > >>> > > During error analysis I stumbled over a place where I >>> encountered a >>> > SocketException which was thrown along with some strerror >>> information as >>> > message. I found it hard to find the originating code spot with >>> that information. >>> > > >>> > > So I looked at the places where we throw exceptions, namely >>> JNU_Throw... >>> > and NET_Throw... functions and came up with the following >>> enhancement: >>> > > - NET_ThrowByNameWithLastError can go completely as it does >>> not provide >>> > any benefit over JNU_ThrowByNameWithLastError. >>> > > - JNU_ThrowByNameWithLastError can be cleaned up. >>> > > >>> > > - I added JNU_ThrowByNameWithMessageAndLastError to print out >>> a string >>> > like message + ": " + last error. >>> > > >>> > > - I went over all places where NET_ThrowByNameWithLastError is >>> used and >>> > replaced it appropriately. >>> > > >>> > > Do you think this change is desirable/possible? >>> > > >>> > > Though it's mainly a net topic, I'm posting it to nio-dev and >>> core-libs-dev as >>> > well as JNU_Throw... code affects all. >>> > > >>> > > Best regards >>> > > Christoph >>> > > >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Thu Jun 30 07:39:39 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 30 Jun 2016 07:39:39 +0000 Subject: RFR 8158023: SocketExceptions contain too little information sometimes In-Reply-To: <90dd289a-be20-b220-87f3-67d8b3190a08@Oracle.com> References: <20160608.095115.312676195.kzr@jp.fujitsu.com> <2c8a21b1235d4b49bf06bf4b11470c1c@DEWDFE13DE11.global.corp.sap> <35fd36320f0a4c5b82302525d4e859e9@DEWDFE13DE11.global.corp.sap> <7631735f-263b-4609-7111-0af6da70220d@Oracle.com> <9825c0d1f8294c86b26e576accceef67@DEWDFE13DE11.global.corp.sap> <90dd289a-be20-b220-87f3-67d8b3190a08@Oracle.com> Message-ID: Thanks, pushed: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0b88eb2f451d From: Roger Riggs [mailto:Roger.Riggs at Oracle.com] Sent: Mittwoch, 29. Juni 2016 23:22 To: Langer, Christoph Cc: net-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; nio-dev at openjdk.java.net Subject: Re: RFR 8158023: SocketExceptions contain too little information sometimes Hi Christph, fine, push when ready. On 6/29/2016 5:18 PM, Langer, Christoph wrote: Hi Roger, thanks for reviewing. As for: jni_util.c: line 216: There I don't create an extra String but the Exception Object to throw, similar to the old function JNU_ThrowByNameWithLastError. I misread line 216, thinking the exception class was fixed. jni_util.h: line 117-119, The original comment was just as informative as the I think you are right - I will restore the old comment. If no objections I consider this reviewed and will push it tomorrow with the reverted comment lines. Yep, Thanks, Roger Thanks Christoph -----Original Message----- From: nio-dev [mailto:nio-dev-bounces at openjdk.java.net] On Behalf Of Roger Riggs Sent: Mittwoch, 29. Juni 2016 20:20 To: nio-dev at openjdk.java.net Subject: Re: RFR 8158023: SocketExceptions contain too little information sometimes Hi Christoph, Looking good, its unfortunate that the handling of mixed platform and utf string require jni up calls to invoke java methods. jni_util.c: line 216: You should not need to create an extra string; the string s is non-null and ready to use. jni_util.h: line 117-119, The original comment was just as informative as the replacement. The rest looks fine. Roger On 6/28/16 4:45 PM, Langer, Christoph wrote: Hi Paul, Ok, you kind of got me convinced and it is also a quite simple modification. I changed from ?java.net.SocketException: ioctl SIOCGSIZIFCONF failed: Bad file number? to ?java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF failed)? like you suggested. The update is in place: http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ Now I finally need a review? Best regards Christoph *From:*Paul Benedict [mailto:pbenedict at apache.org] *Sent:* Montag, 27. Juni 2016 18:15 *To:* Langer, Christoph *Cc:* Kenji Kazumura ; Chris Hegarty ; nio-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; net-dev at openjdk.java.net *Subject:* Re: RFR 8158023: SocketExceptions contain too little information sometimes Christoph, I didn't understand your explanation on your message preference. Typically root cause information is printed last, not first. Another reason not to change the ordering of the exception message is that applications may be looking at existing strings. For this example, if I may presume "Bad file number" is an existing message, I would defer to the possibility applications may be exist that test for that message condition. Cheers, Paul On Mon, Jun 27, 2016 at 2:42 AM, Langer, Christoph > wrote: Hi, eventually here is the - hopefully final - version of this fix: http://cr.openjdk.java.net/~clanger/webrevs/8158023.3/ Now I leave JNU_ThrowByNameWithLastError untouched and I've also added conversion to the new function JNU_ThrowByNameWithMessageAndLastError. I've replaced JNU_ThrowByNameWithLastError with JNU_ThrowByNameWithMessageAndLastError in the java/net coding where I think it is appropriate (mostly in occasions when a SocketException is thrown kind of generically). @Paul: thanks for your suggestion regarding the output format but I would still prefer an output like "java.net.SocketException: ioctl SIOCGSIZIFCONF failed: Bad file number" vs. " java.net.SocketException: Bad file number (ioctl SIOCGSIZIFCONF failed)" as I'm always handing down a message to the new throw routine. Hoping for a review :) Best regards Christoph > -----Original Message----- > From: Kenji Kazumura [mailto:kzr at jp.fujitsu.com] > Sent: Mittwoch, 8. Juni 2016 02:51 > To: Langer, Christoph > Cc: net-dev at openjdk.java.net ; nio-dev at openjdk.java.net ; core-libs- > dev at openjdk.java.net > Subject: Re: RFR 8158023: SocketExceptions contain too little information > sometimes > > Christoph, > > You should not remove conversion codes (platform string to Java String) > at JNU_ThrowByNameWithLastError, > and you have to add conversion codes at > JNU_ThrowByNameWithMessageAndLastError. > > It seems that you assume strerror returns only ascii characters, but actually > not. > It depends on the locale of your environment where java programs runs. > > > -Kenji Kazumura > > > In message > p>> > RFR 8158023: SocketExceptions contain too little information sometimes > "Langer, Christoph" <christoph.langer at sap.com> wrote: > > > Hi all, > > > > please review the following change: > > Webrev: http://cr.openjdk. java.net/~clanger/webrevs/8158023.1/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8158023 > > > > During error analysis I stumbled over a place where I encountered a > SocketException which was thrown along with some strerror information as > message. I found it hard to find the originating code spot with that information. > > > > So I looked at the places where we throw exceptions, namely JNU_Throw... > and NET_Throw... functions and came up with the following enhancement: > > - NET_ThrowByNameWithLastError can go completely as it does not provide > any benefit over JNU_ThrowByNameWithLastError. > > - JNU_ThrowByNameWithLastError can be cleaned up. > > > > - I added JNU_ThrowByNameWithMessageAndLastError to print out a string > like message + ": " + last error. > > > > - I went over all places where NET_ThrowByNameWithLastError is used and > replaced it appropriately. > > > > Do you think this change is desirable/possible? > > > > Though it's mainly a net topic, I'm posting it to nio-dev and core-libs-dev as > well as JNU_Throw... code affects all. > > > > Best regards > > Christoph > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Jun 30 20:19:13 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 30 Jun 2016 13:19:13 -0700 Subject: JDK 9 RFR of 8160018: (fs) Remove GioFileTypeDetector on Solaris Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8160018 Patch: http://cr.openjdk.java.net/~bpb/8160018/ The Solaris builds succeed and the core NIO regression tests pass with this change applied. Thanks, Brian From Roger.Riggs at Oracle.com Thu Jun 30 21:28:45 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 30 Jun 2016 17:28:45 -0400 Subject: JDK 9 RFR of 8160018: (fs) Remove GioFileTypeDetector on Solaris In-Reply-To: References: Message-ID: Hi Brian, Should the GioFileTypeDetector.java also be excluded from the Solaris build to save a bit of space and avoid confusion? The rest looks ok. Roger On 6/30/2016 4:19 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8160018 > Patch: http://cr.openjdk.java.net/~bpb/8160018/ > > The Solaris builds succeed and the core NIO regression tests pass with this change applied. > > Thanks, > > Brian From brian.burkhalter at oracle.com Thu Jun 30 22:06:25 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 30 Jun 2016 15:06:25 -0700 Subject: JDK 9 RFR of 8160018: (fs) Remove GioFileTypeDetector on Solaris In-Reply-To: References: Message-ID: <9656D819-BD9A-4A88-9FFE-67715D0196DC@oracle.com> Hi Roger, Good point. Now that you mention it I think the GioFileTypeDetector.java should be moved from under ?unix? to under ?linux? as now it is only used on Linux. I?ll create another webrev. Thanks, Brian On Jun 30, 2016, at 2:28 PM, Roger Riggs wrote: > Hi Brian, > > Should the GioFileTypeDetector.java also be excluded from the Solaris build to save a bit of space and avoid confusion? > > The rest looks ok. > > Roger > > > On 6/30/2016 4:19 PM, Brian Burkhalter wrote: >> Please review at your convenience. >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8160018 >> Patch: http://cr.openjdk.java.net/~bpb/8160018/ >> >> The Solaris builds succeed and the core NIO regression tests pass with this change applied. >> >> Thanks, >> >> Brian >