具有 JVM（或 Dalvik VM，基本上是 Google 的 Java VM 的重新命名版本）。哎呀，iPhone 有一个 ARM CPU，针对运行 Java 字节码进行了优化（但出于商业原因，Apple 决定不在 iPhone/iPad 上提供 Java）。
当然有 Java 的蓝光播放器（因为它是蓝光规范的一部分）。
我正在用 Java 开发商业软件：我们在 Windows 和 OS X 上销售，但我们都在 Linux 上开发。它确实有效。它也适用于 Solaris 等。这是因为我们的目标是 JVM：告别可移植性问题。只要平台有虚拟机，软件就可以运行。
然后我不敢相信有人提到过它：从安全角度来看，这是一个非常好的开始。
根据设计，Java VM 不会受到缓冲区溢出的影响。这是巨大的。这实际上比大多数人意识到的要大。
我记得在 Linux 上唯一的“Java”缓冲区溢出（由于安全问题促使我升级）实际上是缓冲区溢出导致任意代码执行......一个 C 编写的库（zlib，如果我没记错的话，回到Linux 上的 Java 仍然默认使用该库）。
当然，对于 Web 应用程序来说，缓冲区溢出/溢出导致任意代码执行不再是最重要的攻击媒介（现在 XSS 和 SQL 注入已经抢尽风头）。但在所有其他情况下，缓冲区溢出/溢出是大多数安全问题的根源。
JVM 对此免疫。
除此之外，由于其设计，可以轻松地在其上插入各种工具，例如分析器和调试器。
这是一种非常可靠和安全（如果使用正确）的技术。这就是为什么它被精通技术的公司（Java 在 Google 中巨大，从 GMail 到他们的 Android 再到 GWT 等）和不那么精通技术的公司广泛使用。
事实上，Java 的成功来自于 JVM 并且“Java the VM”比“Java the language”重要得多，这一点实际上是有争议的。
JVM 是过去 20 年来最伟大的“语言”成功故事。这是应得的。它会一直存在:)
The JVM is rock solid and works from the tiniest Java SmartCard (ok, a tiny VM ;) to the biggest clustered super-computers you can imagine.
Because it is rock solid, there are entire countries where people have:
a Java SmartCard in their wallet as either their national ID card or as their medical care system card (or both)
a cellphone that has a JVM (or a Dalvik VM, which is basically Google's rebranded version of the Java VM). Heck, the iPhone has an ARM CPU optimized to run Java bytecode (but for business reason Apple decided not to offer Java on the iPhone/iPad).
a BluRay player that of course has Java (because it's part of the BluRay spec).
I'm developping commercial software in Java: we're selling on Windows and on OS X but we're all developping on Linux. And it just works. And it works on Solaris too, etc. And that's because we're targetting the JVM: goodbye portability issue. As long as the platform has a VM, the software shall work.
Then I can't believe anyone mentioned it yet: it is a very good start from a security point of view.
The Java VM is, by design, immune to buffer overrun/overflow. This is huge. This is actually huger than most people realize.
The only "Java" buffer overflow that I remember on Linux (that prompted me to upgrade due to security concern) was actually a buffer overflow leading to arbitrary code execution in... a C written lib (zlib if I remember correctly, back in the days Java on Linux was still defaulting to that lib).
Sure, for webapps buffer overrun/overflow leading to arbitrary code execution are not the most important vector of attack anymore (now that XSS and SQL injection have stolen the show). But in all the other cases buffer overrun/overflow are the source of most security issues.
The JVM is immune to that.
In addition to that thanks to its design it's easy to plug various tools on it like profilers and debuggers.
It is a very solid and secure (when used correctly) technology. That is why it is so widely used by both tech-savvy (Java is huge at Google, from GMail to their Android to GWT etc.) and tech-not-that-savvy companies.
It is actually arguable that Java's success comes from the JVM and that "Java the VM" is much more important than "Java the language".
The JVM is the biggest "language" success story of these last 20 years. And it is deserved. And it is here to stay :)
如果您编写自己的 VM，则必须为 Linux/Unix/BSD 编写一个，为 Mac 编写一个，为 Windows 编写一个，并且必须支持所有这些平台上的 VM 以及支持您的语言编译器和运行时库。如果您使用 Java VM，第一部分将由 Oracle、IBM 和 Apple 为您处理。
Because somebody else has already taken the trouble to make sure it runs well on every major platform.
If you write your own VM, you have to write one for Linux/Unix/BSD, one for Mac, and one for Windows, and you have to support the VM on all those platforms as well as supporting your language compiler and runtime libraries. If you use the Java VM, the first part is taken care of for you by Oracle, IBM and Apple.
Because with almost 20 years of effort the Java VM is
portable
enough efficient, not as C or C++ but with a good performance (considering it's still a vm)
easy to integrate with
estensively supported with APIs or libraries
I mean, if i would plan to release a new language why shouldn't I use the JVM? Ok, there are others vms (llvm, parrot) but the JVM is estensively supported, known, and tested.
And it works also quite good! The lack of invokeDynamic will be solved with the relase of Java7 so better than this..
编写一个与 JVM 一样好的 VM 是很困难的。十多年来，业界最优秀的人才对 JVM 的规范及其实现进行了完善。
What makes it so powerful or popular that there are new programming languages, which seem gaining popularity too, created for it?
It's free & open, mature (stable, complete), and the surrounding ecosystem is huge.
Why don't they write a new VM for a new language?
Writing a VM as good as the JVM is hard. JVM's spec and its implementations have been refined for well over a decade by the finest minds in the industry.
第一个问题：为什么要重新发明轮子？ Java VM 有多种实现，包括高度优化的实现，并且至少有一种可用于任何平台。
第一个问题第二个问题：有大量的第三方库和工具支持编译为 Java 字节码并在 VM 上运行的代码。当您创建一种新语言时，一个大问题是您必须创建人们可以使用它的所有内容，或者使其与其他语言兼容（例如链接到现有的静态 C 库、.Net、COM 或 Java）虚拟机）。 Java VM 的开放规范（呃，到目前为止）、深厚的历史和广泛的适用性使其成为新语言的良好目标。
Second question first: Why reinvent the wheel? There are multiple implementations of the Java VM, including highly-optimized ones, and there's at least one available for darned near any platform out there.
First question second: There is a huge amount of third party library and tool support for code compiled to Java bytecode and run on the VM. When you create a new language, one big issue is that you have to create everything that people can use with it, or make it compatible with something else (like linking to existing static C libraries, or .Net, or COM, or the Java VM). The Java VM's open specification (erm, so far), deep history, and broad applicability make it a nice target for new languages.
因为它不是微软的技术。正如其他人提到的，使用 JVM 有很多重要的理由，但我认为，如果 Microsoft 的 CLR 也同样免费、可移植和开放，那么它的受欢迎程度可能会稍低一些。
Because its not a Microsoft technology. As others have mentioned, there are a lot of great reasons to use the JVM, but I think it would be slightly less popular if Microsoft's CLR was as free, as portable, and as open.
发布评论
评论（10）
这很简单：
That one is easy:
性能和库
Performance and Libraries
JVM 坚如磐石，适用于从最小的 Java 智能卡（好吧，一个微型虚拟机；）到您能想象到的最大的集群超级计算机。
因为它坚如磐石，所以在很多国家/地区，人们都拥有：
我正在用 Java 开发商业软件：我们在 Windows 和 OS X 上销售，但我们都在 Linux 上开发。它确实有效。它也适用于 Solaris 等。这是因为我们的目标是 JVM：告别可移植性问题。只要平台有虚拟机，软件就可以运行。
然后我不敢相信有人提到过它：从安全角度来看，这是一个非常好的开始。
根据设计，Java VM 不会受到缓冲区溢出的影响。这是巨大的。这实际上比大多数人意识到的要大。
我记得在 Linux 上唯一的“Java”缓冲区溢出（由于安全问题促使我升级）实际上是缓冲区溢出导致任意代码执行......一个 C 编写的库（zlib，如果我没记错的话，回到Linux 上的 Java 仍然默认使用该库）。
当然，对于 Web 应用程序来说，缓冲区溢出/溢出导致任意代码执行不再是最重要的攻击媒介（现在 XSS 和 SQL 注入已经抢尽风头）。但在所有其他情况下，缓冲区溢出/溢出是大多数安全问题的根源。
JVM 对此免疫。
除此之外，由于其设计，可以轻松地在其上插入各种工具，例如分析器和调试器。
这是一种非常可靠和安全（如果使用正确）的技术。这就是为什么它被精通技术的公司（Java 在 Google 中巨大，从 GMail 到他们的 Android 再到 GWT 等）和不那么精通技术的公司广泛使用。
事实上，Java 的成功来自于 JVM 并且“Java the VM”比“Java the language”重要得多，这一点实际上是有争议的。
JVM 是过去 20 年来最伟大的“语言”成功故事。这是应得的。它会一直存在:)
The JVM is rock solid and works from the tiniest Java SmartCard (ok, a tiny VM ;) to the biggest clustered super-computers you can imagine.
Because it is rock solid, there are entire countries where people have:
I'm developping commercial software in Java: we're selling on Windows and on OS X but we're all developping on Linux. And it just works. And it works on Solaris too, etc. And that's because we're targetting the JVM: goodbye portability issue. As long as the platform has a VM, the software shall work.
Then I can't believe anyone mentioned it yet: it is a very good start from a security point of view.
The Java VM is, by design, immune to buffer overrun/overflow. This is huge. This is actually huger than most people realize.
The only "Java" buffer overflow that I remember on Linux (that prompted me to upgrade due to security concern) was actually a buffer overflow leading to arbitrary code execution in... a C written lib (zlib if I remember correctly, back in the days Java on Linux was still defaulting to that lib).
Sure, for webapps buffer overrun/overflow leading to arbitrary code execution are not the most important vector of attack anymore (now that XSS and SQL injection have stolen the show). But in all the other cases buffer overrun/overflow are the source of most security issues.
The JVM is immune to that.
In addition to that thanks to its design it's easy to plug various tools on it like profilers and debuggers.
It is a very solid and secure (when used correctly) technology. That is why it is so widely used by both tech-savvy (Java is huge at Google, from GMail to their Android to GWT etc.) and tech-not-that-savvy companies.
It is actually arguable that Java's success comes from the JVM and that "Java the VM" is much more important than "Java the language".
The JVM is the biggest "language" success story of these last 20 years. And it is deserved. And it is here to stay :)
因为其他人已经不厌其烦地确保它在每个主要平台上运行良好。
如果您编写自己的 VM，则必须为 Linux/Unix/BSD 编写一个，为 Mac 编写一个，为 Windows 编写一个，并且必须支持所有这些平台上的 VM 以及支持您的语言编译器和运行时库。如果您使用 Java VM，第一部分将由 Oracle、IBM 和 Apple 为您处理。
Because somebody else has already taken the trouble to make sure it runs well on every major platform.
If you write your own VM, you have to write one for Linux/Unix/BSD, one for Mac, and one for Windows, and you have to support the VM on all those platforms as well as supporting your language compiler and runtime libraries. If you use the Java VM, the first part is taken care of for you by Oracle, IBM and Apple.
因为经过近 20 年的努力，Java VM 的
集成，我的意思是，如果我打算发布一种新语言为什么不应该使用 JVM？好吧，还有其他虚拟机（llvm、parrot），但 JVM 得到了广泛的支持、已知和测试。
而且效果也相当不错！ Java7 的发布将解决
invokeDynamic的缺失，所以比这更好。Because with almost 20 years of effort the Java VM is
I mean, if i would plan to release a new language why shouldn't I use the JVM? Ok, there are others vms (llvm, parrot) but the JVM is estensively supported, known, and tested.
And it works also quite good! The lack of
invokeDynamicwill be solved with the relase of Java7 so better than this..它是免费的&开放、成熟（稳定、完整），周边生态系统庞大。
编写一个与 JVM 一样好的 VM 是很困难的。十多年来，业界最优秀的人才对 JVM 的规范及其实现进行了完善。
It's free & open, mature (stable, complete), and the surrounding ecosystem is huge.
Writing a VM as good as the JVM is hard. JVM's spec and its implementations have been refined for well over a decade by the finest minds in the industry.
第一个问题：为什么要重新发明轮子？ Java VM 有多种实现，包括高度优化的实现，并且至少有一种可用于任何平台。
第一个问题第二个问题：有大量的第三方库和工具支持编译为 Java 字节码并在 VM 上运行的代码。当您创建一种新语言时，一个大问题是您必须创建人们可以使用它的所有内容，或者使其与其他语言兼容（例如链接到现有的静态 C 库、.Net、COM 或 Java）虚拟机）。 Java VM 的开放规范（呃，到目前为止）、深厚的历史和广泛的适用性使其成为新语言的良好目标。
Second question first: Why reinvent the wheel? There are multiple implementations of the Java VM, including highly-optimized ones, and there's at least one available for darned near any platform out there.
First question second: There is a huge amount of third party library and tool support for code compiled to Java bytecode and run on the VM. When you create a new language, one big issue is that you have to create everything that people can use with it, or make it compatible with something else (like linking to existing static C libraries, or .Net, or COM, or the Java VM). The Java VM's open specification (erm, so far), deep history, and broad applicability make it a nice target for new languages.
因为它不是微软的技术。正如其他人提到的，使用 JVM 有很多重要的理由，但我认为，如果 Microsoft 的 CLR 也同样免费、可移植和开放，那么它的受欢迎程度可能会稍低一些。
Because its not a Microsoft technology. As others have mentioned, there are a lot of great reasons to use the JVM, but I think it would be slightly less popular if Microsoft's CLR was as free, as portable, and as open.
明显的原因：
Obvious reasons: