I sometimes wonder why Java is referred as a Platform Independent Language?
I couldn't find a proper explanation of the below points :
Is the JVM same for Windows/Linux/Mac OS?
Are the bytecode generated same for a same Class in the above environments?
If the answer to the above questions are NO then how the platform independence is achieved.
Please help me out in learning this basic concept.
Is the JVM same for Windows/Linux/Mac OS?
Not at all. Compiler is same across the platforms. But, since it is an executable file, the file itself will be different i.e. on Windows, it would be .exe, on Linux, it would be Linux executable etc.
Are the bytecode generated same for a same Class in the above environments?
Yes. That is why Java is COMPILE ONCE. RUN ANYWHERE.
Before starting please read this doc by oracle
Machine Dependence: This means that whatever you want to execute on your hardware architecture will not be able to execute on another architecture. Like If you have created an executable for your AMD architecture it will not be able to run on Intel's architecture. Now comes Platform Dependence is that you have created some executable for your Windows OS which won't be able to run on Linux.Code written in Assembly(provided by your processor) or Machine Language are machine dependent but if you write code in C,CPP,JAVA then your code is machine independent which is provided by underlying OS.
Platform Independence:If you create some C or CPP code then it becomes platform dependent because it produces an intermediate file i.e. compiled file which matches to the instruction set provided by underlying OS. So you need some mediator which can understand both compiler and OS.Java achieved this by creating JVM. Note: No language is machine independent if you remove the OS which itself is a program created using some language which can directly talk to your underlying machine architecture. OS is such a program which takes your compiled code and run it ontop of the underlying architecture.
The meaning of platform independence is that you only have to distribute your Java program in one format.
This one format will be interpreted by JVMs on each platform (which are coded as different programs optimized for the platform they are on) such that it can run anywhere a JVM exists.
1 ) Is the JVM same for Windows/Linux/Mac OS?
Answer ===> NO , JVM is different for All
2 ) Are the bytecode generated same for a same Class in the above environments?
Answer ====> YES , Byte code generated will be the same.
Below explanation will give you more clarification.
{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 Has 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 do not 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 Language --- compile to bytecode and run on any Machine (Yes need to have Platform DEPENDENT JVM to execute it) makes Java Platform Independent.
Java is called a plattform indipendent language, because virtually all you need to run your code on any operating system, is that systems JVM.
The JVM "maps" your java codes commands to the system's commands, so you don't have to change your code for any operating system, but just install that system's JVM (which should be provided Oracle)
The credo is "Write once, run anywhere."
Watch this 2 min video tutorial hope this will help you understand that why java is platform independent? Everything is explained in just 2 min and 37 seconds.
Why Java is platform independent?
https://www.youtube.com/watch?v=Vn8hdwxkyKI
And here is explanation given below;
There are two steps required to run any java program i.e.
(i) Compilation &
(ii) Interpretation Steps.
Java compiler, which is commonly known as "javac" is used to compile any java file. During compilation process, java compiler will compile each & every statement of java file. If the java program contains any error then it will generate error message on the Output screen. On successful completion of compilation process compiler will create a new file which is known as Class File / Binary Coded File / Byte Code File / Magic Code File.
Generated class file is a binary file therefore java interpreter commonly known as Java is required to interpret each & every statement of class file. After the successful completion of interpretation process, machine will generate Output on the Output screen.
This generated class file is a binary coded file which is depends on the components provided by java interpreter (java) & does not depends on the tools & components available in operating system.
Therefore, we can run java program in any type of operating system provided java interpreter should be available in operating system. Hence, Java language is known as platform independent language.
Two things happen when you run an application in Java,
Java compiler (javac) will compile the source into a bytecode (stored in a .class file)
The java Byte Code (.class) is OS independent, it has same extension in all the different OSs. But since this is not specific to any OS or other environment no one can run this (Unless there is a machine whose native instruction set is bytecodes, i.e. they can understand bytecode itself)
JVM load and execute the bytecode
A virtual machine (VM) is a software implementation of a machine (i.e. a computer) that executes programs like a physical machine. Java also has a virtual machine called Java Virtual Machine (JVM).
JVM has a class loader that loads the compiled Java Bytecode to the Runtime Data Areas. And it has an execution engine which executes the Java Bytecode. And importantly he JVM is platform dependent. You will have different JVM for different operating systems and other environments.
The execution engine must change the bytecode to the language that can be executed by the machine in the JVM. This includes various tasks such as finding performance bottlenecks and recompiling (to native code) frequently used sections of code. The bytecode can be changed to the suitable language in one of two ways,
Interpreter : Reads, interprets and executes the bytecode instructions one by one
JIT (Just-In-Time) compiler : The JIT compiler has been introduced to compensate for the disadvantages of the interpreter. The execution engine runs as an interpreter first, and at the appropriate time, the JIT compiler compiles the entire bytecode to change it to native code. After that, the execution engine no longer interprets the method, but directly executes using native code. Execution in native code is much faster than interpreting instructions one by one. The compiled code can be executed quickly since the native code is stored in the cache.
So in a summary Java codes will get compiled into a bytecode which is platform independent and Java has a virtual machine (JVM) specific to each different platforms (Operation systems and etc) which can load and interpret those bytecodes to the machine specific code.
Refer :
https://www.cubrid.org/blog/understanding-jvm-internals/
https://docs.oracle.com/javase/tutorial/getStarted/intro/definition.html
Related
i've read somewhere that 'execution engine' is part of JVM architecture.
q.1) please confirm role of execution engine inside JVM.
q.2) are JVM and JIT two separate component of execution engine?or, JIT is component of JVM only?
q.3) what is the difference between JVM and JIT?
JVM
A specification where working of Java Virtual Machine is specified. But implementation provider is independent to choose the algorithm. Its implementation has been provided by Sun and other companies.
An implementation Its implementation is known as JRE (Java Runtime Environment).
Runtime Instance Whenever you write java command on the command prompt to run the java class, and instance of JVM is created.
The JVM performs following operation:
Loads code
Verifies code
Executes code
Provides runtime environment
JVM provides definitions for the:
Memory area
Class file format
Register set
Garbage-collected heap
Fatal error reporting etc.
JLT
In the Java programming language and environment, a just-in-time (JIT) compiler is a program that turns Java bytecode into instructions that can be sent directly to the processor.
After you've written a Java program, the source language statements are compiled by the Java compiler into bytecode rather than into code that contains instructions that match a particular hardware platform's processor. The bytecode is platform-independent code that can be sent to any platform and run on that platform.
JVM can be divided into three main components
ClassLoader
Runtime Data Area
Execution Engine
JIT is in Execution Engine to make the interpretation more efficiently.
I came through this document where the same java code compiles in Oracle JDK but not on OpenJDK. Some references for the same problems are present here too on SO.
Does it mean "javac" is vendor specific?
And if the answer is yes ? then there is a possibility that they may produce different bytecode. Refer here.
So if the bytecode is different, How will Oracle's JVM handle bytecode
generated by OpenJDK's javac?
Is it safe to say: "Java is "Write Once and Run Anywhere, provided the javac compiler and JVM are from the same vendor? "
The javac is not vendor specific, however different compilers can have different bugs and this can cause a difference.
What makes much more difference is the built in libraries available, esp classes which are not intended to be used by developers. e.g. sun.misc.Unsafe.copyMemory(5 args) didn't exist until Java 6 update 18 in Oracle JDK and is only available in the last update of OpenJDK. AFAIK, it is not available in IBM JVM.
The Write Once, Run Anywhere means compile once, run anywhere. C++ for example can be written once and run anywhere provided you re-compile it for each system.
Once you have compiled your Java code, it will run on any system which has the libraries you used.
The best answer to your question would be "it depends." Generating different bytecode is not necessarily generating bad bytecode. Bear in mind that the first document you reference is discussing OpenJDK 6 and Oracle JDK 6. Back then, OpenJDK and Oracle JDK were in fact often subtly incompatible because Oracle hadn't brought the two JDK projects together the way they did with JDK 7. Now they're almost identical code bases, but prior to 7 that wasn't the case.
Will java code compiled using OpenJDK always run on Oracle's Hotspot or vice versa?
If they are the same version, yes.
But if you compile on Java 7 and try to run on Java 6 or earlier, you will get problems (unless you use the -target switch appropriately).
There are also differences in both the Java language and Java compilers' interpretation of the JLS between different versions of Java. But these differences typically lead to compilation errors, not to different code.
In reality, OpenJDK and Oracle JDK are pretty close. In fact, for matching versions I'd expect the bytecodes produced by the respective javac compilers to be virtually identical. Compiler bug fixes made to one codebase are ported to the other as a matter of course, and code generation bugs in the bytecode compiler are pretty unusual. Other differences in generated bytecodes (i.e. not due to bugs) are unlikely to impact on the behaviour of a properly written program.
Is it safe to say: "Java is "Write Once and Run Anywhere, provided the javac compiler and JVM are from the same vendor? "
Erm ... no. There are differences in Java behaviour for different platforms; i.e. Java on Windows and Java on Linux behave differently in some respects. Some of these differences are directly attributable to the platforms themselves; e.g. pathname syntaxes and file locking are different on Windows and Linux. Others are due to issues with mapping from Java to the platforms' different native windowing system.
These differences are nothing to do with compilers or code generation.
Sitting with a jar file compiled with OracleJDK, that runs on that system. When I tried to run it on mine when I have OpenJDK installed, it refuses to run. And keeps giving me a missing class error.
We have a storage controller that is used as target, it runs MIPS and has some additional hardware that goes with it. Development is done with Green Hills Compiler. Can we use VALGRIND to perform analysis on the code base ?
If your target is not running Linux or an OS with a POSIX API it is unlikely that you will be able to build and execute Valgrind natively. One possibility is to build your embedded code on Linux in a suitable test harness and execute tests on that.
I have been researching Golang and I see that it has a compiler.
But is it compiling Go into assembly level code or just converting it into BYTECODES and then calling that compilation? I mean, even in PHP we are able to convert it into BYTECODES and have faster performance.
Is Golang a REPLACEMENT for system level programming and compiling ?
This is really a compiler (in fact it embbeds 2 compilers) and it makes totally self sufficient executables. You don't need any supplementary library or any kind of runtime to execute it on your server. You just have to have it compiled for your target computer architecture.
From the documentation :
There are two official Go compiler tool chains. This document focuses
on the gc Go compiler and tools (6g, 8g etc.). For information on how
to work on gccgo, a more traditional compiler using the GCC back end,
see Setting up and using gccgo.
The Go compilers support three instruction sets. There are important
differences in the quality of the compilers for the different
architectures.
amd64 (a.k.a. x86-64); 6g,6l,6c,6a
A mature implementation. The
compiler has an effective optimizer (registerizer) and generates good
code (although gccgo can do noticeably better sometimes).
386 (a.k.a. x86 or x86-32); 8g,8l,8c,8a
Comparable to the amd64 port.
arm (a.k.a. ARM); 5g,5l,5c,5a
Supports only Linux binaries. Less widely used than
the other ports and therefore not as thoroughly tested.
Except for
things like low-level operating system interface code, the run-time
support is the same in all ports and includes a mark-and-sweep garbage
collector, efficient array and string slicing, and support for
efficient goroutines, such as stacks that grow and shrink on demand.
The compilers can target the FreeBSD, Linux, NetBSD, OpenBSD, OS X
(Darwin), and Windows operating systems. The full set of supported
combinations is listed in the discussion of environment variables
below.
On a server you'll usually target the amd64 platform.
Note that Go is well known for the speed of compilation. When deploying my server programs, I don't build for the different platforms on the development computer : I deploy the sources and I compile directly on the production servers. Since Go1 I never had a code compiling on one platform and not compiling on the other ones.
On Windows I had no problem in making an exe on my development computer and simply sending this exe to people never having installed anything Go related.
Go compiles quickly to machine code yet has the convenience of garbage collection and the power of run-time reflection. It's a fast, statically typed, compiled language that feels like a dynamically typed, interpreted language.
Source - golang.org
Golang is a compiler-based language, it can easily be compiled on the development computer for any targeted system such as linux and mac.
A golang project when have compiled turns to a self-sufficient executable and can be ran on the targeted system without anything additional. It's because the golang compiler turns your code into bytes ready to execute on a system which can run compiled c code.
I am quite new to the embedded linux programming and did not really understand this concept very well.
Can anyone explain the essence of the "host-target" relation? Is this model only specific to the "cross-compilation"? Is it used just because "executable code will be run on another enviroment"? and what matters with the linux kernel on the target? E.g., the "building the embedded linux system" book mentioned this, but did not explain its motivation or goal of this type of development.
Thanks a lot.
The 'motivation' for this model is that seldom is an embedded target a suitable platform for development. It may be resource constrained, have no operating system, have no compiler that will run on the target, have no filesystem for source files, have no keyboard or display, no networking, and may be relatively slow or anything else you might need to develop effectively.
If your embedded system is suited to running Linux, it is possible that not all of the above limitations apply, but almost certainly enough of them to make you want to avoid developng directly on the target. If this were not so, they it hardly qualifies as an embedded system perhaps.
http://www.landley.net/writing/docs/cross-compiling.html
Seems pretty clear. What specific questions do you have?
Linux since its very origin was written in very portable way. It runs on a whole range of machines with very different CPUs, and it is considered the Good Thing to write in a portable way, so that, for example, package maintainer can easily port your program to some embedded ARM or Cygwin, or Amiga, or...
So, yes, the model is "only" specific to cross-compilation, but actually about every compilation on Linux is a (variant of) cross-compilation, just that by default build, host and target are automatically set to the same value, the same as the machine you run on.
Still, even then, you can take a Linux-i386 compiled compiler, sources for it, and "cross-compile" it for Linux-amd64. And the resulting binary will run much faster on a 64bit CPU.
It IS quite essential in embedded programming though. Mostly because you write programs for weak CPUs that are not capable of running a compiler or would run it at a snail pace. So you take a cross-compiler on a fast CPU (say, some multi-core Intel) and cross-compile for the embedded CPU (say, some low-end ARM).
"In different environment" is putting things very mildly. What you're doing when cross-compiling for embedded is working with entirely different instruction set, different memory access modes, different resource access methods and so on and so on. A machine of entirely different construction than the build host. Your build host may be a Windows PC running Cygwin. Your target may be a chip inside a smartphone. The binary will look nothing like the Cygwin .exe files.
As a direct consequence, -everything- must be compiled for the target from scratch. The kernel, the system utilities, the system libraries, all the tools the target must be running. Thing is, if the target is a ticket selling booth, there is really no sense cross-compiling Eclipse, GCC and Gnome for it, then developing in "local" environment, typing your code on a ticket booth keyboard. Instead, you just cross-compile the essentials of the OS, and your specific applications. You keep the development environment on the build machine, and cross-compile everything you need on the embedded device.
[in practice, you get a Linux distro for the target, and just compile whatever you need modified].