I am trying to understand how .class files work in java and what's their purpose. I found some information online, but I get unsatisfying explanations.
As soon as we run the compiler we get the .class file, which is bytecode. Is this machine readable or not? And if not, this is why we need the interpreter for the program to run successfully?
Also, since the .class file is the equivalent of our .java programs, why can't somebody run a java program straight away by just running the .class file using VM and they would need to have the .java file as well?
The JVM is by definition a virtual machine, that is a software machine that simulates what a real machine does. Like real machines it has an instruction set (the bytecodes), a virtual computer architecture and an execution model. It is capable of running code written with this virtual instruction set, pretty much like a real machine can run machine code.
So, the class files contain the instructions in the virtual instruction set, and it is capable of running them. For that matter, a virtual machine can either interpret the code itself or compile it for the hardware architecture it is currently running. Some do both, some do just one of them (e.g. .net runtime compiles once the first time the method is called).
For instance, the Java HotSpot initially interprets bytecodes, and progressively compiles the code into machine code. This is called adaptive optimization. Some virtual machines always compile to machine code directly.
So, you can see there are two different "compiling concepts". One consists in the transformation of Java code to JVM bytecodes (From .java to .class). And a second compilation phase happens when the program runs, where the bytecodes may either be interpreted or compiled to actual machine code. This is done by the just-in-time compiler, within the JVM.
So, as you can see, a computer cannot run a Java program directly because the program is not written in a language that the computer understands. It is written in lingua-franca that all JVM implementations can understand. And there are implementations of that JVM for many operating systems and hardware architectures. These JVMs translate the programs in this lingua-franca (bytecodes) for any particular hardware (machine code). That's the beauty of the virtual machine.
The .class file is machine-readable. The machine that reads it is the Java Virtual Machine, which interprets it and compiles it to native code (executable by your computer).
You don't need the .java files to run Java code. The .class files are all you need.
It's machine readable, but does not execute on the bare hardware. It's run through the Java Virtual Machine which is an interpreter with a very high performance just-in time compiler. There are good reasons to have the interpreter only use the class file's bytecode. Briefly they are:
Easier to build the interpeter since the bytecode is much closer to instructions that can be turned into native machine code by the JIT.
Easier to resolve dependencies since the Java compiler does some syntactic sugar on them through the import command.
Java bytecode (.class file) is not directly executable.
It's an intermediate language that is interpreted by the underlying Java Virtual Machine. Of course some optimizations can happen (i.e. Just-in-time compilation).
To run a Java program you only need the bytecode files, .java files contains the source code.
Compiler Vs Interpreter:
Compiler Takes an entire program as
input
Interpreter Takes Single instructions as
input.
Intermediate Object Code is
Generated
No Intermediate Object Code is
Generated
Conditional Control Statements are
Executed faster
Conditional Control Statements are
Executed slower
Memory Requirement: More
(Since Object Code is Generated)
Memory Requirement: Less
Program need not be compiled every
time
Every time higher level program is
converted into lower level program
Errorsare displayed after entire
program is checked
Errors are displayed for every
instruction interpreted (if any)
Example: C Compiler
Example: BASIC
Related
After hours of research I haven't found a concrete answer for my question and I'm going maddd!:
The steps from editing to execution:
1 . (Compilation step) After writing the source code, i compile the program. In this step it is converted into bytecode. A java.class file (the bytecode) is generated.
2 .(Execution step) Now i execute the program.
(Interpretation step) When I do this, the JVM interprets the bytecode into machine code. So I understand that the machine code is only generated after execution!??
Now the steps are: code-->bytecode-->execution-->machinecode
All these steps are hardware- and software-independent.
Am i right?
This is called JIT (just in time compilation), so that when I execute the program the bytecode is compiled into machinecode, and only then.
So why is this step called interpretation?
I'm thanking you in advance for your answers!
In short because JVM doesn't have to have JIT. It can interpret the bytecode instead of compiling it. Of course an interpret-only JVM would be slow, but the JIT part is just an extra feature to improve performance, not a required property of a Java Virtual Machine. The -Xint command line parameter can be used to run a java program in interpret-only mode.
The reason it's compiled to bytecode and not machine code is to get the platform independence. Bytecode is platform independent, so the same code can run on any platform (as long as there's the JVM to interpret it). If it were compiled into machine code, it would be operating system and processor architecture dependent.
(Interpretating step) When i do this, the JVM interprets the bytecode into machine code. So i understand that the machine code is only generated after execution!??
Not exactly, and no. A JVM operating strictly as a bytecode interpreter does not transform bytecode into machine code and then execute that. The machine code executed by such a JVM is (comprised by) the pre-existing machine code of the JVM itself. The byte code is used to provide some of the data on which to operate and to direct which of the JVM's machine code is executed.
Now the steps are: code-->bytecode-->execution-->machinecode
All these steps are hardware- and software-independent. Am i right?
No, not at all. The particulars of the Java code --> bytecode transformation are somewhat dependent on which Java compiler (software) you use. The Java virtual machine you use must be specific to the hardware on which it runs, and it is itself a piece of software. Moreover, the operating environment is influenced by a lot of other software.
Java hardware independence, such as it is, means that a Java program (bytecode) will behave consistently on any hardware, but the details of how that consistent behavior is provided on any given machine are all kinds of hardware- and software-dependent.
This is called JIT(just in time compilation), so that when I execute the program the bytecode is compiled into machinecode, and only then. But why is this step called interpretating?
JIT is something else, and a JVM that performs JIT (as in fact most do) is not strictly an interpreter. Most such JVMs run some bytecode in an interpretative manner as described above, but compile some bytecode to native (machine) code, and run that machine code directly when subsequently needed. The latter manner of execution generally isn't called "interpreting".
This question already has answers here:
How exactly does java compilation take place?
(9 answers)
Closed 7 years ago.
A compilation process takes source code to be translated into machine language.
So far, I have mentioned .java files (source code) and .exe files (0s and 1s).
So, What is the purpose of .class files that seem to be in the middle of the entire process?
We already have executable files coming from java source code and they don't depend on these .class files.
I know .class files are also created after compilation, but their content (which I don't know) differ from .exe files because they can only run with a java compiler and not as an independent application like an executable file will do.
Thank you!
Java was created to be platform independent. .class files contain JVM (Java Virtual Machine) code instead of normal machine code as found in .exes. The JVM is idealized, with features no real processor actually has, but it is less complex than the language of Java itself and is an abstraction layer above the platform specific hardware.
When a Java program is run, the JVM interprets the Java bytecode so that it can actually run on the CPU. The initial javac compilation relieves the JVM from having to compile the entire program on execution and hampering performance, while the abstraction lets the code run anywhere as long as a JVM is installed.
This is in contrast to .exe files, which contain platform specific machine code directly. Windows itself provides abstraction that keeps things from breaking, but because the code is still platform specific it won't work on non-Windows systems and there are separate versions for 32- and 64-bit systems (unless, of course, emulators).
The bytecode interpretation the JVM does is still very expensive compared to .exe files loading machine code directly. Therefore, if some part of the code is called enough, the JIT (Just-In-Time compiler) will kick in and compile the JVM code directly to platform specific machine code and store that in memory to increase performance in these active areas. If that area of code is used enough, the JIT does optimization on that code too, and because it can run profiling on running code it can optimize things with assumptions .exe compilers can't make. This is why many large Java programs have a warmup time before they start working more efficiently.
I had this question in software course:
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.
"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.
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.
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
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.....
For example, let's say you have a java program that simply opens a window. This will obviously result in different assembly code for different operating systems (on windows it will eventually have to call CreateWindowEx). So how does the Java bytecode (or any other similar language) represent something platform specific like this?
The JVM is OS-dependent, byte code isn't.
This means that bytecode is a sort of "generic" language that JVM will interpret end execute according to the system it's running on.
UPDATE
As Chris Jester-Young says, my answer is not strictly correct:
The bytecode for a 100% pure Java program is indeed platform-independent. The underlying Java platform classes that such programs invoke are, of course, not.
Most of the time, the JVM will also JIT compile, not just interpret. (You can enable pure-interpretation mode, but it'll be slow!)
Serenity said this:
Typically, the compiled code is the exact set of instructions the CPU requires to "execute" the program. In Java, the compiled code is an exact set of instructions for a "virtual CPU" which is required to work the same on every physical machine.
So, in a sense, the designers of the Java language decided that the language and the compiled code was going to be platform independent, but since the code eventually has to run on a physical platform, they opted to put all the platform dependent code in the JVM.
This requirement for a JVM is in contrast to your Turbo C example. With Turbo C, the compiler will produce platform dependent code, and there is no need for a JVM work-alike because the compiled Turbo C program can be executed by the CPU directly.
With Java, the CPU executes the JVM, which is platform dependent. This running JVM then executes the Java bytecode which is platform independent, provided that you have a JVM availble for it to execute upon. You might say that writing Java code, you don't program for the code to be executed on the physical machine, you write the code to be executed on the Java Virtual Machine.
The only way that all this Java bytecode works on all Java virtual machines is that a rather strict standard has been written for how Java virtual machines work. This means that no matter what physical platform you are using, the part where the Java bytecode interfaces with the JVM is guaranteed to work only one way. Since all the JVMs work exactly the same, the same code works exactly the same everywhere without recompiling. If you can't pass the tests to make sure it's the same, you're not allowed to call your virtual machine a "Java virtual machine".
Of course, there are ways that you can break the portability of a Java program. You could write a program that looks for files only found on one operating system (cmd.exe for example). You could use JNI, which effectively allows you to put compiled C or C++ code into a class. You could use conventions that only work for a certain operating system (like assuming ":" separates directories). But you are guaranteed to never have to recompile your program for a different machine unless you're doing something really special (like JNI).
Source: How is Java platform-independent when it needs a JVM to run?
In the Java programming language, all source code is first written in plain text files ending with the .java extension. Those source files are then compiled into .class files by the javac compiler. A .class file does not contain code that is native to your processor; it instead contains bytecodes — the machine language of the Java Virtual Machine1 (Java VM). The java launcher tool then runs your application with an instance of the Java Virtual Machine.
please read this doc by oracle
.class files(i.e byte code) are same but not the JVM ,It differs with OS.
There are different Java Virtual Machine binaries for each operating system. They can run the same Java bytecode (classes, jars), but the implementations is sometimes different.
For example, all the window handling code is implemented differently on Windows, Unix and Mac. Each of them will call the OS native calls to open a window or to draw something. You don't have to care about it, because the Virtual Machine automatically does it.
My knowledge of Java isn't great, so I want to ask how the language works. By which I mean not just the "Language" but the Virtual Machine as well.
Here is my understanding.
Java compiler turns code into Java Byte-Code. in the form of a .java file
when the file is run, the JVM reads (just in time) the byte-code and turns it into machine code.
Computer reads the machine code and the program appears to run like a compiled program (to the user).
Is this hopelessly wrong?
There are already many answers, but I'm missing one important point:
"2. when the file is run, the JVM reads (just in time) the byte-code and turns it into machine code."
This is not quite correct.
The JVM starts by interpreting the code
It looks at the most time consuming parts, the hot spots
It analysis the traces, i.e., the typical execution flow
It generates machine code optimized for the hot spots and the traces
The less time-consuming parts of code may stay interpreted. If the situation changes (e.g., by loading a new class), some compiled code may show to be not optimal anymore or even incorrect, and it gets thrown away and the JVM reverts to interpreting for a while, then it re-compiles it again.
A Java Virtual Machine (JVM) is the software, which interprets compiled Java byte code and runs the java program. Java Virtual Machine language conceptually represents the instruction set of a stack-oriented, capability architecture.
Java Virtual Machine does not have any information regarding the programming languages. JVM knows only binary byte code format. Programmer can generate the bytecode that adheres to this format in any of the programming languages. Every java program runs within the boundaries defined by the Java Virtual Machine.
The code of java runs inside the JVM cannot go beyond the security constraints defined by Java Virtual Machine. Java applications are considered as secure applications on internet due to this software.
http://en.wikipedia.org/wiki/Java_bytecode
http://en.wikipedia.org/wiki/Java_virtual_machine
Your understanding is correct. I'd like to add the below
The HotSpot compiler also adaptively compiles Java bytecodes into optimized machine instructions
Almost:
the Java compiler creates .class files not .java files, which contain the byte code. .java files contain the source code.
the JVM (Java virtual machine) is like a (virtual) computer on its own. It interpretes the byte code. The OS only runs the JVM.
A JIT (just in time) compiler can compile part of the code to machine code for performance reasons, in which case the JVM delegates the execution of that code to the OS (I guess).
To be precise,
When you create a java class, the extension would be .java
During compilation, the compiler converts the code (.java file) to
.class (byte code).
When the code is run, JVM converts the byte code (.class file) to
Machine code that can be interpreted by the OS. By doing so, it makes
Java as platform independent and JVM as platform dependent.