Sunday, August 15, 2010

As you've probably heard by now, Oracle has decided to file suit against Google, claiming multiple counts of infringement against Java or JVM patents and copyrights they acquired when they assimilated Sun Microsystems this past year. Since I'm unlikely to keep my mouth shut about even trivial matters, something this big obviously requires at least a couple thousand words.

Who Am I?

Any post of this nature really requires an author to identify where they stand, so their unavoidable biases can be taken with the appropriate dosage of salt. Rather than having you dig through my past and learn who and what I am, I'll just lay it out here.

I am a Java developer. I've been a Java developer since 1996 or so, when I got my first University job writing stupid little applets in this new-fangled web language. That job expanded into a web development position, also using Java, and culminated with me joining a few senior developers for a 6-month shared development gig with IBM's then-nascent Pacific Development Center in Vancouver, BC. Since then I've had a string of Java-related jobs...some as a trenches developer, some as a lead, some as "architect", but all of them heavily wrapped up in this thing called Java. And I can't say that I've ever been particularly annoyed with Java as a language or a platform. Perhaps I haven't spent enough time on other runtimes, or perhaps I've got tunnel-vision after being a Java developer for so many years. But I'd like to think that I've become "seasoned" enough as a developer to realize no platform is perfect, and the manifold benefits of the JVM and the Java platform vastly outweigh the troublesome aspects.

I am an open-source developer. In the late 90s, I worked in earnest on my first open-source project: the LiteStep desktop replacement for Windows. At the time, the LiteStep project was a loosely-confederated glob of C code and amateur C hackers. Being a Windows user at the time, I was looking to improve my situation...specifically, I had worked for years on a small application called Hack-It that exposed aspects of the win32 API normally unavailable through standard Windows UI elements, and I was interested in taking that further. LiteStep was not my creation. It had many developers before me and many after, but my small contribution to the project was an almost complete rewrite in amateur-friendly C++ and a decoupling of the core LiteStep "kernel" from the various plugin mechanisms. I was also interviewed for a Wired article on the then-new domain of "skinning" computers, desktops, applications, and so on, though none of my quotes made it into the article. After LiteStep, I fell back into mostly anonymous corporate software development, all still using Java and many open-source technologies, but not much of a visible presence in the OSS world. Then, in 2004 while working as the lead "Java EE Architect" for a multi-million-dollar US government contract, I found JRuby.

I am a JRuby developer. Since 2004 (or really since late 2005, when I started helping out in earnest) I've been partially responsible for turning JRuby from an interesting novelty project into one of the top Ruby implementations. We've become well known as one of the best-performing – if not the best-performing – Ruby implementations, even faced with increasing competition from the young upstarts. We're also increasingly popular (and perhaps the easiest path) for bringing Ruby and its many paradigm-shifting libraries and frameworks (like Rails) to Java and JVM users around the world – without them having to change platforms or leave any of their legacy code behind. Part of my interest in JRuby has been to bring Ruby to the JVM, plain and simple. I like Ruby, I like the Ruby community, and on most days I like the cockiness and enthusiasm of those community members toward trying crazy new things. But another large part of my interest in JRuby is more sinister: I want to prove to naysayers what a great platform the JVM actually is, and perhaps make them think twice about knee-jerk biases they've carried and cultivated for so many years.

You'll notice I refer to JRuby not as "it" or "she" or "he", but as "we". "We've become well known...We're also increasingly popular..." That's not an accident. There's now over five years of my efforts in JRuby, and I consider it to be as much a part of me as I am a part of it. And so because of that, I have a much deeper, emotional investment in the platform upon which JRuby rests.

I am a Java developer. I am an open-source developer. I am a JRuby developer and a Ruby fan.

I am not a lawyer.

The Facts, According to Me

These are the facts as I see them. You're free to disagree with my interpretation of the world, and I encourage you to do so in the comments, on other forums, over email, or to my face (but buy me a beer first).

On Java

The Java platform is big. Really big. You just won't believe how vastly hugely mindbogglingly big it is. And by big, I mean it's everywhere.

