ONJava.com    
 Published on ONJava.com (http://www.onjava.com/)
 See this if you're having trouble printing code examples


Outsourcing Java SE

by Daniel H. Steinberg
07/12/2006

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.

Now What?

Sun seems to understand the Enterprise market but they don't seem to have a clue about the desktop market. They don't seem to understand that the landscape has changed in the past ten years. You can assume access to Java now in a way that you couldn't before. Given that the Java runtime is widely available, the question becomes, "Now what?"

With Enterprise, Sun's target customer is not you or me accessing a web application through our browsers. Their client is the company coding up the application that we will interact with. This is Sun's sweet spot. They know how to work with developers.

They don't know how to talk to the end user. Look at Project Looking Glass. When the Sun engineer showed up at our local Java User Group to demonstrate it, Sun had sent him out with a Linux box that couldn't support it. He had to describe to us what we would have seen if it had been running on a box capable enough. For developers, we were OK. We nodded our heads and understood what the software should have done. But if there were a chain of Java stores, no customer would have sat still for that non-demo.

It is not within Sun's ability set to change. The company culture is built around geeks talking to geeks. When they try to create something cute for end users, they end up missing the boat and creating a cute graphic of a bulldozer cleaning up the heap, or an animation of Duke turning somersaults.

My visitor winced. He still hadn't lived that one down.

Sun needs to outsource Java SE to someone equipped to make it great. Someone who understands code well enough to create their own implementation of Java. Someone who understands the desktop. Someone who values innovative technology and loves to incorporate open source projects as well. Someone who knows how to talk to end users. Sun needs to outsource Java SE to Apple.

No Way

Sun has let great projects die before they have ceded control to others, so it's not very likely. After acquiring the Watson project (think widgets before Dashboard was a twinkle in Apple's eye), Sun decided they couldn't commit resources to it. Rather than open source it and let others develop it, Sun buried it and let it die.

If Sun were a child, I would have put it in time out for a good long time. This was one of those applications that could have highlighted Java. It was Ajax before Ajax. It could have meant much more to Sun and Java than just an application for viewing the weather or checking sports scores. It could have been a platform that brought widget developers to Java.

Sun should have dumped real money into the Watson project. They should have built up the core platform. They should have created screencasts on how to build widgets. They should have created a NetBeans plugin for widget development. They should have run a contest with high-profile awards for the best widgets.

"Don't blow your top," my visitor said. "We didn't see the possibilities of the Watson project."

But that's exactly the point. How many things have Sun missed because they didn't see the possibilities? If Apple were running Java, the media frameworks would not be in disrepair. With podcasting as popular as it is, Sun could have funded work on the media frameworks by building an app for creating podcasts or for aggregating and viewing them in some different and compelling way.

My blood pressure had risen much too high. But I wasn't finished. When Sun creates desktop APIs, why are the first two platforms targeted and released Solaris and Linux? If you are creating desktop technology, shouldn't you be targeting Windows and Mac first?

The mascot in front of me slowly shook his head back and forth and I realized he was right. It will never happen. At a time when Java desktop needs more resources, Sun will give it less. At a time when Sun could build products on top of the desktop, they will ignore it. I sighed and tossed the file folder into the drawer.

Daniel H. Steinberg is the editor for the new series of Mac Developer titles for the Pragmatic Programmers. He writes feature articles for Apple's ADC web site and is a regular contributor to Mac Devcenter. He has presented at Apple's Worldwide Developer Conference, MacWorld, MacHack and other Mac developer conferences.


Return to ONJava.com.

Copyright © 2009 O'Reilly Media, Inc.