java 程序的依赖大都采用maven来管理，在这种情况下，即使你只需要在artifact 中的一个类，也必须把整个artifact 带入进来，进而把这个artifact的传递依赖都带入进来。这种带入的系统复杂度，通常是无意识的，使用者只是简单的想使用个class，但是带入的这些额外的library 就会带来很多潜在的问题。 不仅会带来系统问题，也可能是系统的启动速度显著下降。
问题
不必要的依赖会带来很多的问题。
- 运行
传递依赖带进来的artifact 可能和 项目本身的 artifact 有版本冲突，如果这个版本没有加入的dependencyManagement 里去，那么就可以发现一些奇怪的现象。 在开发环境一切都正常，但是在运行环境中出现问题，常见的情况请参考 NoSuchMethodError 的思路及解决办法 - 启动
传递依赖带进来的artifact被自动扫描到，本来不需要启动的模块也被启动了（如果这个jar 包有啥autoconfig 之类的）， 初始化时间自然增加。 - 解耦
依赖过多，导致功能不能切分。在一个紧耦合的情况下，牵一发而动全身，等到时间一长，从纠缠的逻辑中剥离这是一项巨大的解耦工程。 - 升级
依赖过多，会导致系统升级的难度增大。 在一些基本library 升级时， 比如Springboot 升级，那么本来没有关系的类，由于启动和Spring boot 的版本造成冲突导致启动失败。或者 本来对业务逻辑没有关系的lib 和升级的里边有冲突，导致启动失败。
方案
从java 的实现来讲， 上面讲的问题在原生java中是难以克服的。尤其对third party 的libaries。为了解决这类问题，从目前的趋势来讲，分为如下几个方向：
微服务
- 分解
把大的app的分解，分散成更小的application。这种分解通常由业务的需求引起。现在叫做微服务。大的app 分解成小的app 本身就降低了复杂度。 - Cherry pick
Spring boot starter 提供了这种功能，把功能modulize 或者 称之为component化，根据项目的需要加入或者不加入。 - Kernel Layer
Component 直接可能有互相依赖，如果一个component 没有加入，那么依赖他的component 相应的功能应该不工作，但是原则上不应该影响依赖他的component的工作。为了解决这个问题，component 分解成 component api + component autoconfig + component impl + component starter.。 任何component 的依赖都只能依赖API ， API 是一个对外暴露的最小必要集合。如果component autoconfig 和impl 加入进来， 那么API 的autowire 是有值的， 这时候就可以进行相关操作。 如果 没有加进来，不影响依赖的编译，在运行中，如果API 的autowire 为null，则不进行相关操作。从这个角度， 做了更进一步的分解，让这个程序尽量解耦的更多。 - App layer
用户还是可以随意定义自己的dependency ，对用户使用library并没有明确的限制。但是对于kernel 来讲，已经完全实现了解耦。
OSGI
class只是个metadata，由那个classloader 加载都可以发挥作用。但是，有不同的classloader加载，就有了class的作用域即命名空间。不同的命名空间可以加载同样的类，也可以不允许加载同样的类，策略的不同，有不同的实现和用处。
- class 的代码会用当前类的classloader去 加载类, 只要入口类被classloader 加载，入口类所有的功能都会被同一个classloader加载
- 创建类的实例
- 访问类的静态变量(注意：当访问类的静态并且final修饰的变量时，不会触发类的初始化。)，或者为静态变量赋值。
- 调用类的静态方法（注意：调用静态且final的成员方法时，会触发类的初始化！一定要和静态且final修饰的变量区分开?。。?/li>
- 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。如：Class.forName("bacejava.Langx");
- 注意通过类名.class得到Class文件对象并不会触发类的加载。
- 初始化某个类的子类
- 直接使用java.exe命令来运行某个主类(java.exe运行，本质上就是调用main方法，所以必须要有main方法才行)
- 类的命名空间存在于 classloader 之间
- 类的classloader findClass 的 方法实现不同，可以有不同的流派。OSGI 是走的一个不同的?？橛刹煌腸lassloader 加载的方式
budle class loader
这样的实现，也可以实现 分解， cherrypick， 但是他的问题是对kernel 和app 层没有区分，大家都需要遵守 bundle 的规范编码，这样的要求就对用户提出了很高的要求。用户需要了解bundle 的规范，同时自己能够遵守bundle 的规范。因此，这样的程序通常在比较封闭的开发产品中，比如说eclipse。
对于应用的系统， 很难实现。主要是因为这需要开发者拥有
- 应用开发者API 封装的能力
- 在不同classloader 下面 debug 的能力
- 在不同class loader triage 的能力
- 并不是常见开发模式。
从上面的分析中， 微服务的方式是比较好的一种合适的方式，在解决系统复杂度方面有了一个平衡。目前按照这个原则，跑下来的程序从复杂度，到启动速度，到升级维护的难度都是在可控范围内。
