17 | 模块系统：为什么Java需要模块化？

Maven、Gradle是怎么解决依赖关系缺失这样的问题的？ 首先，这些工具都只能在jar包的粒度来解决依赖关系，而无法达到java package的粒度，当然你可以通过刻意的设计，比如一个jar包里只有一个package，来变相的达到java package级别，这些工具的打包方式也非常灵活，就算要一个jar包里只有一个package，也不需要在源码的组织上做到一个project只有一个package，源码仍然可以都放在一个project，打包时可以打多个jar包； 然后再来回答这个问题，maven的解决方案是： 1. 通过一个构建描述文件（pom.xml）来描述jar之间的依赖关系； 2. 通过给每个<dependency>定义<scope>来限制一个jar的作用域（是编译时可用，还是只在运行时可用，还是只有测试用例代码可用）； 3. 通过内建的一些原则（如“最短路径原则”）以及外部的可自定义的dependencyManagement来解决版本/作用域冲突； 4. 通过各种打包插件来灵活打包jar gradle的解决方案跟maven类似，不过gradle支持更灵活的构建描述文件，这正好也是maven的很大短板；gradle支持使用groovy和kotlin作为dsl来写构建描述文件，groovy和kotlin是完备的编程语言，其表达能力跟xml比那就强太多了，写起来也简洁太多； 不过这一点也是双刃剑，maven内建了“构建生命周期”，所有的构建过程都必需在这套生命周期的框架之内，即便你自己写一个maven plugin，也必须把你自定义的goal绑定到maven的生命周期上去，无法随意修改构建顺序、构建步骤，也就规范了构建描述文件的写法，不会出现一千个人有一千种写法；而gradle就没有强制遵守的生命周期，限制就放开了，加上用编程语言来写构建描述文件，能玩的花活就多了，只要你愿意，你可以在构建描述文件里编程实现复杂的自定义构建流程，这在maven里通常需要用java写一个maven plugin来实现（甚至都未必能实现，因为maven有生命周期需要强制遵守）

通过Maven管理依赖，会存在依赖传递导致的版本冲突问题。 如： 1、我的工程为ProjectMain，依赖了ProjectA和ProjectB； 2、ProjectA依赖了ProjectC，依赖的ProjectC的版本为1.0； 3、ProjectB依赖了ProjectC，依赖的ProjectC的版本为2.0； 4、启动ProjectMain时，只会加载1版本的个ProjectC。 可能会出现下面问题（假如加载的是ProjectC的1.0版本）： 1、如果ProjectB调用了ProjectC的2.0版本中的新增方法，则运行时会抛出NoSuchMethodError的异常； 2、如果ProjectB调用的ProjectC的2.0版本中的方法签名，在ProjectC的1.0版本中都有，但内部实现做了修改，这样实际执行时，还是按ProjectC的1.0版本的逻辑执行，不符合ProjectB的目的。

另外，JDK9之后模块化这种并不是强制的，可以通过添加VM参数放开限制(--illegal-access=permit)。 例如： 放开之后，在运行时可以通过反射修改String类的value数组，达到动态修改String值的目的。

平常用Maven，在集中管理方面做的很好。比如找一个库，只需要在Maven仓库中搜索，并添加XML配置到项目即可。在依赖加载方面也有很多镜像可以使用。 不足的是，不同依赖的不同版本可能会导致一些未知的问题。而Spring Boot Starts刚好就解决了这个问题。

学习打卡

先回答问题 其实现在都有工具，所以包冲突这个事比以前好排太多了。但是依旧需要人工，只要没有自动化，就依旧会有效率问题和风险。 这篇开头我就有个痛点，虽然增加包维度控制的解决方案能解我的痛点，但看样子并不能很快支持。 我的痛点是，包范围的访问权限缺少对子包的访问权限。这就导致我要么摊平，所有类都放在这个包目录下；要么就都只能用开放的访问权限。这对于有点洁癖想要分包结构整理类的我实在是种折磨。 类权限的发散也是项目腐化的源头，放现在看，能不能说他是个bug？ 这个痛点我觉得其实不难解，如果不用增加包维度访问控制这个解决方案的话。 那么临时方案可不可以？定义好修饰符实现对于使用方又无感，后面长期方案上了，完全可以平滑过度。