Comparison of Java and Android API
| Company type | Software |
|---|---|
| Industry | Computer software |
| Products | Virtual machine for Android |
This article provides a comparison between the application programming interfaces (APIs) and virtual machines (VMs) utilized by the programming language Java and the operating system Android.
Although most Android apps are developed using a language similar to Java, Android’s API is distinct from Java’s, and it does not execute standard Java bytecode on a conventional Java virtual machine (JVM). Instead, earlier Android versions rely on the Dalvik virtual machine, while newer releases use the Android Runtime (ART), which compiles code into Executable and Linkable Format (ELF) executables containing native machine code.
Unlike traditional Java environments that run Java bytecode packaged in Java Archive (JAR) files, Android converts Java classes into dex bytecode specific to its platform. This dex code operates on Dalvik or ART, both of which are specialized VMs tailored for Android. In contrast to Java’s stack-based virtual machines, Dalvik employs a register-based design.
Distinctive features of Dalvik include:
- Optimization for minimal memory consumption.
- A modified constant pool structure utilizing only 32-bit indexes to simplify the interpreter.
- A 16-bit instruction set that works directly with local variables through 4-bit virtual registers, differing from Java’s 8-bit stack instructions that require operand stack manipulation.
Because of Dalvik’s unique bytecode format and class loading approach, it is not feasible to load libraries as JAR files directly. Instead, Android requires libraries to be loaded by copying their underlying dex files into the application’s private internal storage before execution.
System properties
The Android class provides access to system properties similarly to the Java SE class , but several properties related to the Java virtual machine either differ in value or are irrelevant on Android. For instance:
- The
java.versionproperty always returns 0 since it is not used in Android. - The
java.specification.versionproperty consistently yields 0.9 regardless of the Android version. - The
java.class.versionproperty returns a constant value of 50. - The
user.dirproperty has an alternate meaning. - Properties such as
user.homeanduser.nameare absent in Android environments.
Class library
Modern iterations of Android support recent versions of the Java language and its libraries, with the exception of comprehensive graphical user interface frameworks, moving away from reliance on the older Apache Harmony implementation. Additionally, Java 8 source code compatible with newer Android versions can be adapted to work with earlier releases.
java.lang package
By default, the output streams and do not produce visible output, encouraging developers to utilize the class for logging messages to the LogCat tool. Since the release of Android Honeycomb, these streams also forward their output to the log console.
Graphics and widget library
Android does not utilize the Abstract Window Toolkit or Swing libraries. Instead, user interfaces are constructed with View objects, employing a framework that resembles Swing but is based on rather than . In contrast to Swing components, Android widgets demand an application context at the time of creation and are not classified as JavaBeans.
Look and feel
The Android widget library does not provide a pluggable look and feel system; the visual design is integrated directly into each widget. Nevertheless, developers can apply a limited range of styles and themes to modify the appearance of UI components.
Layout manager
In contrast to Swing, where layout managers can be assigned to any container widget, Android defines layout behavior explicitly within its container classes.
java.beans package
Android offers support for only a limited portion of the java.beans package, including and associated classes.