【J2EE】企业级项目开发总结-JBoss Modules

        Java一直使用classpath的方式来加载各种class和jar的资源。

        有什么不妥？

        我们熟知的classpath机制，它会创建一个application类加载器，所有相关jar文件资源提供的class都会被它加载，汇聚成为一个大块。如果有一个很大很复杂的应用，包含很多Jar文件，并且有些jar根本不会被使用，或者有些jar因为依赖管理不好会有多个不同的版本，这个问题很难办。 
 
 
       从JBoss AS7开始，Classloader开始使用全新的JBoss Modules（模块化）。

       模块系统都做了什么？
     
       把所有的jar都被打包成模块，一个模块是一些类、资源的集合，和一个相关的类加载器。一个jar再也不会看到依赖里一个冲突版本的类，或者加载到一个根本不需要加载的资源，而且只有模块被用到才被加载。模块可以表示成另外一个模块的依赖，从依赖里“exported"的类和资源对于依赖它的模块里边的类是可见的。可见是指一个类加载器里加载的类能够“看到”另外一个加载器里的类。“export"一个类或者资源意味着这个类可以被依赖看到。具体是这么实现的，使用module.xml描述文件定义模块，这个描述文件中包含模块的名称，都包含哪些resources（一般一个模块对应一个jar文件，也可以包含多个jar或其它资源），这些resources的版本号，以及这个模块都依赖哪些模块。

       模块系统会负责每一个模块的加载和卸载，而且是实时的，即用的时候加载，不用就卸载，其他不用的不会加载。这样做，首先是资源方面的节省，只有需要的模块才被加载，整个系统的加载速度大大提升了。
 

       JBoss Modules的特性：

       1. 高效的使用内存，提供高性能，多线程类加载实现。

       2. 可扩展的模块加载系统，允许用户配置其他可替代实现的模块定义/加载策略。方便使用的本地模块加载器，能够用一种简单的可预测的结构从文件系统上加载Jar文件，或者是展开的目录。  

       3. 简单的启动过程：提供一系列运行时的API,通过这些API可以加载模块，获得模块的类加载器，在运行时创建模块，扩展JDK service加载机制，使其成为一个能够识别模块，并且能够提供对平台native代码更多的管理。