AFAIK -- not being a Java programmer -- JVM and Dalvik are two very
different beasts. My understanding is that all Java(tm) programs running on a
system run on the same JVM, whereas each Java(android) program is run by its own
dedicated Dalvik.
It might be more accurate to say that JVM's were
designed to be able to run multiple programs, while Dalvik was built with
the assumption of having one VM (often under a unique userid) per
program.
But there's no ultimate reason why you could not ignore the
multi-program capability of the JVM and have one JVM per program too. Consider
if you have a multiuser linux system, you already have something quite similar
to the android case of multiple VM's running programs under distinct userids.
We could ask if IPC is possible between JVMs, but the answer to that is
easy. On Android, code running under Dalvik ultimately uses JNI to talk to
kernel interfaces such as the binder driver - and JNI is from Java, not
something unique to Dalvik.
Probably you can even tweak the JVM to be able
to be forked & specialized in the way zygote does to the DVM in order to
inherit read only shared mappings of commonly used libraries, without breaking
its compatibility with traditional java, at least when invoked in a more
traditional manner.
Look into the details of the situation, and the
differences between what you could theoretically do with a JVM vs. a DVM
aren't really so great - more it's a question of what seemed more technically
advantages, more immune to red tape, (and quite possibly, more fun) when the
decisions were made.
Of course this is all largely irrelevant, as it's
unlikely Google would by free choice replace the DVM with a JVM derivative at
this point in time, and the legal logic by which Oracle might force them to
seems (at least from a programmers perspective) severely lacking.
[ Reply to This | Parent | # ]
| 
