Java 编译与 Perl 编译

Question

How different is the compilation procees of Java and Perl ? Both produce a byte code but what happens after that? Is the interpretation in perl and conversion from object code to machine code in java is all that is different? If so then why cant Java be a scripting language?

Answer 1

There is no definitive answer to this question but I will try anyway.

Java can compile code more aggressively, as it is not as dynamic as Perl. What makes Java unsuitable as a scripting language is that

• you have to write quite a bit of code to do something simple. eg "hello world" is 5 lines.
• file and string manipulation is relatively complicated compared to Perl.
• it is hard to run another program from Java.
• you could use BeanShell or Groovy for scripting Java, but you wouldn't because there is a long list of languages which would be a better choice. eg bash for a start.

Answer 2

Java and Perl are languages that are not per se compiled or interpreted, but both have only one main implementation.

Java

Java source code is compiled ahead-of-time to a portable bytecode. Some optimizations are applied in this step. This byte code is then executed by the JVM, either by interpretation or by JIT compilation, at the choice of the JVM. There is nothing inherent in the language that would prevent compilation + execution in a single step.

Perl

In the perl interpreter, the VM and compiler are tightly integrated. Even during parsing of the source code, certain parts may already be executed. Each executable unit produces an “Opcode Tree” which has both the roles of an AST and of bytecode. This incremental compilation means that it is not possible to really separate compilation from execution, although it would be sometimes possible to cache the compiled result, or to JIT part of the optree. The opcodes are then interpreted.

Comparison

Perl compiles much faster than Java, but only very few optimizations are applied, eg constant folding or removal of unnecessary opcodes. More complex optimizations are too expensive for scripting usage. The lack of JIT support and advanced optimizations also means that Perl is usually much slower than Java.

In principle, both VMs (JVM and perl) can be used for other languages as well. The lack of a formal specification and the very Perl-centric implementation means that no other languages use the perl interpreter as a VM, whereas many languages can compile to JVM bytecode (examples include languages like Python, Ruby, Perl6, Clojure, …).

However, the JVM is optimized for long-running programs like server software or desktop applications. This makes it a feasible tradeoff to perform costly optimizations. OTOH Perl is not only used for large programs but also small tools where start-up cost is important. Therefore simple Perl scripts may only need as little as 2 MB of memory, and can execute faster than the JVM needs for startup alone. While the JVM can be used for scripting, the startup cost and extreme memory usage often makes it unattractive.

Terminology note: scripting is executing a program without manually compiling it. This has nothing to do with interpreted vs. compiled. In Unix, the shebang can be used to specify the interpreter of a script.

Answer 3

The first thing to note is that the "compilation processes" are not inherent to the respective languages. Rather they are aspects of specific implementations of the respective language. (Even Java bytecodes, the JVM, and related stuff are implementation details ... and not universal to all implementations of the Java language.)

The "what happens next" after compilation to bytecodes is ... implementation dependent.

• For Java, the bytecodes are typically interpreted for a bit (to gather some stats) and then compiler to native code. But not always; eg look up the java -int command option. And technically speaking, there isn't even a requirement to have bytecodes anywhere in the picture. (Though there are legal issues about use of the trademark "Java" ...)

• For Perl, my understanding is that the bytecodes are typically just interpreted. But the other wrinkles are that Perl compilers can generate other forms of code, and that Perl can directly interpret the "internal form" the Perl compiler front-end produces.

So to answer your questions:

How different are the compilation processes of Java and Perl?

See above. In both cases it is more complicated than you portray.

Both produce a byte code ...

Again, not necessarily true.

... but what happens after that? Is the interpretation in perl and conversion from object code to machine code in java is all that is different?

Well the "bytecode" instruction sets will necessarily be different, because of the nature of the respective "virtual machines". The JVM is an essentially statically typed thing where the formal type of each and every variable and expression is known ... ane either a primitive or some kind of object type. By contrast, the Perl VM needs to be (more) dynamically typed because of the nature of the Perl language.

If so then why cant Java be a scripting language?

Well clearly, the "if so" part is not satisfied ... there are significant differences.

But (IMO) there are stronger reasons why Java would not be a good scripting language:

• Java is relatively verbose
• Java insists that types and variables be declared
• Java is essentially statically type checked
• Java's support for functional style programming (eg first-class and higher order functions) has traditionally been poor (though this is improving ...)
• Java has limited ability to extend the language core (like typical scripting languages can do)
• The startup time for a (typical) JVM is significantly longer than for regular scripting languages.

These things all combine to make Java a poor choice for scripting ^{1, 2} . But the flip-side is that they make Java a good choice for situations that require higher performance and the improved reliability of static, compile-time typing.

(In a sense, the use of bytecodes and the nature of the compilation process are largely immaterial to scripting versus non-scripting ... provided that compilation isn't too slow ... at the wrong time.)

---

^{1 - The Java 9 release introduced the "jshell" command which allows you to run Java interactively. Unfortunately, it is not really suitable for scripting because "jshell" scripts cannot access the command line arguments.}

^{2 - The Java 11 release allows you compile and run a single Java source file in one command like this: java SomeCommand.java . This still has the problem of JVM slow startup, with the addition overheads of a source to bytecode compilation step.}