StackFlow 之升级JDK.11(JDK.9/JDK.10)

前言

JDK版本升级中的漫长的坑…

最近因项目需求需要对JDK版本升级，之前使用的JDK1.8大版本，这个版本使用起来还是很得心应手的。但升级过程中遇到了相当多的问题，其中有一些JDK自己本身存在的BUG，还有一些好似项目与JDK兼容的问题，总之问题比较多，而且JDK版本更新过快很多BUG来不及修复就又开始迭代了…哎！

下面我将列出一些我在JDK版本是遇到的和JDK有关的问题。

• JAXB-API：java.lang.TypeNotPresentException: Type javax.xml.bind.JAXBContext not present

  • 异常问题描述

    java.lang.TypeNotPresentException: Type javax.xml.bind.JAXBContext not present
    	at java.base/sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:117) ~[na:na]
    	at java.base/sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125) ~[na:na]
    	at java.base/sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49) ~[na:na]
    	at java.base/sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:68) ~[na:na]
    	at java.base/sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:138) ~[na:na]
    	at java.base/sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49) ~[na:na]
    	at java.base/sun.reflect.generics.repository.ClassRepository.computeSuperInterfaces(ClassRepository.java:117) ~[na:na]
    	at java.base/sun.reflect.generics.repository.ClassRepository.getSuperInterfaces(ClassRepository.java:95) ~[na:na]
    	at java.base/java.lang.Class.getGenericInterfaces(Class.java:1138) ~[na:na]
    	at com.sun.jersey.core.reflection.ReflectionHelper.getClass(ReflectionHelper.java:629) ~[jersey-core-1.19.1.jar:1.19.1]
    	at com.sun.jersey.core.reflection.ReflectionHelper.getClass(ReflectionHelper.java:625) ~[jersey-core-1.19.1.jar:1.19.1]
    	at com.sun.jersey.core.spi.factory.ContextResolverFactory.getParameterizedType(ContextResolverFactory.java:202) ~[jersey-core-1.19.1.jar:1.19.1]
    	at com.sun.jersey.core.spi.factory.ContextResolverFactory.init(ContextResolverFactory.java:89) ~[jersey-core-1.19.1.jar:1.19.1]
    	at com.sun.jersey.server.impl.application.WebApplicationImpl._initiate(WebApplicationImpl.java:1332) ~[jersey-server-1.19.1.jar:1.19.1]
    	at com.sun.jersey.server.impl.application.WebApplicationImpl.access$700(WebApplicationImpl.java:180) ~[jersey-server-1.19.1.jar:1.19.1]
    	at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:799) ~[jersey-server-1.19.1.jar:1.19.1]
    	at com.sun.jersey.server.impl.application.WebApplicationImpl$13.f(WebApplicationImpl.java:795) ~[jersey-server-1.19.1.jar:1.19.1]
    	at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:193) ~[jersey-core-1.19.1.jar:1.19.1]
    	at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:795) ~[jersey-server-1.19.1.jar:1.19.1]
    	at com.sun.jersey.server.impl.application.WebApplicationImpl.initiate(WebApplicationImpl.java:790) ~[jersey-server-1.19.1.jar:1.19.1]
    	at com.sun.jersey.spi.container.servlet.ServletContainer.initiate(ServletContainer.java:509) ~[jersey-servlet-1.19.1.jar:1.19.1]
    	at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.initiate(ServletContainer.java:339) ~[jersey-servlet-1.19.1.jar:1.19.1]
    	at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:605) ~[jersey-servlet-1.19.1.jar:1.19.1]
    	at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:207) ~[jersey-servlet-1.19.1.jar:1.19.1]
    	at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:394) ~[jersey-servlet-1.19.1.jar:1.19.1]
    	.
    	.
    

  • 异常原因：JDK V9+模块化的概念使得JAXB默认没有加载，jaxb-api是存在jdk中的，只是默认没有加载而已。因而需要对jaxb-api做接入声明

  • 解决方法

    • 对jaxb-api做接入依赖声明：在pom文件中添加如下依赖

      <!-- jaxb模块引用 - start -->
      <dependency>
         <groupId>javax.xml.bind</groupId>
          <artifactId>jaxb-api</artifactId>
      </dependency>
      <dependency>
          <groupId>com.sun.xml.bind</groupId>
          <artifactId>jaxb-impl</artifactId>
          <version>2.3.0</version>
      </dependency>
      <dependency>
          <groupId>org.glassfish.jaxb</groupId>
          <artifactId>jaxb-runtime</artifactId>
          <version>2.3.0</version>
      </dependency>
      <dependency>
          <groupId>javax.activation</groupId>
          <artifactId>activation</artifactId>
          <version>1.1.1</version>
      </dependency>
      <!-- jaxb模块引用 - end -->
      

    • 模块命令方式

      --add-modles javax.activation 
      --add-modles javax.corba 
      --add-modles javax.transaction 
      --add-modles javax.xml.bind 
      --add-modles javax.xml.ws 
      --add-modles javax.xml.ws.annotation
      

• JDK illegal reflective access operation (Spring JIRA)

  • 问题异常描述

    WARNING: An illegal reflective access operation has occurred
    WARNING: Illegal reflective access by com.thoughtworks.xstream.core.util.Fields (file:/E:/WorkSpace/IDEs/MAVEN/RepositoryMicro/com/thoughtworks/xstream/xstream/1.4.10/xstream-1.4.10.jar) to field java.util.TreeMap.comparator
    WARNING: Please consider reporting this to the maintainers of com.thoughtworks.xstream.core.util.Fields
    WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
    WARNING: All illegal access operations will be denied in a future release
    

  • 异常原因：

    Ironically, the way this is handled now in the JDK 9 release candidate can lead to unpleasant warnings here: Since defineClass is accessible by default for classpath-based code again, CGLIB takes its regular code path there, with the JDK logging a one-time warning to the console. If the illegal-access flag is switched to deny, the warning goes away since CGLIB gets an exception there and proceeds with its alternative code path. The same is true for module-based deployments where such access is completely denied upfront.
    
    So for regular upgrades to JDK 9 in classpath mode, this leads to a one-time but nevertheless unpleasant warning. Two ways to get rid of this: --add-opens java.base/java.lang=ALL-UNNAMED or the above-mentioned --illegal-access=deny, which I find rather ironic. The only way to prevent such a warning out of the box is to use the sun.misc.Unsafe code path by default on JDK 9, or even everywhere, i.e. to flip the order of detection here. Or we'll just live with recommending --illegal-access=deny in such scenarios?
    

  • 解决方法：

    • –add-opens java.base/java.lang=ALL-UNNAMED（JDK V9以上的默认设置但依旧出现Waring）
    • –illegal-access=deny