Quote:
Originally Posted by FrustratedReader
Because they COULDN'T put desktop JVM without getting sued. The entire point of it is instead of limited subset Java allowed by Sun on Mobile (symbian era) they cloned so as to have full fat Java on mobile. So of course it's compatible. There are emails querying if they'd get sued anyway. They did and it's still ongoing. So the Java vm used in android has EVERYTHING to do with the Oracle/Sun machine. Deliberately, so they can have a full Java implementation.
|
Incorrect. JVM is stack based because it is compatible with more architectures and fits the slogan: build once, run everywhere. Dalvik VM is register based because google don't need DVM everywhere and this allow them to run faster as they can skip certain cpu instructions used to manipulate the stack.
Implying that google implementation of the java vm is just a copy or a clone of the java one is wrong. They're both different implementations. The implentation that's part of android core relies on an underlying linux kernel and a bunch of c++ glue code while the oracle one can run on most hw arch without carying about the underlying OS.
BTW, I was wrong in my last comment. DVM don't run java bytecode. It is compatible at the source level but the java classes are not just compiled to java bytecode, but translated to dalvik opcodes too.
Quote:
Originally Posted by FrustratedReader
No ereader needs the Android VM for Java. They don't need to run Java.
|
I agree with you. Sadly isn't a matter of what's needed but what is already available. The two options most manufacturers choose are based on AOSP + SDK framework and Linux + Qt framework. Releasing an application inside an embedded device is not an option if you use qt without a license for that specific device. (See
https://www.qt.io/qt-for-device-creation/). So most vendors go with the android route since it provides more frameworks and permissive licenses too.
Some people still thinks that java, in the context of android, adds an overhead and is slower that native code. Unless you work with multimedia, AR or cpu intensive tasks (like compression/decompression) that's not true.