Why does Java explain execution without directly interpreting the source code? __java

Original address: http://www.zhihu.com/question/34345694

Why does Java source go through the intermediate steps into bytecode, which is not to increase the workload. Directly interpret the source code across platforms as well.

Why not explain the source code directly while interpreting the runtime, but rather the byte code.

Bytecode is more convenient for virtual machine to read, do not parse string, so run faster than directly parse source code. The syntax is changed, and the source code does not have version information, and bytecode not only version information, but also through the compilation process to smooth some language changes (that is, although the language syntax changes, but the bytecode is still in accordance with the original rules). Bytecode can also be generated by other languages, such asGroovy,clojure,scala。 Note that since these languages can be compiled into bytecode, they can be invoked in Java or other JVM languages.In the final analysis, however, there is no absolute reason to design, and many things do, just because they are designed to do so.
Java is strictly a "semi-compiled" type of language Java code first compiled by Javac into bytecode (bytecode). Bytecode is the only instruction that the JVM can recognize, and the specification of the JVM to translate bytecode into a machine code bytecode that is really capable of executing is defined by the JVM specification (the Java®virtual Machine specification). The JVM needs different implementations on different hardware platforms to achieve what is called a "write-and-run" goal. Theoretically, you can directly explain the source code, this can also cross the platform. The introduction of bytecode has additional benefits:
Executing bytecode directly is faster than interpreting the source code and then executing it.
In the process of generating bytecode, the compiler can make grammatical errors or security checks in advance, with fewer opportunities for errors.
The byte code is more compact than the source code, the file size is smaller, facilitates the network transmission.
Some embedded devices, not enough resources to run the full compiler, these devices only need to embed a small JVM on the line, on the additional platform to compile the source code.
Bytecode does not necessarily have to be generated by Java source code, and some other languages like Scala can compile bytecode. So that other languages can take advantage of the JVM that has evolved over the years.
It all comes from better design.
1, fast
2. Cross platform
3, can be extended
4, "The Java Specification" and "The JVM specification" is separate, at the beginning of the design of the commitment to support other languages compiled into bytecode, such as Jruby,scala, Jython, etc.

Instead of reading data directly from the hard disk, the CPU reads data from memory or registers.
It's about the same as the truth.
In order to cross the platform, compiled into a byte stream file. class, which is independent of the hardware and operating system, is cross-platform, then implemented, and then uses the respective platform interpreter to explain the cost of machine code. There is also a security issue, and the result of the compilation itself guarantees code security and copyright.
Author: Fire Rain
Link: http://www.zhihu.com/question/34345694/answer/59501996
Source: Know
Copyright belongs to the author, reprint please contact the author to obtain authorization.

