We Keep Coding

How java solved portability?

Java compiler converts Java code to bytecode and then JVM converts bytecode to machine instructions. As far as I have understood, JVM are built for different platforms (processor + OS). Then how can we say that Java is platform independent? Ultimately, we require a JVM which is platform dependent?

As you have mentioned yourself, JVM is platform-dependent. That's it - JVM is platform-dependent, but not JAVA. After all, the JVM needs to be run in someway inside the native machine, so it must have to be specific to that platform.
JAVA is portable in the sense that the compiled code is portable. For example, if you compare with C, both the C and Java source codes are portable, that means both of them provide source code portability. Once you have a source code written in a Windows PC, you can transfer that exact code in another Linux machine and both Java and C code will compile and run fine in both machines.
But, what about object code portability?
We know, when we compile a C code, it produces the machine readable object code. So, if you compile a C source code from one machine, then that object code may not be run from another machine if they are not compatible. But, in case of JAVA, if you compile a Java source code to bytecode from one machine, that bytecode can be run in any machine that runs the JVM.
Another interesting fact, by successful compilation of a Java source code, we are also producing a byte code for some unknown future CPU which doesn't even exist as JVM acts as a kind of virtual CPU.

The end-user writes code in java and that is platform independent.
The JVM engineer works on creating the JVM and the JRE and within it the compiler and the interpreter for different platforms. Therefore that absolves the end-user to worry about porting their codebase to different platforms. Write once and then run it on all platforms (as long as there is a JVM available for that platform).
So from the perspective of the end-user (Java programmer) the java code is indeed platform independent since it can run anywhere without any changes. Even though the JVM is ported to different platforms and is indeed platform dependent.
Difference with C/C++:
As it is with the JVM, there exists a C/C++ compiler for each platform responsible for translating source to machine/processor instructions. These machine instructions are understood by the processor, for instance: intel etc. Therefore a C/C++ compiler is made available for each platform it supports. However, you might need to link to specific OS/platform specific libraries in your program. That will make your program platform specific and will need to be rewritten for another platform by linking to that platform's version of that library. That becomes C/C++ programmer responsibility. Also each C/C++ compiler has its own vagaries specific to a platform unlike a JVM which provides a consistent view across platforms detailed below.
In case of Java, you are removed from tapping into platform specificities (unless the JVM or Java libraries do not provide it but they usually cover most of the basics). The java code taps into JVM and Java libraries and the JVM is responsible for translating that to bytecode or to machine instructions (to improve performance) at runtime. Unless you use JNI in your java source, you do not have to worry about portability. For instance: within your Java program, you can access the native environment, the host memory, some OS characteristics etc., and your code is still portable. The JVM provides the infrastructure in that the native calls to extract that information specific to the platform. However there might be some platform specific functionality that your java program requires that is not provided by the JVM or Java libraries and therefore you need to JNI and your portability suffers as a result.
Note: C/C++/Java all have source code portability. But what the JVM provides is binary portability. The compiled or interpreted java code runs on an abstraction called the JVM (Virtual Machine). The java programmer writes to that interface instead of the platforms that the JVM runs on. There is a clear separation here.

Why is Java platform independent in theory and platform dependent in practice?

I know that one of the big things about Java is that it is platform independent in the sense that you can make a Java application and have it run in Windows, Linux, Mac, and so forth, as long as you don't use libraries specific to one OS, and as long as you have a JVM installed for the appropriate OS to interpret things correctly...
However, why can't a normal computer Java program (as in a simple Hello World in Java, for Windows or Linux for example) run just the same in a mobile phone, when mobile phones also have their specific JVM installed to interpret things correctly?
Why is it necessary to change the architecture of the program in some cases, such as Android development, or use Java ME to make applications specific for some general mobile phones?
I know that there are some functions that are related to certain functionalities of the OS, that might not apply in the mobile platforms for example, such as some things related with console, input methods, and so forth, but is this really the only reason that makes things not compatible? If so, why won't a simple application that just declares and initializes an integer variable be able to run across all non-mobile and mobile platforms that have a JVM available?
I am aware of other questions that have been posted before, such as this, but that do not focus the exact point I am aiming for here.

