[joseluisll]

Fixes #3456.

What

systemPropertyVariables were applied too late in the forked JVM, so java.net.preferIPv4Stack (and java.net.preferIPv6Addresses) were silently ignored and the fork kept running on the IPv6 stack. Reported against 3.6.0, hit by Hadoop in HADOOP-19964.

Why

ForkedBooter#setupBooter read the booter properties file before applying the effective system properties:

BooterDeserializer booterDeserializer =
        new BooterDeserializer(createSurefirePropertiesIfFileExists(tmpDir, surefirePropsFileName));
setSystemProperties(new File(tmpDir, effectiveSystemPropertiesFileName));

That was harmless while the file was read with FileInputStream. In 3.6.0, commit 0c24343 (#3179) changed createSurefirePropertiesIfFileExists to java.nio.file.Files.newInputStream, and that call chain is:

Files.newInputStream → FileChannel → sun.nio.ch.UnixFileDispatcherImpl (WindowsFileDispatcherImpl) → static { IOUtil.load(); } → BootLoader.loadLibrary("net")

libnet's JNI_OnLoad calls Boolean.getBoolean("java.net.preferIPv4Stack") once and caches the answer in ipv6_available. So by the time setSystemProperties ran, the networking stack was already fixed, and the property had no effect — silently, and only on machines that actually have IPv6.

Ordinary java.nio.file calls are not enough to trigger this on Unix — sun.nio.fs.UnixNativeDispatcher loads only "nio" — which is why the file-reading path specifically is what regressed.

How

• setSystemProperties(...) is now the first statement of setupBooter, before anything else in the fork runs.
• createSurefirePropertiesIfFileExists uses FileInputStream again, so the guarantee does not silently depend on which java.io/java.nio API a future change happens to pick. Both spots carry a comment explaining why.

Platform caveat

Windows cannot be fixed this way and never worked, including before 3.6.0. sun.nio.fs.WindowsNativeDispatcher loads the native library itself:

static {
    // nio.dll has dependency on net.dll
    jdk.internal.loader.BootLoader.loadLibrary("net");
    jdk.internal.loader.BootLoader.loadLibrary("nio");
    initIDs();
}

Opening any jar on the class path reaches that (ZipFile$Source stats the file through java.nio.file), so java.net.preferIPv4Stack is already frozen before main runs. Users who need it on Windows have to pass -Djava.net.preferIPv4Stack=true via argLine. The new integration test is skipped on Windows for this reason.

Tests

• ForkedBooterMockTest.shouldReadSurefirePropertiesWithoutInitializingNio — pins the booter properties file to a non-NIO stream. Fails on the 3.6.0 code, passes with this change.
• Surefire3456PreferIPv4StackIT — runs a project configured with <java.net.preferIPv4Stack>true</java.net.preferIPv4Stack> in systemPropertyVariables and asserts the fork really is on the IPv4 stack (no Inet6Address reported by NetworkInterface). Skipped on Windows per the caveat above.

Verified locally: mvn clean install is green, and ForkedBooterMockTest fails as expected when the Files.newInputStream call is put back. The new IT was exercised on Windows only, where it fails without the fix on the property-propagation path and is skipped by the OS assumption in its final form — I have no Linux box here, so the IT's positive path needs CI to confirm.

Checklist

• Each commit in the pull request should have a meaningful subject line and body.

• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.

• Run mvn clean install to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.

• You have run the integration tests successfully (mvn -Prun-its clean install). — only the new IT was run locally; the full suite was not.

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

🤖 Generated with Claude Code

[olamy]

LOL back in the 90's 🙄 🤣