java - ¿La adición de una nueva dependencia a una biblioteca, con cambios de API compatibles, afecta la compatibilidad binaria?
c# binary-compatibility (3)
Mi pregunta:
¿La adición de una nueva dependencia a una biblioteca afecta a la compatibilidad binaria, siempre que la API externa de la biblioteca sea compatible con versiones anteriores?
Mi situación:
Mi biblioteca CBOR contiene clases para aritmética de precisión arbitraria (en el espacio de nombres PeterO). (Está en C # y Java; la versión de Java está en un repositorio separado, pero el mismo problema se aplica a ambas versiones).
He movido estas clases a un nuevo espacio de nombres (en PeterO.Numbers), y les he cambiado el nombre (conservando las clases originales por compatibilidad con versiones anteriores), porque el espacio de nombres donde están ahora está destinado a contener solo clases de utilidad. Planeo mover las nuevas clases a una biblioteca separada y hacer que la biblioteca CBOR llame a esa biblioteca como una dependencia, ya que las clases de precisión arbitraria son obviamente útiles fuera de CBOR. (Planeo desaprobar las clases anteriores).
Pero me preocupa que crear una biblioteca separada de esta manera sea un problema de compatibilidad binaria, por lo que no puedo actualizar la versión secundaria, sino también la versión principal. La biblioteca CBOR es la versión 2.3.1 en el momento de este escrito. ¿Puedo hacer esto y cambiar la versión a 2.4, o solo 3.0?
Es mejor evitar agregar una nueva dependencia hasta la próxima versión principal, hasta que, agregar cambios internamente y crear su nueva biblioteca de precisión arbitraria con la misma clase y sincronizarlos sin dependencia.
por lo tanto, para la versión 2.4, agregue cambios en el nuevo espacio de nombres y llámelos de la clase anterior y cree otra biblioteca de clases para clases de precisión arbitraria y sincronícelas hasta la próxima versión principal para la biblioteca CBOR
Siempre que haya empezado con una interfaz y todos los clientes de sus bibliotecas estén conscientes de esa interfaz, estará bien. No importa dónde reside su código en su biblioteca o en una biblioteca fuera de ella, siempre y cuando su biblioteca tenga una interfaz que los clientes entiendan e implemente la interfaz.
Este es un problema histórico que se resolvió hace 15 años por COM (modelo de objeto componente). Mantén tus interfaces separadas de la implementación y eres oro.
Voy a responder por la versión de Java. Esta sección de la especificación del lenguaje Java describe en detalle los cambios que se pueden realizar en las aplicaciones al tiempo que se preserva la compatibilidad binaria.
Por lo que entiendo, sus cambios (aunque pueden afectar a una gran parte de la fuente) son refactorizaciones simples que exponen algunas clases de utilidad a otro módulo, y redirigen a las clases antiguas para que llamen a este nuevo módulo. Esto se describe en la sección sobre Evolución de Paquetes :
Se puede agregar una nueva clase de nivel superior o tipo de interfaz a un paquete sin romper la compatibilidad con los binarios preexistentes, siempre que el nuevo tipo no reutilice un nombre dado previamente a un tipo no relacionado.
Por lo tanto, esto no rompe la compatibilidad binaria con las clases existentes que usan su biblioteca. Cualquier clase existente CBORClient que solía llamar a CBORUtil.doArithmetic() continuará trabajando sin la necesidad de volver a compilarlo, ya que el método todavía está allí, solo su cuerpo ha cambiado para llamar a otro módulo para realizar el cálculo.