Google's Android SDK Bypasses Java ME in Favor of Java Lite and Apache Harmony

Posted by Scott Delap on Nov 12, 2007 09:03 PM

Community

Java

Topics

Mobile

Tags

Java ME

Today Google released the Android SDK. This comes after the recently announced Open Handset Alliance.  Sun CEO Jonathan Schwartz praised the OHA and its support of Java after the announcement. However, the details of Java in respect to Android remained sketchy ... until today that is.

Android uses Linux 2.6 as the basis for its hardware abstraction layer providing support for drivers, memory management, networking etc. On top of this layer is a set of native libraries written in C/C++ for features such as OpenGL, fonts, media codecs, SQL Lite, and WebKit for browser rendering. The interesting details come in the next layer up the stack and the Dalvik VM.

Instead of providing a full version of the Java SE or Java ME Google has diverged on two fronts. First, a limited subset of the core Java packages is provided. Commonly used packages such as java.nio, java.lang, and java.util are included. Apache HttpClient is among a few open source projects bundled in addition to Android specific libraries. Notably absent however are JME classes and traditional Java UI related packages Swing and AWT. By going this route Android is following in the footsteps of another Google project GWT which uses Java as its development language but does not support the full JDK.

Android makes use of a custom VM to run applications written in its variant of Java:

Every Android application runs in its own process, with its own instance of the Dalvik virtual machine. Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool. The Dalvik VM relies on the Linux kernel for underlying functionality such as threading and low-level memory management.

Dalvik has been fine tuned for mobile devices in terms running under limited battery and CPU conditions.  Apache V.P., Java Community Process Geir Magnusson notes that Dalvik makes use of Apache Harmony classlib.  The Android SDK is licensed under the Apache Software License.   This decision in comparison to using GPLv2 has been covered in depth by Ars Technica.

The above image shows the Android stack. The items in blue are written in the Android subset of Java. This includes application framework services such as resource management and windowing. The core Android Phone, Browser, and Contact applications are also written in Java and run under the Dalvik VM.

The Android SDK presently supports Windows XP or higher, OS X 10.4.8+ and Linux. JDK 5 or 6 is also needed. While Eclipse is not required an Eclipse 3.2+ plugin is provided along with debugger tools and an emulator.

Early reviews of the SDK from developers seems mixed. Some see the use of Java lite as troublesome:

...In my opinion this is all a bit disappointing. Not aligning with an existing profile of Java is a design choice that is regrettable. It makes Android incompatible with everything else out there which is unnecessary in my view. Additionally, Android seems to duplicate a lot of existing functionality from full Java, J2ME and various open source projects. I’m sure that in each case there is some reason for it but the net result seems reinvention of a lot of wheels. Overall, I doubt that Android APIs are significantly faster, more flexible, usable, etc. than what is already out there...

Ryan Block questions Java in general:

I can’t be the only one who’s disappointed with Android using Java as its application layer environment, can I? ... Android’s got a lot more optimized frameworks than your average Java-capable device, a mobile multitasking Java VM app environment is never going to run as well as something coded native to the core OS; this is already visible in the video demo where some of the swipes, taps, and touch gestures present a far chunkier, less visually satisfying experience than the bar that’s been set by the iPhone / iPod touch...

Others such as Ed Burnette see value in the layers the stack:

...This is great news for developers because we won’t have to worry about recompiling the programs for different architectures, for example one version for ARM and another for x86. It’s also good for manufacturers because it gives them tremendous flexibility in the hardware they can put in their phones. They can drop in new types of processors without having to worry about breaking existing applications...

1. Back to top

   Interesting

   Nov 13, 2007 5:57 AM by Geoffrey Wiseman

   Thanks for calling out the Java subset and the details of the Dalvik VM; despite skimming the documentation once already, I'd missed some of those details on the first pass.

   Reply

2. Back to top

   Nice

   Nov 13, 2007 6:05 PM by Toby Jee

   This is something realling interesting in the mobile space from Google. If only Apple could learn something out of this. Unlike Apple, instead of shunting out Java, Google creates a sollution, Google innovates. Coool.... :)

   Reply

3. Back to top

   Re: Interesting

   Nov 13, 2007 8:55 PM by Michael Neale

   yeah it is interesting. Its not *really* a JVM on the phone, its the purpose built Dalvik VM - which seems the right things to do. They are using JVM bytecode really as a "source" for the VM. Quite a different approach, but it probably works better. Unfortunately, this probably means it may be difficult to get tools onto the phone that rely on meta programming.

   Reply

• Older >