The Oracle v Google Trial IProgrammer Reads the Patents
Written by Mike James   
Friday, 11 May 2012
Article Index
The Oracle v Google Trial IProgrammer Reads the Patents
Convoluted and contentless

There are two important patents that are being asserted by Oracle in its lawsuit against Google's Android. What do these patents actually cover - it must be something really clever and deserving of patent protection...

Patents are not the easiest reading in the world. They follow a stylized format that isn't particularly designed to convey the ideas that are important in the patent and they use a form of words that attempts to make the ideas seem as clever and innovative as they can be. In short, a patent is a press release in legalese.

After much group discussion about the Oracle/Google trial, I suddenly realized that none of my colleagues had read the patents - neither had I and this meant we were all talking about something we didn't know anything about. So I decided to find out what the patents really cover by reading them from cover to cover - the results were interesting.

The first patent is perhaps the more interesting - patent 6,061,520 titled:

Method and system for performing static initialization

If you have been programming for any time you will already begin to suspect that there might not be much to this idea because there isn't much to static initialization - but give it the benefit of the doubt for a moment.

For the record, static initialization is usually taken to mean initializing a data structure that is of known form before the program runs. For example, if you know that an array has ten elements and they are all integers, then this can be set up before the program runs. A dynamic data structure is one that is defined as the program runs and so cannot be initialized beforehand. For example, an integer array that has a variable number of elements can't be set up before the program runs.

Java is a language that is compiled to byte code, which is the machine language of a virtual machine VM. To run a Java program you first compile it to byte code and then you submit it to the VM to run. In practice, there is an intermediate step - the class loader gathers together the byte code of each class in your program before it is submitted to the VM.

The problem that this "invention" attempts to overcome is very easy to explain. There are byte code instructions to initialize various primitive data types, e.g. integers, but it doesn't have an instruction that initializes a static array. As a result when you write something like:

static int myArray[]={1,2,3,4};

the compiler generates a small chunk of code, essentially an unrolled for loop, which initializes each element of the array, something like:

myArray[0]=1;
myArray[1]=2;
myArray[2]=3;
myArray[3]=4;

It actually uses a stack to assemble the data, but this doesn't alter the idea. This initialization code is added to the class initialization method or <clint>.

The problem is that this code takes a lot of storage space in addition to the array it creates. I would also have thought that it was not the fastest way to achieve the initialization, but this isn't a problem addressed by the patent.

Other languages have various ways of making static initialization which are both memory- and time-efficient. For example, any fully compiled language simply stores the static array as part of the binary file and the array is automatically initialized when the program is loaded.

For a language that runs on a VM, the most obvious solution is to augment the VM's byte code to include an instruction that initializes any static array and then makes the compiler generate the new instruction.

So, for example, the compiler would convert

static int myArray[]={1,2,3,4};

into something like:

Tag             Type Size Data
Constant Array T_INT  4   1 2 3 4

Where the symbols like T_INT are converted to codes that mean the same thing. The saving in memory is simply due to the compact coding and the way that the VM converts the simple new op code into the array without needing additional byte code to tell it how to do it.

The patent proposes this idea but with a twist.

Instead of modifying the compiler, the modification is made to the class loader. It scans the byte code looking for <clint> methods and then scans these to see if it can spot an array initialization. If it can, it changes the <clint> method to the new "expression" or the new byte code in a more obvious jargon.

patent1

A figure from the patent showing the structure of a Java system to an alien who has never encountered a computer before.

 

The VM still has to be modified to understand the new byte code but at least you have the advantage that the compiler is unchanged and the class loader and VM can be fed with perfectly standard byte code files.This maintains Java's "compile once, run anywhere" properties.

The disadvantage is that, if the <clint> method contains any byte codes which indicate that it is doing more than just initializing an array, no optimization is performed. You can see the proposed algorithm below:

patent12

Well that's it.

That's the patentable idea.

What it is exactly about this idea that is more novel than any idea that a typical programmer has to create in solving any problem or optimizing an existing solution? I'm not at all sure.

Is the novelty getting the class loader to do the work of the compiler?

If it is then most programmers would call that a "kludge" and hope to do better at the next version.

Code rewriting is a fairly obvious optimization technique that most would implement without seeking to patent any new magic involved in the process.

At the end of reading the first patent my opinion is that if this is patentable then we all could be filing about 10 patents a week, if not more.



Last Updated ( Saturday, 12 May 2012 )