The unit of portability to look at is a class rather than an application. A class that declares and initialises an integer variable will run on all the platforms you describe, and many others too. They understand the same bytecode, even if they do execute it using different mechanisms ranging from bytecode interpreters, to JIT compilation, to Android's Dalvik (which translates JVM bytecode into its own instruction set).
Even if we look beyond a single integer variable, Java that uses "core" functionality will work on most of these devices. There's a great deal of common ground between J2ME, Android and J2SE (and particularly the latter two - J2ME was intended as a cut-down version of the standard Java APIs for devices with limited resources, so less of the standard API is available).
On a Windows/Mac/Linux system, an application is usually something that you explicitly start, use, and - when you're done - tell it to exit. Compare this with, say, an Android phone: the application might be started in response to an event occurring (perhaps an incoming SMS, or a specific type of file downloaded from the web) in which case it needs to know how and why it was started - a simple public static main(String[] args) just doesn't cut it. Once started, the app needs to be aware of events such as "low battery" or "entering standby mode" in order to free up resources or disable CPU-intensive features (such as GPS) that might otherwise drain the battery.
These aren't obscure functions - they're essential to a phone being useful as a phone - so all native applications must handle them.

When Java Code is compiled a byte code(class file) is generated which is independent of the system. This byte code is fed to the JVM (Java Virtual Machine) which resides in the system. Since every system has its own JVM, it doesn't matter where you compile the source code. The byte code generated by the compiler can be interpreted by any JVM of any machine. Hence it is called Platform independent Language.
thanks

Why is Java platform independent in theory and platform dependent in practice?
Remember and clear one thing that only the Java language is platform independent and try to understand the meaning of the sentence. Java is platform independent means the code you have developed using Java can be run on any machine.
When you compile the .java file it generates .class file and it contains bytecode and this bytecode is platform independent you can run it on any machine this is what about platform independency of Java language.
Now you said that it is not in practice so the reason is only Java language is platform independent, but its runtime enviroment, or JVM, is platform dependent, it is written separately for each OS. So we can say the Java language is platform independent, but its runtime environment is platform dependent.

The java language is just one thing but then many other devices such as mobile phones run their own version which is usually a trimmed down version to fit on the device. THese can also occasionally have other proprietary classes to help access the hardware (ie touchscreen). By making separate platforms based off a main one you get much support and a tighter more efficient programming language.

Sun micro systems has released different versions of jdk. one for windows based and another for linux/unix based. When we installed jdk with that we get jvm,jre and javac. Suppose if we write a java program in windows with intel processor which is installed with windows jdk, then the java compiler of that jdk will convert .java file to .class file which contains byte code instructions similar to assembly language code these byte code instructions can be understandable only by jvm. If we take the .class file which is generated in windows o.s and if we run in linux then the jvm of that linux machine internally rewrites your java program by using the approximate 200+ instruction sets which are developed by javasoft people and placed as part of jvm. and the .class file gets executed. So here the point is to concentrate that jdk is platform dependent but .class is not platform dependent it is platform independent because jvm only responsible for running any .class files. Every jdk's jvm internally has predefined instructions sets i.e., approx. 200+.

What is portability? How is java more portable than other languages? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I wonder how Java is more portable than C, C++ and .NET and any other language. I have read many times about java being portable due to the interpreter and JVM, but the JVM just hides the architectural differences in the hardware, right? We'd still need different JVMs for different machine architectures. What am I missing here? So if someone writes an abstraction layer for C for the most common architectures, let's say the CVM, then any C program will run on those architectures once CVM is installed, isn't it?
What exactly is this portability? Can .NET be called portable?

