Home > Android Army > Could a lawsuit derail Android? Understanding…

Could a lawsuit derail Android? Understanding Oracle’s threat to Google

oracle-android-hanging-in-effigy

The major patent and copyright infringement case between Google and Oracle over technology included in Android looks like it may be going to trial, just not anytime soon. Judge William Alsup issued his preliminary trial plan to both sides Wednesday, noting that the trial is not going to get started in 2011—and everyone involved had better get prepared for a long-drawn out proceeding rather than a quick summary trial. Judge Alsup outlined plans for a three-phase jury trial—phase one to cover copyright claims, phase two to cover patent claims, and a third phase for all remaining issues. The judge noted that the court needs lead time for prepare, and that includes jury selection and preparation for the lengthy disruptions jurors can expect to face. And still, no trial date has been set.

What’s at stake in the fight between Oracle and Google, and what impact could it have on the future of Android?

It’s all about Java

The crux of Oracle’s case against Google has to do with Java technology, which became Oracle’s property when it acquired Sun Microsystems back in early 2010. In the 1990s, Sun developed Java as a “write once, run anywhere” technology that was supposed to provide a way for developers to write applications for any platform (Windows, Mac, Linux, whatever) so long as those platforms had a Java virtual machine. In simple terms, a virtual machine is a software program that simulates a computer and operating system. Software for a virtual machine doesn’t need to know anything about the actual hardware it’s running on, so long as the virtual machine provides access to all necessary capabilities. Sun developed the original Java virtual machine, but more importantly, solidified the specifications for virtual machines that could run Java applications. Other people could, and did, make their own Java virtual machines, either based on Sun’s work or starting from scratch.

The appeal was obvious: Instead of having to write and maintain different versions of apps for every different platform, you’d write one app, and it’d run anywhere, thanks to Java.

The reality turned out a bit different. For one thing, Java apps almost always feel wrong on the desktop. They don’t follow the conventions of the host operating system, meaning users have to struggle to manage windows, controls, and even files. In the early days, Java apps performed slowly compared to native apps, thanks to the overhead of the virtual machines.

What’s more, the early days of Java were significantly muddied by Microsoft. Microsoft signed a licensing deal with Sun for Java technology, then proceeded to integrate its own changes into the Java language and virtual machine so it ran differently, and, in Microsoft’s view, better, on Windows. Eventually, apps for Microsoft’s version of Java didn’t run anywhere but on Windows. So much for write once, run anywhere. Sun sued (and eventually settled with) Microsoft to terminate the license agreement and prevent Microsoft from advertising their apps as Java-compatible, but the damage was done. By that point, many desktop app developers were significantly put off from Java technology, although there are exceptions like OpenOffice, which continues to rely on Java.

However, Java survived and actually thrived in two other areas: server applications and mobile. For server apps, the look and feel of a desktop application doesn’t matter: Users are only connecting to it with a Web browser, database client, or other front end that can be native to their platform. Making portions of the server-side code using Java enabled middleware and enterprise software developers to quickly deploy their systems to a number of platforms: Unix, Solaris, BSD — heck, even Windows. This server-side aspect was one of the main reasons Oracle was interested in acquiring Sun in the first place, since Oracle’s primarily business is enterprise software. Similarly, as mobile phones and other devices began to offer more significant processing power and memory, Java became a viable solution for bringing software to those devices. Sun designed the Java Platform, Micro Edition (or J2ME) specifically for things like phones, set-top boxes, and standalone devices, and it was a huge success. Some industry estimates place the number of mobile devices with J2ME over 2.5 billion, and although J2ME isn’t in today’s leading smartphones, it continues to roll out in Symbian and other devices worldwide.

How Java is (and isn’t) in Android

As Google worked to develop Android, it realized that if it wanted to foster a broad ecosystem of device makers, it needed to provide a way to effectively write code for Android devices that would work on a wide variety of possible architectures. That lead Google directly to the idea of virtual machines, and just as quickly to Java.

However, instead of licensing Java technology from Sun (this was all taking place before Oracle’s acquisition) Google decided to make its own virtual machine with characteristics useful to mobile devices: Dalvik. Google’s Dan Bornstein decided to start over from scratch, rather than starting from an existing Java VM. According to Google, Dalvik is a clean-room design of a Java virtual engine, created by reverse engineering the behavior of Java VMs without using any of Sun’s (now Oracle’s) copyrighted or patented technology. And, indeed, Dalvik exhibits several characteristics that make it distinct from other Java VMs. For one thing, it uses a register-based architecture rather than a stack design (meaning, it can run using fewer instructions with the tradeoff of somewhat larger code). Dalvik is also designed to run on resource-constrained mobile devices, and converts most Java class files to its own instruction set, which can then be further optimized on a device-by-device basis depending on profile information.

As Android got to market, Google offered an Android Native Development Kit that enabled developers to create Android software components using C and C++. Many developers use that native development kit for their apps (or parts of them), particularly for apps that can leverage multi-core processors, and high-performance game technologies. However, mainstream Android development using the standard Android SDK relies on Dalvik. In other words, with the exception of some device-specific apps and leading-edge games that only run on a handful of Android devices, the vast majority of Android software depends on the Dalvik engine.

Get our Top Stories delivered to your inbox: