Gradle Version: 3.1
Operating System and JVM version: Linux primarily any JVM
Is this a regression? If yes, which version of Gradle do you know it last worked for? Yes, worked in 3.0
With the upgrade to jansi 1.13 a native library now is attempted to be extracted from the bundled jar and then loaded into memory. Unfortunately, this can fail with Could not initialize class org.fusesource.jansi.internal.CLibrary if there is any issue loading that library.
By default this library attempts to extract itself to java.io.tmpdir, which can often be mounted under linux as noexec, and under those conditions it will fail with the “Could not initialize class org.fusesource.jansi.internal.CLibrary” error.
This error can be simulated on windows or linux by simply modifying the DEFAULT_JVM_ARGS for the gradle or gradle.bat scripts and setting -Djava.io.tmpdir=somedirectory-that-does-not-exist
Fortunately, there is also a -Dlibrary.jansi.path that can be set, as altering java.io.tmpdir is only the fallback if that isn’t explicitly set to something.
The failure occurs in ConsoleConfigureAction.java as all other references to jansi classes do not trigger any native library loading. Ideally the library.jansi.path system property would be assigned just before the AnsiConsole.wrapOutputStream() calls. It seems that setting it to gradleUserHome makes sense, unfortunately the two existing classes that provide that lookup capability are not visible to the logging component at present (and they probably shouldn’t be either).
Unfortunately, attempting to pass in system properties via gradle.properties doesn’t work, and attempting to simulate with commandLine argument settings for system properties forces a daemon to start and the actual failure is not displayed other than the daemon failing to start.