Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

1.5K
Views
Confusión al sobrecargar el método println, en Thread y ExecutorService

Estaba leyendo la Effective Java edition 3 by Joshua Bloch en el artículo 52, página 242. Me encontré con algo extraño que espero que ustedes, los héroes de Java, puedan ayudarme a desmitificar. Cito exactamente del libro:

La adición de lambdas y referencias de métodos en Java 8 aumentó aún más el potencial de confusión en la sobrecarga. Por ejemplo, considere estos dos fragmentos:

 new Thread(System.out::println).start(); ExecutorService exec = Executors.newCachedThreadPool(); exec.submit(System.out::println);

Si bien la invocación del constructor Thread y la invocación del método de envío tienen un aspecto similar, la primera compila mientras que la segunda no. Los argumentos son idénticos (System.out::println), y tanto el constructor como el método tienen una sobrecarga que requiere un Runnable. ¿Que está pasando aqui? La respuesta sorprendente es que el método de envío tiene una sobrecarga que requiere un Callable, mientras que el constructor Thread no. Puede pensar que esto no debería hacer ninguna diferencia porque todas las sobrecargas de println devuelven un valor nulo, por lo que la referencia del método no podría ser un Callable. Esto tiene mucho sentido, pero no es la forma en que funciona el algoritmo de resolución de sobrecarga. Quizás igualmente sorprendente es que la invocación del método de envío sería legal si el método println no estuviera también sobrecargado. Es la combinación de la sobrecarga del método al que se hace referencia (println) y el método invocado (enviar) lo que evita que el algoritmo de resolución de sobrecarga se comporte como cabría esperar.

y el autor continúa dando la razón técnica por la cual el segundo método no compilaría. otra vez no entendí!

el problema es que System.out::println es una referencia de método inexacta [JLS, 15.13.1] y que "ciertas expresiones de argumento que contienen expresiones lambda tipificadas implícitamente o referencias de método inexactas son ignoradas por las pruebas de aplicabilidad, porque su significado no puede ser determinado hasta que se seleccione un tipo de objetivo [JLS, 15.12.2].”

cuando probé el ejemplo de ExecutorService en IDE (Intellij), me dio este error:

 reference to 'println' is ambiguous both 'println()' and 'println(boolean)' match

Si aplico el siguiente cambio, el error de tiempo de compilación desaparece. ¿Cómo este elenco aclara la ambigüedad?

 Executors.newCachedThreadPool().submit((Runnable) System.out::println);

mis preguntas son primero qué está pasando aquí y segundo por qué IDE informó confusión entre println() y println(boolean) . Callable y Runnable no quieren parámetros de entrada, así que por System.out::println definitivamente nos referimos println() en este contexto.

over 4 years ago · Santiago Trujillo
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!