这些程序到底是用了什么骚操作，才能让自己做到无法向前兼容 JVM 的？这么干是为了啥？
abcbuzhiming · 2018-10-23 21:15:44 +08:00 · 2534 次点击这是一个创建于 2253 天前的主题，其中的信息可能已经有所发展或是发生改变。
自打我认识 Java 开始，JVM 那为了让旧版本的 Class 文件无缝的运行在新的 JVM 上而不得搞的一些让人酸爽的设计就深入我心。虽说很酸爽，但是换来的兼容性还是不错的。搞的我一直以为，只要是 jar，都可以放在比编译它时更新的 JVM 上跑。然而我最近才突然无意中发现，jenkins 这个大家几乎都用过的东西。居然是不能向前兼容 JVM，其入口程序明确的会检测 classloader 的版本，发现版本比自己生成的版本高直接就罢工，跑去官方翻了翻，官网表示知道这是个问题，正在解决。而且看了官网的不少 issure。发现有这个问题的不止它一个，之前的 Jetty 也是这样的，不能支持再高版本 JVM 上跑，最近才解决。但是对于为啥他们会这样的原因，没找到解释，他们到底做了什么骚操作，又为啥要做这些。
最后，这样一来，JVM 的向前兼容性简直就是白设计了吗？
最后，这样一来，JVM 的向前兼容性简直就是白设计了吗？
 |
1
yidinghe 2018-10-23 21:21:35 +08:00 via Android
可能只是不想让用户整出七七八八的 bug 出来。如果限定了 Java 版本，就在部署的时候附带一个专用 jre 好了。
|
 |
2
kilen3a 2018-10-23 21:27:04 +08:00
sun 的一些包，java fx，COBRA， 还有 rihno
|
 |
3
abcbuzhiming OP @kilen3a 这些包怎么了？
|
 |
4
cpdyj0 2018-10-23 23:00:39 +08:00
jenkins 不知道，，之前听说过有人用反射 hack JDK 实现一些功能的，或者用到了一些非公开 API，就只能限制版本了，要不然容易搞出了奇奇怪怪的 bug。更有甚者 JNI 加载动态库 hack JVM，，我的天都是大佬。
|
 |
5
billlee 2018-10-23 23:33:20 +08:00
用了 oracle jdk 中的内部实现类吧，比如 sun.* 那些
|
 |
6
tachikomachann 2018-10-23 23:50:04 +08:00 via Android
其入口程序明确的会检测 classloader 的版本，发现版本比自己生成的版本高直接就罢工
你的前半个问题你自己回答了😂 这么做的原因可能就像楼上说的，用了 sun 包下面一些工具类，这些是声明了未来版本可能过期的 |
Select Language