说说Java 7中的模块系统基本概念

以下是本人的一些分享，我热爱编程，希望能多交编程的爱好者，如果你也是其中一名，那么请加好友，大家关注一下，下面的文章是自己觉得一些有用的东西，留下来给自己当笔记，当然也希望能帮助到你，首先感谢你的阅读~！
　　笔者在观看过Devoxx关于Jigsaw的一段演示后，我很兴奋，觉得它应该会是针对复杂类路径版本问题和JAR陷阱等问题的解决方案。开发者最终能够使用他们所期望的任何Xalan版本，而无需被迫使用授权机制。不幸的是，通往更加有效的模块系统的征途并不是很清晰。

　　在研究确实问题之前，我们先来看一些基本概念：

　　模块化

　　模块化是解决复杂性问题很重要的工具。把应用分成不同的部分（模块、库、包、子项目和组件），再分别进行计算，是行之有效的方式。模块化的最终目的是能定义出一套API用于模块间的沟通。

　　如果模块间所有的通讯都只通过这种API来实现，那么模块是松耦合的，于是：

　　改变某个模块的实现会很容易

　　开发和测试各个模块能很容易独立开来

　　面向对象模式也是类似的道理。在OOP中，理想的状况是拥有大量小的、可重用的、简单并分离良好的对象。在模块系统中，就可以完美地实现小的、可重用的、简单并分离良好的模块。它们的想法和最初的动机是完全一样的，只是规模有所不同。

　　逻辑分离

　　传统上，java中有两种办法来实现模块化。逻辑分离是最自然的方式。它包括将应用程序分割成逻辑模块（子项目），最后再部署成一个完整的应用。通过定义正确的包来实现逻辑分离也是可能的，但更通用的办法是把应用分割成一些存档文件（也就是JAR包）。逻辑分离里能促进模块的重用，有助实现模块间的松耦合。你甚至有可能定义一个API,然后宣布所有模块间的通讯都要通过这个给定的API来实现。这样的想法有个大问题，那就是你很难强破大家都采用这种限制性用法，而且没有任何一种机制能够确保这个API的用法。你也没法把那些应用通过给定模块来使用的类和作为公共API一部分的类区分开来。如果一个类是" 公共的",那它就可以被任何其他类使用，无论调用它的那个类属于哪个模块。另一方面，受保护的或者包级可见性的类在其模块内部的调用也有限制。通常来说，涵盖了一些包以及包中类的模块需要能够互相调用。因此即使某个应用是由一些逻辑模块组成，但如果这些模块是耦合的，那么分离也根本没有用处。

　　物理分离

　　另外一个传统的办法就是物理上的分离。你可以通过将应用分割成不同的组件，然后把每个组件部署到不同的JVM上而实现分离。这些组件间通过远程访问机制进行通讯，比如RMI、CORBA或者WebServices.物理分离实现了分离，也实现了松耦合，但负面影响是开支很大。为实现分离而专门采用远程访问机制，有点杀鸡用牛刀的味道。这会增加开发和部署不必要的复杂性，性能上所受到的影响也不能忽视的。

　　模块系统

　　模块系统的作用位于逻辑分离和物理分离之间。它强调模块分离，但各个模块仍然部署到同一个JVM中，而且模块间的通讯由简单传统的方法调用组成，因此不会有运行时的开支负担。在java生态系统中最流行的模块框架是OSGi.它是一个成熟的规范，具有几个不同的实现。在OSGi中，模块被称作bundle,每个bundle等同于一个JAR.每个bundle也包含一个 META-INF/MANIFEST.MF文件，这个文件会宣布导出哪些包（package）以及导入哪些包。只有那些导出包中的类才能被其他 bundle所使用，而其他包都只面向包的内部成员，包里的类也只能在自身bundle中使用。

　　比如下面这个声明：

　　Manifest-Version: 1.0

　　Import-Package: net.krecan.spring.osgi.common

　　Export-Package: net.krecan.spring.osgi.dao

　　Bundle-Version: 1.0.0

　　Bundle-Name: demo-spring-osgi-dao

　　Bundle-SymbolicName: net.krecan.spring-osgi.demo-spring-osgi-dao

　　这个规范指定了名叫demo-spring-osgi-dao的bundle,它要导入包名为 net.krecan.spring.osgi.common中的类，并导出包名为net.krecan.spring.osgi.dao中的类。换句话说，这段声明表明其他模块只能使用net.krecan.spring.osgi.dao包。相反地，这个模块要使用的则只是 net.krecan.spring.osgi.common包，而且也可能会由OSGi来提供专门的模块负责导出这个包。当然你完全可以在导入和导出声明中定义多个包名。

　　需要特别注意的是，OSGi的模块化是构建在Java之上的。它不是语言的一部分！这里的模块分离虽然可以由GUI来执行，但不可以由编译器来执行。运行基于OSGi的应用时，你会需要一个OSGi的容器。这个容器可能是运行时环境的一部分，比如在Spring DM服务器中，也可能是嵌入在应用程序中的。这个容器不仅负责提供分离，也提供了其他诸如安全、模块管理和生命周期管理之类的服务。OSGi还提供大量其他有趣的特性，但这些并不是本文所要关注的。
　　总结

　　当然，我相信Sun的工程师并不想要破坏Java本身。我想他们也是为了让Java变得更好、更易于使用，但我担心政治和市场因素会远大于技术影响。再次声明，这不会仅仅是个API的变化或者是特定于Sun的变化。这会是语言级别的变化！一旦语言被改变了，一旦添加了"module"关键字，就不会再有回头路。到那时，Java中会有个模块系统，无论喜不喜欢，我们都非得要用到这个模块系统。真得很难想象带模块化的JVM,也很难想像Java语言中会有个 "module"关键字，而我们还要在这之上使用OSGi.
在互联网时代，JAVA语言已经是使用最广泛的服务器端语言。随着3G、物联网时代的到来，JAVA语言并不会“过时”，相反，JAVA语言会在新的业务领域有着更辉煌的发展前景。
学员，迅速成长为中国高端IT培训领军品牌。