2

I had this question in software course hw, "True/False: The Java interpreter converts files from a byte-code format to executable files". I think the statement is false. In class, they said the interpreter "executes" the byte-code files, on the system using the JVM (I didn't listen too much but I think I got it fairly correctly), but as I understood, it doesn't actually convert it to executable files (which presumably are .exe files), just runs it on the system directly.

Would be grateful for answers.

Mihax209
  • 21
  • 2
  • 2
    It seems that the 2 strategies exist : http://stackoverflow.com/questions/2203248/what-are-bytecodes-and-how-does-the-jvm-handle-them – Arnaud Denoyelle Mar 16 '15 at 11:52
  • YOu'll need Java native compiler for translation to platform specific executables. Other than that your understanding is correct – UltraInstinct Mar 16 '15 at 11:53

4 Answers4

1

"True/False: The Java interpreter converts files from a byte-code format to executable files".

The answer is false1.

The Java interpreter is one of the two components of the JVM that is responsible for executing Java code. It does it by "emulating" the execution of the Java Virtual Machine instructions (bytecodes); i.e. by pretending to be a "real" instance of the virtual machine.

The other JVM component that is involved is the Just In Time (JIT) compiler. This identifies Java methods that have been interpreted for a significant amount of time, and does an on-the-fly compilation to native code. This native code is then executed instead of interpreting the bytecodes.

But the JIT compiler does not write the compiled native code to the file system. Instead it writes it directly into a memory segment ready to be executed.

Java's interpret / JIT compile is more complicated, but it has a couple of advantages:

  • It means that it is not necessary to compile bytecodes to native code before the application can be run, which removes a significant impediment to portability.

  • It allows the JVM to gather runtime statistics on how the application is functioning, which can give hints as to the best way to optimize the native code. The result is faster execution for long-running applications.

The downside is that JIT compilation is one of the factors that tends to make Java applications slow to start (compared with C / C++ for example).

1 - ... for mainstream Java (tm) compilers. Android isn't Java (tm)2. Note that the first version of Java was interpreter only. I have also seen Java (not tm) implementations where the native code compilers were either ahead-of-time or eager ... or a combination of both.

2 - You are only permitted by Oracle to describe your "java-like" implementation as Java(tm) if it passes the Java compliance tests. Android wouldn't.

Stephen C
  • 632,615
  • 86
  • 730
  • 1,096
0

The Java compiler converts the source code to bytecode. This bytecode is then interpreted (or just-in-time-compiled and then executed) by the JVM. This bytecode is a kind of intermediate language that has not platform dependence. The virtual machine then is the layer that provides system specific functionality.

It is also possible to compile Java code to native code, a project aiming this is for example the GCJ.

To answer your question: no, a normal Java compiler does not emit an executable binary, but a set of classes that can be executed using a JVM. You can read more about this on Wikipedia.

maxdev
  • 2,161
  • 1
  • 21
  • 46
0

The answer is false reason:

JIT-just in time compiler and java interpreter does a same thing in different way but as per performance JIT wins. The main task is to convert the given bytecode into machine dependent Assembly language as of abstract information.Assembly level language is a low level language which understood by machine's assembler and after that assembler converts it to 01010111.....

Bhargav Modi
  • 2,497
  • 3
  • 26
  • 46
0

False for regular JVMs. No executable files are created. The conversion from bytecode to native code for that platform takes place on the fly during execution. If the program is stopped, the compiled code is gone (was in memory only).

The new Android JVM ART does compile the bytecode into executables before to have better startup and runtime behavior. So ART creates files.

ART straddles an interesting mid-ground between compiled and interpreted code, called ahead-of-time (AOT) compilation. Currently with Android apps, they are interpreted at runtime (using the JIT), every time you open them up. This is slow. (iOS apps, by comparison, are compiled native code, which is much faster.) With ART enabled, each Android app is compiled to native code when you install it. Then, when it’s time to run the app, it performs with all the alacrity of a native app. http://www.extremetech.com/computing/170677-android-art-google-finally-moves-to-replace-dalvik-to-boost-performance-and-battery-life

ReneS
  • 3,425
  • 2
  • 24
  • 34