为什么这么多人坚持将 JVM 拖入新应用程序中？
例如，我遇到了一些开发人员和架构师，他们对 Rails 应用程序感到恐惧，但又喜欢编写新的 Grails 应用程序的想法。
据我所知，使用 JVM 来支持 Groovy、JRuby 和 Jython 等语言（而不是直接使用 Ruby 或 Python）会产生大量资源开销。
Ruby 和 Python 几乎都可以在任何操作系统上解释，所以我看不出有任何“一次编写，到处运行”的优势……为什么还要带上笨重的 JVM？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
Java 是一个成熟得多的平台，与 Ruby 或 Python（甚至 Perl）相比，它拥有许多可以“插入”和使用的现有类库。 因此，对于喜欢使用现有代码而不是自己编写所有内容的人来说，Java 是一个巨大的胜利。
例如，最近我一直在寻找类似 JAXB for Python 或 Ruby 的东西。 最后，我最终选择使用 JRuby，只是因为我还没有找到任何成熟的、广泛使用的 XML 绑定库。
Java is a much, much more mature platform, with a lot of existing class libraries that could be "dropped in" and used, than, say, Ruby or Python (or even Perl, for that matter). So for people who like using existing code, rather than writing everything themselves, Java is a huge win.
For example, recently I've been looking for something like JAXB for Python or Ruby. In the end, I ended up using JRuby just because I haven't found any mature, widely-used XML-binding libraries.
为 JVM 编写代码（用任何语言）的巨大优势在于，如果需要的话，通常可以很容易地利用大量成熟的 Java 库。
我不知道您从哪里得到“笨重”的 JVM 以及巨大的资源开销的想法。 JIT 往往会生成相当快的代码，而按照今天的标准，核心 JVM 一点也不庞大。 它在运行时确实会占用大量内存，但这是因为现代机器有大量 RAM，并且当 GC 有大量 RAM 可供使用时，GC 的工作效果最佳。 如果需要，GC 可以微调到地狱更加保守。
正如其他人所说：“Groovy 最好的一点是我不必使用 Java。Groovy 的第二好的一点是我可以使用 Java” 。
The huge advantage of writing code (in any language) for the JVM is that it's usually very easy to tap into the enormous wealth of mature Java libraries out there, if necessary.
And I don't know where you got this idea of a "hulking" JVM with a huge resource overhead. The JIT tends to produce code that is quite fast, and the core JVM is anything but huge by today's standards. It does tend to have a huge memory footprint when running, but that's because modern machines have a lot of RAM and the GC works best when it has a lot of RAM to play with. If desired, the GC can be fine-tuned to hell and back to be more conservative.
As someone else put it: "The best thing about Groovy is that I don't have to use Java. The second best thing about Groovy is that I can use Java".
这个问题似乎内置了一个假设，即新项目是新建项目。 许多组织在过去十年多时间里对 Java 进行了巨额投资，并要求任何新项目都在现有（内部）代码生态系统中运行。 正如所指出的，所有公开可用的 Java 库（无论是免费/OSS 还是商业）都有巨大的好处，但是使用现有代码甚至作为现有系统中的组件的需求至少同样重要（如果不是更重要的话）所以）对于大型组织。
很大程度上还取决于平台的成熟度和功能，也就是说 JVM 及其附带的所有内容（整个 Java 生态系统）。 我想到的几个例子：
您可以将远程调试器插入正在运行的 JVM 中，并获取有关正在运行的应用程序的各种信息，这对于 Python、Ruby 等来说是不可能的。更进一步，有JMX，一种编写代码的标准方法，以便可以在实时应用程序中监视甚至调整对象。 看看 JConsole 看看你是不是流口水了很少（尽管界面丑陋）。
在这个方向上更进一步，出现了 OSGi，这是一种编写高度模块化代码的标准，可以在实时应用程序中部署、启动、停止甚至升级。 使用 OSGi，您可以将大型应用程序分解为许多较小的“捆绑包”，然后可以单独维护（部署、启动/停止、升级）。 对于大型应用程序或任何需要始终保持运行的应用程序来说，这确实是一件大事。
该平台对异步、可靠的消息传递有非常良好的支持。 您将 JMS 作为基准，并在其上构建了许多优秀且强大的库，用于执行复杂的操作代码很少（参见 Apache Camel、ServiceMix、Mule 等）。 这是另一个在较大的应用程序或必须在较大的代码域中运行的应用程序中非常有价值的功能。
JVM 具有真正的（操作系统级别）线程，而 Python 等。 在这方面非常有限（众所周知）。 （话虽这么说，共享状态并发——线程——是错误的方法；参见Erlang，爱丽丝，Mozart/Oz 等）
除了标准 Sun 实现之外，还有许多 JVM 选择，例如 JRockit、IBM的JVM等。这是一个与其他语言一起发展的领域——Python有Jython、Iron Python，甚至PyPy和Stackless； Ruby 有 JRuby、Rubinius 和其他 - 但作为尽管这些都很好，但它们无法与各种 JVM 产品的成熟度相媲美。
话虽这么说，我真的不喜欢Java这种语言并尽可能避免使用它。 如今，有了所有优秀的 JVM 替代语言，我就不必这样做了。 Groovy 因其可访问性以及与平台（甚至语言）的紧密集成而获得我的投票，并且还因为 Grails，我有时喜欢将其称为“成人的 Rails”。 我更喜欢其他 JVM 语言，特别是 Clojure 和 Scala，但这些对于普通程序员来说并不那么容易理解。 不过，Scala 最近突然出现很多，特别是由于其 高Twitter 上的个人资料使用情况，因此希望有趣且真正优秀的语言能够在更大的环境中使用。 但这是另一个话题了。
An assumption that seems to be built into the question is that new projects are greenfield projects. Many organizations have made a huge investment in Java over the last decade+ and require any new project to work within the existing (internal) code ecosystem. As pointed out, there's a huge bonus in all the publicly available Java libraries (whether free/OSS or commercial), but the need to work with existing code and even as a component within an existing system is at least as important (if not more so) to large organizations.
A lot also comes down to the maturity and capability of the platform, which is to say the JVM and everything that comes with it (the entire Java ecosystem). A few examples off the top of my head:
You can plug a remote debugger into a running JVM and get all kinds of information about a running application that is simply impossible with Python, Ruby, etc. Going a step further, there's JMX, a standard way to write code so that objects can be monitored and even tweaked in a live application. Take a look at JConsole and see if you don't drool just a little (despite the ugliness of the interface).
Going even further in this direction, there's OSGi, a standard for writing highly modular code that can be deployed, started, stopped, and even upgraded in a live application. With OSGi you break a large application into many smaller "bundles" which can then be maintained (deployed, started/stopped, upgraded) separately. This is a really big deal in large applications, or any applications that need to remain running at all times.
The platform has very good support for asynchronous, reliable messaging. You get JMS as a baseline, and many excellent and powerful libraries built on it for doing complicated things with very little code (cf. Apache Camel, ServiceMix, Mule, and many others). This is another feature that's extremely valuable in larger applications or those which must run within a larger code universe.
The JVM has real (OS-level) threading, while Python et al. are very limited in this regard (notoriously so). (That being said, shared state concurrency -- threading -- is the wrong approach; cf. Erlang, Alice, Mozart/Oz, etc.)
There are numerous JVM choices beyond the standard Sun implementations, like JRockit, IBM's JVM, etc. This is a developing area with other languages -- Python has Jython, Iron Python, even PyPy and Stackless; Ruby has JRuby, Rubinius, and others -- but as good as these are they can't match the maturity found in the various JVM offerings.
All that being said, I really don't like Java the language and avoid it as much as possible. These days with all the excellent alternative languages for the JVM I don't have to. Groovy gets my vote for its accessibility and tight integration with the platform (and even the language), and because of Grails, which I sometimes like to call "Rails for grownups". I like other JVM languages better, particularly Clojure and Scala, but these aren't as accessible to the average programmer. Scala is popping up a lot lately, though, especially thanks to its high profile use at Twitter, so there's hope for interesting and truly excellent languages making it in larger environments. But that's another topic.
JVM 并不臃肿，也不慢。 相反，它是一个精益、快速、深度优化的虚拟机。 不幸的是，它针对静态 OOP 语言进行了优化。
尽管如此，针对 JVM 的优秀编译器确实可以创建性能良好的程序。 我不了解 JRuby； 但 Jython 的目标是比常规 C Python 全面更快，并且它们正在接近（在几个重要用例中它已经更快）。
请记住，良好的 JIT（如 JVM 的 JIT）可以应用静态 C 编译器上无法实现的一些优化，从它们获得更快的代码并不是白日梦。 当然，针对您的语言优化的 VM应该比 JVM 等“非真正通用”的 VM 更快； 但存在成熟度问题：JVM 已经完成了很多工作，而 Ruby 和 Python 的 JIT 还远远不够。
不幸的是，似乎没有更好的通用字节码虚拟机。 Microsoft 的 CLI 也受到与 JVM 类似的限制（ironPython 比 JPython 慢得多且重）。 最好的候选者似乎是 LLVM。 有人知道为什么没有比 LLVM 更动态的语言吗？ 我见过几个Scheme 编译器，但似乎有几个问题。
JVM isn't bloated, nor is it slow. on the contrary, it's a lean, fast, deeply optimized VM. Unfortunately, it's optimized for static OOP languages.
Still, good compilers targeting JVM do create good performing programs. I don't know about JRuby; but Jython's goal is to be all-around faster than regular C Python, and they're getting close (it's already faster at several important use cases).
Remember that a good JIT (like those for JVM) can apply some optimizations unavailable on static C compilers, getting faster code from them isn't a pipe dream. Of course, a VM optimized for your language should be faster than a 'not-really-generic' VM like JVM; but there's the maturity issue: JVM has a lot of work done there, while JITs for Ruby and Python aren't anywhere near.
Unfortunately, there doesn't seem to be any better generic bytecode VM. Microsoft's CLI suffers from similar limitations as JVM (ironPython is much slower and heavier than JPython). The best candidate seems to be LLVM. Does anybody know why isn't there more dynamic languages over LLVM? I've seen a couple of Scheme compilers, but seem to have several problems.
Groovy 不是一种解释语言，它是一种动态语言。 groovy 编译器生成 JVM 字节码，该字节码在 JVM 内部运行，就像任何其他 java 类一样。 从这个意义上说，groovy 就像 java 一样，只是在 java 语言中添加了只对开发人员有意义而不对 JVM 有意义的语法。
开发人员的生产力、语法的易用性和灵活性使 groovy 对 java 生态系统具有吸引力 - 如果 ruby 或 python 产生 java 字节码（请参阅 jython），它们也会同样有吸引力。
Java 开发人员并不真正害怕 ruby；而是真正害怕 Ruby。 事实上，许多人很快就接受了 groovy 或 jython，它们都接近 ruby 和 python。 他们不关心的是离开如此令人惊叹的平台（java）而使用性能较差、可扩展性较差甚至较少使用的语言，例如 ruby（尽管有其所有优点）。
Groovy is NOT an interpreted language, it is a dynamic language. The groovy compiler produces JVM bytecode that runs inside the JVM just like any other java class. In this sense, groovy is just like java, simply adding syntax to the java language that is meaningful only to developers and not to the JVM.
Developer productivity, ease and flexibility of syntax make groovy attractive to the java ecosystem - ruby or python would be as attractive if they resulted in java bytecode (see jython).
Java developers are not really scared of ruby; as a matter of fact many quickly embrace groovy or jython both close to ruby and python. What they don't care about is leaving such an amazing platform (java) for a less performant, less scalable even less used language such as ruby (for all its merits).
RoR 面临的最大问题是它不可扩展且难以部署。 通过使用 Java 平台，您可以利用现有的基础设施。
生成一个可轻松部署在 Glassfish、Jboss 等上的 war 文件。
The big knock on RoR is that it isn't scalable and hard to deploy. By using the Java platform, you can leverage your existing infrastructure.
Produces a war file that is easily deployed on Glassfish, Jboss, etc.
主要是因为您想要利用 Java 库、API 和产品组成的庞大现有生态系统，这使得 Ruby 或 Python 可用的任何东西都相形见绌，尤其是在企业领域。
另外，请记住，JRuby 和 Jython 在许多基准测试中都比这些语言的常规（C 实现）更快，尤其是 Ruby（甚至 Ruby 1.9）。
针对同一虚拟机使用多种语言有很多好处，例如利用通用基础设施、代码重用、共享 API、使用概念上最适合您或特定问题领域的任何语言的能力等
。 .NET 领域发生了一些事情，多种语言都针对 CLR。 Parrot（vaporware）VM 项目也致力于同样的事情，它的既定目标是LLVM 项目也是如此。
Mostly because you want to take advantage of the HUGE existing ecosystem of Java libraries, APIs and products, which dwarfs anything available for Ruby or Python, especially in the enterprise domain.
Also, keep in mind that JRuby and Jython are faster in a lot of benchmarks than the regular (C implementations) of the languages, especially Ruby (even Ruby 1.9).
Having multiple languages targeting the same virtual machine has a lot of benefits, such as leveraging a common infrastructure, code reuse, shared APIs, the ability to use whatever language is conceptually best for you, or for a specific problem domain, etc.
The same things happens in the .NET space, with multiple languages targeting the CLR. The Parrot (vaporware) VM project also aims to the same thing, and it's a stated goal of the LLVM project too.
原因就是热点。
这是一项工程杰作。
The reason is Hotspot.
It is an engineering tour de force.
另一个没有被很多人提及的原因是与 jvm 相关的现有基础设施 - 如果您已经有一个运行 java 东西的服务器，为什么不使用它而不是引入另一个平台（如 Rails）？
the other reason not many mentioned is existing infrastructure related to jvm - if you already have a server running java stuff, why not use it instead of bringing in yet another platform (like rails)?
我遇到过这种情况，也对此感到困惑，这是我的理论。
企业软件里全是Java程序员。 与各行各业的程序员一样，许多 Java 程序员都坚信自己的语言是最快、最灵活且最容易使用的——他们对其他语言不太熟悉，但坚信实践这些语言的人一定是野蛮人和野蛮人。 ，因为任何开明的人当然都会使用 Java。
这些人构建了庞大而复杂的 Java 基础设施：由框架组成的 rube-goldberg 机器和自动生成的代码，其中充满了拜占庭式的继承结构和非常非常大的 XML 文件。
因此，当有人走过来说“嘿！让我们使用 C 解释型语言吧！它速度很快，有简洁的库，而且脚本编写和原型设计要快得多！” Java 人员首先会说“我必须运行一个 make 文件来配置这个？太可怕了！” 然后，现实就是必须在运行过时的操作系统和 Tomcat 版本的服务器上部署和托管它，而没有其他任何东西开始出现。
“嘿，我知道！这种解释性语言有一个 java 版本！它可能会崩溃高峰时段桥上的快车道，有时会着火，但我可以让 Tomcat 来运行它，我不必因为学习非 Java 的东西而弄脏我的手，而且我可以把它硬塞进去。现有基础设施获胜！”
那么，这是选择脚本语言的 java 实现的“正确”理由吗？ 可能不会。 取决于你对“正确”的定义。 但是，我怀疑这就是他们被选中的原因，比我这样的势利小人愿意相信的要多。
I've encountered this and also been baffled by it, and here's my theory.
Enterprise software is full of Java programmers. Like programmers of all stripes, many Java programmers are convinced that their language is the fastest, the most flexible and the easiest to use--they're not too familiar with other languages but are convinced that those who practice them must be savages and barbarians, because any enlightened person would, of course, use Java.
These people have built vast, complicated Java infrastructures: rube-goldberg machines of frameworks and auto-generated code full of byzantine inheritance structures and very, very large XML files.
So, when someone comes along and says "Hey! Let's use a C interpreted language! It's fast and has neat libraries and is much quicker for scripting and prototyping!" The Java guy is firstly like "I have to run a make file to configure this? QUEL HORREUR!" Then the reality of having to deploy and host this on servers that are running dated OSes and dated versions of Tomcat and nothing else starts to set in.
"Hey, I know! There's a java version of this interpreted language! It may break down in the fast lane on the bridge in rush-hour, and it sometimes catches on fire, but I can get Tomcat to run it. I don't have to dirty my hands with learning non-java stuff, and I can shoehorn it into the existing infrastructure! Win!"
So, is this the "right" reason for choosing a java implementation of a scripting language? Probably not. Depends on your definition of "right". But, I suspect that it's the reason they're chosen more often than snobs like me would like to believe.