On 17 May 2016, at 10:48, vyom <vyom.tew...@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, e...@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.tew...@oracle.com>
>>>>> To: net-dev <net-dev@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
>>>>>
>>>
>
