¿Usando getter/setter que no sea el campo público para la compatibilidad binaria?

Question

estoy leyendo "diseño práctico API" y encuentro siguiente párrafo:.

"La otra razón para preferir métodos más campos se pueden encontrar en la especificación JVM Se te permite mover un método de una clase a uno de sus superclases y aún mantiene la compatibilidad binaria. Por lo tanto, un método introducido inicialmente como Dimension javax.swing.JComponent. getPreferredSize (Dimension d) puede eliminarse en una nueva versión y moverse a Dimension java.awt.Component.getPreferredSize (Dimension d) , como JComponent es una subclase de Component. Un cambio como este realmente sucedió en JDK 1.2, y esto podría hacerse solo porque el campo fue encapsulado por un método. Una operación como esta no está permitida para los campos. se define en una clase, tiene que permanecer allí antes r para mantener la compatibilidad binaria, que es otra razón para mantener los campos privados "

porque estoy de acuerdo con el uso de getter/setter es una mejor manera. Pero no entiendo por qué mover el campo público a la clase principal romperá la compatibilidad binaria. Debería poder acceder a ese campo a través de la clase secundaria, siempre que sea pública en el padre.

Answer 1

Una vez que un campo se define en una clase, tiene que quedarse allí para siempre para mantener la compatibilidad binaria

Eso sería muy sorprendente:

The Java Language Specification, Java SE 7 Edición , defines el nombre binario de una expresión de acceso de campo no calificada de la siguiente manera:

Dada una expresión legal que denota un acceso de campo en una clase C, haciendo referencia a un campo no constante (§13.4.9) llamado f declarado en un (posiblemente diferente) clase o interfaz D, se define el tipo de clasificación de la referencia de campo como sigue:

• Si el expresión es de la forma Primary.f entonces:
  • Si el tipo de tiempo de compilación de primaria es un tipo de intersección (§4.9) V1 & ... & Vn, entonces el tipo de clasificación de la referencia es V1.
  • De lo contrario, el tipo de Primario en tiempo de compilación es el tipo de calificación de la referencia.

(El Lenguaje de Especificación para Java 1.5 uses el mismo texto)

Es decir, el nombre binario de una expresión de acceso de campo no se refiere al tipo que declara el campo, solo al tipo de expresión primaria que usamos para acceder a ese campo, por lo tanto la superclase de ese tipo declara el campo, el compilador es requiere para emitir el misma referencia de campo en el archivo de clase.

De hecho, cuando he intentado ahora a evolucionar a partir de

package p; 

public class Super { 

} 

package p; 

public class Sub extends Super { 
    public String message; 

    @Override 
    public String toString() { 
     return message; 
    } 
} 

a

package p; 

public class Super { 
    public String message; 
} 

package p; 

public class Sub extends Super { 
    @Override 
    public String toString() { 
     return message; 
    } 
} 

sin recompilar

package p; 

public class Main { 
    public static void main(String[] args) { 
     Sub sub = new Sub(); 
     sub.message = "hello"; 
     System.out.println(sub); 
     System.out.println(sub.message); 
    } 
} 

todavía recibí la salida de

hello 
hello 

, no es LinkageError.

Para concluir, esa afirmación no es válida para Java 7. Puede haber sido cierto para JDK 1.4 o anterior, que se declaró al final de su vida útil hace más de 5 años. De cualquier manera, ¿quizás debería usar un libro mejor/más reciente?

Answer 2

Si no recuerdo mal el libro explica esto, pero no lo tengo a mano actualmente. Creo que se trataba de diferencias sutiles entre el lenguaje Java y el formato de archivo de clase (que también es utilizado por otros lenguajes además de Java).

Revise el libro un poco antes o después. Pregunte si tiene más preguntas sobre esa parte.