Herencia en la visibilidad del paquete en Java

inheritance overriding

Question

Estoy buscando una explicación para el siguiente comportamiento:

• Tengo 6 clases, {aA, bB, cC, aD, bE, cF}, cada una con un método de paquete visible m () que escribe el nombre de la clase.
• Tengo una clase a.Main con un método principal que hace algunas pruebas de estas clases.
• El resultado parece no seguir las reglas de herencia adecuadas.

Aquí están las clases:

package a;
public class A {
void m() { System.out.println("A"); }
}
// ------
package b;
import a.A;
public class B extends A {
void m() { System.out.println("B"); }
}
// ------
package c;
import b.B;
public class C extends B {
void m() { System.out.println("C"); }
}
// ------
package a;
import c.C;
public class D extends C {
void m() { System.out.println("D"); }
}
// ------
package b;
import a.D;
public class E extends D {
void m() { System.out.println("E"); }
}
// ------
package c;
import b.E;
public class F extends E {
void m() { System.out.println("F"); }
}

La clase principal está en el package a :

package a;
import b.B;
import b.E;
import c.C;
import c.F;
public class Main {
public static void main(String[] args) {
A a = new A();
B b = new B();
C c = new C();
D d = new D();
E e = new E();
F f = new F();
System.out.println("((A)a).m();"); ((A)a).m();
System.out.println("((A)b).m();"); ((A)b).m();
System.out.println("((A)c).m();"); ((A)c).m();
System.out.println("((A)d).m();"); ((A)d).m();
System.out.println("((A)e).m();"); ((A)e).m();
System.out.println("((A)f).m();"); ((A)f).m();
System.out.println("((D)d).m();"); ((D)d).m();
System.out.println("((D)e).m();"); ((D)e).m();
System.out.println("((D)f).m();"); ((D)f).m();
}
}

Y aquí está el resultado:

((A)a).m();
A
((A)b).m();
A
((A)c).m();
A
((A)d).m();
D
((A)e).m();
E
((A)f).m();
F
((D)d).m();
D
((D)e).m();
D
((D)f).m();
D

Y aquí están mis preguntas:

1) Entiendo que Dm() esconde Am() , pero un reparto a A debería exponer el método oculto m() , ¿es eso cierto? ¿O es que Dm() anula Am() a pesar de que Bm() y Cm() rompen la cadena de herencia?

((A)d).m();
D

2) Aún peor, el siguiente código muestra una anulación en efecto, ¿por qué?

((A)e).m();
E
((A)f).m();
F

Y por qué no en esta parte:

((A)a).m();
A
((A)b).m();
A
((A)c).m();
A

¿y éste?

((D)d).m();
D
((D)e).m();
D
((D)f).m();
D

Estoy usando OpenJDK javac 11.0.2.

EDITAR: ¿Cómo anular un método con el alcance de visibilidad predeterminado (paquete) responde a la primera pregunta ?

Un método de instancia mD declarado o heredado por la clase D, anula de D otro método mA declarado en la clase A, si todo lo siguiente es cierto:

• A es una superclase de D.
• D no hereda mA (porque cruza los límites del paquete)
• La firma de mD es una sub firma (§8.4.2) de la firma de mA.
• Uno de los siguientes es cierto: [...]
  • mA se declara con acceso al paquete en el mismo paquete que D (en este caso), y D declara mD o mA es miembro de la superclase directa de D. [...]

PERO: la segunda pregunta sigue sin resolverse.

Answer 1

Entiendo que Dm() oculta Am() , pero un reparto a A debería exponer el método oculto m() , ¿es eso cierto?

