• Jobs
  • About Us
  • professionals
    • Home
    • Jobs
    • Courses and challenges
  • business
    • Home
    • Post vacancy
    • Our process
    • Pricing
    • Assessments
    • Payroll
    • Blog
    • Sales
    • Salary Calculator

0

646
Views
Gradle console () es nulo con el demonio deshabilitado

Estoy usando Gradle 2.13 con Java 1.8.0_121.

Una de nuestras tareas de Gradle se basa en la entrada del usuario.

def user = System.console().readLine('Please enter new user username: ')

Sin embargo, aparece el siguiente error: > Cannot invoke method readLine() on null object

Así que console() debe ser nulo... está bien. Encontré este problema relacionado que sugiere deshabilitar el demonio.

Hice eso y lo ejecuté con ./gradlew configureTask --no-daemon pero obtuve el mismo resultado... el mismo error. Estoy bastante seguro de que no está usando el daemon, ya que recibo el siguiente mensaje: To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/2.13/userguide/gradle_daemon.html.

Entonces, si el demonio Gradle no está causando este problema, ¿qué más podría ser? ¿Alguien más experimentado con Gradle lo sabe?

about 3 years ago · Santiago Trujillo
1 answers
Answer question

0

Gradle dice que necesita ejecutar la compilación en un subproceso debido a algo en su configuración de compilación:

Para cumplir con la configuración de JVM para esta compilación, se bifurcará una nueva JVM.

Y supongo que Gradle crea ese subproceso de una manera que le permite tomar el resultado (que es el valor predeterminado con las API que ofrece Java para generar subprocesos). Como resultado, el subproceso no tiene acceso a la E/S de su terminal y System.console() es nulo dentro de ese proceso: no está conectado a la consola del sistema.

Me dio curiosidad, así que se me ocurrió un script que demuestra el problema (usando Groovy por su concisión, es lo mismo que Java aquí):

 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

Resultado:

 Console for main JVM: java.io.Console@64cd705f Console for child JVM: null Console for child JVM with inherited IO: java.io.Console@3c130745

Entonces, Gradle probablemente esté construyendo el subproceso como p1 en mi ejemplo. Y supongo que debe hacerlo, porque necesita inspeccionar la salida (y no dejar que vaya directamente a la salida del sistema).

Creo que tus únicas soluciones son:

  • encuentre una manera de hacer que Gradle haga la compilación en la JVM principal, sin bifurcarse. No soy un experto en Gradle, así que no sé cómo, pero el mensaje parece implicar que es posible.
  • encontrar otra forma de obtener la entrada del usuario. ¿Quizás un cuadro de diálogo Swing? (No es muy elegante, pero bueno, una compilación que toma la entrada del usuario no es muy elegante en primer lugar, por lo que la forma en que se recopila no importa mucho en este punto)
about 3 years ago · Santiago Trujillo Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Our process Sales
Legal
Terms and conditions Privacy policy
© 2025 PeakU Inc. All Rights Reserved.

Andres GPT

Recommend me some offers
I have an error