Portability isn't a black and white, yes or no kind of thing. Portability is how easily one can I take a program and run it on all of the platforms one cares about.
There are a few things that affect this. One is the language itself. The Java language spec generally leaves much less up to "the implementation". For example, "i = i++" is undefined in C and C++, but has a defined meaning in Java. More practically speaking, types like "int" have a specific size in Java (eg: int is always 32-bits), while in C and C++ the size varies depending on platform and compiler. These differences alone don't prevent you from writing portable code in C and C++, but you need to be a lot more diligent.
Another is the libraries. Java has a bunch of standard libraries that C and C++ don't have. For example, threading, networking and GUI libraries. Libraries of these sorts exist for C and C++, but they aren't part of the standard and the corresponding libraries available can vary widely from platform to platform.
Finally, there's the whole question of whether you can just take an executable and drop it on the other platform and have it work there. This generally works with Java, assuming there's a JVM for the target platform. (and there are JVMs for many/most platforms people care about) This is generally not true with C and C++. You're typically going to at least need a recompile, and that's assuming you've already taken care of the previous two points.
Yes, if a "CVM " existed for multiple platforms, that would make C and C++ more portable -- sort of. You'd still need to write your C code either in a portable way (eg: assuming nothing about the size of an int other than what the standard says) or you'd write to the CVM (assuming it has made a uniform decision for all of these sorts of things across all target platforms). You'd also need to forgo the use of non-standard libraries (no networking, threading or GUI) or write to the CVM-specific libraries for those purposes. So then we're not really talking about making C and C++ more portable, but a special CVM-C/C++ that's portable.
Once again, portability isn't a black and white thing. Even with Java there can still be incompatibilities. The GUI libraries (especially AWT) were kind of notorious for having inconsistent behavior, and anything involving threads can behave differently if you get sloppy. In general, however, it's a lot easier to take a non-trivial Java program written on one platform and run it on another than it is to do the same with a program written in C or C++.

As others have already said, portability is somewhat of a fuzzy concept. From a certain perspective, C is actually more portable than Java. C makes very few assumptions about the underlying hardware. It doesn't even assume that there are 8 bits in a byte, or that negative numbers should be represented using two's complement. Theoretically, as long as you have a Von Neumann based machine and a compiler, you're good to go with C.
In fact, a "Hello world" program written in C is going to work on many more platforms than a "Hello world" program written in Java. You could probably get the same "hello world" program to work on a PDP-11 and an iPhone.
However, the reality is that most real-world programs do a lot more than output "Hello world". Java has a reputation for being more portable than C because in practice, it takes a lot more effort to port real-world C programs to different platforms than real-world Java programs.
This is because the C language is really ANSI-C, which is an extremely general-purpose, bare-bones language. It has no support for network programming, threading, or GUI development. Therefore, as soon as you write a program which includes any of those things, you have to fall back on a less-portable extension to C, like Win32 or POSIX or whatever.
But with Java, network programming, threading, and GUI tools are defined by the language and built into each VM implementation.
That said, I think a lot of programmers also underestimate the progress modern C/C++ has made in regard to portability these days. POSIX goes a long way towards providing cross-platform threading, and when it comes to C++, Boost provides networking and threading libraries which are basically just as portable as anything in Java. These libraries have some platform-specific quirks, but so does Java.
Essentially, Java relies on each platform having a VM implementation which will interpret byte code in a predictable way, and C/C++ relies on libraries which incorporate platform specific code using the preprocessor (#ifdefs). Both strategies allow for cross platform threading, networking, and GUI development. It's simply that Java has made faster progress than C/C++ when it comes to portability. The Java language spec had threading, networking and GUI development almost from day one, whereas the Boost networking library only came out around 2005, and it wasn't until 2011 with C++11 that standard portable threading was included in C++.

When you write a Java program, it runs on all platforms that have JVM written for them - Windows, Linux, MacOS, etc.
If you write a C++ program, you'll have to compile it specifically for each platform.
Now, it is said that the motto of Java "write once, run everywhere" is a myth. It's not quite true for desktop apps, which need interaction with many native resources, but each JavaEE application can be run on any platform. Currently I'm working on windows, and other colleagues are working on Linux - without any problem whatsoever.
(Another thing related to portability is JavaEE (enterprise edition). It is said that applications written with JavaEE technologies run in any JavaEE-certified application server. This, however, is not true at least until JavaEE6. (see here))

Portability is a measure for the amount of effort to make a program run on another environment than where it originated.
Now you can debate if a JVM on Linux is a different environment than on Windows (I would argue yes), but the fact remains that in many cases there is zero effort involved if you take care of avoiding a few gotchas.
The CVM you are talking about is very much what the POSIX libraries and the runtime libraries try to provide, however there are big implementation differences which make the hurdles high to cross. Certainly in the case of Microsoft and Apple these are probably intentionally so in order to keep developers from bringing out products on competing platforms.
On the .net front, if you can stick to what mono provides, an open source .Net implementation, you will enjoy roughly the same kind of portability as Java, but since mono is significantly behind the Windows versions, this is not a popular choice. I do not know how popular this is for server based development where I can imagine it is less of an issue.

Java is portable from the perspective of the developer: code written in Java can be executed in any environment without the need to recompile. C is not portable because not only is it tied to a specific OS in many cases, it is also always tied to a specific hardware architecture once it has been compiled. The same is true for C++. .Net is more portable than C/C++, as it also relies on a virtual machine and is therefore not tied to a specific hardware architecture at compile-time, but it is limited to Windows machines (officially).
You are correct, the JVM is platform-specific (it has to be!), but when you say Java is portable, you are talking about it from a developer standpoint and standard Java developers do not write the JVM, they use it :-).
Edit #Raze2Dust To address your question. Yes, you could. In fact, you could make Java platform-specific by writing a compiler that would generate machine code rather than bytecode. But as some of the other comments suggest, why would you do that? You'd have to create an interpreter that maps the compiled code to operations in the same way the JVM works. So the long and short of it is, absolutely, you definitely could, but why would you?

