The question is not, what the JVM is written in, but *who* does the porting
work to a particular new platform.
If you've just designed a new microprocessor and need to get a specific
program to run on it, then chances are high, that porting a small C-program
to the new platform's peculiarities will be easier, than to port the whole
JVM to it (and have the program written in Java). Oh, and you'd probably
need a C-compiler ported to it anyway, so I wasn't mentioning it for the
comparison.
well, the C compiler need not be necessarily ported to it, since very
often with such small embedded systems, one cross-compiles to them. then
one just needs a C compiler which targets the given CPU architecture in
use, which may well be a bit easier than getting something more big and
complex (such as a VM framework) ported to it.
If, on the other hand, all of the interesting platforms already have a
Java on it (ported by someone else) then doing the program in Java could
well be the better choice.
it depends a lot on the type of app though, such as how effectively, or
portably, the thing that needs to be done can be implemented purely or
mostly in Java.
for example, Minecraft was written primarily in Java, but still depends
somewhat on special-purpose native interfaces (such as LWJGL) to expose
more OS-level functionality (OpenGL, sound, lower-level keyboard/mouse
input, ...).
about at the time JNI starts really coming into the picture, then things
start looking a little less pretty.
mapping DirectX to Java would also be a bit problematic.
but, yeah, for a vanilla GUI app, Java makes a good deal of sense (well,
along with C#, but C# is mostly only really ideal for very quick/dirty
GUI apps where one doesn't care so much about non-Windows targets).
My impression is, that Android typically runs on hw-platforms
- with a relatively small screen (both: physically and pixels) and no
normal keyboard. (Even though you could pair it with a bluetooth
keyboard, you wouldn't have one with you, most of the time.)
- with a multi-touch-sensitive touch-screen, that can deal with
two (or more) fingers touching it at the same time and with
varying pressure.
- which don't know the concept of "hovering" above a gadget (for
tooltips) or alternative-button clicks (for context menus)
Whereas Java (J2SE) would typically run on hw-platforms that would be
characterized by logically inverting each of the items above.
Any *GUI* app, that might conceivably run on both types of platforms, would
either be really two-separate-apps-in-one, or suck terribly on at least one
of these platforms.
"wut?... so you are saying I can't reasonably use 3DS Max on a cell phone?".
but, yeah, fair enough.
it does pose a bit of a UI design problem, as UIs which are well suited
to a desktop PC are not necessarily as well suited to smaller screens or
keyboards (sometimes even laptops, for example if the app has lots of
on-screen items/information/... and/or makes heavy use of keyboard
shortcuts).
whereas UI designs which work well on cellphones (such as the usual NxN
tiled icons, ...) would look silly on a laptop or desktop (either the
buttons are comically huge, or one has a giant scrolling desktop,
neither of which makes all that much sense).
so, yeah, probably difference sorts of UI designs are needed...
as to whether or not this would be a case of "two apps in one" would
likely depend more on the nature of the app, and possibly how central
the UI design is to its operation.
or such...
