JIT编译器已存在一段时间了。偶尔我会想到，“嘿，为什么不直接将Java源文件编译成机器代码呢？”
与编译库一起，我们可以摆脱繁琐的JVM。
我能想到的唯一障碍是垃圾收集器。你的想法怎么样？
PS：哦，你说便携性？ WTH是那个？另外，我首先被迫安装JVM。答案 0 :(得分：20)
好吧，我的朋友使用Ubuntu，我使用Windows XP，而我的另一个朋友使用OSX。
当我向他们发送我编译的jar时，他们都可以运行该文件而不做任何更改。
这就是为什么你不应该摆脱JVM。
答案 1 :(得分：7)
vm可以根据仅在运行时可用的信息执行复杂的优化。静态编译时优化根本无法竞争。 Java很快，因为它在vm上运行。
看这个
答案 2 :(得分：4)
在某些平台上（主要是嵌入式平台），就像你说的那样（或者机器本身就是java）。您也可以下载执行您所建议的编译器，但我想您在此过程中会丢失大量Java API。
回到你的问题，主要原因是设计语言和规范的人想拥有它。干净利落。它提供了可移植性，考虑到制作可移植代码的“硬”部分应该只需要在每个环境中完成一次（另一个海报讲述了3个不同的OS运行JVM）而不是每个项目的每个环境一次。你有没有试过制作大多数可移植的C ++代码而没有像Qt这样的框架或像Boost这样的软件包？它变得非常困难，即使这样，你仍然必须为每个架构重新编译。
答案 3 :(得分：2)
除了可移植性之外，另一个需要考虑的问题是动态类加载，这很难通过机器代码来处理。 servlet容器如何在这种情况下工作？也许它适用于嵌入式Java，但我不认为是J2EE。
.class表单只是一个在执行前转换为机器代码的中间二进制文件吗？或者你会直接从Java源代码编译成机器代码吗？
答案 4 :(得分：1)
字节码生成对于代码的平台独立性是必要的。