Java provides three distinct types of portability:
Source code portability: A given Java program should produce identical results regardless of the underlying CPU, operating system, or Java compiler.
CPU architecture portability: the current Java compilers produce object code (called byte-code) for a CPU that does not yet exist. For each real CPU on which Java programs are intended to run, a Java interpreter, or virtual machine, "executes" the J-code. This non-existent CPU allows the same object code to run on any CPU for which a Java interpreter exists.
OS/GUI portability: Java solves this problem by providing a set of library functions (contained in Java-supplied libraries such as awt, util, and lang) that talk to an imaginary OS and imaginary GUI. Just like the JVM presents a virtual CPU, the Java libraries present a virtual OS/GUI. Every Java implementation provides libraries implementing this virtual OS/GUI. Java programs that use these libraries to provide needed OS and GUI functionality port fairly easily.
See this link

You ask if one could write a "C VM". Not exactly. "Java" is a big term used by Sun to mean a lot of things, including both the programming language, and the virtual machine. "C" is just a programming language: it's up to the compiler and OS and CPU to decide what format the resulting binary should be.
C is sometimes said to be portable because it doesn't specify the runtime. The people who wrote your compiler were able to pick things that make sense for that platform. The downside is that C is low-level enough, and platforms are different enough, that it's common for C programs to work fine on one system and not at all on another.
If you combine the C language with a specific ABI, you could define a VM for it, analogous to the JVM. There are a few things like this already, for example:
The "Intel Binary Compatibility Specification" is an example of such an ABI (which almost nobody uses today)
"Microsoft Windows" could also be such an ABI (though a huge and underspecified one), for which Wine is one VM that runs programs written for it
"MS-DOS", for which dosemu is one VM
"Linux" is one of the more popular ones today, whose programs can be run by Linux itself, NetBSD, or FreeBSD
"PA-RISC", for which HP's Dynamo was a JIT-like VM
All of these C VMs are in fact a real machine -- nobody, AFAIK, has ever made a C VM that was purely virtual. This isn't surprising, since C was designed to run efficiently on hardware, so you might as well make it run normally on one system. As HP showed, you can still make a JIT to run the code more efficiently, even on the same platform.

You need the JVM for different architectures, but of course your Java programs run on that JVM. So once you have a JVM for an architecture, then your Java programs are available for that architecture.
So I can write a Java program, compile it down to Java bytecode (which is architecture-agnostic), and that means I can run it on any JVM on any architecture. The JVM abstracts away the underlying architecture and my program runs on a virtual machine.

