Java模块化解决方案

   网络上很多OSGi的文章上来就Activator实例，看得云里雾里。要想了解OSGi，首先要知道为什么要用

OSGi？它有哪些好处？

   首先要明确：Java缺少对高级模块化的支持。OSGi服务平台是专门针对Java对模块化支持不足的情况，

由OSGi联盟定义的一个行业标准，它引入了一个面向服务的编程模型，被称作“VM中的SOA”

Java模块化的不足

     为什么说Java缺少对高级模块化的支持？Java确实以面向对象的方式提供了某种程度的模块化，但它从未

考虑支持粗粒度的模块化编程。主要包括三个方面：

1. 可见性问题 / 信息隐藏

• There is no mechanism for information hiding between JARs——JAR文件直接无法实现信息隐藏。

一个Java类，可以是public，也可以是package-private；但是一个Java包呢？Java提供了很多控制可见性的

访问修饰符，但这都是为了解决低层面向对象封装，而不是解决逻辑系统划分。这就导致一个问题：如果类

要在多个包之间可见，那么就必须是public！

例如，com.alpha.interface包定义了若干接口（public），com.alpha.imp包实现了这些接口

（public）；可能你只想向第三方程序暴露com.alpha.interface中的接口，但你却无法阻止客户端直接

new一个实现类，因为你也暴露了 com.alpha.imp包！

如果没有OSGi，就不得不采用下面这种workaround：

• 为了避免暴露非公有API，而把不相干的类放到同一个包中——损害程序的逻辑结构
  而如果保持程序逻辑结构而使用多个包，则又暴露了原本不想暴露的非公有API。

 

2. 易错的classpath

• There is no runtime concept that corresponds to a JAR; they are only meaningful at build-time
• and deploy-time. Once the Java Virtual Ma-chine is running, the contents of all the JARs are simply
• concatenated and treated as a single, global list: the so-called “Classpath”. This model scales very
• poorly.
• They contain no standard metadata to indicate their dependencies.
• They are not versioned, and multiple versions of JARs cannot be loaded simultaneous.

因为classpath隐藏了代码版本、依赖、一致性等特性，所以容易出错！

例如，同一个项目的不同组件，依赖log4j的不同版本；则类路径可能会强制选择某个可能并不合适的版本，

会找到一个并不匹配的Jar，抛出NoSuchMethodEr