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

[vyom]

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

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