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

[Chris Hegarty]

On Wed, 24 Feb 2021 15:54:29 GMT, Michael McMahon <michaelm 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
>
> Looks good to me. Good tidy-up.

If a tool (used during JVM start-up) does more than just initialize the class (maybe it initiates a lookup), then it will find that it is out of luck - the hosts file specified by the property on the command line may not exist. Such a tool would get an UHE with a message similar to: "Unable to resolve host foo as hosts file XXXX not found".  Would this be an issue for such a tool?

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

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