No existe tal cosa como ocultar, por ejemplo, métodos (no estáticos). Aquí, es un ejemplo de shadowing . Un reparto a A en la mayoría de los lugares solo ayuda a resolver la ambigüedad (por ejemplo, cm() ya que puede referirse tanto a A#m C#m [que no es accesible desde a ]) que de lo contrario conduciría a un error de compilación.

¿O es que Dm() anula Am() a pesar de que Bm() y Cm() rompen la cadena de herencia?

bm() es una llamada ambigua porque tanto A#m B#m son aplicables si establece el factor de visibilidad a un lado. Lo mismo vale para cm() . ((A)b).m() y ((A)c).m() se refieren claramente a A#m que es accesible para la persona que llama.

((A)d).m() es más interesante: tanto A como D residen en el mismo paquete (por lo tanto, accesible [que es diferente de los dos casos anteriores]) y D hereda indirectamente A Durante el despacho dinámico, Java podrá llamar a D#m porque D#m realmente anula a A#m no hay razón para no llamarlo (a pesar del desorden en la ruta de herencia [recuerde que ni B#m ni C#m anula A#m debido al problema de visibilidad]).

Peor aún, el siguiente código muestra una anulación en efecto, ¿por qué?

No puedo explicar esto porque no es el comportamiento que esperaba.

Me atrevo a decir que el resultado de

((A)e).m();
((A)f).m();

debe ser idéntico al resultado de

((D)e).m();
((D)f).m();

cual es

D
D

ya que no hay forma de acceder a los métodos privados del paquete en c desde a .

Answer 2

Este es un desafío para la mente, de hecho.

La siguiente respuesta aún no es completamente concluyente, pero mis resultados de echar un vistazo a esto. Tal vez al menos contribuye a encontrar una respuesta definitiva. Algunas partes de la pregunta ya han sido respondidas, por lo que me estoy centrando en el punto que todavía causa confusión y aún no se explica.

El caso crítico se puede resumir en cuatro clases:

package a;
public class A {
void m() { System.out.println("A"); }
}

package a;
import b.B;
public class D extends B {
@Override
void m() { System.out.println("D"); }
}

package b;
import a.A;
public class B extends A {
void m() { System.out.println("B"); }
}

package b;
import a.D;
public class E extends D {
@Override
void m() { System.out.println("E"); }
}

(Tenga en cuenta que @Override anotaciones de @Override cuando sea posible; esperaba que esto ya pudiera dar una pista, pero aún no pude sacar conclusiones de eso ...)

Y la clase principal:

package a;
import b.E;
public class Main {
public static void main(String[] args) {
D d = new D();
E e = new E();
System.out.print("((A)d).m();"); ((A) d).m();
System.out.print("((A)e).m();"); ((A) e).m();
System.out.print("((D)d).m();"); ((D) d).m();
System.out.print("((D)e).m();"); ((D) e).m();
}
}

La salida inesperada aquí es

((A)d).m();D
((A)e).m();E
((D)d).m();D
((D)e).m();D

Entonces

• cuando se lanza un objeto de tipo D a A , el método del tipo D se llama
• cuando se lanza un objeto de tipo E a A , el método del tipo E se llama (!)
• cuando se lanza un objeto de tipo D a D , el método del tipo D se llama
• cuando se lanza un objeto de tipo E a D , el método del tipo D se llama

Es fácil detectar el extraño aquí: naturalmente, uno esperaría que lanzar una E a A provoque que se llame al método de D , porque ese es el método "más alto" en el mismo paquete. El comportamiento observado no puede explicarse fácilmente desde el JLS, aunque uno tendría que volver a leerlo, cuidadosamente , para asegurarse de que no haya una razón sutil para eso.

Por curiosidad, eché un vistazo al bytecode generado de la clase Main . Esta es la salida completa de javap -c -v Main (las partes relevantes se desarrollarán a continuación):

public class a.Main
minor version: 0
major version: 52
flags: ACC_PUBLIC, ACC_SUPER
Constant pool:
#1 = Class #2 // a/Main
#2 = Utf8 a/Main
#3 = Class #4 // java/lang/Object
#4 = Utf8 java/lang/Object
#5 = Utf8 <init>
#6 = Utf8 ()V
#7 = Utf8 Code
#8 = Methodref #3.#9 // java/lang/Object."<init>":()V
#9 = NameAndType #5:#6 // "<init>":()V
#10 = Utf8 LineNumberTable
#11 = Utf8 LocalVariableTable
#12 = Utf8 this
#13 = Utf8 La/Main;
#14 = Utf8 main
#15 = Utf8 ([Ljava/lang/String;)V
#16 = Class #17 // a/D
#17 = Utf8 a/D
#18 = Methodref #16.#9 // a/D."<init>":()V
#19 = Class #20 // b/E
#20 = Utf8 b/E
#21 = Methodref #19.#9 // b/E."<init>":()V
#22 = Fieldref #23.#25 // java/lang/System.out:Ljava/io/PrintStream;
#23 = Class #24 // java/lang/System
#24 = Utf8 java/lang/System
#25 = NameAndType #26:#27 // out:Ljava/io/PrintStream;
#26 = Utf8 out
#27 = Utf8 Ljava/io/PrintStream;
#28 = String #29 // ((A)d).m();
#29 = Utf8 ((A)d).m();
#30 = Methodref #31.#33 // java/io/PrintStream.print:(Ljava/lang/String;)V
#31 = Class #32 // java/io/PrintStream
#32 = Utf8 java/io/PrintStream
#33 = NameAndType #34:#35 // print:(Ljava/lang/String;)V
#34 = Utf8 print
#35 = Utf8 (Ljava/lang/String;)V
#36 = Methodref #37.#39 // a/A.m:()V
#37 = Class #38 // a/A
#38 = Utf8 a/A
#39 = NameAndType #40:#6 // m:()V
#40 = Utf8 m
#41 = String #42 // ((A)e).m();
#42 = Utf8 ((A)e).m();
#43 = String #44 // ((D)d).m();
#44 = Utf8 ((D)d).m();
#45 = Methodref #16.#39 // a/D.m:()V
#46 = String #47 // ((D)e).m();
#47 = Utf8 ((D)e).m();
#48 = Utf8 args
#49 = Utf8 [Ljava/lang/String;
#50 = Utf8 d
#51 = Utf8 La/D;
#52 = Utf8 e
#53 = Utf8 Lb/E;
#54 = Utf8 SourceFile
#55 = Utf8 Main.java
{
public a.Main();
descriptor: ()V
flags: ACC_PUBLIC
Code:
stack=1, locals=1, args_size=1
0: aload_0
1: invokespecial #8 // Method java/lang/Object."<init>":()V
4: return
LineNumberTable:
line 5: 0
LocalVariableTable:
Start Length Slot Name Signature
0 5 0 this La/Main;
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=3, args_size=1
0: new #16 // class a/D
3: dup
4: invokespecial #18 // Method a/D."<init>":()V
7: astore_1
8: new #19 // class b/E
11: dup
12: invokespecial #21 // Method b/E."<init>":()V
15: astore_2
16: getstatic #22 // Field java/lang/System.out:Ljava/io/PrintStream;
19: ldc #28 // String ((A)d).m();
21: invokevirtual #30 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
24: aload_1
25: invokevirtual #36 // Method a/A.m:()V
28: getstatic #22 // Field java/lang/System.out:Ljava/io/PrintStream;
31: ldc #41 // String ((A)e).m();
33: invokevirtual #30 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
36: aload_2
37: invokevirtual #36 // Method a/A.m:()V
40: getstatic #22 // Field java/lang/System.out:Ljava/io/PrintStream;
43: ldc #43 // String ((D)d).m();
45: invokevirtual #30 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
48: aload_1
49: invokevirtual #45 // Method a/D.m:()V
52: getstatic #22 // Field java/lang/System.out:Ljava/io/PrintStream;
55: ldc #46 // String ((D)e).m();
57: invokevirtual #30 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
60: aload_2
61: invokevirtual #45 // Method a/D.m:()V
64: return
LineNumberTable:
line 9: 0
line 10: 8
line 11: 16
line 12: 28
line 14: 40
line 15: 52
line 16: 64
LocalVariableTable:
Start Length Slot Name Signature
0 65 0 args [Ljava/lang/String;
8 57 1 d La/D;
16 49 2 e Lb/E;
}
SourceFile: "Main.java"

Lo interesante es la invocación de los métodos:

16: getstatic #22 // Field java/lang/System.out:Ljava/io/PrintStream;
19: ldc #28 // String ((A)d).m();
21: invokevirtual #30 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
24: aload_1
25: invokevirtual #36 // Method a/A.m:()V
28: getstatic #22 // Field java/lang/System.out:Ljava/io/PrintStream;
31: ldc #41 // String ((A)e).m();
33: invokevirtual #30 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
36: aload_2
37: invokevirtual #36 // Method a/A.m:()V
40: getstatic #22 // Field java/lang/System.out:Ljava/io/PrintStream;
43: ldc #43 // String ((D)d).m();
45: invokevirtual #30 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
48: aload_1
49: invokevirtual #45 // Method a/D.m:()V
52: getstatic #22 // Field java/lang/System.out:Ljava/io/PrintStream;
55: ldc #46 // String ((D)e).m();
57: invokevirtual #30 // Method java/io/PrintStream.print:(Ljava/lang/String;)V
60: aload_2
61: invokevirtual #45 // Method a/D.m:()V

El código de bytes se refiere explícitamente al método Am en las dos primeras llamadas, y se refiere explícitamente al método Dm en las segundas llamadas.

Una conclusión que extraigo de eso: ¡El culpable no es el compilador, sino el manejo de la instrucción invokevirtual de invokevirtual de la JVM!

La documentación de invokevirtual no contiene sorpresas, citando solo la parte relevante aquí:

Sea C la clase de objectref. El método real a invocar se selecciona mediante el siguiente procedimiento de búsqueda:

1. Si C contiene una declaración para un método de instancia m que anula (§5.4.5) el método resuelto, entonces m es el método a invocar.

2. De lo contrario, si C tiene una superclase, se realiza una búsqueda de una declaración de un método de instancia que anule el método resuelto, comenzando con la superclase directa de C y continuando con la superclase directa de esa clase, y así sucesivamente, hasta un método de anulación se encuentra o no existen más superclases. Si se encuentra un método de anulación, es el método a invocar.

3. De lo contrario, si hay exactamente un método máximo específico (§5.4.3.3) en las superinterfaces de C que coincide con el nombre y descriptor del método resuelto y no es abstracto, entonces es el método a invocar.

Supuestamente solo sube la jerarquía, hasta que encuentra un método que ( es o) anula el método, con las anulaciones (§5.4.5) definidas como uno esperaría naturalmente.

Todavía no hay una razón obvia para el comportamiento observado.

Luego comencé a mirar lo que realmente sucede cuando se encuentra un invokevirtual , y profundizo en la función LinkResolver::resolve_method de OpenJDK, pero en ese momento, no estoy completamente seguro de si este es el lugar correcto para mirar, y Actualmente no puedo invertir más tiempo aquí ...

Quizás otros puedan continuar desde aquí, o encontrar inspiración para sus propias investigaciones. Al menos el hecho de que el compilador hace lo correcto, y la peculiaridad parece estar en el manejo de invokevirtual , podría ser un punto de partida.

Answer 3

Interesante pregunta. Lo comprobé en Oracle JDK 13 y Open JDK 13. Ambos dan el mismo resultado, exactamente como lo escribió. Pero este resultado contradice la especificación del lenguaje Java .

A diferencia de la clase D, que está en el mismo paquete que A, las clases B, C, E, F están en un paquete diferente y debido a la declaración privada del paquete de Am() no puede verlo ni anularlo. Para las clases B y C funciona como se especifica en JLS. Pero para las clases E y F no lo hace. Los casos con ((A)e).m() y ((A)f).m() son errores en la implementación del compilador de Java.

¿Cómo debería funcionar ((A)e).m() y ((A)f).m() ? Dado que Dm() anula Am() , esto debería ser válido también para todas sus subclases. Por lo tanto, tanto ((A)e).m() como ((A)f).m() deben ser lo mismo que ((D)e).m() y ((D)f).m() , significa que todos deberían llamar a Dm() .