There are three mainstream JVMs people know about: JRockit (WebLogic's first and then Oracle's after it acquired them), Hotspot (Which came to Sun through an acquisition and eventually became OpenJDK), and J9 (IBM's own JVM, fully-licensed and with all its shots). Upon those three JVMs lives a gigantic world. If you want the details, there's numerous studies and reports about the use of Java in all manner of business, from the hippest new startups (Twitter recently switched much of their stack to the JVM) to the oldest of the old financial concerns. It's the favored choice for government server applications, the strongest not-quite-completely-Free managed runtime for open-source libraries and applications, and now with Android it's rapidly becoming one of the strongest (if not the strongest) mobile OS platform (even though Android isn't *really* Java, as I'll get into later). You may love or hate Java, but I guarantee it's part of your life in some way or another.

There are a few open-source implementations of Java. The most well-known is OpenJDK, the Hotspot JVM that Sun relicensed under the GPL and set Free into the world. There's also Apache Harmony, whose class libraries form part of Dalvik's (Android's VM) Java-compatibility layer. There's GNU Classpath, a GPL-based implementation of the Java class libraries used for the ahead-of-time Java compiler GCJ. There's JamVM, which leverages Classpath to provide a very light, very minimal, (and very simple) JVM implementation. And there's others of varying qualities and relevance like IKVM (Java for .NET), VMKit (a Java compiler atop LLVM), and so on. OpenJDK is certainly the big daddy, though, and its release as GPL guarantees we'll at least have a solid Java 6 implementation forever.

Java is not an entirely open platform, what with the now-obvious encumbrances of patents and copyrights (not to mention draconian policies toward Java's various specifications, which are often very slow to evolve due to the JCP quagmire). That's not a great state of affairs, and if nothing else you have to recognize that folks at Sun at least tried to release the platform from its shackles by chasing OpenJDK. But the process of "freeing" Java has been pretty rocky; OpenJDK itself took years to gain acceptance from OSS purists, and the choice of the GPL has meant that folks afeared of the GPL's "viral" side still had to look for other options (which is a large part of why Apache Harmony was used as part of the basis for Android). Perhaps the biggest nail in the coffin is that Sun's Java test kit, the gold standard of whether an implementation is "compliant" or not, has never been released in open-source form, ultimately binding the hands of developers who wished to build a fully-compatible open-source Java.

Java is not an entirely closed platform, either. OpenJDK was a huge step in the direction of Freeing Java, and the Java community in general has a very strong OSS ethos. There's no piece of Java software that isn't at least partially based on open-source componenents, and most Java library, framework, or application developers either initially or eventually open-source some or all of their works. Open-source development and the Java platform go hand-in-hand, and without that relationship the platform would not be where it is today. Contrast that to other popular environments like Microsoft's .NET – which has been admirably Freed through open standards, but which has not yet become synonymous with or popular for OSS development – or Apple's various platforms – which aren't based on open-standards *or* open-source, but which have managed to become many OSS developers' environment of choice...for writing or consuming non-Apple open-source software. Among the corporation-controlled runtimes, the Java platform has more OSS in its blood than all others combined...many times more.

Java is not perfect, but it's pretty darn good. Every platform has its warts. The Java platform represents a decade and a half of tradeoffs, and it's impossible in that amount of time to make everyone happy all the time. One of the big contentious items is the addition in Java 5 of parametric polymorphism as a compile-time trick without also adding VM-level support for reifying per-type specializations as .NET can do. But ask most Java developers if they'd rather have nothing at all, and you'll get mixed responses. The sad, crippled version of generics in Java 5 doesn't do everything static-typing purists want, nor does it really extend to runtime at all (making reflective introspection almost impossible), but they do provide some nice surface-level sugar for Java developers. The same can be said of many Java "features" and tradeoffs. JavaEE became an abortively complicated jumble of mistakes (tradeoffs that went bad), but even upstarts that arguably made better decisions initially have themselves graduated into chaos (I believe the Spring framework has now grown even larger than the largest Java EE conglomerate, and Microsoft's periodically reboots their blessed-framework-of-the-week, resulting in an even more disruptive environment than a slow-moving, bulky standard like JavaEE). Designing good software is hard. Designing good *big* software is exponentially harder. Designing good *big* software that pleases everyone is impossible.

Why People Hate Java

Java is second only to Microsoft's platforms for being both wildly successful and almost universally hated by the self-sure software elite. The reasons for this are manifold and complex.

First of all, back in the 90s Java started getting shoved down everyone's throat. Developers were increasingly told to investigate this new platform, since their managers and long-disconnected tech leads kept hearing how great it was from Sun Microsystems, then a big deal in server applications and hardware. So developers that were happily using other environments (many of which exist to this day) often found themselves forced to suck it up and become Java developers. Making matters worse, Java itself was designed to be a fairly limited language...or at least limited in how easily a developer could paint themselves into a corner. Many features those reluctant developers had become used to in other environments were explicitly rejected for Java on the grounds that they added too much complexity, too much confusion, and too little value to trenches developers. So people that were happily doing Perl or C++ or Smalltalk or what have you were suddenly forced into a little J-shaped box and forced to write all those same applications upon Java and the JVM at a time when both were still poorly-suited to those domains. Those folks have had a white-hot hate for anything relating to Java ever since, and many will stop at nothing to see the entire platform ejected into space.

Second, as mentioned quickly above, Java in the 90s was simply not that great a platform. It had most of the current warts (classpath issues, VM limitations, poor system-level integration, a very limited language) on top of the fact that it was slow (optimizing JVMs didn't come around until the 2000s), marketed for highly-visible, highly-fickle application domains like desktop and browser-based applications (everyone's cursed a Java app or applet at some point in their life), and still largely driven and controlled by a single company (at a time when many developers were trying to get out from under Microsoft's thumb). It wasn't until Java 1.2 that we started to get a large and diverse update to Java's core libraries. Java 1.3 was the first release to ship Hotspot, which started to get the performance monkey off our backs. Java 1.5 brought the first major changes to the Java language, all designed to aid developers in expressing what they meant in standard ways (like using type-safe enums instead of static final ints, or generics for compiler-level assurances of collection homogeneity). And Java 6, the last major version, made great strides in improving startup time, overall performance, and manageability of JVM processes. Java 7, should it ever ship, will bring new changes to the Java language like support for closures and other syntactic sugar, better system-level integration features as found in NIO.2, and the feather in the cap: VM-level support for function objects and non-standard invocation sequences via Method Handles and InvokeDynamic. But unless you've been a Java developer for the past decade, all you remember is the roaring 90s and the pain Java caused you as a developer or a user.

Third, the Java language and environment has stagnated. Given years of declining fortunes at Sun Microsystems, disagreement among JCP members about the direction the platform should go, and a year of uncertainty triggered by Sun's collapse and rescue at the hands of Oracle, it's surprising anything's managed to get done at all. Java 7 is now many years overdue; they were talking about it when I joined Sun in 2006, and hoped to have preview releases within a year. For both technical and political reasons, it's taken a long time to bring the platform to the next level, and as a result many of the truly excellent improvements have remained on the shelf (much to my dismay...we really could use them in JRuby). For fast-moving technology hipsters, that's as good as dying on the vine; you need to shift paradigms on a regular schedule or you're yesterday's news.

Update: At least one commenter also pointed out that it took a long time for Java to be "everywhere", and even today most users still need to download and install it at least once on any newly-installed OS. Notable exceptions include Mac OS X, which ships a cracker-jack Java 6 based on Hotspot, and some flavors of Linux that come with some sort of Java installed out of the box. But this was definitely a very real problem; developers were being pushed to write apps and applets in Java, and users were forced to download a multi-megabyte installer just to run them...at a time when downloading multi-megabyte software was often a very painful ordeal. That would put a bad taste in anyone's mouth.

It's because of these and similar reasons that folks like Google finally said "enough is enough," and opted to start doing their own things. On the JRuby project, we've routinely hacked around the limitations of the JVM, be they related to its piss-poor process management APIs, its cumbersome support for binding native libraries, or its stubborn reluctance to become the world's greatest dynamic language VM. I've thought on numerous occasions how awesome it would be to spin off a company that took OpenJDK and made it "right" for the kinds of development people want to do today (and I'd love to be a part of that company), but such ventures are both expensive and light on profitability. Nobody pays for platforms or runtimes...they pay for services around those platforms or runtimes, services which are often anathema to the developers of those platforms and runtimes. So it required someone "bigger" to make that happen...someone who could write off the costs of the platform by funding it in creative new ways. Someone with a massive existing investment in Java. Someone with deep pockets and an army of the best developers in the business who love nothing more than a challenge. Someone like Google.

Why Android?

(Note that a lot of this is based on what information I've managed to glean from various conversations. Clarifications or corrections are welcome.)

There's an incredibly successful mobile Java platform out there. One that boasts millions of devices from almost all the major manufacturers, in form factors ranging from crappy mid-00s clamshells to high-end smartphones. A platform with hundreds or thousands of games and applications and freely-available development tools. That platform is Java ME.

Java ME started out as an effort to bring Java back to its original roots: as a language and environment for writing embedded applications. The baseline ME profiles are pretty bare; I did some CLDC development years ago and had to implement my own buffered streams and various data structures just to get by. Even the biggest profiles are still fairly restricted, and I don't believe any of them have ever graduated beyond Java 1.3-level featuresets. So Sun did a great job of getting Java ME on devices, back when people cared about Sun...and then they let mobile Java stagnate to a terrible degree while they spent all resources trying to get people to use Java EE and trying to get Java EE to suck less. So while resources were getting poured into EE, people started to form the same opinions of mobile Java they had formed about desktop and server Java years earlier.

At the same time, Java ME was one of the few Java-related technologies that brought in money. You see, in order for handset manufacturers to ship (and boast about) Java ME support, they had to license the technology from Sun. It wasn't a huge cash cow, but it was a cow nonetheless. Java ME actually made money for Sun. So in true Sun form, they loused it up terribly.

Fast forward to a few years ago. Google, recognizing that mobile devices finally were becoming the next great technology market, decided that leaving the mobile world in the hands of proprietary platforms was a bad idea. Java ME seemed like it could be an answer, but Sun was starting to get desperate for both revenue and relevance...and they'd started to back a completely new horse-that-would-be-cow called JavaFX, which they hoped to pimp as the next great development environment for in-browser and on-device apps alike. They weren't interested in making Java ME be what Google wanted it to be.

Google decided to take the hard route: they'd fund development of a new platform, building it entirely from open-source components, and leveraging two of the best platform technologies available: Linux, for the kernel, and Java, for the runtime environment. However there was a problem with Java: it was encumbered by all sorts of patents and copyrights and specifications and restrictions. Hell, even OpenJDK itself, the most complete and competitive OSS implementation of Java, could not be customized and shipped in binary-only form by hardware manufacturers and service providers due to it being GPL. So the answer was to build a new VM, use unencumbered versions of the core Java class libraries, and basically remake the world in a new, copyright and patent-free image. Android was born.

There's many parts to Android, several of which I'm not really qualified to talk about. But the application environment that runs atop the Dalvik VM needs some explanation.

First, there's the VM. Dalvik is *not* a JVM. It doesn't run JVM bytecode, and you can't ship JVM bytecode expecting it to work on Dalvik. You must recompile it to Dalvik's own bytecode using one of the provided translation tools. This is similar to how IKVM gets Java code to run on .NET: you're not actually running a JVM, you're transforming your code into a different form so it will run on someone else's VM. So it bears repeating, lest anyone get confused: Dalvik is not a JVM...it just plays one on TV.

Second, there's the core Java class libraries. Android supports a rough (but large) subset of the Java 1.5 class libraries. That subset is large enough that projects as complicated as JRuby can basically run unmodified on Android, with very few restrictions (a notable one is the fact that since we can't generate JVM bytecode, we can't reoptimize Ruby code at runtime right now). In order to do this without licensing Sun's class libraries (as most other mainstream Java runtimes like JRockit and J9 do), Google opted to go with the not-quite-complete-but-pretty-close Apache Harmony class libraries, which had for years been developed independent of Sun or OpenJDK but never really tested against the Java compatibility kits (and there's a long and storied history behind this situation).

So by building their own non-JVM VM and using translated versions of non-Sun, non-encumbered class libraries, Google hoped to avoid (or at least blunt) the possibility that their "unofficial", "unlicensed" mobile Java platform might face a legal test. In short, they hoped to build the open mobile Java platform developers wanted without the legal and financial encumbrances of Java ME.

At first, they seemed to be on a gravy train with biscuit wheels.

Splitting Up the Pie

Sun Microsystems was not amused. A little over a year ago, when several Sun developers started to take an eager interest in Android, we were all told to back off. It wasn't yet clear whether Android stood on solid legal ground, and Sun execs didn't want egg on their face if a bunch of their own employees turned out to be supporting a platform they'd eventually have to attack. Furthermore, it was an embarrassment to see Android drawing in the same developers Sun really, really wanted to look at JavaFX or PersonalJava or whatever the latest attempt to bring developers back might be. Android actually *was* a great platform that supported existing Java developers and libraries incredibly well (without actually being a Java environment), and for the first time there was a serious contender to "standard" Java that Sun had absolutely no control over.

To make matters worse, handset manufacturers started to sign on in droves to this new non-Java ME platform, which meant all that technology licensing revenue was reaching a dead end. Nobody (including me) wanted to do Java ME development anymore. Everyone wanted to do Android development.

Now we must say one thing to Sun's credit: they didn't do what Oracle is now attempting to do. As James Gosling blogged recently, patent litigation just wasn't in Sun's blood...even if there might have been legal ground to file suit. So while we Sun employees were still quietly discouraged from looking at or talking about Android, the rest of the world took Sun's silence as carte blanche to stuff Android into everything from phones to TVs, and mobile app developers started to think there might be hope for a real competitor to Apple's iPhone. Things might have proceeded in this way indefinitely, with Android continuing to grab market share (it recently passed iPhone in raw numbers with no slowing in sight) and mindshare (Android is far more approachable than almost any other mobile development environment, especially if you're one of the millions of developers who know Java.)

And then it all started to go wrong.

The Mantle of Java Passes to Oracle

If for nothing else, Jonathan Schwartz will be remembered as the man who broke open the Sun piñata, simultaneously releasing more open-source software than any company in history and killing Sun in the process. Either Jonathan had no "step 2" or the inertia of a company built on closed-source products was too great to overcome. In either case, by spring of 2009 Sun was hemorrhaging. Many reports claim that Jonathan had started shopping Sun around to possible buyers as early as 2008, but it wasn't until 2009 that the first candidates started lining up. Initially, it was IBM, hoping to gobble up its former competitor along with the IP, patents, and copyrights they carried. That deal ultimately went south when Sun refused to consider any deal that IBM wouldn't promise to carry to completion, even in the face of regulatory roadblocks sure to come up. Many of us breathed a sigh of relief; if there's any Java company even more firmly stuck in the old world than Sun, it's IBM...and we weren't looking forward to dealing with that.

Once that deal fell through, folks like me became resigned to the fact that Sun was nearing the end of its independent life. Years of platform negligence, management incompetence, and resting on laurels had dug a hole far too deep for anyone to climb out of. Would it be Cisco, who had recently started building up an interesting new portfolio of application server hardware and virtualization software? What about VMWare, who had recently gobbled up Springsource and seemed to be making all the right moves toward a large-scale virtualized "everything cloud." Or perhaps Oracle, a long-time partner to Sun, whose software was either Java-based or widely deployed on Sun hardware and operating systems. Dear god, please don't let it be Oracle.

Don't get me wrong...Oracle's a highly successful company. They've managed to turn almost every acquisition into gold while coaxing profitability out of just about every one of their divisions. But Oracle's not a developer-oriented company (like Sun)...it's a profit-oriented company (unlike Sun, sadly), and you need to either feed the bottom line or feed others in the company that do. So when it turned out that Oracle would gobble up Sun, many of us OSS folks started to get a little nervous.

You see, many of us at Sun had been actively trying to change the perception of the platform from that of a corporate, enterprisey, closed world to that of a great VM with a great OSS ecosystem and an open-source reference implementation. Folks like Jonathan believed that by freeing Java we'd free the platform, and both the platform and the developer community would be better for it. We were half right...the OpenJDK genie is out of the bottle, and there's basically no way to put it back now (and for that, the world owes Sun a great debt). But only part of the platform was Freed...the patents and copyrights surrounding Hotspot and Java itself remained in place, carefully tucked away in the vault of a company that just didn't mount patent or copyright-driven legal attacks.

Oracle, now in control of those patents and copyrights, obviously has different plans.

The Suit

So now, after spending 4000 words of your time, we come to the meat of the article: the actual Oracle v Google suit. The full text is provided various places online, though the Software Patents Wiki has probably the best collection of related facts (though the wiki-driven discussions of the actual patents are woefully inaccurate).

The suit largely comes down to a patent-infringement battle. Oracle claims that by developing and distributing Android, Google is in violation of seven patents. There's also an amorphous copyright claim without much backing information ("Google probably stole something copyrighted so we'll list a bunch of stuff commonly stolen in that way"), so we'll skip that one today.

Before looking at the actual patents involved, I want to make one thing absolutely clear: Oracle has not already won this suit. Even after a couple days of analysis, nobody has any idea whether they *can* win such a suit, given that Google seems to have taken great pains to avoid legal entanglements when designing Android. So everybody needs to take a deep breath and let things progress as they should, and either trust that things will go the right direction or start doing your damndest to make sure they go the right direction.

With that said, let's take a peek at the patents, one by one. And as always, the "facts" here are based on my reading of the patents and my understanding of the related systems.

The first two patents describe the Java Security Policy system, for controlling access to resources. One of the least-interesting but most-important aspects of the Java platform is its approach to security. Code under a specific classloader or thread can be forced to comply with a specific security policy by installing a security manager. These permissions control just about every aspect of the code's interaction with the JVM and with the host operating system: loading new code, reflectively accessing existing classes, accessing system-level resources like devices and filesystems, and so on. It's even easy for you to build up security policies of your own by checking for custom-named permissions and only granting them when appropriate. It's a pretty good system, and one of the reasons Java has a much stronger security track record than other runtimes that don't have pervasive security in mind from the beginning.

In order to host applications written for the Java platform, and to sandbox them in a compatible way, Android necessarily had to support the same security mechanisms. The problem here is the same problem that plagues many patents: what boils down to a fairly simple and obvious way to solve a problem (associate pieces of code with sets of permissions, don't let that code do anything outside those permissions) becomes so far-reaching that almost any reasonable *implementation* of that idea would violate these patents. In this case the '447 and '476 patents do describe mechanisms for implementing Java security policies, but even that simple implementation is very vague and would be hard to avoid with even a clean-room implementation.

Now I do not know exactly how Android implements security policies, but it's probably pretty close to what's described in these patents...since just about every implementation of security policies would be pretty close to what's described.

This is basically the patent governing the "Pack200" compression format provided as part of the JDK and used to better-compress class file archives.

Update: Alex Blewitt has posted a discussion of the Pack200 specification. He says this patent isn't nearly as comprehensive, but that it may touch upon how Pack200 works. His post is a more complete treatment of the details of the class file format and how Pack200 improves compression ratios for class archives. It also occurs to me now that this patent could be related to mobile/embedded Java too, where better compression would obviously have an enormous savings.

Java class files are filled with redundant data. For example, every class that contains code that calls PrintStream.println (as in System.out.println) contains the same "constant pool" entry identifying that method by name, a la "java/io/PrintStream.println:(Ljava/lang/String;)V". Every field lookup, class reference, literal string, or method invocation will have some sort of entry in the constant pool. Pack200 takes advantage of this fact by compressing all class files as a single unit, batching duplicate data into one place so that the actual unique class data boils down to just the unique class, method, and code structure.

The reason for having a separate compression format is because "zip" files, which includes Java's "jar" files, are notoriously bad at compressing many small files with redundant data. Because one of the features of the "zip" format is that you can easily pull a single file out, compressing all files together as a single unit prevents introducing any interdependencies between those files or a global table. This is a large part of why compression formats like "tar.gz" do a better job of compressing many small files: tar turns many files into one file, and gzip or bzip2 compress that one large file as a single unit (conversely, this is why you can't easily get a single file out of a tarball).

On Android, this is accomplished in a similar way by the "dex" tool, which in the process of translating JVM bytecode into Dalvik bytecode also localizes all duplicate class data in a single place. The general technique is standard data compression theory, so presumably the novelty lies in applying decades-old compression theory specifically to Java classfile structure.

If I've lost you at this point, we can summarize it this way: part of Oracle's suit lies in a patent for a better compression mechanism for archives containing many class files that takes advantage of redundant data in those files.

I'm not sure this patent ever saw the light of day in a mainstream JVM implementation. It describes a mechanism by which a master parent process could pre-load and pre-initialize code for a managed system, and then new processes that need to boot quickly would basically be memory-copied (plus copy-on-write friendly) "forks" of that master process, with the master maintaining overall control of those child processes through some sort of IPC.

Ignore for the moment the obvious prior art of "fork" itself as applied to pre-initializing application state for many children. Anyone who's ever used fork to initialize a heavy process or runtime to avoid the cost of reinitializing children has either violated this patent (if done since 2003) or has a compelling case for prior art (if done before 2003).

It's likely that this patent was formulated as an answer to the poor semantics of running many applications under the same JVM. Java servlets and later Java EE made it possible to consider deploying all of your company's applications in a single process, isolated by classloaders and security policies. What they never really addressed was the fact that code isn't the only thing you're sharing in this model; you're also sharing memory space, CPU time, and process resources like file descriptors. No amount of Java classloader or security trickery could make this a seamless multiapp environment, and so work like this patent hoped to find a lightweight way for all those child applications to actually live as their own processes.

On Android, this manifests in the fact that each application runs independently, and they (like most operating systems) fork off from either the kernel process or some master process.

In this case, Oracle's banking on being able to litigate with a patent for a very common application of "fork".

This patent, invented by James Gosling himself, basically describes a mechanism by which symbolic data references in code (e.g. Java field references) can be resolved dynamically at runtime into actual direct memory accesses, eliminating the symbolic lookup overhead. It's part of standard JIT optimization techniques, and there's a lot of references in this patent many great JIT patents and papers of the past.

Here there may actually be merit, or as much merit as can be found in a software patent to begin with. The patent itself is tiny, as most of these patents are. The techniques seem obvious to me, but perhaps they're obvious because this patent helped make them standard. I'm not qualified to judge. What I can say is that I can't imagine a VM in existence that doesn't violate the spirit – if not the letter – of this patent as well. All systems with symbolic references will seek to eliminate the symbolic references in favor of direct access. The novelty of this patent may be in doing that translation on the fly...not even at a decidedly coarse-grained per-method level, but by rewriting code while the method is actually executing.

I would guess that this is a patent filed during the development of Java's earlier JIT technologies, before systems like Hotspot came along to do a much better large-scale, cross-method job of optimization. It doesn't seem like it would be hard to debunk the novelty of the patent, or at least show prior art that makes it irrelevant.

This patent, invented by Lars Bak of V8 fame, describes a mechanism for building a "mixed mode" VM that can execute interpreted code and compiled (presumably optimized) code in the same VM process, and flip between the two over time to produce better-optimized compiled code. This describes the basic underpinnings of VMs like Hotspot, which alternate between interpreting virtual machine code and executing real machine code even within the same thread of execution (and sometimes, even branching from virtual code to real code and back within the same method body). Any other VMs that are mixed mode would probably violate this patent, so its impact could reach much farther than Android. (In a sense, even JRuby might violate this patent, though our two mixed modes are both virtual instruction sets.)

Now you might think the other mainstream JVMs would violate this patent, but they don't. Neither JRockit nor J9 have interpreters; they both go immediately to native code with various tiers of instrumentation to do the runtime profile data gathering. They iterative regenerate native code with successively more and better optimizations. Lars most recent VM, the V8 Javascript VM at the heart of Chrome, also goes straight to native code.

Now here's where it gets weird: Up until Froyo (Android 2.2) Dalvik did a once-only compilation to native code before anything started executing, which means by definition that it was not mixed-mode. And even in Froyo, I believe it still does its initial execution in native code form with instrumentation to allow subsequent compiles to do a better job. Dalvik does not have an interpreter, Dalvik does not interpret Dalvik bytecode.

Perhaps someone can explain how this patent even applies to Dalvik or Android?

Update: A couple commenters correct me here: Dalvik actually was 100% interpreted before Froyo, and is now a standard mixed-mode environment post-Froyo. So if this suit had been filed a year ago this patent might not have been applicable, but it probably is now.

Sigh. This patent appears to revolve completely around a mechanism by which the static initialization of arrays could be "play executed" in a preloader and then rewritten to do static initialization in one shot, or at least more efficiently than running dozens of class initializers that just construct arrays and populate them. Of all the patents, this is probably the narrowest, and the mechanism described are again not very unusual, but there's probably a good chance that the "dex" tool does something along these lines to tidy up static initializers in Android applications.

Given the "preloader" aspect of this patent, I'd surmise that it was formulated in part to simplify static initialization of code on embedded devices or in applet environments (because on servers...the boot time of static initialization is probably of little concern). Because of the much more limited nature of embedded environments (especially in 1998, when this patent was filed) it would be very beneficial to turn programmatic data initialization into a simple copy operation or a specialized virtual machine instruction. And this may be why it could apply to Android; it's another sort of embedded Java, with a preloader (either dex or the dexopt tool that jit-compiles your app on the device) and resource limitations that would warrant optimizing static initialization.

So, Does the Suit Have Merit?

I'll again reiterate that I'm not a lawyer. I'm just a Java developer with a logical mind and a penchant for debunking myths about the Java platform.

The collection of patents specified by the suit seems pretty laughable to me. If I were Google, I wouldn't be particularly worried about showing prior art for the patents in question or demonstrating how Android/Dalvik don't actually violate them. Some, like the "mixed mode" patent, don't actually seem to apply at all. It feels very much like a bunch of Sun engineers got together in a room with a bunch of lawyers and started digging for patents that Google might have violated without actually knowing much about Android or Dalvik to begin with.

But does the suit have merit? It depends if you consider baseless or over-general patents to have merit. The most substantial patent listed here is the "mixed mode" patent, and unless I'm wrong that one doesn't apply. The others are all variations on prior art, usually specialized for a Java runtime environment (and therefore with some question as to whether they can apply to a non-Java runtime environment that happens to have a translator from Java code). Having read through the suit and scanned the patents, I have to say I'm not particularly worried. But then again, I don't know what sort of magic David Boies and company might be able to pull off.

What Might Happen?

In the unlikely event of a total victory by Oracle, there's probably a lot of possible outcomes. I don't see the "death of Java" among them. There's also the possibility that Google could win a convincing victory. What might happen in each case?

The Nuclear Option

The worst case scenario would be that Android is completely destroyed, all Android handsets are confiscated by the Oracle mafia and burned in the city square, and all hope for a Free and Open Java are forever laid to rest. Long live Mono.

To understand why this won't happen we need to explore Oracle's possible motives.

As I mentioned above, Java ME actually did bring licensing revenue to Sun. There's a lot of handset manufacturers, millions of handsets, and every one put a couple cents (or a couple bucks?) in Sun's pocket. In the heady high times of Java ME, it was the only managed mobile runtime in town, with sound and graphics and standard UI elements. It wasn't always pretty, but it worked well and it was really easy to write for.

Now with Android rapidly becoming the preferred mobile and embedded Java, it's become apparent that there's no future for Java ME - or at least no future in the expanding "smart" consumer electronics business. Java ME lives on in Blackberries, some other low-end phones, in most Blu-Ray devices (BD-J is a standard for writing Java apps that run on Blu-Ray systems, utilizing one of the richer class libraries available for Java ME), and in some sub-micro devices like Ajile's AJ-200 Java-based multimedia CPU. If you want Java on a phone or in your TV, Android is taking that world by storm. That means Java ME licensing revenue is rapidly drying up.

So why wouldn't Oracle want to take a bite of the rapidly-growing Android pie? Would they turn down a portion of that revenue and instead completely destroy a very popular and successful mobile Java, or would they just strongarm a few bucks out of Google and Android handset manufacturers? Remember we're talking about a profit-driven company here. Java ME is never going to come back to smartphones, that much is certain and I don't think even Oracle could argue it. There's no profit in filing this suit just to kill Android, since it would just mean competing mobile platforms like Windows Phone, RIM, Symbian, or iOS would just canibalize their younger brother. Instead of getting a slice of the fastest-growing segment of Java developers, you'd kill off the entire segment and force those developers to non-Java, non-Oracle-friendly platforms.

Oracle may be big and evil, but they're not stupid.

Google Licensing Deal

A more likely outcome might be that Google would be forced to license the patents or pay royalties on Android revenue. I honestly believe this is the goal of this lawsuit; Oracle wants to get their foot into the door of the smartphone world, and they know they can't innovate enough to make up for the collapse of Java ME. So they're hoping that by sabre-rattling a few patents, Google will be forced (or scared) into sharing the harvest.

Given the contents of the suit and the patents, I think this one is pretty unlikely too. Much of Android and Dalvik's designs are specifically crafted to avoid Java entanglements, and I think it's unlikely if this suit goes to trial that Oracle's lawyers would be able to make a convincing argument that the patents were both novel and that they were violated by Google. But let's not put anything past either the lawyers or the US federal court system, eh?

Nothing At All

There's a good chance that either Oracle or the court will realize quickly that the case has no merit, and drop all charges. I'm obviously hoping for this one, but it's likely to take the longest of all. First, the court would need to gather all facts in the case, which could take months (especially given the highly technical nature of some of the compaints). Then there's the rebuttals of those facts, sorting out the wheat from the chaff, deciding there's not enough there to proceed, and either Oracle backs out or the court tosses the case. In the latter case, there's the possibility of appeals, and things could start to get very expensive.

Total Collapse of Software Patents

This is probably the one of the highest-profile cases involving software patents in recent years. The other would be Apple's recent suit against HTC for design elements of the iPhone. Several other bloggers and analysts have called out the possibility that this could lead to the death of software patents in general. I think that's a bit optimistic, but both Google *and* Oracle have come down officially against patents in the past (though perhaps Oracle's had a change of heart since acquiring Sun's portfolio).

As much as I'd like to see it happen, software patents probably won't be dead in the next year or two. But this might be a nail in the coffin.

What Does This Mean for Java?

Now we come to the biggest question of all: how does this suit affect the Java world, regardless of outcome?

Well it's obviously not great to have two Java heavyweights bickering like schoolchildren, and it would be positively devastating if Android were obliterated because of this. But I think the real damage will be in how the developer community perceives Java, rather than in any lasting impact on the platform itself.

Let's return to some of our facts. First off, nothing in this suit would apply to any of the three mainstream JVMs that 99% of the world's Java runs on. Hotspot and JRockit are both owned by Oracle, and J9 is subject to the Java specification's patent grant for compliant implementations. The lesson here is that Android is the first Java-like environment since Microsoft's J++ to attempt to unilaterally subset or superset the platform (with the difference in Android's case being that it doesn't claim to be a Java environment, and it may not actually need the patent grant). Other Java implementations that "follow the Rules" are in the clear, and so 99% of the world's use of Java is in the clear. Sorry, Java haters...this isn't your moment.

This certainly does some damage to the notion of open-source Java implementations, but only those that are not (or can not be) compliant with the specification. As the Apache Harmony folks know all too well, it's really hard to build a clean-room implementation of Java and expect to get the "spec compliance patent grant" if you don't actually have the tools necessary to show spec compliance. Tossing the code over to Sun to run compliance testing is a nonstarter; the actual test kit is enormous and requires a huge time investment to set up and run (and Sun/Oracle have better things to do with their time than help out a competing OSS Java implementation). If the test kit had been open-sourced before Sun foundered, there would be no problem; everyone that wanted to make an open-source java would just aim for 100% compliance with the spec and all would be well. As it stands, independently implemented (i.e. non-OpenJDK) open-source Java is a really hard thing to create, especially if you have to clean-room implement all the class libraries yourself. Android has neatly dodged this issue by letting Android just be what it is: a subset of a Java-like platform that doesn't actually run Java bytecode and doesn't use any code from OpenJDK.

How will it affect Android if this case drags on? It could certainly hurt Android's adoption by hardware manufacturers, but they're already getting such an oustanding deal on the platform that they might not even care. Android is the first platform that has the potential to unify all hardware profiles, freeing manufacturers from the drudgery of building their own OSes or licensing OSes from someone else. Hell, HTC rose from zero to Hero largely because of their backing of Android and shipping of Android devices. Are they going to back off from that platform now just because Oracle's throwing lawyerbombs at Google? Probably not.

What Does This Mean For You?

If you're a non-Android Java developer...don't lose sleep over this. The details are going to take months to play out, and regardless of the outcome you're probably not going to be affected. Be happy, do great things, and keep making the Java platform a better place.

If you're an Android developer...don't lose sleep over this. Even if things go the way of the "Nuclear Option", you've still got a lot of time to build and sell apps and improve yourself as a developer. For a bit of novelty, start considering what a migration path might look like and turn that into a nice Android-agnostic application layer, something that's largely lacking in the current Android APIs. Or explore Android development in languages like JRuby, which are based on off-platform ecosystems that will survive regardless of Android's fate. Whatever you do, don't panic and run for the hills, and don't tell your friends to panic.

If you're mad as hell about this...I sympathize. I'm personally going to do whatever I can to keep people informed and keep pushing Android, including but not limited to writing 8000-word essays with my moderately-educated analysis of the "facts". I welcome your help in that fight, and I think it's a damn good time for people that want an open Java and an open mobile platform to show their quality by standing up and letting the world know we're here.

"All that is necessary for the triumph of evil is for good men to do nothing."

Do something, and we'll get through this together.

Footnote: Java Copyrights

I'd love for someone versed in copyright law to provide a brief analysis of how the Java copyrights described (vaguely) in the lawsuit might play out in Android. Java is certainly not ignored as a concept in Android docs, tools, and libraries, but it's unclear to me whether those copyrights amount to something enforceable when it comes to Android or Dalvik.

Update: "Crazy" Bob Lee emailed me to clear up a few facts. First off, Android and OpenJDK first came out around roughly the same time, so there was never really time to consider using OpenJDK's GPL'ed class libraries in Android. Bob also claims that Dalvik's design decisions were all technical and not made to circumvent IP, but it seems impossible to me that IP, patent, and licensing issues didn't have *some* influence on those decisions. He goes on to say that Android relies on process separation to sandbox applications, rather than leveraging Java security policies (or similar mechanisms (which Bob insists are badly designed anyway, and I might agree). Finally, he believes that in the worst case scenario, Dalvik would probably only require minor modifications to address the complaints in this suit. The "nuclear option" is, according to Bob, out of the realm of possibility.

111 comments:

I find it terribly sad that two huge corporations can piss away millions of shareholder dollars and thousands of hours of court resources on this insanity. I think they ought to be ashamed of themselves, and I think the stockholders ought to put their millions of feet down. Sell ORCL and GOOG short, and maybe these bozos will come to their senses.

Nice writeup. Not sure why you cover the implementation details of parametric polymorphism (relevancy?), but not the previous case of Sun vs. Microsoft - for essentially doing the same thing (although Google has the benefits of hindsight and thus avoids referring to Android as Java).

Also, curious as to how V8 can now go directly to native code considering JavaScript and it's very permissive/dynamic nature? I thought mixed-mode (backtracking) was the very essence of V8. It certainly was in the last presentation I saw by Lars.

Thanks Charles for this valuable contribution to the discussion under a relaxed and objective approach.

Of course, we're all trying to make an educated guess about this story, and we have different points of view. Still, there's a passage which really doesn't sound right, or complete, to me:

"However there was a problem with Java: it was encumbered by all sorts of patents and copyrights and specifications and restrictions. Hell, even OpenJDK itself, the most complete and competitive OSS implementation of Java, could not be customized and shipped in binary-only form by hardware manufacturers and service providers due to it being GPL. "

First, OpenJDK is GPL+CPE and not GPL only. The GPL license explicitly provides you with patent protection, AFAIU, In fact, I've read opinions pointing out the paradox, that Google is potentially vulnerable to Java patents precisely for the reason that they tried to create a Java look-alike thing from scratch. Furthermore, I don't understand that "can't be shipped in binary-only form...". Can you explain? I see lots of pieces of software based on GPL+CPE, even from Sun/Oracle (e.g. the NetBeans Platform) that are routinely used in closed or open projects, without any problem about shipping in binary-only form the runtime. Indeed, my point about the reason for which Google created a Java look-alike is that they just wanted a thing that they were able to control in full. Many people are talking about talks between Sun and Google, even before the Oracle buy, that in the end failed. And plenty of opinions there were published when Android came out clearly pointed out that rationale behind Google's choice.

Thanks for the analysis, Charles. Especially the patent analysis. This is exactly what I was looking for in all the reports, a basic explanation of what the patents are.

@fabrizio I believe what Charles means is that the GPL requires that when you "distribute" the project as binary, you also provide access to the source. I believe this could be satisfied by providing a download on Google's site. I don't think it requires distributing the source on the actual Android device, but perhaps this would require every device manufacturer to provide the source for their "distribution" including their modifications and customizations.

I may be wrong, but how come SW-patents can be worded so vague? Aren't "real" patents very specific about the implementation?

I.e. let's say there is an "Automatic Door Closing Device" patent that uses a spring at the top to pull the door closed.

Alternatives that uses, say a rubber band instead, or a counterweight and a string to use gravity to pull it closed, are not violating the patent. Also auto-closing doors, but completely different implemenations.

(repost from HN)Even if Oracle and Google settle in some peaceful way (best outcome out of the likely ones), it is very likely Oracle will continue this avenue of profit. Perhaps IBM is next, given the long time hostilities among both. Or the Android-based handset manufacturers and sellers. There's a lot of shakedown money to be made for Oracle. And it is probably even lawful in spite of it being labeled as morally wrong. Good luck.

You forgot the distribution issues. For a long time, the JRE couldn't be bundled with Linux, nor did it ship on Windows after Sun (rightfully) sued Microsoft over ye olde embrace-extend-extinguish move. So if you wrote Java software, you had to ask every user to download a JRE in some fashion.

IIRC, you could bundle an unmodified JRE into your installer; or you could ask every potential user to go through Sun's confusing download site, hope they pick the correct platform/architecture/package, and hope their dialup didn't drop during the multi-megabyte download--because it was non-restartable.

I probably should have previewed that. My point was: for all its advantages, Java offered a terrible end-user experience. Which is why it ended up in the enterprise and on servers, where the end-users weren't saddled with handling the JRE.

As a developer, during that time, if you wanted to write software for end-users, Java was write once, run nowhere.

So Sun spent 5-10 years trying their hardest to stunt the Java desktop ecosystem, and they succeeded: today, C# apps F-spot and Tomboy are installed by default with Ubuntu, but no JRE or Java apps are, because there aren't any that are useful and popular enough to warrant inclusion.

While Android has security policies and the harmony code actually contains the Java support for this, it doesn't use this mechanism. In fact, it is discouraged to rely on this feature for untrusted code.

Instead, Android's sandboxing relies on the Linux process model, access to privileged data is done through IPCs. This is in a very fundamental way different to the implementation in current JVMs.

Pack200:While the process used in Android seems similar to pack200, I think, it is more general since it not only works on the class files but on the configuration xmls etc.I've didn't read the patent, so it may still apply.

As the founder and former director of the NoSoftwarePatents.com campaign I wouldn't mind seeing Oracle vs. Google and Apple vs. HTC raising doubts about the political desirability of software patents. It's just not too likely to happen because there's too much industry support for those patents, all in all.

Oracle changed its stance a long time ago, not just after acquiring Sun. I was involved with MySQL AB as an adviser to the CEO and I know that in 2004 a high-ranking Oracle executive told MySQL that Oracle's stance on software patents had changed and they were then already in favor of them.

Oracle kept a low profile in the legislative process we had here in the EU concerning software patents (which ended in July 2005), but through various industry associations such as EICTA and ACT Oracle effectively supported the patentability of software.

Google didn't do anything serious to oppose software patents. They only wanted an interoperability exception so they could read and index PDF files, basically speaking. There were many Google employees who really were against that EU software patent directive, but corporately, Google didn't do anything meaningful.

On my FOSS Patents blog I also comment on the Oracle vs. Google case, but I must admit this posting here is the most detailed analysis I've seen so far. Impressive.

I believe you are wrong on the Dalvik claim. The Dalvik byte code is not precompiled, it is 100% interpreted as can be seen in the source code available here.

JIT has been added in the Android 2.2 Froyo, and do mix interpreted code with native code. JIT is only turned on by default if 512MB memory os available, otherwise 2.2 Froyo also uses a pure interpreter solution.

What dexopt do is to "optimize" the Dalvik byte code before execution, it is still byte code. For example converting to native byte order and address alignment if needed. The process is described here.

1) Only a small core of .NET is backed by standards. The latest ECMA spec covers C# 2.0; coverage of APIs is worse, and the derived ISO specs should be even less updated.

2) HotSpot was released in JDK 1.2. It was good only for servers, though. The only new thing in 1.3 was HotSpot Client.

3) I don't think JavaME stagnated due to low investment... but that's another story. IMHO J2ME/JavaME was doomed when it was designed back in ~99: some important APIs didn't scale; remarkably, you can't just lay new classes on top of LCDUI and get a modern, competitive toolkit for today's high-end devices. The composition of layered APIs (e.g. MMAPI, M3G) didn't work well enough. And LCDUI was created, because Swing's architecture was a disaster - couldn't scale down, no sensible subset could be cut. But maybe there was no good choice 10+ years ago. Sometimes you just need to restart from scratch, at least in core frameworks; Sun made the same decision with JavaFX, Microsoft too with WinMob7...

4) Google bought Andy Rubin's Android in Aug 2005. I don't think JavaFX (first announced on May 2007) had much influence.

5) "Dalvik is not a JVM" is just smoke & mirrors. Its bytecode is different enough to not be a clone of Java, and the file format has improvements; but it's also similar enough that 1-to-1 translation is lossless, to the point that the Android SDK actually *relies* on Java bytecode as an intermediary format in the source-to-Dalvik translation. Additionally, Dalvik is enough compatible with the JVM that it can run advanced low-level APIs like java.nio and java.util.concurrent (this requires full compliance with the detailed Java Memory Model spec, for example). Like Shakespeare would say, a JVM by another name... and I guess this won't be good enough to dodge most JVM patents.

6) On Sun not having sued Google: Maybe that was just because Sun was already severely down, or already considering to sell itself, or very optimistic about JavaFX? Sun's DNA certainly didn't stop them to sue NetApp over filesystem patents (I know, in this story there's a debate about which company did the first aggressive move, but still).

On the JIT patent: Pre-FroYo, Android was a purely interpreted VM, it didn't have neither JIT nor AOT compilation into native code. After FroYo it's a standard mixed-mode VM that combines interpreted and JIT'd native code.

What are the odds on Google settling a deal for short-term compatibility reasons for existing customers/handsets. While longer term engineering a move away from Dalvik/Java. While its convenient to reuse a language many developers are familiar with it doesn't sound critical to the platform (low level memory management stuff?). Frankly the existing SDK always seemed a bit of a engineers kludge anyway.

Javascript has come on leaps & bounds over the last few years and Google has played no small part in this and the push for HTML5. They've been wanting to refocus the perceived Andriod platform fragmentation so why not create a new SDK based on open web standards. One not so dissimilar to WebOS which has shown whats possible. An engineering solution does seem most likely from Google but those VM patents appear too wide raging for a simple Dalvik fix.

In an ideal world I'd like to see this go away quickly and quietly as possible. Counter patent suits from Google, or maybe Microsoft might step in to help. Would they help Google? given the VM patents could apply to .Net and weakening Andriod strengthens Apple (they've already offered to help HTC against Apple)..? Though for Open Source / Open Java the damage has been done and Oracle have really shown their hand. Killing OpenSolaris on the same day.. hoping one bad story would cancel the other? A dark day Friday the 13th. So I either see Google moving away from Dalvik & Java or Oracle losing and probably wondering what value they've got from buying Sun. Seems like a lose-lose for Java & the community.

It's sad to see that Oracles priority isn't strengthening the Java ecosystem, fixing the JCP or competing with Andriod & Apple with JavaFX.. It's community damaging law suits that will further drive people away from Java. Not signals that needing sending right now. Not counting the move of javaone, the bungled Javadocs url move or the bungled jre update 21 as their first moves.

Great writeup. You are rightly pessimistic about this having any profound effect on software patents -- the Sun/NetApp case is/was a much broader case than this (though I suppose the day is still young in ORCL v. GOOG), and despite Sun having invalidated all the of the litigated patents, we have seen no real push to reform. Which brings up a comment to Osvaldo: you are showing complete and total ignorance of the Sun/NetApp case to believe that that was a Sun-initiated endeavor. Charles is right: this kind of behavior was simply not in Sun's DNA.

When you wrote, "So it required someone "bigger" to make that happen...someone who could write off the costs of the platform by funding it in creative new ways. Someone with a massive existing investment in Java. Someone with deep pockets and an army of the best developers in the business who love nothing more than a challenge. Someone like..."

I immediately thought Oracle, but then you put Google into the slot. Interesting.

Interesting writeup. As a software developer, my distaste for software patents is... extreme. As a business owner, I understand the reality of patents is that you need them or someone else will beat you over the head with them.

My fondest hope is that this lawsuit, with all it's embedded prior-art landmines, manages to put the stake in the heart of software patents. But, I suspect, that as patent owners themselves, Google wouldn't let that happen. If I had to put money on the outcome right now, I'd bet on Google coughing up license fees.

Charles, thanks for taking the time to write this article - very informative!

The most interesting development I am expecting is what position will IBM take. They are certainly not happy with Oracle taking control over Java and this lawsuit may be god-sent for them. Here is another outcome that is somewhat wishful thinking, but not that improbable:

1. Google and IBM join forces to invalidate the Java patents and in essence free the way for Dalvik and Harmony.

2. Google, IBM, and SAP start a broad coalition including other Java heavy-weights like VMWare and Red Hat to create a Next Gen (Java) VM, naturally Apache licensed, and vow to protect it against patent lawsuits.

3. Oracle finds itself cornered and decides to spin off Java and the JCP as an independent organization.

Why do you say 2 corporations? I see only one corporation screwing it's shareholders by starting this insanity. I see another doing whatever it can to protect its assets and their value from the other. I don't see 2 corporations to blame here.

Thanks for this very informative and detailed read. It would be great to see more coming out of that direction.

On "Why People Hate Java" ... I would like to add: this wasen't just a thing of the 90's, it was from my personal expierience also a thing of the 2000's thru 2005 and beyond. I am not taking about some obscure projects, but a very huge effort with very knowledgable people developing an entire technology and software stack. Java got a very bad name with that Software Vendor, not sure if "hate" would be the word for what many feel after that very frustrating and negative expirience with Java.

I am not sure what the alternativ is, but I no longer believe in write once run anywhere... something better is needed, also supporting Multicore architectures.

On possible outcomes of the Patent Litigation: it would be a very good outcome if the U.S. Patent Office got grilled over a slow fire for their very poor judgement in granting many of their patents relating to software. The entire process and all of its policy's need to come under severe political fire. Politicians supporting it also need to feel that heat. Hopefully at the end of that long field day, there will be a new and better situation.

In the real life the most what matters is $$$ so Oracle have to get back what they invest on Sun and Java even Java community disappear Oracle needs their money back and they could use Java just for inhouse and their customers as with abap and SAP. Also future version of Java Oracle can relicensing to proprietary license so that will be really bad and maybe some people will want to fork OpenJDK 6. So will be OpenJDK6 forks everywhere. Me I think this is a vicious circle already, Java is not an "open standard" is a proprietary platform of Oracle and they can do what ever they like with it of course.

Ellison is a good friend of Jobs. A few weeks after the news that Android overtook IPhone in sales Oracle files a lawsuit against Google. "In its complaint, Oracle does’t just demand monetary infringement damages, it’s seeking to have any code that is found to infringe upon Oracle’s copyrights “impounded and destroyed.”"See http://www.roughlydrafted.com/2010/08/14/how-oracle-might-kill-googles-android-and-software-patents-all-at-once/

At the time of the Sun acquisition, a friend of mine - an Oracle employee, no less - indicated that Larry doesn't give a hoot about Java or its developer community. Rather, he sees it as a fantastic leverage point with a number of Oracle's competitors. He specified two particular points:

1. Strategic non-promotion of Java in various markets, to support other Oracle initiatives - "Hey Microsoft, we'll put the brakes on Java for a while if you guys back off your sales efforts of Product X in Region Y." - or something to that effect.

and

2. IP suits. As referenced in this post, Sun just wasn't being aggressive with patent litigation and Oracle thinks that there's an opportunity here.

At the time, I accused this friend of "tinfoil hat" behavior in this case. Now, eight/nine months later, we're seeing #2 play out on a grand scale and I'm beginning to think he was right.

Like you say, the "death of Java" is probably not on the horizon. Oracle doesn't want to kill it off, but severely crippling its growth (for a while, at least) stands to make them a boatload of money in the short term - and all that at the expense of developers, users, etc.

@Bryan [Cantrill?]: In fact I am as much informed about the Sun/NetApp issue, I think, as any outsider can be. I have read every public commentary on the subject, from both the Sun and NetApp sides. I know that NetApp field its patent suit first, but that was not the first chapter of the dispute. My final impression was favorable to Sun, but this may be just my pro-Sun bias (in my previous comment here, i was just trying to be impartial). I would give more credit to Jonathan Schwartz's blog than to Dave Hitz's, although I should know better to not trust any CEO.

Read a lot of post around the blogs about Google being careless or naive about the possible threat from Java infringement suit like this one. I am guessing Google could have bought Sun, end of issue. They didn't. So, they and their lawyers must be pretty sure on how they can come out on this thing. Since

I think we should start to support Scala cause right now Scala I think its the only way to go to replace Java as language of choice on the JVM(ORacle VM) and we need Scala also support CLR/.Net, Parrot and LLVM. Imagine Scala running on all those VM's we can have an universal programming language, If JVM(Oracle VM) go out of business cause patents and copyright bullshit dont worry move Your Scala to the next VM as CLR.Net,Parrot or LLVM. I think this is a good time for Scala get the push to become mainstream and I always comment that Scala is complex but right now it have everything to become mainstream with closures and much more, yes still a complex language but C# and C++ and Haskell are also complex anyway. I think we should help to port Scala to LLVM and Parrot and improve the CLR/.Net port. And help to rewrite Eclipse in Scala with better support for Scala development ,Intellij have a good plugin for Scala development I think this could work out pretty good.

The good I see about Scala in this Oracle/Google isue is that is not bound to one particular VM, it can run on many VM's. Plus Scala is true Open Source as Python or Ruby or PHP etc.

Regarding RE38104 (the patent on replacing accesses with direct access) it sounds very similar to optimizations that were routinely used in Smalltalk VMs during the late 80's and the 1990's. e.g. Polymorphic Inline Caches for method lookup, and a very similar application of the same very basic (and very obvious) idea.

Regarding 6,910,205 (the mixing of bytecode and native instructions), and regarding your comment about J9 not having an interpreter:

This is incorrect. The J9 Java VM definitely has bytecode interpreters for dozens of platforms, and it has JIT and ahead-of-time compilers for only a subset of those platforms (x86/64 Windows and Linux for example). Many of J9's supported platforms are small embedded/mobile platforms where a JIT would be too costly. I know that a few years ago, even platforms which had the JIT would still interpret methods until they had been run a bunch of times, and only then JIT-compile them. Maybe newer versions of the system have a super-cheap JIT compile mode that they use instead of the interpreter for cold code; I don't know (though I do know that early versions of .NET were fully compiled with no interpreter--perhaps current versions also?)

I also know there has been at least one Java VM project in the past that had no interpreter: I think it was the Jalapeno VM, now known as Jikes RVM. IIRC, Jalapeno was written in Java and targeted at server applications, and used its JIT compiler to compile all code with instrumentation and without optimization, then went back and re-optimized the methods that were being run a lot.

How useful is the OpenJDK GPL2 license without the ability to use Oracle's patents?

OpenJDK is released under the GPL2 which doesn't specifically prevent encumbering patents ... Oracle has a number of patents it thinks are valid which are present in the OpenJDK code .. the use of those patents is only allowed if the result of any derivation passes Oracle's very expensive Java certification tests.

It would appear that releasing the code under the GPL2 license has very little benefit.

For example I'm very impressed with what's going on with the MLVM effort building on top of OpenJDK: http://openjdk.java.net/projects/mlvm/

While much of this isn't yet planned to be part of Java 1.7 I can see using the MLVM variant sooner (in a constrained server environment) for the performance advantages it can provide dynamic languages like JRuby.

Normally with the code being GPL2 licensed I would not have a problem even making my own fork and using it if the benefit was there (I also have no problem re-distributing any change I make under the GPL2) -- but I'd never get any fork of Java I used through the official Java certification process.

In this case it appears that Oracle would have the right to sue me for using MLVM for patent infringement.

If I'm understanding this right (and Oracle's argument holds up) people can ONLY legally use or derive from the GPL2 OpenJDK codebase if Oracle certifies the resulting work as "Java".

So if I fork the OpenJDK codebase, don't call it Java, and then use it Oracle can now sue me for patent infringement.

Thank-you very much for this lengthy and informative analysis. I really appreciate your insights. As an independent software developer who likes (or perhaps liked) to use Java, and who has used Oracle extensively in the past, I was never real comfortable about Oracle having Java. Don't get me wrong, I think very highly of Oracle the database; it is Oracle the company I have suspicions about. With Oracle taking this type of approach I am seriously re-evaluating my use of Java in the future and may move some of my existing Java stuff to another platform.

I do not have a problem with people making money for their work and ideas, after all that is what I do, but this type of nonsense bothers me and it also disturbs me to think I may be inadvertently supporting it. I clearly do not have any influence on large corporations like Oracle, Microsoft, Sun, Google, IBM, but I can vote with my brain and my development efforts. Looks like it is time to examine the Android platform...

What about clean room implementations of Java? I used to write set top box software and we chose Skelmir's JVM after bad experiences with Java ME. The reason for the switch was pretty simple - Skelmir was cheaper, faster and had a remarkably complete runtime support that was almost on par with Java 5 SE. All in a STB.

I had a quick look at US patent 6125447. I agree that the basic structure--mapping classes to protection domains to permission sets--seems exceedingly obvious. But I don't think that this is the only way one can implement a mechanism for deciding whether a particular security check can pass. Just to toss out a possibility, rather than calling

checkPermission(new RuntimePermission("exitVM"));

a modified SecurityManager.checkExit method might require some other object that is evidence of the permissibility of the operation, rather than using the origin of the class higher up on the call stack:

checkPermission(new RuntimePermission("exitVM"), grantingObject);

It might be more cumbersome, but I don't think it's a fundamental obstacle if someone wanted to work around this patent.

From my point of view, as a Java-hater, this law suit means a lot. This means Oracle is trying to milk Java for $$$ in destructive ways. This means Oracle might make the next version of the JDK for-pay. Suicide for Java? True. But it would be a goldmine as well -- large projects won't switch from Java, and if Oracle charges $1k a pop, many businesses will pay, and Oracle will make more money than it spent on Sun.

My guess is Google is just the first in a long line of Java-users Oracle will milk. I don't want to be the next one.

With all those wall of texts from the original poster and comments... I searched for the text 'NDK' and very surprisingly (for me) - none found.

http://developer.android.com/sdk/ndk/index.html

It's meant to be for more performance-critical application (ie: games~), but I don't see a reason for Google not seeing it as a "plan-B" kind of solution. All it needs is more libs and it's good to go :)

I just have a beef with this---Hell, even OpenJDK itself, the most complete and competitive OSS implementation of Java, could not be customized and shipped in binary-only form by hardware manufacturers and service providers due to it being GPL.---

According to my reading of the GPL, and, if not legal precedent, then existing standard practice, you could definitely ship customized, binary-only versions of OpenJDK.

The only thing that you do have to do is make the customized source available, on a website somewhere.

It is not that programmers hate Java. It is that Java hates certain programmers.

I am one of them they hated. For years I believed Sun's "real soon now" when it came to system integration and desktop support. For years Sun was dishonest, to say the least. They never ever meant it. Sun hated us desktop programmers with a vengeance. What, you are not doing EE? How dare you ask for USB support, HOW DARE!

Then it darned on me it would never happen and I went away from this Java mess. It took a while, I was suckered in, but one day it was just enough. One broken promise to many.

Sun reaped what they sow. When they came out with that FX thing I laugher off my behind. That should be it? Once again stiffing the desktop programmers they hate, targeting some ominous web jockey, artists instead. With some next generation Applet thing? Hahaha. With visual effects my users would severely beat me up for if I would ship something like this? Hahaha.

Sun, and especially Java, ending up in the hands of Oracle gives me great pleasure. Yeah, feel the pain you ex-Sun, now Oracle, Java jockeys. Feel how it is when your projects get destroyed. Suffer like we suffered at your hands.

This is the best post and analysis on the subject by a long way, so just wanted to say thank you for writing it.

I have been involved in similar lawsuits in the past, from the perspective of being part of a larger company suing a small company, vice-versa and with both patent and contract law.

What Oracle have filed so far is rather week. The usual practice is to 'kitchen sink' the initial complaint and overload it, and then during the course of the trial and negotiations narrow down to specific points of complain. Oracle might be taking an opposite approach here.

This will also take a long long time to sort out, which will not suit Google if manufacturers begin shying away from Android because of the certainty. On the other hand, if the manufacturers are comfortable with Google indemnifying them from any damages (who wouldn't be comfortable with them), then time will be on Google's side and they could spend years dragging this process out through the courts and in negotiations.

It will cost both sides a lot to fight and work through this, but the amounts will be minor compared to what it as stake (one project I worked for that was cancelled after 12 months we ended up spending 4-5x the total project funds on just our lawyers afterwards in a contract dispute with our manufacturer).

The other unfortunate side effect is that there will now be complete radio silence on this issue from people involved on both sides. I would like to know if the Android 'clean room' design and legal decisions were made at Google, or if they were made at Android Inc. prior to the acquisition by Google. If they were made prior to the acquisition, surely the Google legal team would have checked the VM and Java implementation and if it infringed on any IP prior to purchasing it as part of due diligence?

Hi, I think that there is one point missing, software patents are only valid in US? I think that there is no patents in the rest of the world, how does this affect? worst case would be "no android in usa" there is still lots of people around the world. Android is a great success.

Patents are state granted Monopolies for a limited time, nothing more...

Why should anyone grant a Cooperation of the size of Oracle a Monopoly for anything, much less if they are going to abuse it?

The issues around this question cannot be underestimated, especially because the U.S. Department of Justice has just sued Oracle for allegedly defrauding the US government of hundreds of millions of Dollars. So sure... Judges of the Federal Circuit are likely going to be very supportive of Oracle against this backdrop when thinking about granting them further monopoly power in any upcoming litigation.

Monopolies are actually illegal if the powers thus granted are abused...

Everybody remembers the long drawn out IBM anti-trust suit. My opinion is that Oracle, SAP and Microsoft would never have had a chance in this Marketplace without this anti-trust litigation against IBM, it is historically of utmost relevance in the Software Industry. There was also an anti-trust suit against AT&T which had quit a lot of influence on the way Unix developed.

Patent Law as such is a highly political and contentious issue, because it grants Monopolies. This is not natural law or common law, actually there is no real legal base for it, it is a mere policy based on politics. Just as there is not really such a thing as “Intellectual Property”, this is also total fiction based on government policy's.

I found it odd to find no mention of Netscape, especially as the work they did in the '95-'98 time period may invalidate quite a few of these patents. JAR files, JRI (which Sun co-opted and renamed JNI), the security model - all of these started at Netscape and were embraced and extended by Sun. My colleagues at Netscape seemed pretty resigned to Sun co-opting their ideas, and it wouldn't be surprising, given our "rising tide raises all boats" outlook that there were no patent apps filed on these, especially to any extent it might introduce friction with our good partner Sun. Netscape was also incredibly open about their innovations, so there are almost surely prior art documents out there.

One of those engineers, Jim Roskind (initials JAR), now works at Google.

I'm fairly confident Google will prevail, both in the court and absolutely in the court of developer opinion.

Thanks for a nice read.I agree prior art should be easy to prove in most cases. Just take the old MUD games in early 90'th which often utilized many things in those claims. With all MudDrivers out there released prior to the patents, they are bound to cover most claims with just that.

I think Google was timing very badly building Android on slow performance Java, especially the original Dalvik VM which - being interpreted - was much slower than Sun's VM, and much-much slower than native code.No surprise all bigger Android software projects are done on the native side mostly (Google recognized the misstep and launched NDK) so basically we're developing for Android like Linux, but with all the Java UI and JNI complexities.Hopefully Oracle will win and we'll have a more efficient Android without all the Java hassle.BTW, I think Oracle is right, Google stole its technology, however unefficient is on mobile platforms.

This is a great write up...the best I have seen so far dealing with this matter. I will definitely continue to check back for more.

I just wanted to drop my 2 cents on your comments about Java haters and what Java devs should do currently. Those that feared Java because of something like this IMO have a point. I'd think it would prove the point of the anti-Mono crowd but yet I still see people advocating a move to Mono in the middle of all of this. Anyway who's to say what other scheme Oracle may cook up or if they won't start cutting tools like Glassfish. And theres no way to hide the fact that they've offended the FOSS community which of course makes Java what it is. So couldn't it be seen as a gamble to continue on the Java path when you don't know if the community is going to be there with the same level of support.

However I think you're saying the same thing I have been thinking since last Friday. Maybe you mean not to abandon the Java language but pushing for an open and free Java in the form of Dalvik IS running for the hills in my opinion and I'm all for it. I don't want to see Java die at all. I just want to see Oracle's grip on it erased. What I'd really love to see if is resources could be thrown into Parrot. It seems like a great way for everyone to have the language they prefer, have it run in many places if not everywhere and be able to work with each others libraries no matter the language (or at least as much as possible).

Also The true is Oracle and Larry give a sh*t about Java and the community, Larry Ellison is a brilliant business man and he is only interested in what he knows to do is MONEY, Show me the Money that his mantra.

To last last Anonymous comment, Accept that Open Standard or what we thought Open Source Java is dead in the hands of Oracle.

You love Java the language and be ported to Parrot thats a good idea but as someone told me also who will port all the class libraries are huge. Also there is LLVM is awesome too.

I think for OSS, FOSS, and Java people disappointed about this move our only choices now are native development with C++ and Scripting languages as Python, Ruby and PHP.

Right now we need really the next big thing but we need something in the form of REAL open standard and open source not owned by a company with economic interests.

Mono have the same problem as Java is not 100% open, anytime M$ can go after Mono, .Net is Microsoft so forget it.

But human always know to get out of trouble, we will get our open standard platform and programming language of choice out of this huge mess of dinosaurs of the past as Sun, Microsoft, Google, Oracle and Apple did many years.

Thank you for your blog post. It is always great to have someone on the inside share their thoughts on an issue such as this. I will have to go through your extensive posts (and the great comments) in greater detail and add it to my Summaries of War: Oracle vs. Google:

From what you've presented, my reading is that the only patent that appears truly damaging to Android's future is the mixed-mode VM patent, together with the ongoing concern that the Dalvik VM is not actually substantially different from the Java VM.

Speaking as someone with no Android development experience, am I right in understanding that the development environment consists of: 1. the Java language 2. the Apache Harmony implementation of a java standard library 3. a portable bytecode which is very similar to the JVM's 4. a plugin to Eclipse which compiles Java source code to Google's bytecode 5. the Dalvik VM which executes the Google bytecode on the device

If so, couldn't Google preserve the existing development environment without any developer-level changes by: 1. getting rid of Dalvik and the associated bytecode 2. use a variant of the GWT tooling to convert the developer's Java language sources to a machine-product javascript 3. execute the resulting JS on the device using a form of the V8 compiler

That would seem to remove Oracle from the equation without causing undue pain to the existing developer group. There may be serious penalties to performance or security in this model, but I am not in a position to speculate on this, sorry.

Interesting thoughts, worth sharing. Anyway, it's all about money and power without added value. O thinks G owns too much claiming for shares gained from business A. Indeed, it is a crazy way, but this is somehow way of (re)distribution of financial (not intelectual!) values.Personally, I do not care G or O owns that sum. I'm sure all those guys have their bread buttered on both sides. But now, after this silly idea came out from some head, there is chance to ask for either side gaining profit on this crazy issue let that sum of money go on to some party that do not have so much power to ask for, but has real needs instead! Distribution? Be it. But both those bigs should offer and give not ask for more!

Earning money has online never been this easy and transparent. You would find great tips on how to make that dream amount every month. So go ahead and click here for more details and open floodgates to your online income. All the best.

That idea about the Java to Javascript on V8 sounds really good. But isn't V8 also a mixed mode type of VM? I thought I read that maybe even somewhere in this post.

It would seriously be damaging to Oracle if Google found a way to come out and say we're going to settle and then we're going to throw out Java period and then asked the developer community what they wanted in both an Android API and general high level language system. I think anyone that could would leave Oracle's platform immediately. I guess I can dream.

For all those in the dump java for anything else camp, there is absolutely no way that Google will replace their core java investments as a result of this law suit. The most reasonable response is to either cross license or pay a fee to Oracle.

Part of the draw of Android is that all the massive collection of Java libraries and languages out there generally work without modification. This is not possible with GWT, which only supports source-to-source translation and on a very limited scale. Android would not be as attractive or successful if it were not possible to build "plain old Java applications".

According to [ http://code.google.com/apis/v8/design.html ], the V8 engine purely compiles to native code, so the mixed-mode patent is not applicable.

@Charles: w/r/t limitations of GWT in converting naturally-occurring Java to JS: is this a fundamental problem with the differences between the languages, or just inadequacies in the current implementation of GWT?

Or, is the problem that some desirable class libraries are only available in bytecode form, which is not accessible to GWT? Even in that case, wouldn't the 'disassembled' source of the libraries likely be simpler for GWT to process than the original source code?

"...everybody needs to take a deep breath and let things progress as they should..."

No need to jump to conclusions or get out on the ledge of a tall building somewhere. Oracle, right or wrong, is making a strategic move. We may not know what their strategy is just yet, but this is their fight. We'll see how it plays out and in the meantime keep doing what we do.

In the "What Might Happen?" you didn't consider the option of a Google Countersuit on other grounds. Although unlikely, it's still more likely than your Nuclear Option. In this Google Countersuit scenario, Google's lawyers find some Google's patents Oracle is violating and sue for damage. It will then end up in "Nothing at All" or "Cross License Deal" with undisclosed terms (is Google paying Oracle or vice-versa?)

One other thought, I did not see it, so if someone else posted it, sorry.

Another possible outcome:

Oracle has done a very poor job with acquired technologies unless they have been directly integrated into the database core. So, I have to ask, why do they want Java to start with? Especially the desktop stuff that they really have no expertise with. So...

Oracle rattle the sabres long enough, and gets Google to buy the desktop Java technologies from them as a way to settle the lawsuit and have undisputed ownership of their underlying technologies (of debate that they can make this argument, but that does not mean it wasn't their original intention), and Oracle gets to unload an asset they really do not know how to revive and make money from to offset what they paid for Sun.

I'm sure, oracle can do much more with some of Sun's security patents, that's their strong suit anyway.

<< The UCSD p-System used to allow mixed mode execution. You could mark sections of code that could later be compiled to native code when deployed on a physical machine. >>

Are there more specifics and sources for that one?

All the groudbreaking conceptual and inventive work for VM's, Emulators, incremental compilers was pretty much done in the 70's already, thats how old these techniques are. Nothing new here its all prior-art. Some of the more derivative stuff traces back to Xerox Parc, Smalltalk.

I hope Google see's this thru, they could probably recover their costs just by selling the movie rights to this story.

Google bought Android which most people don't seem to know. More details about that as well as the sale of Dalvik before and after would be very useful.

The problem with Android app development is developers mostly seem to do it for fun because there is no clear profit path yet. This does not help that situation at all.

People like Google/Android but hardly anyone really likes Oracle. So you see a lot of knee jerk reactions because people don't want Android messed with. But I think Oracle has a fiduciary duty to their shareholders to have these lawsuits. Thats life in the big city.

Google is not your firend and never has been. if you were not aware of that before then you should be now with their scheming with Verizon

Patents are rarely overturned on obviousness. It's so rare it's not even worth looking at normally, consider for example 'one click purchase.'

Prior art is usually not easy to find either, and you have to look at the claims and find something that matches them exactly. The claims are all that matter. Andrew Tridgell made a presentation on how programmers can deal with patents from a legal perspective here: http://yro.slashdot.org/story/10/03/24/022209/Tridgell-Recommends-Reading-Software-Patents

@headius: you really try to be neutral on that matter, and this post is really the most extensive and fair account I read about that matter.

However, even if I also think that software patents only work to prevent any innovation, I think that a few things must be stated here (my only POV of course):

1) On a moral point of view, regardless of patents, google does not stand on high grounds at all. They took a Java Open Source implementation that was free and happened to be on an Apache licence, + the Dalvik trick, because they wanted nothing to do with Sun, they even did not warn them on what they would do. I presume Sun execs knew of this as eveyone. They wanted to save money, and they wanted to have total control. And they succeeded, even in the view of peole. Even now everyone praise Android to be a huge leap foward in the Java world,completely forgetting that none of this would have happened i Sun had not invest lots of lots of money and time in the Java platform.

2) This move from Google may have precipitated the end of Sun. JavaME licences one were one of the only profits Sun could make with Java, Sun could gain nohing with Android because google made it that they had no part in it at all, so their propective future profits were very dim

3) Had Sun been bought by IBM qnd bnot Oracle, all would probably have ended the same way. Harmony was mainly an IBM effort to gain control over the Java future, shattered by the fact that it became LGPL.

4) It would have been very simple for google to work with Sun on the Java part in Android, but they thought (like for a lot of other matters), that they could do as they pleased and that they could just take the ideas and the code and dont give back anything to anybody. At the end they have this huge problem because they were too much greedy and were alright to take but not to give anything in return.

