studio programacion móviles libros gratis español desarrollo desarrollar curso aprende aplicaciones java overload-resolution

java - móviles - manual programacion android español pdf



¿Por qué el método Short llama al método entero? (3)

El compilador prefiere convertir un short en un int lugar de encajarlo en un objeto Short .

public class Yikes { public static void go(Long n) { System.out.print("Long "); } public static void go(Short n) { System.out.print("Short "); } public static void go(int n) { System.out.print("int "); } public static void main(String[] args) { short y = 6; long z = 7; go(y); go(z); } }

Este programa está dando la salida.

int Long

Pensé que la salida era

short Long

¿Cuál es la razón para esto?


La sección de resolución de sobrecarga en el JLS explica por qué:

  1. La primera fase ( §15.12.2.2 ) realiza la resolución de sobrecarga sin permitir la conversión de boxeo o unboxing , o el uso de invocación del método de aridad variable. Si no se encuentra un método aplicable durante esta fase, el procesamiento continúa a la segunda fase.

Esto garantiza que cualquier llamada que fuera válida en el lenguaje de programación Java anterior a Java SE 5.0 no se considerará ambigua como resultado de la introducción de métodos de aridad variable, boxeo implícito y / o unboxing. Sin embargo, la declaración de un método de aridad variable (§8.4.1) puede cambiar el método elegido para una expresión de invocación del método del método dado, porque un método de aridad variable se trata como un método de aridad fija en la primera fase. Por ejemplo, declarar m(Object...) en una clase que ya declara m(Object) hace que m(Object) ya no sea elegido para algunas expresiones de invocación (como m(null)) , como m(Object[]) es más específico.

  1. La segunda fase ( §15.12.2.3 ) realiza la resolución de sobrecarga mientras permite el boxeo y el desempaquetado, pero aún impide el uso de la invocación del método de aridad variable. Si no se encuentra ningún método aplicable durante esta fase, el procesamiento continúa hasta la tercera fase.

En la primera fase, el compilador no incluye el método go(Short n) en su resolución. En su lugar, considera go(int n) es un método aplicable. Este método es aplicable porque un short es la ampliación convertida en un int .


Prueba con este:

En lugar de

public static void go(Short n) { System.out.print("Short "); }

tratar

public static void go(short n) { System.out.print("Short "); }