Re: InetAddress.getByName/getAllByName for empty host string
On 20/04/18 11:24 AM, Alan Bateman wrote: On 20/04/2018 05:37, Jaikiran Pai wrote: I'm in the process of creating the patch and will send it out to this list soon. Best to send it to the net-dev list as this is where the java.net API is mostly maintained. Will do. Thank you. -Jaikiran
Re: InetAddress.getByName/getAllByName for empty host string
On 20/04/2018 05:37, Jaikiran Pai wrote: : The change will require a CSR, but I can do that on your behalf. Thank you, can you please file one (if it can be done before a patch is submitted)? I'm in the process of creating the patch and will send it out to this list soon. Best to send it to the net-dev list as this is where the java.net API is mostly maintained. -Alan.
Re: InetAddress.getByName/getAllByName for empty host string
Hi Chris, On 16/04/18 9:33 PM, Chris Hegarty wrote: Jaikiran, On 13/04/18 16:29, Jaikiran Pai wrote: Hi Chris, Thank you creating that JIRA. If the fix involves just updating the javadoc, is this something that youwould like me to contribute as a patch? I have a signed and approved OCA, but I will need a sponsor if I do come up with the patch. A patch containing the specification clarification I'm a bit new to the OpenJDK project - does the specification clarification (at least in the context of this issue) mean anything more than updating the javadoc? and an update to an existing test to cover said specification clarification would be helpful. I have started working on a test. The change will require a CSR, but I can do that on your behalf. Thank you, can you please file one (if it can be done before a patch is submitted)? I'm in the process of creating the patch and will send it out to this list soon. -Jaikiran
Re: InetAddress.getByName/getAllByName for empty host string
Jaikiran, On 13/04/18 16:29, Jaikiran Pai wrote: Hi Chris, Thank you creating that JIRA. If the fix involves just updating the javadoc, is this something that youwould like me to contribute as a patch? I have a signed and approved OCA, but I will need a sponsor if I do come up with the patch. A patch containing the specification clarification and an update to an existing test to cover said specification clarification would be helpful. The change will require a CSR, but I can do that on your behalf. -Chris. -Jaikiran On 13/04/18 8:41 PM, Chris Hegarty wrote: Hi Jaikiran, On 13/04/18 15:29, Jaikiran Pai wrote: The javadoc of InetAddress.getByName(host) and getAllByName(host) states that: If the host is null then an InetAddress representing an address of the loopback interface is returned. For non-null values the javadoc explains what the implementation does. However, there seems to be no mention of what it does with an empty string (length == 0) value for the host param. Right now, the implementation seems to treat an empty value the same way it treats the host == null case and returns an InetAddress representing the loopback address. Consider the following example: public class InetAddressTest { public static void main(final String[] args) throws Exception { System.out.println("InetAddress.getByName() for empty string returns " + java.net.InetAddress.getByName("")); System.out.println("InetAddress.getAllByName() for empty string returns " + java.util.Arrays.toString(java.net.InetAddress.getAllByName(""))); } } This outputs: InetAddress.getByName() for empty string returns localhost/127.0.0.1 InetAddress.getAllByName() for empty string returns [localhost/127.0.0.1] Is it intentional for these APIs to behave this way for empty string? Yes. If so, should the javadoc be updated to explicitly state this behaviour? Yeah, probably. The following JIRA issue has been filed to track this: https://bugs.openjdk.java.net/browse/JDK-8201545 -Chris.
Re: InetAddress.getByName/getAllByName for empty host string
Hi Chris, Thank you creating that JIRA. If the fix involves just updating the javadoc, is this something that youwould like me to contribute as a patch? I have a signed and approved OCA, but I will need a sponsor if I do come up with the patch. -Jaikiran On 13/04/18 8:41 PM, Chris Hegarty wrote: Hi Jaikiran, On 13/04/18 15:29, Jaikiran Pai wrote: The javadoc of InetAddress.getByName(host) and getAllByName(host) states that: If the host is null then an InetAddress representing an address of the loopback interface is returned. For non-null values the javadoc explains what the implementation does. However, there seems to be no mention of what it does with an empty string (length == 0) value for the host param. Right now, the implementation seems to treat an empty value the same way it treats the host == null case and returns an InetAddress representing the loopback address. Consider the following example: public class InetAddressTest { public static void main(final String[] args) throws Exception { System.out.println("InetAddress.getByName() for empty string returns " + java.net.InetAddress.getByName("")); System.out.println("InetAddress.getAllByName() for empty string returns " + java.util.Arrays.toString(java.net.InetAddress.getAllByName(""))); } } This outputs: InetAddress.getByName() for empty string returns localhost/127.0.0.1 InetAddress.getAllByName() for empty string returns [localhost/127.0.0.1] Is it intentional for these APIs to behave this way for empty string? Yes. If so, should the javadoc be updated to explicitly state this behaviour? Yeah, probably. The following JIRA issue has been filed to track this: https://bugs.openjdk.java.net/browse/JDK-8201545 -Chris.
Re: InetAddress.getByName/getAllByName for empty host string
Hi Jaikiran, On 13/04/18 15:29, Jaikiran Pai wrote: The javadoc of InetAddress.getByName(host) and getAllByName(host) states that: If the host is null then an InetAddress representing an address of the loopback interface is returned. For non-null values the javadoc explains what the implementation does. However, there seems to be no mention of what it does with an empty string (length == 0) value for the host param. Right now, the implementation seems to treat an empty value the same way it treats the host == null case and returns an InetAddress representing the loopback address. Consider the following example: public class InetAddressTest { public static void main(final String[] args) throws Exception { System.out.println("InetAddress.getByName() for empty string returns " + java.net.InetAddress.getByName("")); System.out.println("InetAddress.getAllByName() for empty string returns " + java.util.Arrays.toString(java.net.InetAddress.getAllByName(""))); } } This outputs: InetAddress.getByName() for empty string returns localhost/127.0.0.1 InetAddress.getAllByName() for empty string returns [localhost/127.0.0.1] Is it intentional for these APIs to behave this way for empty string? Yes. If so, should the javadoc be updated to explicitly state this behaviour? Yeah, probably. The following JIRA issue has been filed to track this: https://bugs.openjdk.java.net/browse/JDK-8201545 -Chris.
InetAddress.getByName/getAllByName for empty host string
The javadoc of InetAddress.getByName(host) and getAllByName(host) states that: If the host is null then an InetAddress representing an address of the loopback interface is returned. For non-null values the javadoc explains what the implementation does. However, there seems to be no mention of what it does with an empty string (length == 0) value for the host param. Right now, the implementation seems to treat an empty value the same way it treats the host == null case and returns an InetAddress representing the loopback address. Consider the following example: public class InetAddressTest { public static void main(final String[] args) throws Exception { System.out.println("InetAddress.getByName() for empty string returns " + java.net.InetAddress.getByName("")); System.out.println("InetAddress.getAllByName() for empty string returns " + java.util.Arrays.toString(java.net.InetAddress.getAllByName(""))); } } This outputs: InetAddress.getByName() for empty string returns localhost/127.0.0.1 InetAddress.getAllByName() for empty string returns [localhost/127.0.0.1] Is it intentional for these APIs to behave this way for empty string? If so, should the javadoc be updated to explicitly state this behaviour? -Jaikiran