java9中opens与exports区别 java9区分opens与exports

序

本文主要研究下迁移到java9的一些注意事项。

迁移种类

1. 代码不模块化，先迁移到jdk9上，好利用jdk9的api
2. 代码同时也模块化迁移

几点注意事项

不可读类

比如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.unsupported
jdk.unsupported@9
exports com.sun.nio.file
exports sun.misc
exports sun.reflect
requires java.base mandated
opens sun.misc
opens 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上；然后再模块化。