如何知道在AMD64上建造的.jar是否会在手臂上完美运行？

发布于 2025-02-03 04:14:22 字数 888 浏览 3 评论 0原文

我在 ARM 体系结构上的Docker中建立了一个.jar， AMD64 上建立了。

两个.jar文件具有相同的大小，但是vbindiff说它们的内容完全不同。

我在我的AMD64计算机上测试了.jar文件，并且“在任何地方构建，运行一次”。

我的假设是，这与 Java天然界面（JNI）有关。 .jar是Spring Boot WebFlux后端。不幸的是，我不知道它或其他任何依赖性使用JNI。

我注意到手臂图像已安装 JDK 17.0.3 ，而AMD64映像具有 JDK 17.0.2。代码> .jar 使用 gradle包装器，它指定要下载并用于构建项目的确切工具链：

kotlin("jvm") version "1.6.10"

差异的原因是什么？我可以假设.jar可以在具有兼容JVM的任何平台上使用吗？

编辑：我遵循托马斯的建议，并使用diff -r比较.jar文件的提取内容。他们是相同的。

但是，diff确认.jar文件本身不同。

我刚刚了解到，.jar格式基于.zip，它可以使用各种压缩方法，并在文件标头中包含其他信息，例如'最后修改'或可选的OS特异性属性。神秘解决了。

原文

I built a .jar in docker on the ARM architecture and one on AMD64.

The two .jar files have the identical size, but vbindiff says their contents are quite different.

I tested both .jar files on my AMD64 computer and the reversed slogan "build anywhere, run once" holds.

My hypothesis is that this has to do with Java Native Interface (JNI). The .jar is a Spring Boot Webflux backend. Unfortunately, I don't know if it or any other dependency uses JNI.

I noted that the ARM image has JDK 17.0.3 installed, while the AMD64 image has JDK 17.0.2. But this should not be a problem, since I built both .jars using the Gradle wrapper, which specifies the exact toolchain to be downloaded and used to build the project:

kotlin("jvm") version "1.6.10"

What could be the reason for the difference? Can I assume that either .jar can be used on any platform that has a compatible JVM?

EDIT: I followed Thomas' advice and used diff -r to compare the extracted contents of the .jar files. They are identical.

However, diff confirms that the .jar files themselves are different.

I just learned that the .jar format is based on .zip, which can use various compression methods, as well as include extra information in file headers, such as 'last modified' or optional OS-specific attributes. Mystery solved.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

忘羡 2025-02-10 04:14:22

您可以在.jar中使用jar tf myfile.jar列出文件。如果唯一的内容是.class文件和meta-inf/中的清单数据，那么它是100％便携式的机会。如果您看到其他文件，例如.so，.dll或.dylib，那么其中的本机代码可能会带来麻烦。

您可以列出所有可能需要仔细查看的文件：

jar tf myfile.jar | grep -Pv '^META-INF/|(\.class|/)
由于您已经在两个不同平台上构建了 .jar  s，因此您还可以使用 jar xf myfile提取其内容。 jar 并使用 diff -r 递归比较它们。尽管我认为 .class 文件在语义上，这是一种比直接比较档案的更强大的检测差异的方法，尽管我认为 .class 文件也可能不是相同的。

由于您已经在两个不同平台上构建了.jar s，因此您还可以使用jar xf myfile提取其内容。 jar并使用diff -r递归比较它们。尽管我认为.class文件在语义上，这是一种比直接比较档案的更强大的检测差异的方法，尽管我认为.class文件也可能不是相同的。

You can list the files in the .jar using jar tf myfile.jar. If the only contents are .class files and the manifest data in META-INF/, then chances are good that it's 100% portable. If you see other files like .so, .dll or .dylib, then there is native code in there which might give trouble.

Here's how you can list all the files which might warrant a closer look:

jar tf myfile.jar | grep -Pv '^META-INF/|(\.class|/)
Since you have already built the .jars on two different platforms, you can also extract their contents using jar xf myfile.jar and use diff -r to compare them recursively. This is a more robust way to detect differences than comparing the archives directly, although I imagine that .class files might not be byte-wise identical either even if they're semantically the same.

Since you have already built the .jars on two different platforms, you can also extract their contents using jar xf myfile.jar and use diff -r to compare them recursively. This is a more robust way to detect differences than comparing the archives directly, although I imagine that .class files might not be byte-wise identical either even if they're semantically the same.

回复收藏 0 原文

~没有更多了~