This article compares theapplication programming interfaces (APIs) andvirtual machines (VMs) of the programming languageJava and operating systemAndroid.
While most Android applications are written in Java-like language, there are some differences between the Java API and the Android API, and Android does not runJava bytecode by a traditionalJava virtual machine (JVM), but instead by aDalvik virtual machine in older versions of Android, and anAndroid Runtime (ART) in newer versions, that compile the same code that Dalvik runs toExecutable and Linkable Format (ELF) executables containingmachine code.
Java bytecode in Java Archive (JAR) files is not executed by Android devices. Instead, Java classes are compiled into an android bytecode (dex bytecode) format and run onDalvik (or compiled version thereof with newer ART), a specialized virtual machine (VM) designed for Android. Unlike Java VMs, which arestack machines (stack-based architecture), the Dalvik VM is aregister machine (register-based architecture).
Dalvik has some traits that differentiate it from other standard VMs:[1]
Because the bytecode loaded by the Dalvik virtual machine is not Java bytecode and due to the way Dalvik loads classes, it is impossible to load library packages asjar files. A different procedure must be used to load Android libraries, in which the content of the underlyingdex file must be copied in the application private internal storage area before it is loaded.[2]
As is the case for theJava SE classSystem, the AndroidSystem class allows retrieving system properties. However, some mandatory properties defined with the Java virtual machine have no meaning or a different meaning on Android. For example:
java.version property returns 0 because it is not used on Android.java.specification.version invariably returns 0.9 independently of the version of Android used.java.class.version invariably returns 50 independently of the version of Android used.user.dir has a different meaning on Android.user.home anduser.name properties do not exist on Android.Current versions of Android use the latest Java language and its libraries (but not fullgraphical user interface (GUI) frameworks), not theApache Harmony Java implementation, that older versions used.Java 8 source code that works in latest version of Android, can be made to work in older versions of Android.[3]
By default, the default output streamSystem.out andSystem.err do not output anything,[4] and developers are encouraged to use theLog class, which logs Strings on the LogCat tool.[5] This has changed at least fromHoneyComb, and they now output to the log console also.
Android does not use theAbstract Window Toolkit nor theSwing library.User interfaces are built using View objects. Android uses a framework similar to Swing, based onViews rather thanJComponents. However, Android widgets are notJavaBeans: the Android applicationContext must be provided to the widget at creation.
Android widget library does not support apluggable look and feel architecture. The look and feel of Android widgets must be embedded in the widgets. However, a limited ability exists to set styles and themes for an application.[6]
Contrary to Swing wherelayout managers can be applied to anycontainer widget, Android layout behavior is encoded in the containers.[7]
Android includes only a small subset of thejava.beans package (PropertyChangeEvent and related classes).
By default, the Android system sends stdout and stderr (System.out and System.err) output to /dev/null.
