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.

Off-the-shelf components still need attention

Typical advice for the builder of a system is often "when possible, use commercial products". The idea is that a commercial product is more stable, better maintained, and cheaper in the long run.

Today, that advice might be amended to "use commercial or open source products". The idea is to use a large, ready-made component to do the work, rather than write your own.

For some tasks, a commercial product does make sense. It's better to use the commercial (or open source) compilers for C#, Java, and C++ programs that to write your own compilers. It's better to use the commercial (or open source) word processors and spreadsheets.

Using off-the-shelf applications is a pretty easy decision.

Assembling systems with commercial (or open source) products is a bit trickier.

The issue is dependencies. When building a system, your system becomes dependent on the off-the-shelf components. It also becomes dependent on any external web services.

For some reason, we tend to think of off-the-shelf components (or external web services) as long-lasting. We tend to think that they will endure forever. Possibly because we want to forget about them, to use them like electricity or water -- something that is always available.

Commercial products do not live forever. Popular products such as WordPerfect, Lotus Notes, and Windows XP have all been discontinued. If you build a system on a commercial product and it (the commercial product) goes away, what happens to your system?

Web services do not live forever. Google recently terminated its RSS Reader. Other web services have been born, lived, and died. If you build your system on a web service and it (the web service) goes away, what happens to your system?

Product management is about many things, and one of them is dependency management. A responsible product manager knows about the components used within the product (or has people who know). A responsible product manager keeps tabs on those components (or has people who keep tabs). A responsible product manager has a plan for alternative components, should the current ones be discontinued.

Leveraging off-the-shelf products is a reasonable tactic for system design. It can save time and allow your people to work on the critical, proprietary, custom components that are needed to complete the system. But those off-the-shelf components still require a watchful eye and planning; they do not alleviate you of your duties. They can fail, they can be discontinued, and they can break on new versions of the operating system (yet another off-the-shelf component, and another dependency).

Build you system. Rebuild your legacy system. Use off-the-shelf components when they make sense. Use external web services when they make sense.

Stay aware of those components and stay aware of their status in the market. Be prepared for change.