La pregunta del millón es: “¿Qué es OSGi?” La respuesta más simple a esta pregunta es que se trata de una capa de modularidad para la plataforma Java. Por supuesto, la siguiente pregunta que podría surgir es: “¿Qué se entiende por modularidad?” Aquí usamos modularidad en el sentido tradicional, donde el código de la aplicación de software se divide en partes lógicas que representan intereses separados.

Aunque Java ofrece una serie adecuada de modificadores de acceso para controlar la visibilidad (por ejemplo, public, protected, private y el acceso por paquete), estos tienden a abordar la encapsulación orientada a objetos a nivel bajo y no abordan realmente la partición lógica del sistema. Java cuenta con el concepto de paquete, que se utiliza típicamente para organizar el código. Para que el código sea visible desde un paquete Java hacia otro, debe declararse como public (o protected si se usa herencia). A veces, la estructura lógica de una aplicación requiere que cierto código pertenezca a diferentes paquetes, pero esto significa que cualquier dependencia entre los paquetes debe ser expuesta como public, lo cual lo hace accesible para cualquier otro. Con frecuencia, esto puede exponer detalles de la implementación, lo que dificulta la evolución futura, ya que otros usuarios pueden llegar a depender de su API que no está destinada a ser pública.

Considere el siguiente ejemplo:

// #1
package org.foo.hello;
public interface Greeting {
 
void sayHello();
}

// #2
package org.foo.hello.impl;
import org.foo.hello.Greeting;
 
  public class GreetingImpl implements Greeting {
    final String m_name;
    public GreetingImpl(String name) {
 
      m_name = name;
    }
 
   public void sayHello() {
    System.out.println("Hello, " + m_name + "!");
   }
}

// #3
package org.foo.hello.main;
importimportorg.foo.hello.Greeting;
org.foo.hello.impl.GreetingImpl;
 
public class Main {
  public static void main(String[] args) {
    Greeting greet = new GreetingImpl(“Hello World”);
    greet.sayHello();
  }
}

En el código anterior, el autor pudo haber tenido la intención de que un software tercerizado interactuara con la aplicación a través de la interfaz Greeting en (#1). Puede que haya mencionado esto en Javadoc, tutoriales, blogs o incluso en correos electrónicos, pero en realidad no hay nada que impida que una tercera parte construya una nueva instancia de GreetingImpl usando su constructor público en (#2), como se hace en (#3). Se podría argumentar que el constructor no debería ser público y que no es necesario dividir la aplicación en varios paquetes, lo cual podría ser cierto en este ejemplo trivial. Sin embargo, en aplicaciones del mundo real, la visibilidad a nivel de clase combinada con la organización en paquetes resulta ser una herramienta muy burda para asegurar la coherencia de la API. Al ver cómo una implementación supuestamente privada puede ser accedida por desarrolladores externos, ahora también se debe preocupar por los cambios en las firmas de las implementaciones privadas, además de las interfaces públicas, al realizar actualizaciones.

Este problema surge del hecho de que, aunque los paquetes de Java parecen tener una relación lógica mediante paquetes anidados, en realidad no la tienen. Un error común entre quienes aprenden Java por primera vez es suponer que la relación de paquete padre-hijo otorga privilegios de visibilidad especiales a los paquetes involucrados. Dos paquetes en una relación anidada son equivalentes a dos paquetes que no lo están. Los paquetes anidados son útiles principalmente para evitar conflictos de nombres y ofrecen solo un soporte parcial para la partición lógica del código.