Develop Reference

How can java use Compiler

I studied somewhere that to execute on different processor architectures Java is interpreted. If it would use compiler then there would be some (Machine Code) instructions which would be specific to processor architectures and Java would be platform dependent.
But since java use interpreter it is processor architecture independent.
My question is how can the java use JIT (Just In Time) Compiler? Doesn't the processor's architectures affect it? If it doesn't affect it, then why doesn't it affect it?

There isn't just one JIT compiler. There is a different one for each architecture, so there's one for Windows 32-bit, one for Windows 64-bit etc.
Your Java code is the same across all platforms. That is compiled into byte code by the Java compiler. The byte code is also the same across all platforms.
Now we run your Java program on Windows 32-bit. The JVM starts up and it interprets the byte code and turns that into machine code for that architecture. Note that that JVM is specifically for this architecture.
If we run your program on another architecture, another variation of the JVM will be used to interpret the byte code.
That's why you see all these different download links when you download the JRE:

Your java code is interpreted to byte code and is not platform dependent. But to run your machine code you need a JVM, the​ JVM is platform dependent, you cannot download an x86 JVM and run it on an ARM processor and vice versa.
The idea is that the JVM is platform dependent but your code is not.

The java program life cycle goes as follows.
Source code is compiled into Java Byte Code (aka .class files),
Java Byte Code is then interpreted by the JVM which performs the Just In Time compilation sending instructions your specific processor architecture can understand.
Its important to understand that compilation is just another way to say "translation", and does not always mean compiling to binary. Also, interpretation is similar, but is done per instruction, as needed by the program.
But more specifically in your question, JIT is the interpretation done by the JVM, which is coded specifically for each processor architecture.

Role of Compiler and JVM in java? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am new to java and bit confused about the role of compiler and JVM . I have read couple of resources and to name few
What-are-the-functions-of-Java-Compiler ?
Is the JVM a compiler or an interpreter?
Compiler
As i save the file .java file in system, computer internally saves it in bytes 0 and 1's. I understand compiler is validating whether written java program
confirms to java standard or not. If not throws the error otherwise jenerate the class file.
My question is what is need of generating .class file.
Can't
JVM interpret it directly (from bytes generated corresponding to .java file) without needing .class file? Does compiler(javac) do any kind of optimization here ?
JVM :- This question is other way around. Can't compiler generate the byte/machine code which can be interpreted by CPU directly? so why JVM is needed here ?
Is JVM required to interpret the byte code specific to platform for example windows or linux ?

The compiler generates byte code, in a Java meaning, which is a .class file, containing the byte code, which is not made of 1 or 0, no matter what OS you are running on.
And JVM interprets byte code to run it on specific OS

The main point of having these two stages and intermediate representation ("byte code" in Java) is platform-independence.
The Java program, in a source code, is platform-independent (to a degree). When you compile it into byte code, the Java compiler basically does (almost) all of the things it can do while still maintaining the platform-independence:
validates syntax
performs static type checks
translates human-readable source code into machine-readable byte code
does static optimizations
etc.
These are all things, that:
maintain platform-independence
only need to be performed once, since they don't rely on any run-time data
take (possibly long) time to do so it would be waste of time to do them again each time the code is executed
So now you have .class files with byte code, which are still platform-independent and can be distributed to different OS or even hardware platform.
And then the second step is the JVM. The JVM itself is platform-specific, and it's task is to translate/compile/interpret the byte code on the target architecture and OS. That means:
translate byte code to the instruction set of given platform, and using target OS system calls
run-time optimizations
etc.

What-are-the-functions-of-Java-Compiler ?
'Javac' is a Java compiler which produces byte-code(.class File) and that code is platform-independent.
Is the JVM a compiler or an interpreter? Ans- Interpreter
JVM is Java Virtual Machine -- Runs/ Interprets/ translates Bytecode into Native Machine Code and it internally uses JIT
JIT Compiles the given bytecode instruction sequence to machine code at runtime before executing it natively and do all the heavy optimizations.
All the above complexities exists to make java compile once run anywhere or Platform independent Language and Because of that bytecode or JAVAC Output is platform-independent but JVM executing that bytecode is Platform-dependent i.e we have different JVM for Windows and Unix.

