JDK-8248647 : api/java_net/NetworkInterface/GetByIndex/GetByIndexTests.html fails on Windows 2016
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.net
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2020-07-01
  • Updated: 2020-07-03
  • Resolved: 2020-07-03
Related Reports
Relates :  
JDK-8248703 - Clarify the behavior of java.net.NetworkInterface::equals
Relates :  
JDK-8230132 - java/net/NetworkInterface/NetworkInterfaceRetrievalTests.java to skip Teredo Tunneling Pseudo-Interface
Relates :  
JDK-8022963 - java/net/NetworkInterface/Equals.java fails equality for Windows Teredo Interface
Description
Test api/java_net/NetworkInterface/GetByIndex/GetByIndexTests.html fails on Win 2016

log:
Testcase "test_general(1)" failed with message: Expected equal to : "name:net0 (Teredo Tunneling Pseudo-Interface)", was given: "name:net0 (Teredo Tunneling Pseudo-Interface)"
	at com.sun.tck.lib.Assert.fail(Assert.java:494)
	at com.sun.tck.lib.Assert.assertEquals(Assert.java:179)
	at com.sun.tck.lib.Assert.assertEquals(Assert.java:135)
	at javasoft.sqe.tests.api.java.net.GetByIndex.GetByIndexTests.test_general(GetByIndexTests.java:72)
Testcase "test_general(1)" failed with arguments [name:net0 (Teredo Tunneling Pseudo-Interface), 2]
test_general: Failed. test cases: 8; passed: 7; failed: 1
test_iae: Passed. test cases: 4; all passed
test_null: Passed. test cases: 6; all passed
Comments
OK I'll close this one as a duplicate then. Though fixing JDK-8248703 is not going to make these tests suddenly pass ;-) Fixing JCK-7314461 might.
02-07-2020
My impression was that what's written in JDK-8248703 should be here in JDK-8248647 and this one is expected to be resolved exactly by spec updates.
02-07-2020
Should we close this bug as a duplicate of either JCK-7314461 or JDK-8248703 then?
02-07-2020
Right. Let's replace `@implNote` with `<p> Note:` in my suggestion above.
02-07-2020
Maybe we could improve the API documentation of NetworkInterface::equals: /** * Compares this object against the specified object. * The result is {@code true} if and only if the argument is * not {@code null} and it represents the same NetworkInterface * as this object. * <p> * Two instances of {@code NetworkInterface} represent the same * NetworkInterface if both name and raw IP addresses are the same * for both. * * @implNote Two NetworkInterface objects referring to the same * underlying interface may not compare equals if the addresses * of the underlying interface are beeing dynamically updated by * the system. * * @param obj the object to compare against. * @return {@code true} if the objects are the same; * {@code false} otherwise. * @see java.net.InetAddress#getAddress() */
02-07-2020
[~lmesnik] please use JCK-7314461 for exclusing the test from JCK15 run
02-07-2020
[~alanb] Do you mean that there could be two different interfaces in the system with the same name and the same index? Assert.assertEquals(ni, NetworkInterface.getByIndex(index)); <== this fails where index was obtained by calling ni.getIndex();
02-07-2020
[~dfuchs] Are you sure this is about the tunnel configuration changing while the test is running? I can well imagine that happening but I assume the test also has the potential to fail if the network interface is not unique. No objection to adding an apiNote to make it clear that the two NetworkInterfaces objects created for the same underlying interface may not be equal but there may be other challenges here too.
02-07-2020
> Expected equal to : "name:net0 (Teredo Tunneling Pseudo-Interface)", was given: "name:net0 (Teredo Tunneling Pseudo-Interface)" The test first gets all interfaces, then for each interface gets its index, then call getByIndex() to obtain a new interface object, and then expects that the two objects will be equal. The trace above shows the display names of the two objects, which shows that the name hasn't changed. Given the implementation of equals, it can only means that the list of addresses has changed - because the interface was dynamically reconfigured between the two calls. This is why I suggest that the JCK test should skip the "Teredo" interface on windows, as no assumption can be made on the equality of dynamically reconfigured interfaces given how NetworkInterface::equals is specified. We should probably improve the specification of that method though - it says: * Two instances of {@code NetworkInterface} represent the same * NetworkInterface if both name and addrs are the same for both. (and `addrs` is the name of a private variable in the class).
01-07-2020
It would be useful to get a dump of the network interfaces on this system. I can't tell from the bug report if the issue is that there are many interfaces with the same index or whether there is dynamic configuration at play. If the former then the test could be made more robust by only calling getByIndex with the unique index values. If the issue is that the Teredo tunnel is is changing so that getByIndex returns a non-equal NI each time then there isn't much that can be done as it's not a JDK or spec issue.
01-07-2020
NetworkInterfaces are considered equals if their names match and their addresses match. The Teredo Pseudo-Interface is a special interface on Windows. We usually skip that interface in unit tests - as it can't be used for regular networking and has proved to be problematic in many cases. I wouldn't be surprise if the address of that interface could change over time - which probably explains the strange message: Expected equal to : "name:net0 (Teredo Tunneling Pseudo-Interface)", was given: "name:net0 (Teredo Tunneling Pseudo-Interface)" I'd suggest to update the JCK test to skip Teredo interfaces on windows. See also: JDK-8022963, JDK-8030755, JDK-8230132, JDK-8042370, etc...
01-07-2020