[13u, 11u] RFR: 8236441: Bound MulticastSocket fails when setting outbound interface on Windows

Alex Kashchenko akashche at redhat.com
Wed Apr 29 14:19:22 UTC 2020


Hi,

Please review backports of 8236441 to 13u and 11u:

Bug: https://bugs.openjdk.java.net/browse/JDK-8236441

Original change: https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde

Original review thread: 
https://mail.openjdk.java.net/pipermail/net-dev/2019-December/013458.html

Patches to NetworkInterface_winXP.c and 
TwoStacksPlainDatagramSocketImpl.c apply cleanly to both 13u and 11u. 
Minor changes were required for IPMulticastIF.java test.


13u webrev: https://cr.openjdk.java.net/~akasko/jdk13u/8236441/webrev.00/

Test is changed in 13 because behaviour of getOption(IP_MULTICAST_IF) 
was changed in 14 in JDK-8233307 [1]. So in testGetOptionBound and 
testGetOptionUnbound this line [2]:

assertEquals(ms.getOption(IP_MULTICAST_IF), null);

was changed to:

NetworkInterface ni = ms.getOption(IP_MULTICAST_IF);
if (null != ni) { // JDK-8233307: return value changed
     assertEquals(ni.getName(), null);
}


11u webrev: https://cr.openjdk.java.net/~akasko/jdk11u/8236441/webrev.00/

In addition to the change above, jdk.test.lib.net.IPSupport class was 
added in 13 in 8220673 [3] and 8223652 [4]. It is not clear, whether 
these changes to test code should be backported to 11u. In the webrev 
above usage of IPSupport is removed (this line [5]). If it is preferred 
to have these changes backported to 11 before 8236441 - please let me 
know, I can work on backporting them.

Besides that, jdk.test.lib.NetworkConfiguration in 11u lacks 
multicastInterfaces method that was added in 8207404 [6]. Likewise the 
above, it is not clear whether this change should be backported to 11u, 
so its call [7] is changed from:

nc.multicastInterfaces(true)

to:

Stream.concat(nc.ip4MulticastInterfaces(), 
nc.ip6MulticastInterfaces()).distinct()


Testing: test is included with the patch, also ran regression and 
compatibility tests for MulticastSocket.


PS: regarding 13u, it is not clear, what would be the correct process 
for such backports: whether it should be backported to 13 first and to 
11 only after that, whether it should go to 13 at all (P2 issue, but not 
security related) etc. From the local backporting process point of view, 
checking the patch with 13 first, and then moving to 11 and 8 seems to 
be the most convenient.


[1] https://bugs.openjdk.java.net/browse/JDK-8233307
[2] https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde#l3.158
[3] https://bugs.openjdk.java.net/browse/JDK-8220673
[4] https://bugs.openjdk.java.net/browse/JDK-8223652
[5] https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde#l3.59
[6] https://bugs.openjdk.java.net/browse/JDK-8207404
[7] https://hg.openjdk.java.net/jdk/jdk14/rev/97744abc4fde#l3.69


-- 
-Alex



More information about the jdk-updates-dev mailing list