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

[vyom]

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.

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