RFR 8016521: InetAddress should not always re-order addresses returned from name service

[Chris Hegarty]

On 17 May 2016, at 10:48, vyom <vyom.tewari at oracle.com> wrote:

> Hi Chris,
> 
> Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.2/index.html <http://cr.openjdk.java.net/%7Evtewari/8016521/webrev0.2/index.html>).

This looks good Vyom. Thanks.

One additional change is needed. Apologies, I forgot that the specification
of java.net.preferIPv6Addresses was in the source tree and not in the 
guides.  We will need to update this, something similar to...

diff --git a/src/java.base/share/classes/java/net/doc-files/net-properties.html b/src/java.base/share/classes/java/net/doc-files/net-properties.html
--- a/src/java.base/share/classes/java/net/doc-files/net-properties.html
+++ b/src/java.base/share/classes/java/net/doc-files/net-properties.html
@@ -58,7 +58,8 @@
 	applications that depend on the representation of an IPv4 address
 	(e.g. 192.168.1.1). This property can be set to <B>true</B> to
 	change that preference and use IPv6 addresses over IPv4 ones where
-	possible.</P>
+	possible, or <B>system</B> to preserve the order of the addresses as
+    returned by the operating system.</P>
 </UL>
 <P>Both of these properties are checked only once, at startup.</P>
 <a name="Proxies"></a>

If you agree, can you fold it into your patch, and generate a changeset.

-Chris.

> Thanks,
> Vyom
> 
> 
> On Friday 13 May 2016 06:33 PM, Chris Hegarty wrote:
>> Vyom,
>> 
>> On 13/05/16 08:23, vyom wrote:
>>> Hi,
>>> 
>>> Please find the updated
>>> webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.1/index.html
>>> <http://cr.openjdk.java.net/%7Evtewari/8016521/webrev0.1/index.html>), i
>>> incorporated the review comments.
>> 
>> This addresses my comments regarding the code. I'm still not
>> sure what, if anything, we can do in the area of testing, but
>> maybe that could be done as a follow up.
>> 
>> One final comment, that I missed earlier. I think
>> preferIPv6Address can be made final, if you remove the '-1'
>> initializer.
>> 
>> -Chris.
>> 
>>> Thanks,
>>> Vyom
>>> 
>>> 
>>> On Thursday 12 May 2016 09:57 PM, Chris Hegarty wrote:
>>>> On 10 May 2016, at 20:52, ecki at zusammenkunft.net wrote:
>>>> 
>>>>> Hello,
>>>>> 
>>>>> Love it.
>>>> Yes, this is along the same lines as I was thinking.
>>>> 
>>>>> Not sure about two things, first of all if there are more test cases
>>>>> (especially assertions) needed and
>>>> Right. Maybe a new test that, 1) runs in all three modes, and 2) asserts
>>>> that the order of addressed returned from several different InetAddress
>>>> getXXX calls, is consistent with what we expect. Though, I’m not sure how
>>>> to check ‘system’ other than it must contain the same set of addresses
>>>> as 'false' or ‘true’.
>>>> 
>>>> I wonder if being able to successfully create a
>>>> java.io.channels.DatagramChannel.open(StandardProtocolFamily.INET6)
>>>> is a reliable way to tell if IPv6 is supported.
>>>> 
>>>>> secondly how to handle the prefer=System case for anyAddr and local.
>>>>> Currently it seems to prefer v4 (since this is the current default)
>>>>> howver i would expect in the system case to either detect the
>>>>> prefered AF or use ipv6 (as of rfc). Returning 127.0.1/0.0.0.0 might
>>>>> actually make the system based address detection unuseable in v6
>>>>> scenarios.
>>>> I agree. Specifically you talking about Inet6AddressImpl
>>>> anyLocalAddress() and loopbackAddress(), right?
>>>> I think the changes in Inet6AddressImpl need to check:
>>>> 
>>>>    if (InetAddress.preferIPv6Address == PREFER_IPV6_VALUE ||
>>>>        InetAddress.preferIPv6Address == PREFER_SYSTEM_VALUE)
>>>> 
>>>> InetAddressImplFactory already checks for ‘isIPv6Supported’ when
>>>> determining which impl to create. If an Inet6AddressImpl is created,
>>>> then IPv6 is supported on the system, therefore either
>>>> PREFER_SYSTEM_VALUE or PREFER_IPV6_VALUE should
>>>> cause anyLocalAddress() and loopbackAddress() to return an
>>>> Inet6Address.
>>>> 
>>>> 
>>>> Other minor comments:
>>>>   Inet6AddressImpl.java: can you statically import the int values
>>>>   unix Inet6AddressImpl.c. missing space, ‘if(…)’ L 445
>>>> 
>>>> -Chris.
>>>> 
>>>>> Gruss
>>>>> Bernd
>>>>> -- 
>>>>> http://bernd.eckenfels.net
>>>>> 
>>>>> -----Original Message-----
>>>>> From: vyom <vyom.tewari at oracle.com>
>>>>> To: net-dev <net-dev at openjdk.java.net>
>>>>> Sent: Di., 10 Mai 2016 12:36
>>>>> Subject: RFR 8016521: InetAddress should not always re-order
>>>>> addresses returned from name service
>>>>> 
>>>>> Hi All,
>>>>> 
>>>>> Please review the code changes for the below issue.
>>>>> 
>>>>> Bug       : JDK-8016521 : InetAddress should not always re-order
>>>>> addresses returned from name service
>>>>> Webrev :
>>>>> http://cr.openjdk.java.net/~vtewari/8016521/webrev0.0/index.html
>>>>> <http://cr.openjdk.java.net/%7Evtewari/8016521/webrev0.0/index.html>
>>>>> 
>>>>> Thanks,
>>>>> Vyom
>>>>> 
>>> 
>