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

[Chris Hegarty]

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
>>>
>