RFR: 8262195: Harden tests that use the HostsFileNameService (jdk.net.hosts.file property)

[Conor Cleary]

On Wed, 24 Feb 2021 10:24:06 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> A number of net tests use a **[HostsFileNameService](https://github.com/openjdk/jdk/blob/382e38dd246596ec94a1f1ce0e0f9e87f53366c7/src/java.base/share/classes/java/net/InetAddress.java#L955)** to verify either the functionality of this type of Name Service or as a complement to other tests (such as Caching, Address Format etc.).
> 
> Intermittent failures of these tests can be caused by tools used during JVM start-up accessing/initialising classes sooner than may be expected which can cause unexpected behaviour. Most commonly, this unexpected behaviour takes the form of the **[PlatformNameService](https://github.com/openjdk/jdk/blob/382e38dd246596ec94a1f1ce0e0f9e87f53366c7/src/java.base/share/classes/java/net/InetAddress.java#L927)** being used despite a call to `System.setProperty("jdk.net.hosts.file", ...)` in the test file. Due to the fact that **InetAddress** initialises it's Implementation and Name Service fields in a static class initialiser ([see L1132 of InetAddress.java](https://github.com/openjdk/jdk/blob/382e38dd246596ec94a1f1ce0e0f9e87f53366c7/src/java.base/share/classes/java/net/InetAddress.java#L1132)) and that the default mode is to use the **Platform Name Service**, setting a system property in the main method to specify the use of **HostsFileNameService** (with the jdk.net.hosts.file property) 
 has no affect if the class has been previously accessed during JVM start-up and **InetAddress** will default to the **PlatformNameService** which is unsuitable for this test. This explains the intermittent failures caused by the use of `System.setProperty("jdk.net.hosts.file", ...)`.
> 
> This fix improves the robustness of this test by specifying the use of the **HostsFileNameService** in the `@run` tag for this test via the previously mentioned system property. This gives certainty that the property will be properly set in time for the actual run of this test after the JVM has booted. An example of one the fixes...
>  * @run main/othervm -Djdk.net.hosts.file=TestToNumericFormatHosts textToNumericFormat

The following host files have been removed, `test/jdk/java/net/Inet4Address/TestToNumericFormatHosts`, `test/jdk/sun/net/InetAddress/nameservice/simple/DefaultCachingHosts` and `test/jdk/sun/net/InetAddress/nameservice/simple/CacheTestHosts`.

These host files are concerned with `test/jdk/java/net/Inet4Address/textToNumericFormat.java`, `test/jdk/sun/net/InetAddress/nameservice/simple/DefaultCaching.java` and `test/jdk/sun/net/InetAddress/nameservice/simple/CacheTest.java` respectively. 

In the case of the latter two tests in `sun/net/InetAddress/nameservice/simple/`, the hosts file is created from the use of an `addMappingToHostsFile(...)` method which subsequently creates a new FileWriter object.  If the file does not exist, the FileWriter will create it based off of the "jdk.net.hosts.file" property which in the case of these tests will write to the current directory ("user.dir", the paths are relative so `-Djdk.net.hosts.file=some/hosts/file` is valid). If the file does exist, it will write to it as needed by the test. Given that the hosts file is created as needed by the FileWriter, there is less need for either `simple/DefaultCachingHosts` and `simple/CacheTest` to be present.

For `test/jdk/java/net/Inet4Address/textToNumericFormat.java`, there is a little further explanation required. This test is concerned with testing if InetAddress correctly identifies well formatted and badly formatted IP address literals. For example "224.0.1.0" (good) vs. "238.255.255.2550" (bad). The test makes use of `InetAddress.getByName()`which will not perform a lookup if given an IPv4 address. For "good" addresses, a new InetAddress with a null hostName is returned (which is discarded). For "bad" addresses an UnknownHostException is thrown. This behaviour can be seen at InetAddress

If its the case that a PlatformNameService is unexpectedly used, the test behaviour is mostly the same (although there is a chance that the addresses will not be found). However the test will take far longer to complete as the PlatformNameService will attempt to resolve the "good" addresses concerned rather than just cross-check a hosts file. Of course, the original hosts file is empty as we are not actually looking to resolve names, just that InetAddress can detect a textual representation of an IP address. Therefore a hosts file is not needed here, all that is needed is for the HostsFileNameService to be used for name lookups.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2703