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)