Skip to content
Advertisement

Java Compilation vs Perl Compilation

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?

Advertisement

Answer

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; e.g. 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 (e.g. 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 scripting1, 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.

User contributions licensed under: CC BY-SA
8 People found this is helpful
Advertisement