On Wed, 24 Feb 2021 16:10:01 GMT, Aleksei Efimov <aefi...@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 > > Thanks for cleaning-up tests, Conor. > NIT: You also update/add the modification year in test headers. > 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? It would depend on how the tool handles such an exception. In my opinion if the HostsFileNameService is being used to resolve addresses in testing the onus falls on the developer to ensure that such a tool can still function correctly in this situation. For example, a tool might silently catch the exception thrown and still function as intended. Or if it did the opposite, a different approach may be needed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2703
