-2

I'm confused about the advantage of an interpreted language like java, over a compiled language.

The standard explanation for the advantage of an interpreted language, such as java, over a compiled language is that the same .class file can run on different types of machine architectures. How doe this save you any work?

For each different machine architecture, wouldn't you need a different compiler to interpret the same .class file into the machine language? So if you need a different compiler for each different machine architecture to interpret the same .class file into machine code, how does this save you any work?

Why not just makes a compiled language where the .java source file is compiled into machine language right away. Sure this would require a different compiler to compile from the java source file to machine language for each machine architecture, but how is this any more work than having to have a different compiler for each machine compile from a .class file to machine language?

I mean this is the same as with a compiled language -- you need a compiler for each machine architecture whether it's compiling a java source file into machine code or a class file into machine code.

thanks.

user3124200
  • 343
  • 1
  • 5
  • how many different machine architecture exists and how many will be created in future? – Iłya Bursov Apr 18 '16 at 21:37
  • 1
    http://stackoverflow.com/questions/48144/what-are-advantages-of-bytecode-over-native-code – Andy Turner Apr 18 '16 at 21:37
  • 1
    You mean javascript? Java is compiled. – maraca Apr 18 '16 at 21:40
  • 1
    @maraca no, OP is asking about Java, e.g. referring to ".class file". (S)he is referring to the fact that the JVM interprets the bytecode. – Andy Turner Apr 18 '16 at 21:41
  • @maraca java file is compiled into byte code, which later is interpreted by JVM and could be optimized/compiled into native code by JIT – Iłya Bursov Apr 18 '16 at 21:43
  • You might want to read about "write once, run anywhere". This was a huge deal back before client/server development moved to web-based thin clients. – azurefrog Apr 18 '16 at 21:44
  • 3
    [WORA (write once, run anywhere)](https://en.wikipedia.org/wiki/Write_once,_run_anywhere). You can compile a program on your machine, then hand it to your friends/coworkers to be ran. No need to rewrite or recompile any code. And it's not a different compiler that's used, it's a different VM. – Vince Apr 18 '16 at 21:44
  • 1
    The big advantage is having an amazing vm and developing langs on top of it (eg: Scala, Clojure, 50+ langs ..). Having a vm that interprets byte code made this possible – Sleiman Jneidi Apr 18 '16 at 21:47
  • 1
    The point is that average programmers don't have to write _their_ program for different kinds of hardware; the people who write Java write VMs for each different kind of hardware, and make it available so average programmers can run their code on any machine there's a VM for. Someone writing Java code doesn't need to worry about any of that. (Furthermore, JIT-style compilation can do many optimizations that would not be possible ahead of time.) – Louis Wasserman Apr 18 '16 at 21:48
  • Yes I think it's more programmer- and user-friendly, but might be a little less optimized for the hardware. – maraca Apr 18 '16 at 21:49
  • Java can't run on any computer, it only runs on a virtual computer, the JVM. Most devices have that virtual computer/software factory installed. This also gives you a sandbox, pointers are not allowed theoretically improving security, java does have other security issues as does any software. If i sell you source code software do you want to have to buy a compiler and have to figure out how to use it on your hardware? Or do you just want it to run? Compiled software is tied to your specific hardware but it runs faster – Pomagranite Apr 18 '16 at 21:54

4 Answers4

5

First, the claim that "Java is interpreted", while it has some basis in truth, is pretty misleading, and it's probably best if you simply delete that notion from your head.

Java is compiled from source code to an intermediate representation (classfiles, bytecode) at build time. When a class is first loaded, most JVM implementations (including Oracle HotSpot, and IBM J9) will go through a short-lived interpretation phase, but if the class is going to be used with any frequency, a dynamic compiler (JIT) will run and compile to native code. (Some JVMs, like JRockit, go directly to native with no interpreter.)

I think "Why isn't Java compiled directly to native code" is the real question here. The obvious answer, as others have suggested, is portability. But its more subtle than that: dynamic compilation yields higher quality code than static compilation. When the code is compiled dynamically, the JIT knows things that no static compiler could know: characteristics of the current hardware (CPU version, stepping level, cache line size, etc), as well as properties of the current run (thanks to profiling data gathered during interpretation.) The quality of your decisions is dependent on the quality of your information; a dynamic compiler has more and better information available to it than a static compiler ever could, and so can produce better code.

Further, dynamic compilers have the possibility to perform optimizations that no static compiler could dream of. For example, dynamic compilers can do speculative optimizations, and back them out if they turn out to be ineffective or if their assumptions later become incorrect. (See "Dynamic Deoptimization" here: http://www.ibm.com/developerworks/library/j-jtp12214/).

Brian Goetz
  • 90,105
  • 23
  • 150
  • 161
2

For each different machine architecture, wouldn't you need a different compiler to interpret the same .class file into the machine language? So if you need a different compiler for each different machine architecture to interpret the same .class file into machine code, how does this save you any work?

The above statement is your core misunderstanding.

Application developers write Java code that is compiled to byte code that can run on any compliant Java Virtual Machine.

The Java Virtual Machine interprets (and possibly compiles) this bytecode and executes the application. These JVMs are developed for the major architectures and operating systems, such as Windows/Mac/Linux on Intel. The JVM developers are a relatively small group of engineers, such as those from Oracle and Sun.

From the application developers' point of view, he or she only has to compile once because the byte code (in the .class file) can be executed on compliant JVMs. Application developers do not need to worry about the underlying architecture or OS; they only need to target the architecture of the JVM. The JVM developers are the ones who deal with the underlying layer.

stackoverflowuser2010
  • 38,621
  • 48
  • 169
  • 217
0

First, Java is a compiled language as well an interpreted language, because you have to compile from .java to .class.

To get the meat of your question, the advantage Java gains by being (somewhat) interpreted is you only need to compile each program once, and it can run on any computer, because the Java Runtime Environment (JRE), which is compiled in advance to match the local OS and architecture, can bridge that gap without (or with minimal) further compiling.

In an uninterpreted language, however, you must compile each program for each OS and each Architecture you want it to run on, which entails much more effort and total compile time than just compiling the JRE once for each OS and architecture and only compiling each individual program once.

It would be impractical to have a language that compiles for the local architecture each and every time it runs, because compiling is a rather intensive process. Python does compile each time it runs (though, like Java, it compiles for a Runtime Environment, not the local architecture) and it is one of the slowest languages out there.

Hopefully that helped clear things up.

sowrd299
  • 149
  • 6
  • Java is compiled. The bytecode *may* be interpreted, but it may also be compiled further into native code. Java is not an interpreted language. "*It would be impractical to have a language that compiles for the local architecture*" - check out [ahead-of-time compilation](https://en.wikipedia.org/wiki/Ahead-of-time_compilation) – Vince Apr 18 '16 at 21:51
  • No problem. And we wouldn't say Java is interpreted (somewhat). The *intermediate language*, byte code, would be the language that's (somewhat) interpreted. Keep in mind, Java is 1 of 2 things: a programming language and a piece of software. The software is the JVM, while the language is the high-leveled stuff we work with. Java code itself isn't interpreted at all. You may call this nit-picking terms, but it really does make a difference – Vince Apr 18 '16 at 22:11
0

I like answer of sowrd299. My two cents:

  • you have technically endless different target architectures
  • and therefore compiling your code for all targets at the same time and packing it together would result an infinite big executable
  • therefore compiling Java against a virtual machine byte code is a better solution: since it has the footprint of only one target architecture
  • while developers can separately add JVMs for all new and old architectures, allowing total new stuffs (such as a Raspberry PI) run your java code compiled in the previous century.

On the other hand, the "compile for multiple targets in advance" is not a totally insane thing. Afaik Windows Universal Apps works this way: it is the same application in the same exe file, but actually the exe contains the code compiled for a 80x86 as well as for an ARM target. This way one application looks to be portable amongst windows mobile and desktop solutions without any further interpreting.

Gee Bee
  • 1,794
  • 15
  • 17