A JVM, is an implementation of the Java Virtual Machine Specification. It interprets compiled Java binary code (called bytecode) for a computer's processor (or "hardware platform").
JVM is the target machine for byte-code instead of the underlying architecture.
The Java compiler ,'Javac' produces byte-code which is platform-independent. This byte-code is, we can say generic, ie., it does not include machine level details, which are specific to each platform.
The instructions in this byte-code cannot be directly run by the CPU.
Therefore some other 'program' is needed which can interpret the code, and give the CPU machine level instructions which it can execute. This program is the 'JVM' (Java Virtual Machine) which is platform specific.
That's why you have different JVM for Windows, Linux or Solaris.

I think first we should discuss the difference between executing an interpreted runtime vs a machinecode runtime vs a bytecode runtime.
In an interpreted runtime the (generally human readable) source code is converted to machine code by the interpreter only at the point when the code is run. Generally this confers advantages such that code is platform independent (so long as an interpreter exists for your platform) and ease of debugging (the code is right there in front of you) but at the cost of relatively slow execution speed as you have the overhead of converting the source code into machine code when you run the program.
In a compiled runtime the source code has been compiled into native machine code ahead of time by a dedicated compiler. This gives fast execution speed (because the code is already in the format expected by the processor), but means that the thing you distribute (the compiled binary) is generally tied to a given platform.
A bytecode runtime is sort of a halfway house that aims to give the advantages of both intepretation and compilation. In this case the source code is complied down into an intermediate format (byte code) ahead of time and then converted into machine code at runtime. The byte code is designed to be machine friendly rather than human friendly which means it's much faster to convert to machine code than in a traditionally interpreted language. Additionally, because the actual conversion to machine code is being done at run time, you still get all that nice platform independence.
Note that the choice of whether to intepret or compile is independent of the language used: for example there is no reason in theory why you could not have a c intepreter or compile python directly into machine code. Of course in practise most languages are generally only either compiled or interpreted.
So this brings us back to the question of what the Java compiler does- essentially it's main job is to turn all your nice human readable java files into java bytecode (class files) so that the JVM can efficiently execute them.
The JVM's main job, on the other hand, is to take those class files and turn them into machine code at execution time. Of course it also does other stuff (for example it manages your memory and it provides various standard libraries), but from the point of view of your question it's the conversion to machine code that's important!

Java bytecode is an intermediate, compact, way of representing a series of operations. The processor can't execute these directly. A processor executes machine instructions. They are the only thing that a processor can understands.
The JVM processes stream of bytecode operations and interprets them into a series of machine instructions for the processor to execute.
My question is what is need of generating .class file. Can't JVM interpret it directly (from bytes generated corresponding to .java file) without needing .class file? Does compiler (javac) do any kind of optimization here ?
The javac generate .class file which is an intermediate thing to achieve platform independence.
To see what compiler optimized, simply decompile the bytecode, for instance with javap or JD.
This question is other way around. Can't compiler generate the byte/machine code which can be interpreted by CPU directly? so why JVM is needed here ? Is JVM required to interpret the byte code specific to platform for example windows or linux ?
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. Hence for this reason we need JVM to execute code.
To see what the just in time compiler optimized, activate debug logging and read the disassembled machine code.

Confused about advantage of interpreted language

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.

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/).

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.

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.

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.

What is the difference between "architecture-neutral" and "portable"?

I'm reading Herbert Schildt's book "Java: The Complete Reference" and there he writes that Java is portable AND architecture-neutral. What is the difference between this two concepts? I couldn't understand it from the text.

Take a look at this white paper on Java.
Basically they're saying that in addition to running on multiple environments (because of being interpreted within the JVM), it also runs the same regardless of environment. The former is what makes it portable, the latter is what makes it architecture-neutral. For example, the size of an int does not vary based on platform; it's established by the JVM.

A portable C program:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
printf("Hello, World!");
return (EXIT_SUCCESS);
}
You can take that C program and compile it on any machine with a C compiler and have it work (assuming it supports printf... I am guessing some things out there may not).
If you compile it on Windows and try to run that binary on a Mac it won't work.
The same sort of program written in Java will also compile on any machine with a Java compiler installed, but the resulting .class file will also run on any machine with a Java VM. That is the architectural neutral part.
So, portable is a source code idea, while architectural neutral is an executable idea.

Looking around I found another book that describes the difference between the two.
For architecture neutral the compiler will generate an architecture-neutral object file meaning that compiled Java code (bytecode) can run on many processors given the presence of a Java runtime.
For portable it means there are are no implementation-dependent aspects of the specification. For instance in C++ an int can be 16-bit, or 32 bit depending on who is implementing the specification where as in Java an int is always 32 bit.
I got my information from a different book (Core Java 2: Fundamentals) so it may differ from his meaning. Here is a link: Core Java 2: Fundamentals