5) For us Java users and developers, using a different bytecode and not base the code on the reference implementation is really a big hassle. As usual, and ;aybe as for Linux zere they did the same thing, there is no real way to the main JavaSE line and the Android fork of Harmony to align sometime in the future. This is a waste of money and a waste of time.

So qt the end, even if I really thing software patents are not a good thing I still thing that Google deserve what happens now.

Thanks for a decent review of this issue. As an Oracle employee and a programmer, this wasn't the best news I've ever seen. I still can't believe we bought Sun. I wish your blog post had been the focus on Slashdot instead of the drivel that was used as the article basis. One detail that I've seen is that there were a lot of Sun "defectors" over to Google. Conventional wisdom is someone violated an NDA and provided technique from existing, proprietary code. Which, if even remotely true, means the code monkeys out there (hey, guys) really can leave a footprint on the moon of a boardroom.

The Open Invention Network (OIN) and its allies now try to create confusion about whether the fact that Sun never signed the OIN patent agreement (which Oracle and Google did sign) plays a role. I've commented on this matter and other OIN-related aspects of the dispute on my blog. The bottom line is that Oracle's acquisition of Sun made Sun's patents part of the OIN pool, but it doesn't help Google because Dalvik doesn't fall under the OIN's scope.

here's a sketch of a fairness argument supporting Oracle's suit. first, Sun spent a lot of money developing Java. A lot. Sun struck a balanced approach for those interested in using Java: share everything you derive from Java, or take a license. Google imitated or cloned much of Java, but didnt' take a license, and didn't make their code available as opensource. Sun-Oracle sues Google for taking some of the benefit of Sun's investment in Java without paying. Google in effect jumped the turnstyle.