In fact, Java as a high-level language, easy for developers to read and understand the code, the JVM virtual machine to execute code directives, and the instructions will not be as strong as the source code is very readable, in addition, the class file content compact, using small space, the JVM load class to support the load from the network class file This can reduce network bandwidth and improve performance.
Javac compilation process, is not simple to interpret as a virtual machine can recognize the instructions so simple, in the compilation process, the need for lexical analysis of the source code, syntax analysis, semantic analysis, the final generation of bytecode. We all know that the Java language, memory is automatically managed, an object instance of the memory space application, allocation and recycling are the virtual machines themselves to manage. Java memory allocation has dynamic memory allocation, but also has static memory allocation, static memory allocation is at compile time to determine the amount of memory to allocate, such as static constants of classes, for some unknown size objects, only the runtime can determine the size of the requested space. Therefore, the static allocation performance relative dynamic allocation is relatively higher. As a result, Java compiled into bytecode, in addition to compiling the source code into a virtual machine executable bytecode, but also did some other preparation work.
Therefore, if the source code instead of bytecode, virtual machine directly execute the source code, either the programmer will write the source code as bytecode, which is unfriendly to the programmer, and when the virtual machine loads a class or instantiates an object, the virtual machine does something similar to the compiler, but the performance can be greatly affected.
Understanding of the relatively shallow, there may be many places are not correct, I hope that we explore together.
Java9 added a new tool, Jshell, and then I got off the EA version originally. It should be said that from the beginning of the JAVA9, Java has the tools to directly explain the source code to run the program (refers to the surface, the bottom should still be a byte code and then run).
First, write a program to calculate PI:
<img src="https://pic4.zhimg.com/34a2775021ca4db77ac604d6d84a74b3_b.png" data-rawwidth="859" data-rawheight="326" Class="origin_image zh-lightbox-thumb" width="859" Data-original="https://pic4.zhimg.com/34a2775021ca4db77ac604d6d84a74b3_r.png">
Then use Jshell to run:
<img src="https://pic1.zhimg.com/97078a23dbd40e7a559fb308a83236ac_b.png" data-rawwidth="409" data-rawheight="46" class="content_image" Width="409"> Yes, you did not read the wrong, later Java can also be used as a scripting language. Of course, it's a little bit more verbose than Scala and Groovy,java (though it's not obvious in this case). But it's great (after all, it's Java:) Yes, you did not read the wrong, later Java can also be used as a scripting language. Of course, it's a little bit more verbose than Scala and Groovy,java (though it's not obvious in this case). But it's great (after all, it's Java:) ）
At present, the disadvantage of Jshell is that the startup time is longer (the JVM startup time +jshell itself), the latter should be improved; the second is that there are so few built-in methods, so there's only one way to do it now. The third problem should be the Java language itself, the lack of a var keyword (Jep 286 Consider adding this feature to Java, which should hopefully be implemented in JAVA10, Jep 286:local-variable Type inference)

I would like to add some r big reply.

Interpreation The source code is OK, but might to slow in many places because of any absent. By translation, the generate code can is somewhat optimized or simplified.

Norammly, there are a lot of mode for interpretation.
1) interprete source code directly.
2) interprete IR, eg. Bytecode.
3) between 1) and 2, e.g., interprete AST tree.
4) Translate AST to native code and execute.
5).
Many interpreters would mix above four modes. For example, JIT compilation to Java/javascript which mixes of bytecode interpretation and native code execution in many Projects.

The decison is made for the performance/memory/factors. For example, the interpreter in Cruby under 1.9 is AST interpreter this does not generate. However, it generates bytecode since V1.9 for the performance purpose. Similarly, the jruby+truffle take the idea of early Cruby. The interpreter walks on the AST tree and then truffle (Graal) compiles the code and execution. This is also performance purpose.

In fact, Java as a high-level language, easy for developers to read and understand the code, the JVM virtual machine to execute code directives, and the instructions will not be as strong as the source code is very readable, in addition, the class file content compact, using small space, the JVM load class to support the load from the network class file This can reduce network bandwidth and improve performance.
Javac compilation process, is not simple to interpret as a virtual machine can recognize the instructions so simple, in the compilation process, the need for lexical analysis of the source code, syntax analysis, semantic analysis, the final generation of bytecode. We all know that the Java language, memory is automatically managed, an object instance of the memory space application, allocation and recycling are the virtual machines themselves to manage. Java memory allocation has dynamic memory allocation, but also has static memory allocation, static memory allocation is at compile time to determine the amount of memory to allocate, such as static constants of classes, for some unknown size objects, only the runtime can determine the size of the requested space. Therefore, the static allocation performance relative dynamic allocation is relatively higher. As a result, Java compiled into bytecode, in addition to compiling the source code into a virtual machine executable bytecode, but also did some other preparation work.
Therefore, if the source code instead of bytecode, virtual machine directly execute the source code, either the programmer will write the source code as bytecode, which is unfriendly to the programmer, and when the virtual machine loads a class or instantiates an object, the virtual machine does something similar to the compiler, but the performance can be greatly affected.
Understanding of the relatively shallow, there may be many places are not correct, I hope that we explore together.

Explain the source code directly, and cross the platform.
This kind of programming language really has ah, Php,python. To say efficiency, or Java higher.
The compiler would have been faster than the explanatory type, and the JVM would have optimized the code at runtime.

Original