现在越来越多的Java开发人员在谈论OSGi是有其道理的。在几年前上学的时候我进行了比较多的Eclipse插件开发，当时就亲身感觉到Eclipse插件体系的灵活与强大，而该体系与OSGi也可谓一脉相承、同气连枝。最近打算重新系统的研究一下OSGi，一边学习一边写一个OSGi探秘系列作为总结，和大家分享，也请大家多给评价和建议。
在这一篇里面，我想先回答一个基本的问题：什么是OSGi？其实如果要很好地回答这个问题，也许先明白是什么导致了OSGi的产生和发展会有些帮助。
相信每个Java程序员都知道Classpath是什么。Java的类加载器(Classloader)是一种分层结构，如下图所示，分为引导类加载器(Bootstrap Class Loader)，扩展类加载器(Extension Class Loader)，系统类加载器(System Class Loader)以及用户定义的类加载器(User-defined Class Loader)。引导类加载器在JVM时负责加载rt.jar里面的类，扩展类加载器负责加载在扩展目录下的jar文件中的类，系统类加载器则在Classpath上面搜索类加载器，用户定义的类加载器则从用户指定的路径（比如一个网络URI）加载类。在该类加载体系中，一个类加载器总是先去上层类加载器加载类，一层一层迭代，当无法找到需要的类时在自己加载。
在这种类加载机制中，存在以下几个问题：1）类版本冲突：当类路径上存在同一个类的不同版本时，如果类加载器找到一个版本，则不再搜索加载下一个版本；2）无法确定jar之间的依赖关系：现有的JAR标准中缺乏对与Jar文件之间依赖关系的定义支持，因此只有在运行时间无法找到所需的类时，才会打出java.lang.ClassNotFoundException，但这通常不能有效帮助开发人员解决问题；3）信息隐藏：如果一个jar在类路径上并且被加载，那么所有该jar中的公共类（public class）都会被加载，无法避免某些类被隐藏从而不被加载。尽管在J2EE中改进了类加载机制，可以支持以war或者ear应用为单元进行加载，但是这些问题还是没有被很好地解决，并且热部署效果让人忧心。
OSGi就是为了克服这些问题而生，却又不局限与这些问题，对Java开发人员而言的确是好多顿大餐。OSGi是一个动态的Java模块（Module）系统，它规定了如何定义一个Module以及这些模块之间如何交互。每个OSGi的Java模块被称为一个bundle。每个bundle都有自己的类路径，可以精确规定哪些Java包和类可以被导出，需要导入哪些其它bundle的哪些类和包，并从而指明bundle之间的依赖关系。另外bundle可以被在运行时间安装，更新，卸载并且不影响整个应用。通过这种方式，分层的类加载机制变成了网状的类加载机制。在应用程序启动之前，OSGi就可以检测出来是否所有的依赖关系被满足，并在不满足时精确报出是哪些依赖关系没被满足。
当然，OSGi不止这些。我会在后续的系列文章中系统介绍什么是OSGi 以及其内部的秘密。