Java: compatibilidad binaria de clases y subclases abstractas

Question

En Java, defino una clase abstracta con métodos concretos y abstractos, y tiene que ser subclasificada de forma independiente por desarrolladores externos. Solo para estar seguro: ¿hay algún cambio que pueda hacer en la clase abstracta que sea compatible con sus clases pero no compatible con binarios? En otras palabras: después de que hayan compilado sus subclases, ¿podría cambiar la clase abstracta, aparte de, p. agregarle un método abstracto o eliminar un método protegido de él que se llama por subclases, que por supuesto son incompatibles, de una manera que podría obligarlos a recompilar sus subclases?

Answer 1

Si no es demasiado tarde para cambiar su sistema, sugeriría que se hace eso. Anulación generalmente no es una buena manera de personalizar la funcionalidad, ya que es increíblemente frágil. Por ejemplo, si más adelante utiliza un nombre de método que sus clientes han usado (que ahora están anulando de forma no intencionada), entonces es posible que la anulación rompa completamente las invariantes de su clase. Una forma usualmente mejor de proporcionar personalización es proporcionar a sus clientes una interfaz que se limita al comportamiento personalizado, y luego tiene una clase totalmente concreta que depende de una instancia de esta interfaz, y delega adecuadamente en la interfaz cuando necesita usa los comportamientos personalizados De esta forma, su código y el código de su cliente están completamente separados, y no interferirán entre sí.

Answer 2

Sure.

Puede utilizar accidentalmente un nombre de método que haya usado, que ahora se reemplaza de repente, con resultados tal vez dramáticamente diferentes.

Puede agregar campos a la clase que desordenar serialización etc.

Answer 3

Supongo que está utilizando "incompatibilidad binaria" en el sentido técnico; p.ej. donde el cargador de clases detecta la incompatibilidad y se niega a cargar las clases.

incompatibilidad binaria también podría introducirse si se ha añadido un método visible y declaró final, y que el método chocó con la firma de algún método existente en una subclase de terceros. Sin embargo, si el método no es final, el método existente se convertirá en una anulación de su (nuevo) método que podría causar problemas ... pero no la incompatibilidad binaria.

Del mismo modo, agregar nuevos campos visibles dará lugar a la ocultación, puede dar lugar a un comportamiento confuso y romperá la serialización de objetos. Pero esto no dará como resultado una incompatibilidad binaria.

En general, esto apunta al hecho de que debe tener en cuenta los problemas semánticos de la aplicación, así como la compatibilidad binaria simple. Y el sistema de tipo Java no lo ayudará allí.

Para completar, hay otras cosas que usted puede hacer en su código que romperían la compatibilidad binaria para las clases de 3 ª parte:

• reducir la visibilidad de su clase abstracta y/o de sus métodos,
• cambio de las firmas de otras clases utilizadas como resultado de parámetros y tipos de excepción,
• cambio la cadena de superclases que se extiende a su clase abstracta, o hacer un cambio incompatible en esas clases, o
• cambia el árbol de interfaces de t que su clase abstracta implementa, o hacer un cambio incompatible en esas interfaces.