这些程序到底是用了什么骚操作，才能让自己做到无法向前兼容 JVM 的？这么干是为了啥？

[abcbuzhiming]

自打我认识 Java 开始，JVM 那为了让旧版本的 Class 文件无缝的运行在新的 JVM 上而不得搞的一些让人酸爽的设计就深入我心。虽说很酸爽，但是换来的兼容性还是不错的。搞的我一直以为，只要是 jar，都可以放在比编译它时更新的 JVM 上跑。然而我最近才突然无意中发现，jenkins 这个大家几乎都用过的东西。居然是不能向前兼容 JVM，其入口程序明确的会检测 classloader 的版本，发现版本比自己生成的版本高直接就罢工，跑去官方翻了翻，官网表示知道这是个问题，正在解决。而且看了官网的不少 issure。发现有这个问题的不止它一个，之前的 Jetty 也是这样的，不能支持再高版本 JVM 上跑，最近才解决。但是对于为啥他们会这样的原因，没找到解释，他们到底做了什么骚操作，又为啥要做这些。

最后，这样一来，JVM 的向前兼容性简直就是白设计了吗？

[yidinghe]

可能只是不想让用户整出七七八八的 bug 出来。如果限定了 Java 版本，就在部署的时候附带一个专用 jre 好了。

[kilen3a]

sun 的一些包，java fx，COBRA， 还有 rihno

[abcbuzhiming]

@kilen3a 这些包怎么了？

[cpdyj0]

jenkins 不知道，，之前听说过有人用反射 hack JDK 实现一些功能的，或者用到了一些非公开 API，就只能限制版本了，要不然容易搞出了奇奇怪怪的 bug。更有甚者 JNI 加载动态库 hack JVM，，我的天都是大佬。

[billlee]

用了 oracle jdk 中的内部实现类吧，比如 sun.* 那些

[tachikomachann]

其入口程序明确的会检测 classloader 的版本，发现版本比自己生成的版本高直接就罢工
你的前半个问题你自己回答了😂

这么做的原因可能就像楼上说的，用了 sun 包下面一些工具类，这些是声明了未来版本可能过期的