With architecture-neutral, the book means that the byte code is independent of the underlying platform that the program is running on. For example, it doesn't matter if your operating system is 32-bit or 64-bit, the Java byte code is exactly the same. You don't have to recompile your Java source code for 32-bit or 64-bit. (So, "architecture" refers to the CPU architecture).
"Portable" means that a program written to run on one operating system works on another operating system without changing anything. With Java, you don't even have to recompile the source code; a *.class file compiled on Windows, for example, works on Linux, Mac OS X or any other OS for which you have a Java virtual machine available.
Note that you have to take care with some things to make your Java code truly portable. If you for example hard-code Windows-style file paths (C:\Users\Myself...) in your Java application, it is not going to work on other operating systems.

I suspect that he means that code can run on many platforms without recompilation.
It is also possible to write code that deals with the underlying system without rewrites or conditions.
E.g. Serialized objects from a 32 bit Windows system can be read on a 64bit Linux system.

there are 3 related features in java.
platform independent -> this means that the java program can be run on any OS without considering its vendor. It is implemented by using the MAGIC CODE called "BYTE CODE". The JVM then either interprets this at runtime or uses JIT (Just in Time) compilation to compile it to machine code for the architecture that is being run on (e.g. i386).
architecture neutral -> it means the java program can be run on any processor irrespective of its vendor and architecture. so it avoids rebuilding problem.
portable -> a programming language/technology is said to be purely portable if it satisfies the above two features.

.class file is portable because it can run on any OS . The reason is , .class file generated by JVM is same for all OS. On the other hand JVM is differ as OS , but it generate same .class file for all OS, so JVM is architectural neutral.

What is difference between Architecture Neutral and Portable?
Architecture Neutral: Java is an Architecture neutral programming language because, java allows its application to compile on one hardware architecture and to execute on another hardware architecture.
Portable: Java is a portable programming language because, java is able to execute its application and all the operating system and all the hardware system.

In Terms of Java
Java Architecture Neutral - Here we are talking about the Operating System Architecture i.e the java Generate the Intermediate Byte-code(binary code) (handle by the JVM) and allow the java code to run on any O.S for which you have a Java virtual machine available( irrespective of its O.S architecture to handle memory allocation ,Cashing, register handling , bit code processing 32 bit or 64 bit while interpreting the code like each interpreter execute the code line by line - this is handle by jvm with respect to Hardware and O.S configuration) .
Portable (Generic meaning like transferable, Platform Independent, or even in terms of the Source code is fix for all i.e Simply means support to many)
Java Portable means java machine code write in one machine and will run on any machine that has proper JVM with respect to O.S.

How is Java platform-independent when it needs a JVM to run?

I just started learning Java and I'm confused about the topic of platform independence.
Doesn't "independent" imply that Java code should run on any machine and need no special software to be installed? Yet the JVM needs to be present in the machine.
For example, we need to have the Turbo C Compiler in order to compile C/C++ source code and then execute it. The machine has to have the C compiler.
Could somebody please what is meant when Java is described as "platform independent"?

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 available 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).

Technical Article on How java is platform indepedent?
Before going into the detail,first you have to understand what is the mean of platform?
Platform consists of the computer hardware(mainly architecture of the microprocessor)
and OS.
Platform=hardware+Operating System
Anything that is platform indepedent can run on any operating system and hardware.
Java is platform indepedent so java can run on any operating system and hardware.
Now question is how is it platform independent?
This is because of the magic of Byte Code which is OS indepedent.
When java compiler compiles any code then it generates the byte code not the machine native code(unlike C compiler). Now this
byte code needs an interpreter to execute on a machine. This interpreter is JVM. So JVM reads that byte code(that is machine indepedent)
amd execute it.
Different JVM is designed for different OS and byte code is able to run on different OS.
In case of C or C++(language that are not platform indepedent) compiler generate the .exe file that is OS depedent so when we
run this .exe file on another OS it will not run because this file is OS depedent so is not compatible with the another OS.
Finally an intermediate OS indepedent Byte code make the java platform independent.

It means the Java programmer does not (in theory) need to know machine or OS details. These details do exist and the JVM and class libraries handle them. Further, in sharp contrast to C, Java binaries (bytecode) can often be moved to entirely different systems without modifying or recompiling.

No, it's the other way around. It's because you use the virtual machine that the Java program gets independend.
The virtual machine is not independent, you have to install one that is specifically made for your type of system. The virtual machine creates an independent platform on top of the operating system.

