Gradle says it needs to run the build in a subprocess because of something in your build settings:
To honour the JVM settings for this build a new JVM will be forked.
And I guess Gradle creates that subprocess in a way that allows it to grab the output (which is the default with the APIs Java offers to spawn subprocesses). As a result, the subprocess does not have access to I/O of your terminal, and System.console()
is null within that process: it is not attached to the system console.
It got me curious so I came up with a script that demonstrates the issue (using Groovy for its conciseness, it's the same thing as Java here):
import java.io.Console
println "Console for main JVM: " + System.console()
Process p1 = new ProcessBuilder("groovy", "-e", "print System.console()")
.redirectErrorStream(true)
.start()
p1.waitFor()
println "Console for child JVM: " + p1.text
Process p2 = new ProcessBuilder("groovy", "-e", "println 'Console for child JVM with inherited IO: ' + System.console()")
.redirectErrorStream(true)
.inheritIO() // <- this changes everything, as now p2 is attached to system console
.start()
p2.waitFor()
// No need to (actually cannot) get output of p2, as I/O is inherited by p2 it gets printed to terminal directly
Result:
Console for main JVM: java.io.Console@64cd705f
Console for child JVM: null
Console for child JVM with inherited IO: java.io.Console@3c130745
So Gradle is probably building the subprocess like p1 in my example. And I guess it needs to, because it needs to inspect the output (and not let it go directly to system output).
I think your only solutions are:
- find a way to get Gradle do the build in the main JVM, without forking. Not a Gradle expert so I don't know how but the message seems to imply it's possible.
- find another way to get user input. Maybe a Swing dialog? (not very elegant but hey, a build that takes user input is not very elegant in the first place, so the way it is collected does not matter much at this point)