在 Java 中加载 32 位或 64 位 JNI 库 [重复]答案

【问题标题】：Loading 32 or 64 bit JNI Library in Java [duplicate]在 Java 中加载 32 位或 64 位 JNI 库 [重复]
【发布时间】：2011-07-23 20:54:16
【问题描述】：

可能重复：
Java : switching between dll depends on system architecture (32/64)

在我的 Java 应用程序中，我需要一个可用于 32 位和 64 位的 JNI 库。我不想发布我的应用程序的两个不同版本，所以我想发布带有两个库的应用程序，并且应用程序必须自行确定要加载哪个库（foobar32.so 或 foobar64.so）。我该怎么做？

我考虑过尝试加载第一个，如果这引发异常，那么我会加载第二个，但这听起来很难看。

是否可以检查一些系统属性来确定是使用 32 位 Java 还是 64 位 Java 来运行我的应用程序？我知道有一些os.arch 属性，但根据this answer，返回值似乎非常不可预测。

那么让应用程序决定是加载 32 位还是 64 位 JNI 库的最佳方法是什么？

【问题讨论】：

您如何捆绑您的应用程序？在 OSGi 中，您只能根据操作系统架构加载某些包或包片段。这就是交付特定于平台的功能的方式。你可以考虑使用 OSGi 吗？
您主要关心的不是操作系统是什么，而是可执行文件是什么：您可以在 64 位操作系统上运行 32 位可执行文件，但它仍然是 32 位，您需要的库是 32 位而不是 64 位。如果假设您可以在某些 32 位操作系统上运行 64 位可执行文件，您需要 64 位库。这就是 przemelek 试图解释的。 os.arch 几乎可以满足任何需求，只要它存在，我的答案是针对 Unsafe 存在但某些系统属性可能不存在的情况。

【解决方案1】：

Unsafe.addressSize();

报告本地指针的字节大小，通过 {@link #putAddress} 存储。该值将是 4 或 8。

你可以从这里拿走。

【讨论】：

【解决方案2】：

为什么不可预测？您只想检测它是否是 32 位系统，在这种情况下，它将始终是 x86（当然对于 x86 处理器），其他一切都意味着 64 位。

如果您知道您的代码也可以在 PPC 或其他非 x86 处理器上执行，那么问题就来了。但在这种情况下，您可能会使用带有异常驱动流控制的丑陋 hack，并使用 try {} catch () 来“检测”此类情况。

恕我直言，os.arch 将是最好的解决方案。

【讨论】：

@przemelek - os.arch 不可靠，因为它返回用于编译 jar 的系统的属性，而不是它运行的系统（请参阅我的答案中的链接）
@MByD: 不，系统属性os.arch --- 与所有 Java 系统属性一样 --- 是运行时概念，而不是编译时概念。因此，它返回运行时架构。
@jmg。我犯了一个错误。 os.arch 的返回值是运行时值，但它取决于 JRE 的位数，而不是实际架构，因此如果您在 64 位 Windows 机器上运行 32 位 JRE，您将得到 x86 结果.看到这个帖子：mark.koli.ch/2009/10/…
@MByD：好的，你说得对。但是，运行 JVM 的“位数”或架构正是 OP 需要决定加载哪个库。
+1 @jmg，实际上，你也是对的，并且教会了我一些我不清楚的重要事情。谢谢。