“Various nifty functions”

Further to the code-literate judge in Oracle v Google, via Groklaw we now have his ruling that the Java APIs are not copyrightable.

It’s an exceptionally clear piece of work and a good introduction to the subject. I certainly couldn’t have written a better technical summary, although I’m sure there are bits that a non-programmer would still struggle with—for example, the judge uses the term “subroutine” without explanation.

I like the jaunty language:

After Java’s introduction in 1996, Sun [...] wrote hundreds more programs to carry out various nifty functions

And he is certainly decisive. The section describing the code at issue (rangeCheck) is introduced thus:

Oracle has made much of nine lines of code that crept into both Android and Java. This circumstance is so innocuous and overblown by Oracle that the actual facts, as found herein by the judge, will be set forth below for the benefit of the court of appeals.

And in the closing remark,

[It] is important to step back and take in the breadth of Oracle’s claim. Of the 166 Java packages, 129 were not violated in any way. Of the 37 accused, 97 percent of the Android lines were new from Google and the remaining three percent were freely replicable under the merger and names doctrines. Oracle must resort, therefore, to claiming that it owns, by copyright, the exclusive right to any and all possible implementations of the taxonomy-like command structure for the 166 packages and/or any subpart thereof — even though it copyrighted only one implementation. To accept Oracle’s claim would be to allow anyone to copyright one version of code to carry out a system of commands and thereby bar all others from writing their own different versions to carry out all or part of the same commands. No holding has ever endorsed such a sweeping proposition.

As an aside, nice to see our old friend Sega v Accolade cited again. I haven’t read all that many US legal opinions on software copyright, but I think pretty much all the ones I have seen have referred to Sega v Accolade.

You can read the whole thing on Groklaw.

Speaking of learning to code

Dialogue in Oracle vs Google, between Judge Alsup and Oracle’s lead counsel David Boies:

Judge: We heard the testimony of Mr. Bloch. I couldn’t have told you the first thing about Java before this problem. I have done, and still do, a significant amount of programming in other languages. I’ve written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There’s no way you could say that was speeding them along to the marketplace. You’re one of the best lawyers in America, how could you even make that kind of argument?

Oracle: I want to come back to rangeCheck.

Judge: rangeCheck! All it does is make sure the numbers you’re inputting are within a range, and gives them some sort of exceptional treatment.

(via Groklaw)

Spare us humans from XML

XML appeared in 1996, was refined during 1997, and was standardised in 1998.

I remember a lot of excitement about it at the time, from managers who imagined it would solve all their data portability problems. I was conscious of some of this enthusiasm before I really looked at the format.

When I did, I thought


But it wasn’t as bad as all that. The idea of XML was to standardise the lexical layer for a file format, helping to cut down on the programmer’s natural tendency to just bodge something up when saving and worry about loading later.

It worked, and it made and still makes a tolerable format for all kinds of things—within limits. Of course it’s horribly verbose and slow to parse, but hey, it compresses well. And you still don’t get reliable interchange unless you have a known storage structure on both sides, something a series of increasingly complex helper standards evolved atop XML to help you with.

One thing XML never was, though, was nice for humans to read.

At the time this seemed OK, because it obviously wasn’t intended to be for humans. We humans would never be editing it. We’d only ever be looking at it through filters and lenses and programs that knew what it really meant. We’d never actually have to see the format.

Fifteen years later, here I am sitting looking at

        <isset property="tested.project.dir" />
        <property name="tested.project.absolute.dir" location="${tested.project.dir}" />
        <xpath input="${tested.project.absolute.dir}/AndroidManifest.xml"
            expression="/manifest/@package" output="tested.manifest.package" />
                <isset property="tested.manifest.package" />

Oof! Enough of that.  But that’s Android development: of course that’s for robots.

Windows Phone is for people, though. How about:

    <shell:ApplicationBar Opacity="0">
        <shell:ApplicationBarIconButton Text="previous" IsEnabled="False"
            IconUri="/Shared/Images/appbar.left.png" Click="PreviousButton_Click"/>
        <shell:ApplicationBarIconButton Text="page jump"
            IconUri="/Images/appbar.book.png" Click="JumpButton_Click"/>
        <shell:ApplicationBarIconButton Text="settings" IconUri=


These aren’t pathological examples that I’m having to grub around the internals of some graphical environment in order to find. That last one, for example, is copied verbatim from a beginners’ programming book for Windows Phone 7.

I’d far, far rather see developers use XML than go back to rolling completely unique file formats for every application. But surely by now there are enough widely-supported data representation languages—formats that simplify the presentation by standardising object relationships as well as lexical details, such as JSON or RDF/Turtle—to cover the majority of situations in which humans may end up having to edit something?

Operating system updates

Google have released a version of their Chrome web browser for Android, and it seems to be rather good—but it only runs on the very latest version of Android, version 4. Which is a bit of an annoyance, because hardly anybody has that version.

Glancing at the 12 most popular Android phones on the Expansys site, I can see only two—the two variants of Google’s Galaxy Nexus—supplied with Android 4. That’ll change, but in the mean time there hasn’t been much of a rush to provide updates for older phones.

I’m generally ambivalent about operating system updates. I believe that both phones and PCs are bought on the basis of the way they look and work at the time, not in the expectation that updates will change anything significant.

As a long-term Linux user I’m all too familiar with the concept of the Ubuntu update that breaks everything, but I think my uncertainty about the wisdom of updates is common among people using most kinds of computer.

I updated my Galaxy Tab from Android 2.2 to 2.3: it improved battery life a bit, stopped cut and paste working in some applications, and provided no obvious interface improvements—not a big net positive. I know iPhone users who complain about Apple persuading them to install updates that slow down their previously perfectly good phones. My wife updated her WP7 phone recently, grumbling about the amount of time and laptop disc space used by the installer, only to find the update made no detectable change at all. OS/X 10.7 had a decidedly mixed response from users of earlier versions.

Why would anyone want to update anyway?

What drives updates is application support. The only time most users will start hunting for an operating system update—as opposed to installing one that’s thrust into their face by the device itself—is when they find they can’t run applications they care about because their OS is too old.

Even then, they’ll probably resent having to update to do it.

I don’t really care about Android 4 on my own device, which is fortunate because it doesn’t appear to be available. But I would like to try out Chrome. (There are several OK browsers for Android, but no really good ones—and the one I like best in principle, Firefox, itself gets less stable for me with every update.)

I wonder how fundamental Chrome’s dependency on Android 4 really is. Perhaps the only reason it didn’t exist before was that it needed some quite basic OS support that earlier versions couldn’t provide.

Or perhaps the dependency is seen as a serendipitous one, and the release of Chrome as a way to encourage users like me, and phone manufacturers, to update as soon as possible.