我听说 java 的优点是人们可以编写代码，为 JVM 编译它，并在任何地方运行它。每个人只需要一个适用于他们平台的 JVM 应用程序。
当然，它看起来类似于当前的情况，每个人都有一个特定于他们平台的编译器。所以这个优势并不能解释。但我想我看到了解释..问题一定是在java情况下，你不能或不打算以特定于操作系统的方式直接访问真机。
我想这意味着在其他语言中，代码本身必须根据运行的计算机进行修改。
任何人都可以提供这样的简短示例，例如演示这一点的 Hello World 程序吗？毫无疑问，它会在非 java 中，例如 C
由于这不是通常发生在 Hello World 程序中的事情，或者自从我在 Java 上使用的书籍以来我所见过的大多数事情，不幸的是，它们是“如何编程”风格的书籍，而其中的所有内容都没有演示它（也许是因为他们不能或不想使用 java 来演示它！）。尽管他们吹嘘这是一个很大的优势。我想看看它的例子。
...每个人都有一个特定于他们平台的编译器。所以这个优势并不能解释。
移植用例如 C 或 C++ 编写的代码几乎总是比简单地重新编译代码要复杂得多。这当然不是普通的非开发人员计算机用户可以轻松完成的事情。用编译语言编写的代码通常是针对特定操作系统的 API（例如 Win32 API）编写的，因此无法在其他操作系统上轻松编译。
Java 字节码可以在任何有 Java 运行时环境可用的平台上运行。代码不需要重新编译。当然，您可以使用 Java 编写特定于操作系统的代码，但是 Java 的标准库以及 Web 上提供的许多免费库提供了非常丰富的跨平台环境。
除了可移植性之外，在虚拟机上运行还有其他优势。Java 使用JIT 编译器在运行时将 Java 字节码编译为本机机器码。JIT 编译器可以对运行程序的特定 CPU 进行复杂的优化，并且它可以使用提前编译器无法使用的分析信息 - 原则上，JIT 编译器因此可以生成更优化的代码比“普通”编译器。
除了 Java VM，还有其他虚拟机。例如，Microsoft .NET 包含CLR（公共语言运行时），还有LLVM，它具有许多不同语言的前端，包括 C 和 C++（并且应该将 JIT 编译的优势也带到 C 和 C++） .
Of course, it looks similar to the current situation, where everybody has a compiler specific for their platform.
The thing you need to understand is that even if there is a compiler specific for each platform, the languages are slightly different (unless it is the exact same compiler, which is rare for others than the gcc compiler), and that the platform the programs see are vastly different. "Oh, we have 64-bit integers here, and you need to use X11 to do graphics etc etc etc". You need to handle these things in code, and just the fact that there exist a pretty big GNU project just for handling the configuration of specifying these differences to programs (automake) should indicate that this is not a trivial matter.
The platform provided by a JVM is much more rigidly specified, and your programs behave the same on all of them. Integers overflowing? Oh, that means do this, and ignore that. etc. This is so well done that it is expected that things work the same on all JVM's, and that failures are not due to platform differences between development and deployment machines. You always look first for some external reason and only in the rarest cases you find a bug in the JVM. A very well-engineered piece of work.
我认为关键是在 java 上你也可以做一些有用的可移植的东西。在 C 和 C++ 中，您有时最终不得不进行指针运算并担心 int 的大小（因操作系统和 CPU 而异）等等。标准中有一些以可移植方式处理它的修复程序，但 java 从一开始就考虑到了这一点。我认为 JVM 还有另一个好处。jython 和 scala 之类的东西能够使用大量的 java 库（以及任何其他可用的 java 类），就好像它们是自己语言的一部分一样。在大多数其他语言中，与不同语言交互的方式是使用 C ABI，这在 OOP 世界中有些限制。从这个意义上说，java 是新的 C。此外，jvm 提供了垃圾收集和反射等好东西。
除了 JVM 的优势之外，由于 JIT 编译器允许您以合理的性能独立于 CPU 架构执行代码，Java 的一个基本优势在于它不仅仅是一种编程语言，而是一个具有通用 API 的运行时环境到它可以运行的所有底层平台（偶尔会有一些差异，但它们往往是错误）。
gcc例如，（GNU 交叉编译器）可以让您为或多或少的任何平台编译 C 代码。对于仅限于使用调用stdio.h和其他一些方法的任何事情，原则上都可以。但是，一旦您尝试使用更特定于操作系统的东西，就会很快遇到麻烦，这些东西往往会很快出现：GUI、一些 I/O、线程、进程、网络。
一旦您#include <win32.h>在 C 代码中获得类似或类似的代码，您就必须重写部分代码以将其移植到 Linux/OSX 平台，其中一些工作可能并不明显或直接不可能。
Java 的优势不仅在于它的虚拟机以及在任何平台上读取和运行相同字节码的能力，还在于作为 JRE 一部分的相当大的库（例如 J2SE）和通用线程和网络的可用性模型。
对我来说，主要优势是库的可移植性。库之间可能存在版本依赖关系，但除此之外，JAR 也可以工作。
有所谓的类加载器地狱，但这并不常见。
在大多数其他语言中，您要么必须找到正确的库二进制文件，要么必须下载源代码来安装它。
猜猜你在谈论移植问题。事实上，JVM 就是流行文献中所说的，Java 消除了对代码移植的需要是一种更微妙的阴影。
你不必看得太远。正是出于这个原因，存在一个小型行业，即 Windows 到 UNIX 代码移植开发人员 [反之亦然]。想要例子吗？C 语言中的近、远指针之类的东西怎么样？或者使用 __declspec(dllexport) 创建一个 Windows 特定的 dll，而 gcc 没有这些，你需要 -shared 选项？
最困难的场景之一是在 QT 出现之前做基于 C++ 的 GUI。大量的 GUI 仍然在 .NET 上完成，遗留代码在 MFC 上，对于 Linux/UNIX，很多遗留代码在 XWindows 中。在这种情况下，Java 是天赐之物——大多数东西都可以在不跨平台重新发明轮子的情况下工作。
我整理了一些答案。。
虽然我还没有测试过它们。我从答案中看到了对我有意义的好例子
Bruno 在 C 中提供了一个示例
#include <win32.h>（必须针对不同的操作系统重写操作系统特定的行和代码）任何仅限于使用 stdio.h 和其他一些调用（可移植）的东西
加里，谈到了一个 int 的案例。在 C 中，“一个 int 在 32 位盒子上是 32 位。在 64 位盒子上是 64 位”“可移植的方式是使用 int32_t”以及关于 C 和汇编语言的一点。我问过发现如果超过限制，它会循环回 0。所以，这可能是代码对不同系统和编译产生不同影响的情况，但可能无法按预期工作，它必须是重写。
Thorbjørn 提供了指向不同 CPU 上的汇编语言示例的链接。Win32 ASM 用于 32 位 CPU，Win64 用于 64 位。它每个都有一个 hello world 示例，并说转换它们并不容易，因为“在 Win32 中，所有参数都通过堆栈传递，但在 Win64 中，它们通过寄存器传递。” 他说它使用不同的指令..我想你可能不止于此，从某种意义上说，如果它是一种不同的汇编语言..而汇编语言是一个明显的不可移植性案例..因此我没有在问题，但很高兴看到该链接上的示例。这是很好的知识。很高兴看到一些当代汇编语言不是晦涩的机器..
主要是便携性。相同的 Java 二进制文件可以在 Linux/Mac/Windows 上运行。加上 SPARC/PPC/x86/x86-64/ARM/MIPS 等。阅读：相同的二进制文件。无需重新编译。:)