ONJava.com -- The Independent Source for Enterprise Java
oreilly.comSafari Books Online.Conferences.


AddThis Social Bookmark Button

Outsourcing Java SE

by Daniel H. Steinberg

I sat in my office thumbing through the file drawer labeled "dead languages." I'd been debating for the better part of an hour whether or not to toss the Java desktop folder into the drawer with the others when the door burst open. A fat character dressed in white up to his red nose nodded his black and pointy head at me. He quickly saw what I was doing and grabbed the folder out of my hands.

"That's a little premature," said my visitor. "Java isn't dead. It runs on two billion devices."

"Two billion?" I laughed.

"Well," he answered, "that's what the official marketing says."

I looked at this shapeless blob before me and asked if he wanted to save Java.

"Save Java," he snorted. If he had eyes they would be rolling back in his head to express his disgust with where he thought I was going. "Surely, you aren't one of those nuts who thinks the only way to save Java is to open source it?"

"No," I replied, "I am not suggesting you open source Java. I'm suggesting you out source it."

"Preposterous," he said. "There is Java coursing through the internet."

"Oh," I nodded, "I'm not suggesting that we outsource all of it. You guys are doing OK with Micro and Enterprise, it's the Desktop that needs love and attention."

I told my guest that we'd have to begin at the beginning.

Before the OS in Java Meant Open Source

In the beginning there was no EE, ME, or SE. There was only Java. Those were the days when automatic garbage collection was such a novelty that Sun drew our attention to it when it was happening. The entire program would come to a halt while a bulldozer animation showed us that garbage was being collected. Right there, that should have told us we were in trouble. Why would an operating system emphasize the time it was spending on housekeeping tasks? This was a feature designed to entertain programmers and not end users.

"Wait a minute," the visitor interrupted, "did you say Operating System?"

Sure, Java was a stealth operating system. Developers were told that they didn't have to write applications that were OS-specific. Instead of writing a Windows app or a Mac app, they could write a Java app and it would run on all of these platforms. In fact, without the "Write Once Run Anywhere" value proposition, Java on the desktop meant nothing.

You can see it happening again. It's why Eclipse worries Sun so much. Where Sun told developers to write to Java not to the OS, IBM told people to write rich client applications that sat on the Eclipse platform/framework and not to write to Swing. Sun slid Java as a layer on top of the operating system and IBM, or now the Eclipse Foundation, slid Eclipse on top of Java.

In order for Java to succeed, end users would need to know when they were running a Java application. They did. But not in a good way. If you remember back in the 1.02 days, Java applications were slow and ugly. The cross-platform goals were ridiculed. The applications were equally ugly on many platforms, and Java applications could not contain the full feature set of any of the host platforms because it had to run the same on all of them. It had the least of all worlds.

The 747 Cockpit

The mascot's nose grew even redder. "You're dwelling in the past," he shouted. "This all happened ten years ago. Java 1.02? Look at where we've come since then. We've had Swing for darn near a decade. And performance has improved. Most people can't tell the difference between a Swing app and a native app."

Ahhh Swing. You almost feel sorry for Sun. The performance issues have, for the most part, been addressed. As for looks, they heard the objections that people had to AWT and they created a framework in which applications can look nicer. With Swing, applications can look as nice as native applications, if only developers could figure out how to code them up.

I can sum up people's frustration in three words: Grid, Bag, and Layout. Swing was too hard. When people's apps wouldn't perform as they should the Sun engineers would say, rightly, that's because you're executing in the wrong thread. Ken Arnold wrote about the conceptual overhead of writing with Swing when he counted up the number of methods available to him in a simple JButton. Sun's repeated response was that Swing was like the cockpit of a 747. You could do anything with it, and so the controls were necessarily confusing.

In the first iteration of the GUI, Sun ignored the user experience. In this second iteration, the beginning of what would be called Java 2, Sun provided developers with everything they would need to deliver an attractive, performant application. They just didn't make it easy. I would argue that in both cases the cause is the same and still exists today: Sun does not build end-user applications. They are not consuming their APIs.

Looking Elsewhere

Microsoft and Apple are both in the business of creating and selling operating systems. But both companies also make applications that sit on top of these operating systems. No one knows more about programming on the Windows platform than the Office team. What a great source for feedback.

But it's more than just that. Features added at the OS level aren't just abstract technologies. The client applications written by Microsoft and Apple show developers how best to integrate features into their own applications. Apple's Bonjour technology would not have caught on so quickly or so widely if it hadn't been integrated into their own iChat, iPhoto, and iTunes applications. In fact, iTunes brought Bonjour to the Windows platform and was proof that it could work well on that platform too.

A technological feature doesn't mean a thing to an end user. The power it brings to an application does matter.

Having a consumer products division strengthens the operating system in five important ways. 1) It provides feedback on the OS and its implementation. 2) It uncovers features that should be added to the OS. 3) It highlights the power of the OS. 4) It challenges other companies to innovate on top of the platform as well. 5) End users will pay for good applications.

Imagine cool, attractive applications written in Java that provide a revenue stream that encourages Sun to put more resources into really improving Java. As Chris Adamson has argued, the Apple iApps could have been written in Java. As the Aerith project shows, you can achieve much of the Apple look and feel in a 100-percent-Java application.

Pages: 1, 2

Next Pagearrow