From david.holmes at oracle.com Wed Dec 5 01:41:31 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 5 Dec 2018 11:41:31 +1000 Subject: RFR: 8210107: vmTestbase/nsk/stress/network tests fail with Cannot assign requested address (Bind failed) In-Reply-To: References: Message-ID: <2acf13a4-2830-cf83-4818-17d4f742996d@oracle.com> Hi Leonid, This seems fine to me. It's been some time since hotspot hosted any of the native code used by networking. Thanks, David On 5/12/2018 7:36 am, Leonid Mesnik wrote: > Hi > > Could you please review following fix which removes vmTestbase/nsk/stress/network tests. These tests are pretty old stress networking tests and are don't seem to be useful for hotspot. > I was not able to find any product bugs related with these tests failures. > > Bug JDK-4245704 which is mentioned in the test sources is not related with these tests itself. > > If anyone from network team consider these tests useful then they could be just moved in more appropriate location. > > I verified that there are no additional changes in TEST.groups file are required. > > webrev: http://cr.openjdk.java.net/~lmesnik/8210107/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8210107 > > Leonid > From leonid.mesnik at oracle.com Tue Dec 4 21:36:17 2018 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Tue, 4 Dec 2018 13:36:17 -0800 Subject: RFR: 8210107: vmTestbase/nsk/stress/network tests fail with Cannot assign requested address (Bind failed) Message-ID: Hi Could you please review following fix which removes vmTestbase/nsk/stress/network tests. These tests are pretty old stress networking tests and are don't seem to be useful for hotspot. I was not able to find any product bugs related with these tests failures. Bug JDK-4245704 which is mentioned in the test sources is not related with these tests itself. If anyone from network team consider these tests useful then they could be just moved in more appropriate location. I verified that there are no additional changes in TEST.groups file are required. webrev: http://cr.openjdk.java.net/~lmesnik/8210107/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8210107 Leonid -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhailo.seledtsov at oracle.com Wed Dec 5 03:35:47 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Tue, 04 Dec 2018 19:35:47 -0800 Subject: RFR: 8210107: vmTestbase/nsk/stress/network tests fail with Cannot assign requested address (Bind failed) In-Reply-To: <2acf13a4-2830-cf83-4818-17d4f742996d@oracle.com> References: <2acf13a4-2830-cf83-4818-17d4f742996d@oracle.com> Message-ID: <5C074793.4090301@oracle.com> Looks good to me, Misha On 12/4/18, 5:41 PM, David Holmes wrote: > Hi Leonid, > > This seems fine to me. It's been some time since hotspot hosted any of > the native code used by networking. > > Thanks, > David > > On 5/12/2018 7:36 am, Leonid Mesnik wrote: >> Hi >> >> Could you please review following fix which removes >> vmTestbase/nsk/stress/network tests. These tests are pretty old >> stress networking tests and are don't seem to be useful for hotspot. >> I was not able to find any product bugs related with these tests >> failures. >> >> Bug JDK-4245704 >> which is mentioned in the test sources is not related with these >> tests itself. >> >> If anyone from network team consider these tests useful then they >> could be just moved in more appropriate location. >> >> I verified that there are no additional changes in TEST.groups file >> are required. >> >> webrev: http://cr.openjdk.java.net/~lmesnik/8210107/webrev.00/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8210107 >> >> >> Leonid >> From GROEGES at uk.ibm.com Wed Dec 5 10:50:12 2018 From: GROEGES at uk.ibm.com (Steve Groeger) Date: Wed, 5 Dec 2018 10:50:12 +0000 Subject: 8207404: MulticastSocket tests failing on Aix In-Reply-To: References: <285fd29d18994a74be86dd923a07e10b@sap.com> Message-ID: Posting this to net-dev as well as ppc-aix-port-dev as this may be a more appropriate mailing list to get responses about networking. I have performed the test Volker mentioned in an earlier post (on xLinux machine, remove the ipv6 address from the ens32 interface but leaving inte6 enabled on the system). With this configuration the jdk/java/net/MulticastSocket/JoinLeave.java test still passes, whereas on AIX with a similar configuration the test fails. For those with knowledge of networking, should this MulticastSocket test pass if there is no ipv6 address enabled for the interface being used. On AIX the setsockopt the call to the mcast_set_if_by_if_v6 function in PlainDatagramSocketImpl.c returns an EADDRNOTAVAIL, whereas on xLinux it doesnt throw an error. Is this as expected? Thanks Steve Groeger IBM Runtime Technologies Hursley, Winchester Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 Fax (44) 1962 816800 Lotus Notes: Steve Groeger/UK/IBM Internet: groeges at uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From: Volker Simonis To: Steve Groeger Cc: "Lindenmaier, Goetz" , ppc-aix-port-dev at openjdk.java.net, Java Core Libs Date: 30/11/2018 16:28 Subject: Re: 8207404: MulticastSocket tests failing on Aix On Fri, Nov 30, 2018 at 12:20 PM Steve Groeger wrote: > > Hi Goetz, > > I disabled IPv6 on my xLinux box and the MulticastSocket tests pass, as > they detected that IPv6 is not enabled and then didnt try and set the IPv6 > options. Not being a network expert either, I think there's two things to consider here. It seems that IPv6 can be disabled globally (e.g. in the Linux kernel) or IPv6 can be enabled globally, but not all network devices supporting it. A quick search revealed that it seems to be fairly easy to disable IPv6 on a single interface on Linux while still having IPv6 globally enabled (see https://superuser.com/questions/575684/how-to-disable-ipv6-on-a-specific-interface-in-linux ). @Steve Groeger can you please check if the test still succeeds on Linux if you only disable IPv6 on the specific interface used by the test? If it still succeeds, there's probably something to fix on AIX. If it fails on Linux as well, there may be something to fix in the test (i.e. to detect that the corresponding interface doesn't support IPv6) or even in the Java network implementation (i.e. to handle both, IPv6 and IPv4-only interfaces on an IPv6 enabled system correctly). Thank you and best regards, Volker > I am currently unable to disable IPv6 on my AIX box to test this but would > assume it would also work as the code checks to see whether IPv6 is > enabled and doesnt try and set the IPV6 options. > It seems the issue with the tests failing seems to be, if IPv6 is enabled > but the interface doesn't have an IPv6 address associated with it, as in > your case here: > > bash-4.3$ ifconfig -a > en0: > flags=1e084863,480 > inet 10.xx.xxx.xxx netmask 0xfffffe00 broadcast 10.xx.xxx.xxx > tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 > lo0: > flags=e08084b,c0 > inet 127.x.x.x netmask 0xff000000 broadcast 127.xxx.xxx.xxx > inet6 ::1%1/0 > tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1 > > where you can see that the en0 interface has an inet address associated > but doesnt have an inet6 address associated. > I can see that IPv6 is enabled as the lo0 interface has an inet6 address > (pointing to localhost) > > As I stated below, my AIX system was configured in a similar way to yours > and the tests failed. When I was able to add an inet6 address to en0, > everything works correctly. > NOTE: Not sure this was correct but I ran 'sudo autoconf6' which seemed to > add the inet6 address to my en0 interface. After that all tests worked. > > So I think the tests are working as expected, but the AIX system is not > configured correctly, but I would like someone else to confirm this. > > Thanks > Steve Groeger > IBM Runtime Technologies > Hursley, Winchester > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > Fax (44) 1962 816800 > Lotus Notes: Steve Groeger/UK/IBM > Internet: groeges at uk.ibm.com > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > > > From: "Lindenmaier, Goetz" > To: Steve Groeger , ppc-aix-port-dev > > Date: 30/11/2018 10:18 > Subject: RE: 8207404: MulticastSocket tests failing on Aix > > > > i Steve, > > thanks for looking at this issue. > > > Should these tests work without having IPV6 configured on the interface? > In general, tests should not show errors if a system does not meet > the requirements for the test. In such cases the test should > be skipped somehow. Maybe only a test fix is needed. > > Can you check on a non-aix machine without ipv6 whether the test > passes? > > > Goetz, do you have IPV6 configured on the machine you were running these > > tests on? > This is our test machine: > > bash-4.3$ ifconfig -a > en0: > flags=1e084863,480 > inet 10.xx.xxx.xxx netmask 0xfffffe00 broadcast 10.xx.xxx.xxx > tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 > lo0: > flags=e08084b,c0 > inet 127.x.x.x netmask 0xff000000 broadcast 127.xxx.xxx.xxx > inet6 ::1%1/0 > tcp_sendspace 131072 tcp_recvspace 131072 rfc1323 1 > > I think this message should be posted to core-libs-dev, too. That's also > the list where a potential fix needs to be reviewed. > > Best regards, > Goetz. > > > > -----Original Message----- > > From: Steve Groeger > > Sent: Donnerstag, 29. November 2018 17:07 > > To: ppc-aix-port-dev > > Cc: Lindenmaier, Goetz > > Subject: 8207404: MulticastSocket tests failing on Aix > > > > Hi All, > > > > I have been having a look at this issue: > > > https://bugs.openjdk.java.net/browse/JDK-8207404 > > > < > https://bugs.openjdk.java.net/browse/JDK-8207404 > > > > which was raised by Goetz Lindenmaier. > > > > When I ran the tests on my AIX system I got the same results as Goetz > listed > > in the issue. > > > > Looking at the failure I noticed that it was failing on a setsockopt > call in the > > native code in > > the PlainDatagramSocketImpl.c file which returned a EADDRNOTAVAIL (Can't > > assign requested address) > > > > Looking at my network configuration using "ifconfig -a", I noticed that > my > > interface "en0" which the test > > was trying to use did not have an inet6 address configured (see below - > some > > addresses have been obfuscated with x's). > > > > en0: > > flags=1e084863,14c0 > CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> > > inet 9.20.xx.xx netmask 0xffffff00 broadcast 9.20.xx.xxx > > tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 > > > > configuring the IPV6 on my AIX box I then had a inet6 address configured > for > > en0 > > > > en0: > > flags=1e084863,14c0 > CAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),LARGESEND,CHAIN> > > inet 9.20.xx.xx netmask 0xffffff00 broadcast 9.20.xx.xxx > > inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 > > tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1 > > > > with this configured the MulticastSocket tests all passed. > > > > Should these tests work without having IPV6 configured on the interface? > > > > Goetz, do you have IPV6 configured on the machine you were running these > > tests on? > > > > Thanks > > Steve Groeger > > IBM Runtime Technologies > > Hursley, UK > > Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129 > > Fax (44) 1962 816800 > > Lotus Notes: Steve Groeger/UK/IBM > > Internet: groeges at uk.ibm.com > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 > > 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Wed Dec 5 11:42:59 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 5 Dec 2018 11:42:59 +0000 Subject: RFR: 8210107: vmTestbase/nsk/stress/network tests fail with Cannot assign requested address (Bind failed) In-Reply-To: References: Message-ID: On 04/12/2018 21:36, Leonid Mesnik wrote: > Hi > > Could you please review following fix which > removes?vmTestbase/nsk/stress/network tests. These tests ?are pretty old > stress networking tests and are don't seem to be useful for hotspot. > I was not able to find any product bugs related with these tests failures. > > Bug JDK-4245704 ?which > is mentioned in the test sources is not related with these tests itself. > > If anyone from network team consider these tests useful then they could > be just moved in more appropriate location. I have no objection to their removal. > I verified that there are no additional changes in TEST.groups file are > required. > > webrev: http://cr.openjdk.java.net/~lmesnik/8210107/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8210107 Looks ok. -Chris. From daniel.fuchs at oracle.com Fri Dec 7 15:13:09 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Dec 2018 15:13:09 +0000 Subject: RFR 8215008: Clear confusion between URL/URI paths and file system paths Message-ID: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> Hi, Please find below a fix for 8215008: Clear confusion between URL/URI paths and file system paths https://bugs.openjdk.java.net/browse/JDK-8215008 It adds a small non normative @apiNote to java.net.URL and java.net.URI. http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.00/ best regards, -- daniel From Alan.Bateman at oracle.com Fri Dec 7 15:20:07 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 7 Dec 2018 15:20:07 +0000 Subject: RFR 8215008: Clear confusion between URL/URI paths and file system paths In-Reply-To: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> References: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> Message-ID: On 07/12/2018 15:13, Daniel Fuchs wrote: > Hi, > > Please find below a fix for > 8215008: Clear confusion between URL/URI paths and file system paths > https://bugs.openjdk.java.net/browse/JDK-8215008 > > It adds a small non normative @apiNote to java.net.URL and java.net.URI. > > http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.00/ I've come across dozens of cases where code has been trying to use a URL path as a file path so an API note is a good idea. On the wording then "there is not necessarily any direct relationship ..." is a bit confusing to read, at least for file URIs where the file path is encoded as a URI. I also think it would be useful to link to the APIs that do the encoding/decoding, as in File(URI), File::toURI, Path.of(URI), Path::toUri. -Alan From daniel.fuchs at oracle.com Fri Dec 7 16:16:43 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Dec 2018 16:16:43 +0000 Subject: RFR 8215008: Clear confusion between URL/URI paths and file system paths In-Reply-To: References: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> Message-ID: <3fb5963c-9f24-9ff6-fb88-e89f7d96b49d@oracle.com> Thanks for the feedback Alan! I have updated the webrev accordingly: http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.01/ best regards, -- daniel On 07/12/2018 15:20, Alan Bateman wrote: > I've come across dozens of cases where code has been trying to use a URL > path as a file path so an API note is a good idea. On the wording then > "there is not necessarily any direct relationship ..." is a bit > confusing to read, at least for file URIs where the file path is encoded > as a URI. I also think it would be useful to link to the APIs that do > the encoding/decoding, as in File(URI), File::toURI, Path.of(URI), > Path::toUri. > On 07/12/2018 15:13, Daniel Fuchs wrote: > Please find below a fix for > 8215008: Clear confusion between URL/URI paths and file system paths > https://bugs.openjdk.java.net/browse/JDK-8215008 > > It adds a small non normative @apiNote to java.net.URL and java.net.URI. From chris.hegarty at oracle.com Fri Dec 7 16:21:13 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 7 Dec 2018 16:21:13 +0000 Subject: RFR 8215008: Clear confusion between URL/URI paths and file system paths In-Reply-To: <3fb5963c-9f24-9ff6-fb88-e89f7d96b49d@oracle.com> References: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> <3fb5963c-9f24-9ff6-fb88-e89f7d96b49d@oracle.com> Message-ID: <75B06673-684E-4146-B96E-C38DE56059FD@oracle.com> > On 7 Dec 2018, at 16:16, Daniel Fuchs wrote: > > Thanks for the feedback Alan! > > I have updated the webrev accordingly: > > http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.01/ Looks good. Maybe userinfo. -Chris. From daniel.fuchs at oracle.com Fri Dec 7 16:30:15 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 7 Dec 2018 16:30:15 +0000 Subject: RFR 8215008: Clear confusion between URL/URI paths and file system paths In-Reply-To: <75B06673-684E-4146-B96E-C38DE56059FD@oracle.com> References: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> <3fb5963c-9f24-9ff6-fb88-e89f7d96b49d@oracle.com> <75B06673-684E-4146-B96E-C38DE56059FD@oracle.com> Message-ID: <03943e47-99e4-3724-c629-a5e31977993c@oracle.com> Thanks Chris. Will do. -- daniel On 07/12/2018 16:21, Chris Hegarty wrote: > > >> On 7 Dec 2018, at 16:16, Daniel Fuchs wrote: >> >> Thanks for the feedback Alan! >> >> I have updated the webrev accordingly: >> >> http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.01/ > > Looks good. > > Maybe userinfo. > > -Chris. > From daniel.fuchs at oracle.com Mon Dec 10 17:54:38 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 10 Dec 2018 17:54:38 +0000 Subject: RFR 8215008: Clear confusion between URL/URI paths and file system paths In-Reply-To: <3fb5963c-9f24-9ff6-fb88-e89f7d96b49d@oracle.com> References: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> <3fb5963c-9f24-9ff6-fb88-e89f7d96b49d@oracle.com> Message-ID: Hi Alan, Here is an updated webrev that takes into account your later feedback: http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.02/ best regards, -- daniel On 07/12/2018 16:16, Daniel Fuchs wrote: > Thanks for the feedback Alan! > > I have updated the webrev accordingly: > > http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.01/ > > best regards, > > -- daniel > > On 07/12/2018 15:20, Alan Bateman wrote: >> I've come across dozens of cases where code has been trying to use a >> URL path as a file path so an API note is a good idea. On the wording >> then "there is not necessarily any direct relationship ..." is a bit >> confusing to read, at least for file URIs where the file path is >> encoded as a URI. I also think it would be useful to link to the APIs >> that do the encoding/decoding, as in File(URI), File::toURI, >> Path.of(URI), Path::toUri. >> On 07/12/2018 15:13, Daniel Fuchs wrote: >> Please find below a fix for >> 8215008: Clear confusion between URL/URI paths and file system paths >> https://bugs.openjdk.java.net/browse/JDK-8215008 >> >> It adds a small non normative @apiNote to java.net.URL and java.net.URI. From Alan.Bateman at oracle.com Mon Dec 10 18:00:12 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 10 Dec 2018 18:00:12 +0000 Subject: RFR 8215008: Clear confusion between URL/URI paths and file system paths In-Reply-To: References: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> <3fb5963c-9f24-9ff6-fb88-e89f7d96b49d@oracle.com> Message-ID: On 10/12/2018 17:54, Daniel Fuchs wrote: > Hi Alan, > > Here is an updated webrev that takes into account > your later feedback: > > http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.02/ > This update looks good to me. -Alan From martinrb at google.com Mon Dec 10 19:41:48 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 10 Dec 2018 11:41:48 -0800 Subject: RFR 8215008: Clear confusion between URL/URI paths and file system paths In-Reply-To: References: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> <3fb5963c-9f24-9ff6-fb88-e89f7d96b49d@oracle.com> Message-ID: Thanks. Looks good. Tangentially ... I see URLClassLoader uses URLClassPath which uses FileURLMapper, which tries to directly convert a URL to a String path. FileURLMapper uses URL#getFile, and TIL that #getFile differs from #getPath in that it also returns a query component where present. Maybe FileURLMapper should check explicitly that the URL's query and anchor components are empty (etc ...)? Maybe an audit should be done to ensure that openjdk itself follows the guidelines? Maybe that would turn up additional API methods for users that would be good to add? On Mon, Dec 10, 2018 at 9:54 AM Daniel Fuchs wrote: > Hi Alan, > > Here is an updated webrev that takes into account > your later feedback: > > http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.02/ > > best regards, > > -- daniel > > On 07/12/2018 16:16, Daniel Fuchs wrote: > > Thanks for the feedback Alan! > > > > I have updated the webrev accordingly: > > > > http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.01/ > > > > best regards, > > > > -- daniel > > > > On 07/12/2018 15:20, Alan Bateman wrote: > >> I've come across dozens of cases where code has been trying to use a > >> URL path as a file path so an API note is a good idea. On the wording > >> then "there is not necessarily any direct relationship ..." is a bit > >> confusing to read, at least for file URIs where the file path is > >> encoded as a URI. I also think it would be useful to link to the APIs > >> that do the encoding/decoding, as in File(URI), File::toURI, > >> Path.of(URI), Path::toUri. > >> On 07/12/2018 15:13, Daniel Fuchs wrote: > >> Please find below a fix for > >> 8215008: Clear confusion between URL/URI paths and file system paths > >> https://bugs.openjdk.java.net/browse/JDK-8215008 > >> > >> It adds a small non normative @apiNote to java.net.URL and java.net.URI. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.fuchs at oracle.com Tue Dec 11 11:27:53 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 11 Dec 2018 11:27:53 +0000 Subject: RFR 8215008: Clear confusion between URL/URI paths and file system paths In-Reply-To: References: <1b2b2730-ccb9-6361-e5b0-bec0fefee49f@oracle.com> <3fb5963c-9f24-9ff6-fb88-e89f7d96b49d@oracle.com> Message-ID: Hi Martin, Thanks for pointing that out. I have logged https://bugs.openjdk.java.net/browse/JDK-8215207 best regards, -- daniel On 10/12/2018 19:41, Martin Buchholz wrote: > Thanks.? Looks good. > > Tangentially ... I see URLClassLoader uses URLClassPath which uses > FileURLMapper, which tries to directly convert a URL to a String path. > FileURLMapper uses URL#getFile, and TIL that #getFile differs from > #getPath in that it also returns a query component where present. > Maybe?FileURLMapper should check explicitly that the URL's query and > anchor components are empty (etc ...)? > Maybe an audit should be done to ensure that openjdk itself follows the > guidelines? > Maybe that would turn up additional API methods for users that would be > good to add? > > On Mon, Dec 10, 2018 at 9:54 AM Daniel Fuchs > wrote: > > Hi Alan, > > Here is an updated webrev that takes into account > your later feedback: > > http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.02/ > > > best regards, > > -- daniel > > On 07/12/2018 16:16, Daniel Fuchs wrote: > > Thanks for the feedback Alan! > > > > I have updated the webrev accordingly: > > > > http://cr.openjdk.java.net/~dfuchs/webrev_8215008/webrev.01/ > > > > > best regards, > > > > -- daniel > > > > On 07/12/2018 15:20, Alan Bateman wrote: > >> I've come across dozens of cases where code has been trying to > use a > >> URL path as a file path so an API note is a good idea. On the > wording > >> then "there is not necessarily any direct relationship ..." is a > bit > >> confusing to read, at least for file URIs where the file path is > >> encoded as a URI. I also think it would be useful to link to the > APIs > >> that do the encoding/decoding, as in File(URI), File::toURI, > >> Path.of(URI), Path::toUri. > >> On 07/12/2018 15:13, Daniel Fuchs wrote: > >> Please find below a fix for > >> 8215008: Clear confusion between URL/URI paths and file system paths > >> https://bugs.openjdk.java.net/browse/JDK-8215008 > >> > >> It adds a small non normative @apiNote to java.net.URL and > java.net.URI. > From michael.x.mcmahon at oracle.com Wed Dec 12 10:51:09 2018 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 12 Dec 2018 10:51:09 +0000 Subject: RFR: 8199849 HttpServer/BasicAuthenticator: unicode bytes are not correctly handled and no workaround is provided Message-ID: <5C10E81D.4010206@oracle.com> Could I get the following webrev reviewed please? http://cr.openjdk.java.net/~michaelm/8199849/webrev.1/ A CSR for the small API change will follow. Thanks, Michael From daniel.fuchs at oracle.com Wed Dec 12 11:46:20 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 12 Dec 2018 11:46:20 +0000 Subject: RFR: 8199849 HttpServer/BasicAuthenticator: unicode bytes are not correctly handled and no workaround is provided In-Reply-To: <5C10E81D.4010206@oracle.com> References: <5C10E81D.4010206@oracle.com> Message-ID: <0cb8d07c-abf5-8064-53cc-ad318f5ef88f@oracle.com> Hi Michael, BasicAuthentication.java: An alternative to: byte[] passwdBytes = (new String(passwd)).getBytes(cs); would be: ByteBuffer bb = cs.newEncoder() .encode(CharBuffer.wrap(passwd)); then use ByteBuffer::get to copy the bytes into `concat` Or better you could construct a CharBuffer that contains both the userid, ':', and passwd chars and do the decoding in one go. HttpURLConnection.java Given that these lines appear twice: 2310 HeaderParser hp = authhdr.headerParser(); 2311 Charset charset = null; 2312 String cs = hp.findValue("charset"); 2313 if (cs != null && cs.equalsIgnoreCase("UTF-8")) { 2314 charset = StandardCharsets.UTF_8; 2315 } I now wonder if it should be moved to a `Charset getAuthCharset()` method in AuthenticationHeader? best regards, -- daniel On 12/12/2018 10:51, Michael McMahon wrote: > Could I get the following webrev reviewed please? > > http://cr.openjdk.java.net/~michaelm/8199849/webrev.1/ > > A CSR for the small API change will follow. > > Thanks, > > Michael From michael.x.mcmahon at oracle.com Wed Dec 12 16:06:26 2018 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 12 Dec 2018 16:06:26 +0000 Subject: RFR: 8199849 HttpServer/BasicAuthenticator: unicode bytes are not correctly handled and no workaround is provided In-Reply-To: <0cb8d07c-abf5-8064-53cc-ad318f5ef88f@oracle.com> References: <5C10E81D.4010206@oracle.com> <0cb8d07c-abf5-8064-53cc-ad318f5ef88f@oracle.com> Message-ID: <5C113202.20705@oracle.com> Hi Daniel, On 12/12/2018, 11:46, Daniel Fuchs wrote: > Hi Michael, > > BasicAuthentication.java: > > An alternative to: > > byte[] passwdBytes = (new String(passwd)).getBytes(cs); > > would be: > > ByteBuffer bb = cs.newEncoder() > .encode(CharBuffer.wrap(passwd)); > > then use ByteBuffer::get to copy the bytes into `concat` > > Or better you could construct a CharBuffer that contains both > the userid, ':', and passwd chars and do the decoding in one go. > I think the simplest solution is just to use a StringBuilder to combine the username and password into one String and encode that string in one call. > HttpURLConnection.java > > Given that these lines appear twice: > > 2310 HeaderParser hp = authhdr.headerParser(); > 2311 Charset charset = null; > 2312 String cs = hp.findValue("charset"); > 2313 if (cs != null && > cs.equalsIgnoreCase("UTF-8")) { > 2314 charset = StandardCharsets.UTF_8; > 2315 } > > > I now wonder if it should be moved to a `Charset getAuthCharset()` > method in AuthenticationHeader? > That's a good idea. Thanks, Michael > best regards, > > -- daniel > > On 12/12/2018 10:51, Michael McMahon wrote: >> Could I get the following webrev reviewed please? >> >> http://cr.openjdk.java.net/~michaelm/8199849/webrev.1/ >> >> A CSR for the small API change will follow. >> >> Thanks, >> >> Michael > From pavel.rappo at oracle.com Wed Dec 12 16:09:25 2018 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 12 Dec 2018 16:09:25 +0000 Subject: RFR [12] 8215292: Back out changes for node- and link- local ipv6 multicast address Message-ID: <76200D25-5812-4DE1-95CB-3AB904BD209F@oracle.com> Hello, Please review the following change: http://cr.openjdk.java.net/~prappo/8215292/webrev.00 That change backs out the fix for "Bind to node- or linklocal ipv6 multicast address fails" [1]. The change in question is produced as: hg diff -c 23b3a46fa159 --reverse --git After I have applied the fix for JDK-8210493 some tests started to fail, even though initial testing didn't show any signs of the problem. It now makes sense to back those changes out, create a separate bug, investigate and fix the issue. The new bug has been created [2] with the title: "Provide a better fix for binding to node- and link- local ipv6 multicast addresses" Apologies for any inconvenience caused. Thanks, -Pavel ------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8210493 [2] https://bugs.openjdk.java.net/browse/JDK-8215294 From chris.hegarty at oracle.com Wed Dec 12 16:15:09 2018 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 12 Dec 2018 16:15:09 +0000 Subject: RFR [12] 8215292: Back out changes for node- and link- local ipv6 multicast address In-Reply-To: <76200D25-5812-4DE1-95CB-3AB904BD209F@oracle.com> References: <76200D25-5812-4DE1-95CB-3AB904BD209F@oracle.com> Message-ID: <4fbb1f9c-b246-7fa3-97a0-11ce30c0d8af@oracle.com> The backout looks correct, and I agree with the approach. -Chris. On 12/12/2018 16:09, Pavel Rappo wrote: > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8215292/webrev.00 > > That change backs out the fix for "Bind to node- or linklocal ipv6 multicast > address fails" [1]. The change in question is produced as: > > hg diff -c 23b3a46fa159 --reverse --git > > After I have applied the fix for JDK-8210493 some tests started to fail, even > though initial testing didn't show any signs of the problem. It now makes sense > to back those changes out, create a separate bug, investigate and fix the issue. > > The new bug has been created [2] with the title: > > "Provide a better fix for binding to node- and link- local ipv6 multicast > addresses" > > Apologies for any inconvenience caused. > > Thanks, > -Pavel > > ------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8210493 > [2] https://bugs.openjdk.java.net/browse/JDK-8215294 > From Alan.Bateman at oracle.com Wed Dec 12 16:25:28 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 16:25:28 +0000 Subject: RFR [12] 8215292: Back out changes for node- and link- local ipv6 multicast address In-Reply-To: <4fbb1f9c-b246-7fa3-97a0-11ce30c0d8af@oracle.com> References: <76200D25-5812-4DE1-95CB-3AB904BD209F@oracle.com> <4fbb1f9c-b246-7fa3-97a0-11ce30c0d8af@oracle.com> Message-ID: On 12/12/2018 16:15, Chris Hegarty wrote: > The backout looks correct, and I agree with the approach. > > -Chris. > > On 12/12/2018 16:09, Pavel Rappo wrote: >> Hello, >> >> Please review the following change: >> >> ? http://cr.openjdk.java.net/~prappo/8215292/webrev.00 >> >> That change backs out the fix for "Bind to node- or linklocal ipv6 >> multicast >> address fails" [1]. The change in question is produced as: >> >> ???? hg diff -c 23b3a46fa159 --reverse --git Looks okay to me too, this one turned to be side effects that originally intended. I think our long standing recommendation to use the join methods for portable code stands. -Alan From claes.redestad at oracle.com Wed Dec 12 16:53:11 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 17:53:11 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base Message-ID: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Hi, please review this patch to use String.isEmpty when applicable: Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 Why? - It reads better :-) - Better startup/warmup due fewer method invocations - Better peak performance: String.isEmpty is ~1.2x faster than String.length Most changes are simple search and replace, but I took the liberty to clean out some dead/pointless uses and improve formatting in places due the shorter expression length. Instances of "".equals(string) were only changed when it was immediately obvious that string is not null, e.g., due a preceding null check. Thanks! /Claes From daniel.fuchs at oracle.com Wed Dec 12 16:54:29 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 12 Dec 2018 16:54:29 +0000 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Message-ID: <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> Hi Claes, It might read even better if things like: + resultString = !specarg.isEmpty() ? specarg.intern(): opt; were changed into: + resultString = specarg.isEmpty() ? opt : specarg.intern(); best regards, -- daniel On 12/12/2018 16:53, Claes Redestad wrote: > Hi, > > please review this patch to use String.isEmpty when applicable: > > Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 > > Why? > - It reads better :-) > - Better startup/warmup due fewer method invocations > - Better peak performance: String.isEmpty is ~1.2x faster than > ? String.length > > Most changes are simple search and replace, but I took the liberty to > clean out some dead/pointless uses and improve formatting in places due > the shorter expression length. > > Instances of "".equals(string) were only changed when it was immediately > obvious that string is not null, e.g., due a preceding null check. > > Thanks! > > /Claes From Alan.Bateman at oracle.com Wed Dec 12 16:56:17 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 12 Dec 2018 16:56:17 +0000 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Message-ID: On 12/12/2018 16:53, Claes Redestad wrote: > Hi, > > please review this patch to use String.isEmpty when applicable: > > Webrev: http://cr.openjdk.java.net/~redestad/8215281/jdk.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215281 > > Why? > - It reads better :-) > - Better startup/warmup due fewer method invocations > - Better peak performance: String.isEmpty is ~1.2x faster than > ? String.length > > Most changes are simple search and replace, but I took the liberty to > clean out some dead/pointless uses and improve formatting in places due > the shorter expression length. > > Instances of "".equals(string) were only changed when it was immediately > obvious that string is not null, e.g., due a preceding null check. In Checks.java, the parameter change from CharSequence to String means that "cs" needs to be renamed. -Alan. From claes.redestad at oracle.com Wed Dec 12 17:04:33 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 18:04:33 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> Message-ID: <10eafdbe-f524-2534-3bea-3744c06fbc81@oracle.com> On 2018-12-12 17:56, Alan Bateman wrote: > In Checks.java, the parameter change from CharSequence to String means > that "cs" needs to be renamed. Changed to 'str' /Claes From claes.redestad at oracle.com Wed Dec 12 17:06:24 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 12 Dec 2018 18:06:24 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> Message-ID: <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> On 2018-12-12 17:54, Daniel Fuchs wrote: > Hi Claes, > > It might read even better if things like: > > +??????? resultString = !specarg.isEmpty() ? specarg.intern(): opt; > > were changed into: > > +??????? resultString = specarg.isEmpty() ? opt : specarg.intern(); > > best regards, I only found this pattern in this file, so incremental diff will look like the below. I will update in place due hugeness of webrev. Thanks! /Claes diff -r 732b03e40349 src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java Wed Dec 12 17:41:46 2018 +0100 +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java Wed Dec 12 18:03:57 2018 +0100 @@ -641,10 +641,10 @@ String specarg = spec.substring(sidx); switch (specop) { case '.': // terminate the option sequence - resultString = !specarg.isEmpty() ? specarg.intern(): opt; + resultString = specarg.isEmpty() ? opt : specarg.intern(); break doArgs; case '?': // abort the option sequence - resultString = !specarg.isEmpty() ? specarg.intern(): arg; + resultString = specarg.isEmpty() ? arg : specarg.intern(); isError = true; break eachSpec; case '@': // change the effective opt name @@ -655,7 +655,7 @@ val = ""; break; case '!': // negation option - String negopt = !specarg.isEmpty() ? specarg.intern(): opt; + String negopt = specarg.isEmpty() ? opt : specarg.intern(); properties.remove(negopt); properties.put(negopt, null); // leave placeholder didAction = true; From daniel.fuchs at oracle.com Thu Dec 13 13:06:07 2018 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 13 Dec 2018 13:06:07 +0000 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> Message-ID: <7f522277-602f-553b-e725-456fdaa2b2fe@oracle.com> Looks good Claes! I eyeballed the rest of the patch and found nothing wrong - but with a patch this size it would be easy to miss something. Were you able to measure any improvement after patching? best regards, -- daniel On 12/12/2018 17:06, Claes Redestad wrote: > > > On 2018-12-12 17:54, Daniel Fuchs wrote: >> Hi Claes, >> >> It might read even better if things like: >> >> +??????? resultString = !specarg.isEmpty() ? specarg.intern(): opt; >> >> were changed into: >> >> +??????? resultString = specarg.isEmpty() ? opt : specarg.intern(); >> >> best regards, > > I only found this pattern in this file, so incremental > diff will look like the below. I will update in place due hugeness of > webrev. > > Thanks! > > /Claes > > diff -r 732b03e40349 > src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java > --- a/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java > Wed Dec 12 17:41:46 2018 +0100 > +++ b/src/java.base/share/classes/com/sun/java/util/jar/pack/Driver.java > Wed Dec 12 18:03:57 2018 +0100 > @@ -641,10 +641,10 @@ > ???????????????????? String specarg = spec.substring(sidx); > ???????????????????? switch (specop) { > ???????????????????? case '.':? // terminate the option sequence > -??????????????????????? resultString = !specarg.isEmpty() ? > specarg.intern(): opt; > +??????????????????????? resultString = specarg.isEmpty() ? opt : > specarg.intern(); > ???????????????????????? break doArgs; > ???????????????????? case '?':? // abort the option sequence > -??????????????????????? resultString = !specarg.isEmpty() ? > specarg.intern(): arg; > +??????????????????????? resultString = specarg.isEmpty() ? arg : > specarg.intern(); > ???????????????????????? isError = true; > ???????????????????????? break eachSpec; > ???????????????????? case '@':? // change the effective opt name > @@ -655,7 +655,7 @@ > ???????????????????????? val = ""; > ???????????????????????? break; > ???????????????????? case '!':? // negation option > -??????????????????????? String negopt = !specarg.isEmpty() ? > specarg.intern(): opt; > +??????????????????????? String negopt = specarg.isEmpty() ? opt : > specarg.intern(); > ???????????????????????? properties.remove(negopt); > ???????????????????????? properties.put(negopt, null);? // leave > placeholder > ???????????????????????? didAction = true; From claes.redestad at oracle.com Thu Dec 13 13:17:05 2018 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 13 Dec 2018 14:17:05 +0100 Subject: RFR: 8215281: Use String.isEmpty() where applicable in java.base In-Reply-To: <7f522277-602f-553b-e725-456fdaa2b2fe@oracle.com> References: <25e2d51e-6086-2f14-61cd-d2cdb32794e8@oracle.com> <7a99245d-d418-a49c-005b-77b07236661f@oracle.com> <46e901de-a9e4-2485-16cf-0b57542f7475@oracle.com> <7f522277-602f-553b-e725-456fdaa2b2fe@oracle.com> Message-ID: <3917b2c2-127a-8ed2-dfec-fb4e1f4631f2@oracle.com> On 2018-12-13 14:06, Daniel Fuchs wrote: > Looks good Claes! Thanks! > I eyeballed the rest of the patch and found > nothing wrong - but with a patch this size > it would be easy to miss something. Yes, I've gone through it a couple of times now to be sure. > > Were you able to measure any improvement after > patching? There's a tiny reduction in bytecode executed in initPhase1, but on any real measures any improvement is in the noise. /Claes > > best regards, > > -- daniel