Oracle's Java Headaches

Oracle, after its purchase of Sun Microsystems, has found that it owns a number of things including MySQL and Java. MySQL presents obvious problems, as it competes with Oracle's big, expensive database. But Java also presents problems.

Oracle has two challenges with Java. The first (and obvious) challenge is money. Specifically, how does Oracle "monetize" Java? Extracting money from programming languages is possible; Microsoft succeeded with BASIC, Visual Basic, and C#. (Although the last was really profitable through Visual Studio, not the language itself.)

Extracting money from Java remains elusive. Oracle's latest attempt to sue Google has failed. It was a "whale" strategy, designed to obtain a large amount from a single entity. With the loss in court, will Oracle look for a different strategy, perhaps one that looks for fees from more (and smaller) entities?

Revenue is one headache for Oracle. A second headache exists, one that is less obvious, and may show up in the expense, not revenue column.

Oracle's history has been with SQL, a language designed in the 1970s for accessing data. As a programming language, it has been remarkably stable, with only a few changes since its inception. In contrast, programming languages like Visual Basic, C, C++, and C# have seen frequent and sometimes significant changes. Java, too, has seen changes, and it has the "JCP", the Java Community Process, which allows just about anyone to recommend changes to the Java language.

This second challenge is more subtle, and possibly larger, for Oracle. After decades of a stable, unchanging language, is it capable of managing a fast-moving programming language? After decades of maintaining the Oracle database (which I'm sure had lots of internal changes and lots of changes requested by Oracle's relatively few high-paying customers) is Oracle ready to maintain a product used by "the rest of us"?

This is the bigger issue for Oracle. Maintaining the Java code base, adapting it to new platforms, adding features to the language, and putting up with all of the pesky requests from pipsqueaks (highly opinionated pipsqueaks, some of us are) is going to be expensive.

So Oracle is in a squeeze. On one side, Java has no significant revenue. On the other, it has expenses (possibly higher than the expenses for the Oracle database). How will Oracle navigate these straights?

I see a few possible ways forward:

Find a funding mechanism Perhaps licenses, perhaps advertising. Perhaps a version of Java for the Internet of Things.

Tie Java to the Oracle database Make Oracle the easiest database to use in Java.

Keep Java but stop development A fast was to reduce costs, but also a fast way to anger users. (On the other hand, Oracle seems to care little about user opinion.)

Spin off Java If Java doesn't fit into Oracle's strategy, why bother to keep it?

The last is an interesting idea. IBM might be interested in Java. Google almost certainly would. Microsoft probably not so much -- except perhaps to prevent Google from acquiring it.

Ever-increasing maintenance costs

We like to think that a program, once written, tested, and deployed, is "finished". We like to think that it is a completed work, something we can leave in place and forget about.

But programs are not static elements. The maintenance costs of a given program tend to increase over time.

Now, programs often change over time. Once version 1.0 has been released, we often start working on version 1.1 (or 1.2, or 2.0, depending on one's ideas towards version numbers). Those changes usually increase the size and complexity of the code, which means an increase in maintenance expense. More code costs more to maintain.

Yet even with no changes, maintenance costs increase. At first glance, this seems wrong. Why would cost increase when the code remains unchanged?

Compilers and languages change over time. New versions of compilers implement new versions of languages. Sometimes, these changes cause existing code to break.

A subtler change occurs when new features are added to a language. The C++ language was modified to include the STL. Microsoft modified C# to include the LINC functions. Sun and Oracle have enhanced Java.

While enhancements do not (usually) break existing code, they do change the core knowledge used by programmers. Today, it is a poor C++ programmer who does not use the STL, and a poor C# programmer who avoids LINC. The enhancements become part of the "working set of knowledge".

Yet those old programs, the ones we think are "finished", may be old enough to pre-date the enhancements. When maintained, programmers have to think back to "the old days" and remember the old-fashioned methods for accomplishing certain tasks. A programmer may be able to use the new language features to add functionality to a program, but he must be able to read the old-style code.

When the idioms of old-style code are no longer popular, then fewer programmers understand them. Thus, to successfully maintain an older program, you as project manager must find a programmer who does understand the old-style code, or you must allow a less-experienced programmer time to learn the old idioms. That's the increase to your maintenance costs: more money for a scarce resource, or more time for an available resource.

No program stays "modern", at least not without constant upkeep. We build programs on top of compilers, languages, libraries, operating systems, databases, and communication protocols. All of these "platforms" change, regardless of our business.

The idea that a program is "finished" is a false one. Programs live in an ocean of change, and they must evolve and adapt in that ocean.