正如我所知道的java开发人员，需要让他们的.java文件成为.class，而.class需要JVM转换为本机代码才能执行。为什么Java设计会这样？为什么不只是使用解释器作为脚本语言来解释.java文件？或者为什么不将它转换为像C这样的可执行文件？为什么需要转换为字节码？ java语言背后的设计理念是什么？
答案 0 :(得分：10)
同时为了速度和便携性。
我要说的所有内容都是根据具体情况进行调整和审核，但粗略地说：
如果您只是用解释器来解释java文件 会有便携性而不是速度。
如果必须编译给定处理器的代码 架构你会有速度而不是便携性。
使用字节码，您可以编译公共代码（到字节码） 将执行它的机器（JVM）它是一个之间的妥协 速度和便携性。
答案 1 :(得分：3)
为什么以这种方式设计Java？
编写一次，随处运行 - 可移植性。
为什么不只是使用解释器作为脚本语言来解释.java文件？
性能。字节码可以通过一些积极的优化编译为本机代码，不适用于普通编译器。
或者为什么不将它转换为像C这样的可执行文件？
因为不同的平台需要不同的可执行二进制文件。 Java字节码（再次）是可移植的。
答案 2 :(得分：2)
为什么不只是使用解释器作为脚本语言 解释器.java文件？或者为什么不将它转换为可执行文件 喜欢C？为什么需要转换为字节码？
我认为其意图是
1）编制时间安全
2）写一次，随处运行。
如果转换为像C这样的可执行文件，则会丢失＃2。从某种意义上说，JVM是一个解释器，所以解释了Java 字节码，同时编译了Java代码。
答案 3 :(得分：2)
为什么不只是使用解释器作为脚本语言来解释.java文件？
或者为什么不将它转换为像C这样的可执行文件？
因为这不会跨平台工作。 Portable Executable（在Windows上使用）不会在Linux或iOS上运行，至少不会没有技巧。
通过考虑套接字和文件访问，可以进行简单的比较。如何在没有JVM的情况下使用一个可执行文件在不同平台上执行此操作？
答案 4 :(得分：0)
解释（和编译）字节代码比解释原始java更快。
字节代码是可移植的。您可以在Windows上编译，并在Mac或Unix上运行字节代码。