As a follow-on from #14042, Logstash will not build on Windows when using 11.0.15+10, 17.0.3+7 versions of the JDK, regardless of whether the workaround -Djdk.io.File.enableADS=true is set.

After some investigation work, this appears to be down to how gradle passes System properties to its build daemon - only certain values specified in org.gradle.jvmargs in gradle.properties are included in the command line invocation of the build daemon. While -Xmx settings are passed through, most system properties set via -D are not - only a fixed set of immutable properties

file.encoding
user.language
user.country
user.variant
java.io.tmpdir
javax.net.ssl.keyStore
javax.net.ssl.keyStorePassword
javax.net.ssl.keyStoreType
javax.net.ssl.trustStore
javax.net.ssl.trustStorePassword
javax.net.ssl.trustStoreType
com.sun.management.jmxremote

will be added to the command-line parameters, with other system properties set at runtime.

Unfortunately, this is too late for the setting of -Djdk.io.File.enableADS=true to take effect, causing builds to fail when they attempt to open the NUL: device for the specific JDK's in question.

Simple reproducer:

build.gradle

println(System.getProperty("jdk.io.File.enableADS"))
  try{ 
    new java.io.FileOutputStream("NUL:")
    println("success")
  } catch (Exception e) { 
    println(e.getMessage()) 
}

gradle.properties

org.gradle.jvmargs=-Xmx1g -Djdk.io.File.enableADS=true 

Will result in the following output when run on a Windows box running one of the affected JVM;s

C:\Users\rob_bavey>gradlew
> Configure project :
true
java.io.FileNotFoundException: Invalid file path

This happens regardless of whether the gradle wrapper is called with -Djdk.io.File.enableADS=true or if an attempt is made to disable the gradle daemon