处理SWT bit版本与JDK bit版本的对应

最新推荐文章于 2024-09-07 11:41:04 发布

原创

最新推荐文章于 2024-09-07 11:41:04 发布 · 3.9k 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#swt #jdk #产品 #action #shell #string

本文探讨了SWT的32-bit和64-bit版本与JDK的兼容性问题，指出两者必须匹配使用，否则会导致版本不兼容错误。为了解决产品在不同位数JDK环境下运行的问题，文章提出通过InstallAnywhere扩展实现动态绑定相应位数的SWT包，但在某些情况下可能判断失误。最后，提出一种容错处理方案：在产品启动时尝试加载swt32.jar，异常则切换到swt64.jar，以此确保产品首次启动的正常运行。该方法作为临时解决方案，未来将寻找更优的解决策略。

bit版本(bit version)，是从国外一个论坛的帖子抄过来的，我原本也不清楚该怎样命名它，觉得bit version挺合适的，就这样使用起来了。

SWT bit version有32-bit和64-bit两种，同样，jdk也有32-bit和64-bit两种。经过多次测试，发现32-bit SWT只能安装在32-bit JDK 上，而64-bit SWT也只能安装在 64-bit JDK上，两都不能交叉使用，即32-bit SWT 不能在 64-bit JDK 上使用， 64-bit SWT 不能在 32-bit JDK 上使用，这两种情况都会报类似"版本不兼容“的错误。我们的产品用到SWT，而客户环境的JDK可能会是32-bit或64-bit的，一般情况下，可以做个划分，比如产品也对应地分出两个版本，版本32-bit就只能安装在32-bit的JDK上，版本64-bit就只能安装在64-bit的JDK上，但这样不好，如果客户装了32-bit的之后发现不行，再重新安装64-bit的，换成是我，也会不爽的，所以要解决这个问题，让产品能够根据客户选择的JDK bit version来选用对应的SWT包。

研究了一下InatallAnywhere，发现可以对它做扩展。在这里，我写了一个扩展，在产品安装完之后，执行一个Action，检查客户所选择的JDK的bit version，再绑定对应bit version的SWT包。这种方法测试一段时间，发现可行性还挺好的，但之后又发现，如果客户不选择JDK，产品会到system32(此时是windows platform)时读取java.exe，这时，会导致该Action判断失误，所以这种方法不能完全解决问题。

接着考虑了一段时间，想出了一个不算太好的方法来做个“容错”处理。在产品安装完后的lib包有swt32.jar和swt64.jar