When you inject product into the marketplace, you have to consider fairness to competitors. Legal realities aside, Google, a profitable company, should have just licensed Java (EE?) like so many other players in the marketplace. If they wanted a homemade "hybrid" JVM that is compatible yet built in ways google prefers, that's fine, but take a license from Sun-Oracle, as many others have. Java didn't appear out of thin air, and it is undeniable that there are some fine unobvious innovations introduced by Sun (why is Java successfuly anyway? because it's wholly lacking in novelty?)

Google did not argue against software patents in re Bilski. Here's an analysis of the brief Google submitted to the US Supreme Court jointly with some financial services companies. It stops far short of arguing that software shouldn't be patentable. It just says some software patents are too abstract, some are too "conventional", but of course, Google's own patents would not be affected by what they proposed. Not at all.

Nice read.I would like to know your thoughts on the where Java(in general, non-android) is headed.Not just from the Oracle takeover perspective. Are we going to see a lot of added cost by some sort of new licenses from Oracle? Technically, Java has already stagnated a lot. Will this improve? Oracle is not a company that is known for innovations. Is Java's future bright?I think you should have an article on this.

Somewhat off topic, I was very interested in your remarks ecapsulated by the quote:

"You see, many of us at Sun had been actively trying to change the perception of the platform from that of a corporate, enterprisey, closed world to that of a great VM with a great OSS ecosystem and an open-source reference implementation"

I have long, and increasingly, thought that the value of the JVM as a platform has been overlooked (not by you and the JRuby team)

As we continue to see advances (and predictions thereof) in server hardware trends and distributed computing models it seems like the JVM is an ever better fit for distributed systems with large physical memories, CMP, faster interconnect, and distributed computation ...

It seems as though we really need JDK 7 for both dynamic language support in the JVM and perhaps also for language level features such as closures.

How do you think the JVM compares to Rubinus or V8 or other technologies such as LLVM?

Larry: I won't go into great detail, but none of the VMs you list come anywhere near to current JVMs for robustness of GC, optimization, threading and more. And LLVM is really just a compiler framework (albeit a very nice one). I'm sure the JVM is going to remain the strongest VM option for many years to come, and I hope I'm able to help keep it moving forward.

Also, JRuby has managed to do great things for Ruby without VM-level dynlang support. We're looking forward to Java 7 and invokedynamic, but I know we can do a lot to improve JRuby on Java 6 too.