The JVM is a "simulated machine" that can be installed on different systems. In this way, the same Java code can run on different systems, because it relies on the JVM, not on the operational system itself.
That is to say, this allows the programmer to communicate with the virtual system (JVM) and utilize its functions, instead of the specific machine and OS functions.
Since Java only relies on JVM, it is platform independent (if the platform has JVM installed).
So in short, Java is not platform independent as such, it requires a JVM-installation for all systems it should run on. However, it will run on all systems that has the JVM installed.

Java is platform-independent as it has JVM(Java virtual machine). Let us illustrate it with a real life example. Let's assume you are free to your family members. But why?
Because you know them well and they know you as well. But, you are not free to my family members. Because you don't know them and they don't know you either. But, if I'm your friend and when I can introduce you to my family members, hence you will be able to talk to them freely.
In a similar way, if you are a code and I am a JVM. Also, your family is windows platform and mine is the Linux platform. In the case you were a C or other platform-dependent languages, you only know your family members and vice versa. That's why only the platform on which you were written knows that Code and will support it. But if you are a JAVA code and when you come to my family viz. the Linux platform and if there you find me, JVM, then I can introduce you to my family, the Linux platform and you will be able to interact with it.
For platform-dependent languages, there isn't any friend like JVM available to them to introduce themselves to any platform family. That is how Java is platform-independent. :)

The JVM abstracts from the concrete platform. Your program relies only upon the JVM and since the JVM is available for different platforms like Windows and Linux, your program is platform independent (but jvm depended).

In c/c++ the source code(c program file) after the compilation using a compiler is directly converted to native machine code(which is understandable to particular machine on which u compiling the code). And hence the compiled code of c/c++ can not run on different OS.
But in case of Java : the source file of java(.java) will be compiled using JAVAC compiler(present in JDK) which provides the Byte code(.class file) which is understandable to any JVM installed on any OS(Physical System).
Here we need to have different JVM (which is platform dependent) for different operating Systems where we want to run the code, but the .class file(compiled code/Intermediate code)remains same, because it is understandable to any of the JVM installed on any OS.
In c/c++ : only source code is machine independent.
In Java : both the source code and the compiled code is platform independent.
This makes Java Platform(machine) independent.

java is not platform Independent, itself is a platform,based on that platform java apps runs,but java platform itself is platform dependent

1:jvm(i.e java virtual machine)is a collection of programs which contains lot of files which provides various functionatiles present on a folder(i.e collections of programs on middle level format)as called packages.jvm helps not to be overloaded on o/s where its helps to execute only the .class files or java applications only by itself only.It helps to make its equalities middle level format after compliation by the java compiler then its provide the byte code (.class file)reprsentation which is not specific to o/s and processor .
2:jvm makes byte code to .exe file for proccessor to understandable and prsents memory allocation for every functions after recieving frm byte code.
3:jvm also releases memory alocation from ram after control makes finishes thier execution .

JVM is os dependent.
for every os JVM different.
".class" is same for all JVMs.
so, every JVM understand that ".class" file data.
windows dependent JVM give windows dependent instruction to windows
linux dependent JVM give linux dependent instruction to linux.
that's like it for other operating systems.
so,java runs on any operating system.
that's why java is os independent.

In simple terms:
Java programming language is platform independent.
JVM is platform dependent

Java is not platform independent in that it runs on the JVM. Having said that, you gain platform independence via programming against a single abstract machine that has concrete realizations on most common OS platforms (and some embedded appliances).
A related idea is the hardware abstraction layer present in many operating systems that allows the same OS to run on disparate hardware.
In you original question, Turbo C is analagous to the javac program, and the JVM is the OS/HAL.

Doesn't independent means that Java code should be able to run on any machine and would need no special software to be installed (JVM in this case has to be present in the machine)?
With Java, you can compile source code on Windows and the compiled code (bytecode to be precise) can be executed (interpreted) on any platform running a JVM. So yes you need a JVM but the JVM can run any compiled code, the compiled code is platform independent.
In other words, you have both portability of source code and portability of compiled code.
Like, for example, we need to have Turbo C Compiler in order to compile C/C++ source code and then execute it.. The machine has to have the C compiler.
The machine doesn't have to have a C compiler, the machine has to use a platform specific binary. With C or C++, the compiled code is specific to each architecture, it is platform independent.
In other words, with C / C++ you have portability of source code (with some discipline) but not portability of compiled code: you need to recompile for each architecture into platform specific binaries.

