3 ms·
Has anyone in mobile OS and mobile apps ever questioned the assumptions that Java must be used and/or a scripting language must be used, e.g., Javascript? What
by Moto7451 13y ago
Has anyone in mobile OS and mobile apps ever questioned the assumptions that Java must be used and/or a scripting language must be used, e.g., Javascript?
What if we had a mobile OS and a mobile app that was 100% Java free and only ran compiled code (i.e., that compiles to ARM assembly)?
First, it's a bit pedantic but JIT VMs still compile down to ARM assembly on an ARM device. They basically optimize away the overhead of interpreting their target language.
That said, what you're getting at is how Palm and Windows Mobile did it (for the most part, there is/was .Net for Windows CE) and how iOS does it now. Ubuntu Mobile and Win Phone 8 offer native toolsets in addition to GC/managed runtimes.
I don't think its an assumption at all that mobile devices have to use Java. J2ME didn't exactly take over the world, and that had the advantage of hardware acceleration in the form of ARM Jazelle[1].
What has happened is as hardware gets faster/cheaper, Java, .Net, JS, etc become a better fit for development on mobile devices. On the Desktop we have stupidly powerful machines that can generally brute force their way through the inherent overhead of interpreted/JITed/VMed languages. On mobile however, we're not there yet.
[1]http://en.wikipedia.org/wiki/Jazelle http://en.wikipedia.org/wiki/Jazelle
- gwu78 13y ago"become a better fit" How? Why? I might better understand your perspective if you could elaborate on the details. Why do we have to write resource hogging software _now_ for mobile if the devices are not yet ready to "brute force" their way through it? And if we wrote small, fast software _now_, what would be the downside fo this as devices get more powerful in the future? Users complaining about lightening fast programs that lack the whiz-bang factor that would have been added if developers had used interpreted languages? I can't imagine it.