Related
I am educating myself in the theory of programming languages and I wonder, why exactly do we need a Java Virtual Machine or any virtual machine at all for that matter? What are the fundamental reasons?
Is it solely for making it multi-platform? If so, why cannot we just have a platform independent language and different compilers for different platforms?
In their 1996 whitepaper The Java Language Environment, the Java team at Sun states the following design goals for the Java Language:
The design requirements of the Java TM programming language are driven by the nature of the computing environments in which software must be deployed.
The massive growth of the Internet and the World-Wide Web leads us to a completely new way of looking at development and distribution of software. To live in the world of electronic commerce and distribution, Java technology must enable the development of secure, high performance, and highly robust applications on multiple platforms in heterogeneous, distributed networks.
Operating on multiple platforms in heterogeneous networks invalidates the traditional schemes of binary distribution, release, upgrade, patch, and so on. To survive in this jungle, the Java programming language must be architecture neutral, portable, and dynamically adaptable.
The system that emerged to meet these needs is simple, so it can be easily programmed by most developers; familiar, so that current developers can easily learn the Java programming language; object oriented, to take advantage of modern software development methodologies and to fit into distributed client-server applications; multithreaded, for high performance in applications that need to perform multiple concurrent activities, such as multimedia; and interpreted, for maximum portability and dynamic capabilities.
A bit further down, they address the reasons for using an interpreter in greater detail:
The Java interpreter can execute Java bytecodes directly on any machine to which the interpreter and run-time system have been ported. In an interpreted platform such as Java technology-based system, the link phase of a program is simple, incremental, and lightweight. You benefit from much faster development cycles--prototyping, experimentation, and rapid development are the normal case, versus the traditional heavyweight compile, link, and test cycles.
While the Java Compiler is strict in its compile-time static checking, the language and run-time system are dynamic in their linking stages. Classes are linked only as needed. New code modules can be linked in on demand from a variety of sources, even from sources across a network. In the case of the HotJava Browser and similar applications, interactive executable code can be loaded from anywhere, which enables transparent updating of applications. The result is on-line services that constantly evolve; they can remain innovative and fresh, draw more customers, and spur the growth of electronic commerce on the Internet.
why cannot we just have a platform independent language and different compilers for different platforms?
Well. What if I write a Linear Search program (in any language..) on a 16 bit machine, compile it using a 16 - bit compiler and then try running it on a 32 - bit machine. Will it behave in the same way?.
Imagine products that have millions of lines of code. Do you think that nothing in that million line code will break because of change in machine architecture ?
Now,
Virtual Machines : These are basically software written to convert instructions into the "machine understanding / OS understanding language". They sit on top of your OS and make calls to it i.e, make the OS understand what your application wants.
JVM : is a kind of virtual Machine in which is used for Java. When you write and compile a java program, it will be in an " almost -machine independent" state. This is called as byte code. You can take it to another machine and run / interpret it.
Is it for platform portability? Yes. You already know most of the obvious features of JVM and its advantages and others have already given splendid responses.
Here I'll add the human side of the advantage Virtual Machines provide. It is primarily for ease of development and reach.
Consider C as an example of platform independent language with specific compilers for specific Operating Systems. One can code in C on Linux as well as Windows. But, you'll require an additional library header file conio.h to run your same program on a Windows system.
Now, if massive million lined source code programs and application suites were required to be recompiled on every system (with diverse hardware and software) will require them to recompile the same code over and over on each and every compiler. This may leave out some systems as possible targets, if the developers missed compiling for that system.
This actually happens in the game industry where certain games are just not compiled and build for certain systems (like most high end games are not made for Linux). The game studios are forced to compile each time for every target machine they want, like Wii, PS3, PS4, PC, XBOX etc.
It's a waste of time, effort, resources and sanity (specially when you're dealing with super massive heterogeneous file types and source codes, which take massive amounts of time to compile).
In short; It is to reduce menial repetitive recompilation of the same source code for every system, so that we programmers can focus on things worthy of our time. [Or we're just lazy ;)]
Addendum:
According to Larry Wall, the original author of the Perl programming language, there are three great virtues of a programmer; Laziness, Impatience and Hubris. Link
Java virtual machine (JVM) is a platform or a sandbox to run the byte code. Byte code has special instruction sets and operation which can only be identified by JVM.
This is the same case with any virtual machines where it expects specific set of operations.
Virtual machines are an important abstraction used to make language development and implementation easier.
A large number of languages use virtual machines of some kind to allow them to be executed. Dynamic scripting languages such as Ruby and Python are interpreted at runtime on simple virtual machine. The advantage of this is that if the interpreter can be re-compiled to run on an given environment then then language itself can be used on that environment too.
Other languages such as Java can be compiled ahead of time to bytecode which is then either interpreted or just-in-time (JIT) compiled for execution. In this model only the virtual machine itself, and not the compiler, needs to be ported to any given environment to run code there. Java used this to advantage by allowing applications to be embedded in web pages.
Even outside these more dynamic languages virtual machines are used to abstract away from the details of the underlaying hardware. For example the Low-Level Virtual Machine (llvm) compiler is engineered in such a way that it first compiles C, C++, Objective-C or whatever into instructions to run on virtual machine architecture and then translates this to real machine code. This translation can be done straight away, just as a traditional C or C++ compiler would, or at runtime using JIT compilation.
These different types of virtual machines are working at different levels of abstraction. The llvm virtual machine is, as it's name suggests, at a very low level. It abstracts the different peculiarities of CPU architectures such as how to load and store floating point numbers, if things should be passed around on the stack or in registers, and so on. Virtual machines for languages such as Python however are abstracting over operating system APIs and similar things.
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 difference between Java Virtual Machine and Dalvik Virtual Machine?
DVM is Register based which is designed to run on low memory, uses its own byte code and runs .Dex file
JVM is Stack based which uses java byte code and runs .class file having JIT.
Java source code is compiled by the Java compiler into .class files.
Then the dx (dexer) tool, part of the Android SDK processes the .class files into a file format called DEX that contains Dalvik bytecode.
The dx tool eliminate all the redundant information that is present in the classes.
In DEX all the classes of the application are packed into one file.
DVM has been designed so that a device can run multiple instances of the VM efficiently.
stack-based machines must use instructions to load data on the stack and manipulate that data, and, thus, require more instructions than register machines to implement the same high level code, but the instructions in a register machine must encode the source and destination registers and, therefore, tend to be larger.
Conceptually, there is little
difference from an application level
between a DVM and a JVM.
Architecturally, there is a major
difference between the registerbased
DVM and the stack-based JVM.
Both use a VM code model. However, the
DVM uses registerbased opcodes that
are comparable to the register-based
bytecode instructions that most of the
target platforms already execute. This
includes architectures such as those
available from ARM and MIPS and the
x86-compatible architectures from
Intel, AMD, and VIA Technologies.
Google developed Android and chose DVM
for several reasons. First, there were
licensing issues with most JVMs. Next,
the DVM should be more efficient in
terms of memory usage and performance
on a register-based machine. DVM is
also supposed to be more efficient
when running multiple instances of the
DVM. Applications are given their own
instance. Hence, multiple active
applications require multiple DVM
instances. Like most Java
implementations, the DVM has an
automatic garbage collector.
More about it
The jvm architecture is stack-based whereas the dvm architecture is register-based. Stack-based machines require more instructions(i.e. larger instruction set) than register-based machines for the same task. On the other side, each instruction in the register-based machines are larger.
When a Java virtual machine start running a program, it needs memory to store
many things, including bytecodes and other information it extracts
from loaded class files, objects the program instantiates, parameters to
methods, return values, local variables, and intermediate results of computations.
The Java virtual machine organizes the memory it requires to execute a program
into several runtime data areas.
Generally, stack-based machines must use instructions to load data on the stack
and manipulate that data, and, thus, require more instructions than
register machines to implement the same high level code, but the instructions
in a register machine must encode the source and destination registers
and, therefore, tend to be larger.
This difference is primarily of importance to VM interpreters for whom opcode
dispatch tends to be expensive and other factors are relevant for JIT Compilation.
Being optimized for low memory requirements, Dalvik has some specific characteristics
that differentiate it from other standard VMs>>>>>
The VM was just slimmed down to use less space--->>
Dalvik currently has no just-in-time-compiler (JIT), but Android 2.0
includes experimental source for one (disabled by default).
The constant pool has been modified to use only32-bit indexes to simplify
the interpreter. It uses its own bytecode, not Java bytecode***
Dalvik VM can't execute Java bytecode(.class) It has to be(.dex)
Oracle JVM has stack based architecture & Dalvik has register based architecture.
JVM suppost to multiple operating system. (it is open source) but DVM supported for Android Operating system (before comming android 5.o android used the DVM)
Here is a tabular comparison(Source: Mr. Atul):
Jvm will work based on byte code and the dvm will works based on optimized bytecode it is optimised for mobile platforms because mobile devices have low memory and low process that's why it is using the linux kernal.
Here, We can get the basic difference among the JVM (Java Virtual Machine) and DVM (Dalvik Virtual Machine).
From figure it is obvious that DVM can run only .dex files. Dex compiler takes all .class (can be executed by JVM) files for all the classes belongs to application and convert all of them into a single .dex file. Later .dex file is executed by DVM. Additionally, .class files resulted by Javac (java compiler) from .java->.class.
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.
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.