UnsupportedClassVersionError, 覆盖率平台怎么了

最近覆盖率平台有一个小bug, 所以临时发了一个版本解决了问题。结果上线一天后，陆续有测试同学反馈，打开覆盖率报告的结果都是空的。

问题现象

打开应用的日志终端, 结果就看到了这样子的一个报错信息。

java.util.concurrent.ExecutionException: java.lang.UnsupportedClassVersionError: org/eclipse/core/runtime/IProgressMonitor has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.util.concurrent.FutureTask.get(FutureTask.java:192)
	at org.jacoco.core.internal.diff.CodeDiff.batchPrepareDiffMethodForTag(CodeDiff.java:186)
	at org.jacoco.core.internal.diff.CodeDiff.diffTagMethods(CodeDiff.java:132)
	at org.jacoco.core.internal.diff.CodeDiff.diffTagToTag(CodeDiff.java:98)
	at org.jacoco.core.analysis.CoverageBuilder.<init>(CoverageBuilder.java:119)
	at com.seewo.service.impl.ReportServiceImpl.createDiffReport(ReportServiceImpl.java:160)
	at com.seewo.service.impl.ReportServiceImpl.create(ReportServiceImpl.java:133)
	at com.seewo.handler.JavaReportGenHandler.handle(JavaReportGenHandler.java:72)
	at com.seewo.service.impl.CoverageServiceImpl.generateCoverageData(CoverageServiceImpl.java:80)
	at com.seewo.service.impl.CoverageServiceImpl.refreshCoverageData(CoverageServiceImpl.java:368)
	at com.seewo.task.DemoTask.executeInternal(DemoTask.java:47)
	at org.springframework.scheduling.quartz.QuartzJobBean.execute(QuartzJobBean.java:75)
	at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
	at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:573)
Caused by: java.lang.UnsupportedClassVersionError: org/eclipse/core/runtime/IProgressMonitor has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:763)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
	at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:94)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.jacoco.core.internal.diff.ASTGenerator.initCompilationUnit(ASTGenerator.java:42)
	at org.jacoco.core.internal.diff.ASTGenerator.<init>(ASTGenerator.java:34)
	at org.jacoco.core.internal.diff.CodeDiff.prepareDiffMethodForTag(CodeDiff.java:279)
	at org.jacoco.core.internal.diff.CodeDiff.access$000(CodeDiff.java:38)
	at org.jacoco.core.internal.diff.CodeDiff$1.call(CodeDiff.java:170)
	at org.jacoco.core.internal.diff.CodeDiff$1.call(CodeDiff.java:165)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)

看着就不是代码逻辑的错误了, 根据上面的关键信息 version 55.0 以及version 52.0。其实就可以大概了解到 很大概率是我们代码的依赖库用的java 11的编译的class， 但是我当前java 运行版本是java8 导致有问题了。

另外还有一个关键的信息就是 org/eclipse/core/runtime/IProgressMonitor 这个报错的代码。需要确认下引用它的库是哪个就可以了。

首先我们看到这个印证了我们最开始关于version 版本的想法了，然后我们再看看引用它的库是：

是被 org.eclipse.equinox.common 所引用了。

那是这个包的版本发生改变了吗？ 我们现在需要确认的是这个问题。 所以我们分别解压了正常版本以及异常版本的 jar 包 对比查看 org.eclipse.equinox.common 的版本是否发生了变化。

正常版本 ： 3.14.100

异常版本：3.15.0

确实发现不一样的地方了, 并且我们发现其实不单单是这个包的版本发生了变化，还有好几个对应的eclipse的版本也有变化，所以有可能我们解决了这个包的问题后，可能还需要修改其他包的问题。

解决问题

现在我们需要做的是在pom中将对应包的依赖的版本给强制设置了。不过我们先看看 org.eclipse.equinox.common 这个包顶级的引用者是谁

可以看出来实际上是 org.eclipse.jtd.core 才是真正引用它的，所以我们需要在pom中exclude掉它， 然后重新引入低版本的包即可。 当然这里面不单单只是需要处理这个包，因为刚才我们在前面说到过，引用的包有好几个发生了变化。

结尾

最后我们虽然解决了问题，但是我们还需要明白一个问题，为什么重新打包后，依赖的版本号发生了变化呢？ 所以我们需要看下 org.eclipse.jtd.core 他的版本依赖的规则是如何的了。

我们可以发现这里的版本引用都是一个范围的，所以一旦有最新的版本的话，他是会使用最新的版本的。这个就是我们明明在pom中指定了版本，但是实际上依赖的包的版本还是发生变化的原因了。