Paquetes divididos en Java simple

Question

OSGi tiene un problema con los paquetes divididos, es decir, el mismo paquete pero alojado en múltiples paquetes.

¿Hay casos extremos en los que los paquetes divididos puedan presentar problemas en Java simple (sin OSGi)?

Simplemente curioso.

Answer 1

Los paquetes OSGi en diferentes paquetes son diferentes, independientemente de su nombre, porque cada paquete usa su propio cargador de clases. No es un problema sino una característica, asegurar la encapsulación de paquetes.

Entonces, en Java normal, esto normalmente no es un problema, hasta que comience a usar algún marco que use cargadores de clases. Ese suele ser el caso cuando se cargan los componentes.

Answer 2

De dónde vienen los paquetes divididos

Paquetes divididos (en OSGi) ocurre cuando se usa el encabezado del manifiesto Require-Bundle (tal como está, creo, en los manifiestos de Eclipse). Require-Bundle nombra otros paquetes que se usan para buscar clases (si el paquete no es Import ed). La búsqueda se realiza antes de que se busquen los propios classpath. Esto permite que las clases para un solo paquete se carguen desde las exportaciones de paquetes múltiples (probablemente tarros distintos).

La sección 3.13 de la especificación OSGi (4.1) describe Require-Bundle y tiene una larga lista de consecuencias (inesperadas) de usar este encabezado (¿debería este encabezado estar en desuso?), una sección de las cuales es dedicado a paquetes divididos . Algunas de estas consecuencias son extrañas (y más bien específicas de OSGi), pero la mayoría se evitan si comprende una cosa:

• si más de un paquete proporciona un clase/c> (en un paquete) por más de un paquete, entonces está en problemas.

Si las partes del paquete están separadas, entonces todas deberían estar bien, excepto que es posible que no tenga las clases visibles en todas partes y que los miembros de la visibilidad del paquete puedan parecer privados si se ven desde un " incorrecto " parte de un paquete dividido.

[Por supuesto que es demasiado simple & # 8212; se pueden instalar varias versiones de paquetes & # 8212; pero desde el punto de vista de la aplicación en cualquier momento todas las clases de un paquete deben provenir de una módulo único.]

¿Qué sucede en 'Java estándar'

En Java estándar, sin cargadores de clase sofisticados, tiene una ruta de clase y el orden de búsqueda de archivos (y directorios) de clases para cargar es fijo y está bien definido: lo que obtiene es lo que obtiene. (Pero entonces, abandonamos la modularidad manejable).

Claro, puede tener paquetes divididos & # 8212; es bastante común de hecho & # 8212; y es una indicación de una modularidad deficiente. Los síntomas pueden ser oscuros errores de compilación / tiempo de compilación, pero en el caso de implementaciones de múltiples clases (una sobrepasa al resto en una única ruta de clase) con mayor frecuencia produce un comportamiento oscuro en el tiempo de ejecución, debido a una semántica sutilmente diferente .

Si tienes lucky terminas mirando el código incorrecto & # 8212; sin darte cuenta & # 8212; y preguntándote a ti mismo "pero cómo puede estar haciendo eso" that ? "
Si eres mala suerte estás buscando el código correcto y preguntando exactamente lo mismo & # 8212; porque algo más estaba produciendo respuestas inesperadas.

Esto no es totalmente diferente al antiguo adagio de la base de datos: " si grabas la misma información en dos lugares, muy pronto ya no será el mismo " ;. Nuestro problema es que "bastante pronto" normalmente no es lo suficientemente pronto.

Answer 3

La división de paquetes en tarros probablemente no sea una gran idea. Sugiero hacer todos los paquetes dentro de los frascos sellados (ponga " Sealed: true " en la sección principal del manifiesto). Los paquetes sellados no se pueden dividir entre frascos.

En el caso de OSGi, las clases con el mismo nombre de paquete pero un cargador de clases diferente se tratan como si estuvieran en paquetes diferentes.

Answer 4

Obtendrás un error de ejecución desagradable si tienes clases en el mismo paquete y algunas están en un JAR firmado, mientras que otras no.

Answer 5

¿Está preguntando porque el paquete en cuestión es suyo, no un código de terceros?

Un ejemplo sencillo sería una aplicación web con capas de servicio y persistencia como paquetes OSGi separados. Las interfaces de persistencia tendrían que ser compartidas por ambos paquetes.

Si he interpretado su pregunta correctamente, ¿la solución sería crear un JAR sellado que contenga las interfaces compartidas y hacerlo parte de ambos paquetes?

No quiero intentar secuestrar el hilo. Solicito aclaraciones y una mejor perspectiva de aquellos que podrían haber hecho más con OSGi hasta la fecha que yo.