分享:java9迁移注意事项

129 阅读5分钟
原文链接: my.oschina.net

本文主要研究下迁移到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上;然后再模块化。

doc