¿La firma de un método en Java incluye su tipo de devolución?

¿La firma del método en una clase / interfaz Java incluye su tipo de devolución?

Ejemplo:

¿Sabe Java la diferencia entre esos dos métodos?

public class Foo { public int myMethod(int param) {} public char myMethod(int param) {} } 

¿O es tal vez solo el nombre del método y la lista de parámetros lo que importa?

Citando de Oracle Docs :

Definición: Dos de los componentes de una statement de método comprenden la firma del método: el nombre del método y los tipos de parámetros.

enter image description here

Dado que la pregunta fue editada para incluir este ejemplo:

 public class Foo { public int myMethod(int param) {} public char myMethod(int param) {} } 

No, el comstackdor no sabrá la diferencia, ya que su firma: myMethod(int param) es la misma. La segunda línea

  public char myMethod(int param) {} 

le dará el error can: el método ya está definido en la clase , lo que confirma aún más la statement anterior.

¿La firma del método de clase en Java incluye el tipo de devolución?

En Java no lo hace, pero en esta JVM lo hace, lo que puede llevar a una confusión obvia.

¿La firma del método de interfaz en Java incluye el tipo de devolución?

Lo mismo que para los methos de clase.

¿O solo el nombre del método y la lista de parámetros?

Nombre del método y tipos de parámetros para Java. Por ejemplo, las anotaciones y nombres de parámetros no importan.

En el nivel de código de byte, el tipo de devolución forma parte de la firma del método. Considera esto

 public class Test1 { public Test1 clone() throws CloneNotSupportedException { return (Test1) super.clone(); } } 

en bytecode hay 2 métodos clone ()

 public clone()LTest1; throws java/lang/CloneNotSupportedException public clone()Ljava/lang/Object; throws java/lang/CloneNotSupportedException 

difieren solo por tipo de devolución.

No, no en Java. El nombre del método y la lista de parámetros son solo para la firma del método . El tipo de devolución no incluye.

Java Language Spec dice

Dos métodos tienen la misma firma si tienen el mismo nombre y tipos de argumentos.

por lo tanto, No, el tipo de devolución no es parte de la firma del método

.

Bro, en java, utilizamos para llamar a los métodos por su nombre y sus parámetros solo para usarlos en nuestro código, como

myMethod (20, 40)

por lo tanto, JAVA solo busca coincidencias de elementos similares en su statement correspondiente (nombre + param), esta es la razón por la cual la firma del método solo incluye el nombre y los parámetros del método. 🙂

La firma del método es solo el nombre y la lista de parámetros.

En JAVA y en muchos otros idiomas, puede llamar a un método sin una variable para mantener el valor de retorno. Si el tipo de devolución es parte de la firma de un método, no hay forma de saber a qué método se llamará al llamar sin especificar la variable que contiene el valor de retorno.

no, en Java, la firma del método no incluye el tipo de devolución, pero sí la statement.

 public String getString(String myString) ^access modifier ^return type ^name ^parameter type and name 

editado en base a los comentarios a continuación 🙂

El tipo de devolución no se incluye en la firma del método. Solo el nombre del método y los parámetros se definen como la firma del método.

Reffer: ‘Métodos de definición’ de Oracle Docs

Usando AspectJ (org.aspectj.lang.reflect.MethodSignature), sí tiene el tipo de devolución

LA FIRMA DEL MÉTODO INCLUYE EL TIPO DE DEVOLUCIÓN.

El comstackdor lo ignora cuando tiene que verificar si hay duplicados. Para Java es ilegal tener dos métodos con la firma que difiera solo por el tipo de devolución.

Trata eso:

 public class Called { public String aMethod() { return ""; } } public class Caller { public static void main(String[] main) { aMethod(); } public static void aMethod() { Called x = new Called(); x.aMethod(); } } 

Cree el proyecto, vaya al directorio bin, copie el Caller.cass en algún lugar. Luego cambie el método llamado:

 public int aMethod() { return 0; } 

Cree el proyecto, verá que tanto Called.class como Caller.class tienen una nueva marca de tiempo. Reemplace la clase de llamada anterior y ejecute el proyecto. Tendrás una excepción:

 java.lang.NoSuchMethodError: it.prova.Called.aMethod()Ljava/lang/String; 

La firma del método es solo el nombre y los parámetros del método. Pero creo que su ejemplo generará un error si estuvieran en la misma clase. Simplemente puede probarlo en cualquier ide y ver que el comstackdor lanzará un error

Si intenta ejecutar el código que ha mencionado en eclipse, tendrá una respuesta sobre qué elementos busca el comstackdor de Java para diferenciar entre los métodos de Java:

 class Foo { public int myMethod(int param) { return param;} public char *myMethod*(int param) { //this line throws an error return param; } } 

El error arrojado es: Método duplicado myMethod (int) en tipo Foo.