On Wed, 24 Feb 2021 15:54:29 GMT, Michael McMahon <micha...@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
