[OFFLIST] Re: RFR 8016521: InetAddress should not always re-order addresses returned from name service

Tue May 17 13:53:24 UTC 2016

[OFFLIST]

The code changes, test updates, etc are done. But we need a CCC request,
because you are effectively changing a "public interface”, i.e. the set of
allowable values for the documented system property.

Are you familiar with CCC?
  http://ccc.us.oracle.com

-Chris.

On 17 May 2016, at 14:36, vyom <vyom.tewari at oracle.com> wrote:

> Hi Chris,
> 
> Please find the updated webrev(http://cr.openjdk.java.net/~vtewari/8016521/webrev0.3/index.html <http://cr.openjdk.java.net/%7Evtewari/8016521/webrev0.3/index.html>). i have did the changes as you suggested.
> 
> Thanks,
> Vyom
> 
> 
> On Tuesday 17 May 2016 05:04 PM, Chris Hegarty wrote:
>> 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
>>>>>>> 
> 