0

Just a question of curiosity that I came up with when I was reading the JVM introduction.

Why do we need the Java compiler when we have the universal, platform-independent Java Virtual Machine? I mean, consider Python, which has an interactive shell that reads the source code line by line and then execute it without having to compile the source code beforehand, why can't JVM be designed to be able to read .java files directly like that of Python and then execute it?

If that's not the case, can someone please explain the significance of Java compiler?

Lemon
  • 29
  • 2
  • Actually, python also compiles the `.py` file's code to bytecode `.pyc` and then on the runtime the bytecode gets interpreted. – The Alpha Jan 06 '18 at 19:52
  • So normal users of Java applications only need the JRE, not developer tools. Also, compiled .class files take up much less space than .java files. – bcsb1001 Jan 06 '18 at 19:52
  • 1
    @TheAlpha: Modern Python does. :-) – T.J. Crowder Jan 06 '18 at 19:52
  • @T.J.Crowder, I'm confused by your comment, if you please explain a little bit then it might help me to clarify my understanding. – The Alpha Jan 06 '18 at 19:55
  • 1
    @TheAlpha: It's not important. :-) But Python was, originally, interpreted; lots of detail [here](https://stackoverflow.com/questions/2998215/if-python-is-interpreted-what-are-pyc-files). It didn't take long to start saving pyc files, though, I believe (not to mention PyPy and Cython and...). – T.J. Crowder Jan 06 '18 at 20:03

2 Answers2

4

Java could indeed have been created where you ship source everywhere (as one typically does with JavaScript). But as a design choice, Gosling et. al. decided to ship bytecode instead, which is created from the source by the Java compiler. There are several objective reasons for doing so:

  • Bytecode is smaller than source code.
  • Bytecode is harder to reverse-engineer than source code (though only slightly).
  • Bytecode is harder to modify than source code.
  • Using bytecode means the JVM doesn't have to have the Java compiler in it (reducing footprint, which was more important in ~1995 than it is now)
  • Compiling takes non-trivial time (and non-trivial memory use). Compiling to bytecode preserves Run Everywhere(tm) without that startup impact.

Again, though, it was just a design decision they took. Microsoft took the same decision with .Net.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • Thanks for your answer! I just have a few more questions to ask regarding the points you made. You mentioned that Bytecode is smaller than source code, but when I checked one of my practice programs that I made before, I found that, actually, the source code is smaller than bytecode (respectively 1,163 bytes vs. 2,125 bytes)? How could this happen? – Lemon Jan 06 '18 at 20:18
  • Also, you pointed out that Bytecode is harder to reverse-engineer. In what way is this accomplished? Like in terms of reverse-compiling? – Lemon Jan 06 '18 at 20:19
  • @Lemon: Small classes, particularly ones without JavaDoc or other comments, and most particularly ones compiled with debugging information, can go the other way. Re reverse engineering: A search will turn up all kinds of tools to turn bytecode back into source code. You lose local variable names, but... – T.J. Crowder Jan 07 '18 at 06:15
0

The java compiler converts the java source to bytecode.

The JVM only executes bytecode. JVMs on different operating systems can run the same bytecode.

Other languages like Scala can also be compiled to bytecode and run on a JVM.

The compilation improves execution efficiency and security.

Dragonthoughts
  • 2,180
  • 8
  • 25
  • 28
  • 1
    "*The JVM only executes bytecode.*" - and compiles it down to binary code if it feels like it, thus the name "Hotspot VM" =) – Turing85 Jan 06 '18 at 19:55