The idea is that the Java language is portable (or more accurately, the compiled byte-code is portable). You are correct that each VM requires a specific implementation for a given hardware profile. However, once that effort has been made, all java bytecode will run on that platform. You write the java/bytecode once, and it runs on any JVM.
.NET is quite similar, but with a far lower emphasis on the principle. The CLR is analogous to the JVM and it has its own bytecode. Mono exists on *nix, but you are correct that it is not "official".

Portability or as written in Wikipedia, Software Portability is the ability to reuse the same software (code) across multiple environments (OSes). The java JVM is a JVM that can be run on any operating systems it was designed for: Windows, Linux, Mac OSes, etc.
On .NET, it is possible to port your software to different platforms. From Wikipedia:
The design of the .NET Framework
allows it to theoretically be platform
agnostic, and thus cross-platform
compatible. That is, a program written
to use the framework should run
without change on any type of system
for which the framework is
implemented.
And because Microsoft never implemented the .NET framework outside of Windows and seeing that .NET is platform agnostic, Mono has made it possible to run .NET applications and compile code to run in Linux.
For languages such as C++, Pascal, etc. you will have to go to each OS and build it on that platform in order to run it on that platform. The EXE file in Windows isn't the same as the .so in linux (the machine code) since both uses different libraries to talk to the kernel and each OS has its own kernel.

WORE - Write Once Run Everywhere
In reality, this is limited to the platforms that have a JVM, but this covers off the majority of platforms you would wish to deploy to. It is almost a half-way between an interpreted language, and a compiled language, gaining the benefits of both.

Java virtual machine (JVM) - In what language JVM coded?

Is JVM software based? If so in which language is JVM coded?

Almost all JVMs are implemented in software. However, a JVM is anything that interprets Java bytecode in a manner that complies with the JVM specification, and there are some hardware-based JVMs as well.

Java Virtual Machine is a formal specification for how a virtual machine needs to behave by interpreting bytecode as instructions in the virtual machine's operation set.
If there's some mechanism that interprets the bytecode and behaves the right way, it is a JVM, no matter how it's implemented.
That means a JVM can be implemented in a program, or it can equally well be implemented in hardware. If you want to know which is the case, you need to be talking about some specific implementation.

Kind of... it's more like a standard that has resulted in a number of pieces of software. You cannot be 100% certain what language the JVM is written in, but in most cases, I'd bet it was written in C/C++.

To answer what I think is your question, the JVM is written in C++. The majority of the Java libraries are written in Java, however.
Same applies to .NET: The code CLR/VM is written in C++, but the class libs are written in C#.

JVM stands for "Java Virtual Machine". It's a virtualised environment that provides Java applications with a way of running in the same way across multiple different physical environments.
The idea is that Java code is compiled and is executed by the JVM. The JVM provides the same look and feel for the actual code regardless of whether it's being run on a massively parallel mainframe or a single processor PC running Windows XP.
These days the JVM is being used for languages other than Java (Scala, for example).

JVM is a specification that provides runtime environment in which java bytecode can be executed.
Jvm Interprets your bytecode into Machine Understandable code.
The JVM performs following operation:
- Loads code
- Verifies code
- Executes code
- Provides runtime environment
To do this a code has to be written, So Implementation of specifications is done here(sun provides mostly).This implemetation is JRE.
JVM ALSO TELL HOW FOLLOWING THINGS MUST HAPPEN:
- Memory area
- Class file format
- Register set
- Garbage-collected heap
- Fatal error reporting etc.
So This all is Software,find detail working Here JVM Details

The Java Virtual Machine is a program whose purpose is to execute other programs.
The JVM has two primary functions: to allow Java programs to run on any device or operating system (known as the "Write once, run anywhere" principle), and to manage and optimize program memory. When Java was released in 1995, all computer programs were written to a specific operating system, and program memory was managed by the software developer.
JVM is a software specification. In a somewhat circular fashion, the JVM spec highlights that its implementation details are not defined within the spec, in order to allow for maximum creativity in its realization.
So, all the JVM has to do is run Java programs correctly. Sounds simple, might even look simple from outside, but it is a massive undertaking, especially given the power and flexibility of the Java language.
Check out the article to learn more about JVM.