JVM will be platform dependent.
But whatever it will generate that will be platform independent. [which we called as bytecode or simply you can say...the class file]. for that why Java is called Platform independent.
you can run the same class file on Mac as well on Windows but it will require JRE.

bytecode is not plateform independent, but its JVM that makes bytecode independent. Bytecode is not the matchine code. bytecodes are compact numeric codes, constants, and references (normally numeric addresses) which encode the result of parsing and semantic analysis of things like type, scope, and nesting depths of program objects. They therefore allow much better performance than direct interpretation of source code. bytecode needs to be interpreted before execution which is always done by JVM interpreter.

Just a side note to the discussion about JVM and JIT Compilation.
This is the same principle as with C# and the CLR and to some extent in Python, and when somebody says that the code runs "directly on hardware" that is actually true in that instructions that is already compiled will be able to take advantage of optimization on the machine/cpu it's being run on. So even if the initial compilation of a module is rather slow, the next time this module is run, the code being executed runs at native speed and thus runs directly on hardware so to say.

Java is platform independent in aspect of java developer,but this is not the case for the end-user, who need to have platform dependent JVM to run java code. Basically, when java code is compiled, a bytecode is generated which is typically platform independent. Thus, the developer has to have write a single code for entire platform series. But, this benefit comes with a headache for end-user who need to install JVM in order to run this compiled code. This JVM is differnt for every platform. Thus, dependency comes into effect only for end-user.

Javac – compiler that converts source code to byte code.
JVM- interpreter that converts byte code to machine language code.
As we know java is both compile**r & **interpreter based language. Once the java code also known as source code is compiled, it gets converted to native code known as BYTE CODE which is portable & can be easily executed on all operating systems. Byte code generated is basically represented in hexa decimal format. This format is same on every platform be it Solaris work station or Macintosh, windows or Linux. After compilation, the interpreter reads the generated byte code & translates it according to the host machine. . Byte code is interpreted by Java Virtual Machine which is available with all the operating systems we install. so to port Java programs to a new platform all that is required is to port the interpreter and some of the library routines.
Hope it helps!!!

When we compile C source data, it generate native code which can be understood by current operating system.
When we move this source code to the other operating system, it can't be understood by operating system because of native code that means representation is change from O.S to O.S.
So C or C++ are platform dependent .
Now in case of java, after compilation we get byte code instead of native code. When we will run the byte code,
it is converted into native code with the help of JVM and then it will be executed.
So Java is platform independent and C or C++ is not platform independent.

well good question but when the source code is changed into intermediate native byte code by a compiler in which it converts the program into the byte code by giving the errors after the whole checking at once (if found) and then the program needs a interpreter which would check the program line by line and directly change it into machine code or object code and each operating system by default cannot have an java interpreter because of some security reasons so you need to have jvm at any cost to run it in that different O.S platform independence as you said here means that the program can be run in any os like unix, mac, linux, windows, etc but this does not mean that each and every os will be able to run the codes without a jvm which saysspecification, implementation, and instance , if i advance then by changing the configuration of your pc so that you can have a class loader that can open even the byte code then also you can execute java byte code, applets, etc.
-by nimish :) best of luck

{App1(Java code)------>App1byteCode}........{(JVM+MacOS) help work
with App1,App2,App3}
{App2(Java Code)----->App2byteCode}........{(JVM+LinuxOS) help work
with App1,App2,App3}
{App3(Java Code)----->App3byteCode}........{(JVM+WindowsOS) help work
with App1,App2,App3}
How this is happening ?
Ans: JVM have capability to read ByteCode and Response In Accordance with the underlying OS As the JVM is in Sync with OS.
So we find, we need JVM with Sync with Platform.
But the main thing is that the programmer dont have to know specific knowledge of the Platform and program his application keeping one specific platform in mind.
This Flexibility of write Program in Java --- compile to ByteCode and run on any Machine (Yes need to have Platform DEPENDENT JVM to execute it) makes Java Platform Independent.

when we compile java file the .class file of that program is generated that .class file contain the byte code.That byte code is platform independent,byte code can run on any operating system using java virtual machine. platform independence not about only operating system it also about the hardware.
When you run you java application on a 16-bit machine that you made on 32-bit, you do not have to worry about converting the data types according to the target system. You can run your app on any architecture and you will get the same result in each.

Edit: Not quite. See comments below.
Java doesn't directly run on anything. It needs to be converted to bytecode by a JVM.
Because JVMs exist for all major platforms, this makes Java platform-independent THROUGH the JVM.