序
本文主要研究下迁移到java9的一些注意事项。
迁移种类
几点注意事项
不可读类
比如sun.security.x509，在java9中归到java.base模块中，但是该模块没有export该package
可以通过运行的时候添加--add-exports java.base/sun.security.x509=ALL-UNNAMED来修改exports设定
内部类
比如sun.misc.Unsafe，原本只想让oracle jdk team来使用，不过由于这些类应用太广泛了，为了向后兼容，java9做了妥协，只是将这些类归到了jdk.unsupported模块，并没有限定其可读性。
➜ ~ java -d jdk.unsupportedjdk.unsupported@9exports com.sun.nio.fileexports sun.miscexports sun.reflectrequires java.base mandatedopens sun.miscopens sun.reflect
删除的类
java9删除了sun.misc.BASE64Encoder，这种情况只能改用其他api，比如java.util.Base64
classpath vs module-path
java9引入了模块系统，同时自身的jdk也模块化了，引入了module-path，来屏蔽classpath，也就是说在java9优先使用module-path，毕竟jdk本身都模块化了，应用本身没有模块化的话，java9通过unnamed modules及automatic modules机制来隐式模块化，当然classpath在java9上还能继续使用，比如配合module-path使用等。
没有模块化的jar在classpath会被归到unnamed modules；在module-path则会被自动创建为automatic modules(一个automatic modules会声明transitive依赖所有named和unnamed module，然后导出自身的package)
一个包名不能在多个模块中出现(split packages)
因为模块中可以exports指定包给其他模块，如果多个模块exports同样的包名会造成混乱，特别若有其他类库同时requires这两个模块，就不知道该引用那个模块的了。
传递依赖
如果一个模块的接口参数或返回类型使用了其他模块的类，则建议requires transitive它依赖的模块
小心循环依赖
在设计模块的时候，要尽可能考虑到是否会有循环依赖的问题，如果有则需要重新设计
使用services来实现optional依赖
services特别适合用来解耦调用方与实现类依赖的问题，如果接口有多种实现类，调用方不必要requires所有的实现类，只需要requires接口即可，使用services类型来加载实现类的实例。通过在module-path去动态添加实现模块实现解耦。
模块版本管理
module-info.java不支持声明版本号，但是创建jar包的时候，可以通过--module-version设置。不过模块系统查找模块的时候还是使用模块名来查找(如果module-path里头有多个重名模块，则模块系统知会使用找到的第一个，自动忽略后续的同名模块)，版本依赖问题不在模块系统解决范畴内，交由maven之类的依赖管理工具去管理。
模块资源访问
模块化之后资源文件也收到保护，只能由该模块去访问本模块自身的资源文件，如果需要跨模块访问，也必须借助ModuleLayer找到目标模块，再调用目标模块去加载该模块的资源文件。
反射的使用
这里涉及到deep reflection问题，所谓的deep reflection就是通过反射去调用一个class的非public元素。module-info.java的exports声明package只是允许该package直接所属的类允许访问其public元素，并不允许反射调用非public元素。
反射在模块系统里头需要特殊声明才允许使用(使用opens声明允许deep reflection)，这样就导致很多使用反射的类库诸如spring，需要额外配置才能迁移到java9。解决方案有两个：一个是opens package包名给需要反射的模块，比如spring.beans等；一个就是直接opens整个模块。
默认--illegal-access=permit，同时该设置只适用于java9之前的package在java9被不允许访问，不适用于java9中新的不允许访问的package.(建议迁移到模块化系统时设置为deny)
不过就是在模块系统中包名不一样就属于不同的包，没有继承关系，比如com.service.func1与com.service.func2这两个是不同的包，你不能只opens com.service，必须分别指定这样就导致需要open的的package比较多。因此open整个module可能更省事一点，但也属于比较粗暴的做法。
上面的做法是在原来module-info.java里头去做修改，另外一种是在执行java或javac的时候通过指定的命令来修改原来的关系。比如
java ... --add-opens source-module/source-package=target-module
如果需要导出给unnamed modules，则target-module为ALL-UNNAMED
当然如果是新的系统，那就不建议使用反射了，可以使用MethodHandles及VarHandles。
常见问题和措施
ClassNotFoundException/NoClassDefFoundError
比如javax.xml.bind.JAXBException，JAXB已经归入到java.xml.bind模块，在java命名后面添加
--add-modules java.xml.bind
如果图省事，把$JAVA_HOME及所有第三方类库添加到module-path，然后来个
--add-modules ALL-MODULE-PATH
illegal reflective access by xxx to method java.lang.ClassLoader.defineClass
反射原因引起，由于旧系统没有module-info，因此在java命名添加参数加以修改
--add-opens java.base/java.lang=ALL-UNNAMED
确定依赖的模块
通过IDE或者jdeps分析
jdeps --class-path 'classes/lib/*' -recursive -summary app.jar
jdeps只是静态代码分析，如果有使用反射用的类jdeps分析不出来，需要自己手工requires，如果dependency是optional的，可以requires static
对模块单元测试的可读性问题
如果单元测试时单独模块的话，可以在运行时通过--add-exports或--add-opens来授予单元测试模块对目标模块的可读性及反射能力。另外由于split packages问题，单元测试类的包名不能跟目标模块包名重复。原来maven工程那种test
小结
可以分两步走迁移到java9，首先是先不模块化，只先跑在jdk9上；然后再模块化。