Running Java bytecode on the Android - Sun JVM on top of DalvikVM

Since both the java implementation (OpenJDK) and Android's virtual machine DalvikVM are opensource it must be possible to implement Sun's JavaVM on top Google's DalvikVM. This would make it possible to run JVM based apps and languages (Clojure, Jython) out-of-the-box on the android.
Is there an ongoing effort to produce such an implementation of the Sun JVM?

The OpenJDK makes use of native code so it would be a non-trivial port... there is at least one VM (JikesRVM) that is written in Java, unfortunately it is not a completely working implementation of Java.
Since DalvikVM runs classes that were converted from .class files it should be possible to convert the classes over. Then the "only" issue is when languages generate bytecode on the fly - for that it would require the extra step of converting the generated bytecode over to the DalvikVM format while the program is running on the DalvikVM.
Hmmm.... sort of a JITT (Just In Time Translator) that covertes class files to a DalvikVM files at runtime on the phone. I wonder how slow that would be.

Porting OpenJDK to Android platform is possible. There are effort like : Shark, Zero and caciocavallo that vastly ease the port process (= no ASM, simple AWT peer). Plus Android is nothing but a linux kernel behind. The only question is when will it be done by anybody ?
By the way, both iphones and android phones got Jazelle compatible processor, somebody with very strong processor hacking skills would be very welcome to add Jazelle support to OpenJDK.
Doing so, we could choose between : very light resource acceleration (Jazelle) and JIT ;-)
About iPhone, it is the same thing : a port is possible. Only Apple has put a section in the the iPhone license that clearly forbid VM usage. As per European law, to me, this license section is unlegal. Two reasons : You can not force/link buy of two of your product. Here I tune and Iphones are linked. You can not refuse to sell something that you can sell. Here as soon as a VM would be build for iPhone, if it is refused to be put on the iTune store, then this point will apply. Is there anybody that want to chalenge Apple licence legality on earth ? I don't think so, unhappy people will be flying to Android or any other platform.

In the meantime I have found a possible solution (only JavaME):
"MicroEmulator is a pure Java implementation of Java ME in Java SE."
Running Java ME applications on Android

technically it should be possible to interpret hotspot byte-code on dalvik vm or dalvik's byte-code on hotspot, but it will never be efficient (not mentioning elegant) design for a long run. the cost of doing that might become very high especially with respect to maintenance in the future evolution of such a split ecosystem.
i think, from the very beginning, dalvik vm is a matter of power/market control rather than innovative effort to improve java virtual machine ecosystem. dalvik vm and hotspot vm are lake two highway bridges across the same river build in parallel five meters from each other. it divides and brings confusion to java technological ecosystem.
google is, in my opinion, definitely the technological leader with innovative contributions over last decade that dwarf far more conservative oracle, but in this very subject they have shaken the java ecosystem in nearly destructive way. we (programmers) should strive for a single uniform solution to this problem. that is the main idea behind the concept of "virtual machine" anyway - it should not belong to neither google nor oracle.

try GNURoot app (proot ptrace container) with debian Wheezy;
apt-get update
apt-get install openjdk-7-jre
/usr/lib/jvm/java-7-openjdk-armel/jre/bin/java ...
(including long path)

I don't think the problem is technical. In theory you can migrate OpenJDK to the iPhone for example, but there are legal restriction in place.

See http://davy.preuveneers.be/phoneme/ for MIDP, Foundation and Personal Profile jvms for Android ARM apks. (Thank you Davy!!!)
I have repackaged the Foundation jvm for command line use and host it at vkfox.com/android/bin/foundation-jvm.bin for your pleasure. One could use the eclipse compiler in the JavaIDEdroid free app, or the old kopi or kopisusu compilers with this jvm, togeather with the stubbed cdc + foundation jar file from a J2ME jdk for an onboard development system. Using the features of TerminalIDE -- console and sun compiler -- with indicated ref jars would also get you there. This is essentially equivalent to a headless jdk1.4 with the possibility of MIDP or awt graphics.