What If the iApps Had Been the jApps?

by Chris Adamson

This blog has two inspirations. The first is the research for my O'Reilly Mac OS X Conference presentation, which goes by the cheerful and innocuous title Why Mac Users Hate Java. It got me thinking about what Java could be, but isn't.

The second inspiration is the "What If..."
line of comic books that Marvel used to produce, which would present
one-issue alternate-history stories about what might have happened if
super-heroes had never gained their powers, lost key battles, joined
different super-teams, turned evil, etc.. The stories were presented
by "The Watcher", (not "The Monitor" as I said in an earlier version of this weblog), who was this bald guy who wore a toga and was typically found floating on an asteroid.

So if you'll just imagine yourself crossing a cosmic boundary to a four-color universe...

The Story So Far...

The makers and fans of Java knew they had a problem. To them,
software that could run on any operating system had huge advantages.
They could develop an app once and deploy it everywhere, instead of
writing different versions for different OS's. Users, on the other
hand, could choose the operating systems that best suited their needs,
without having to fear a lack of software.

But the users didn't see it that way. They saw Java applications
as href="http://archive.salon.com/tech/col/garf/2001/01/08/bad_java/index.html">slow,
ugly, and irrelevant. Slow, because Java's virtual machine turned
every machine into an emulator, one whose code could not possibly be
as fast as native code. Ugly, because the applications' GUI widgets
had obvious visual differences from native applications, and used widgets
inappropriate to the host platform, like in-window menu bars on the
Mac. And irrelevant, because Java applications didn't do anything
that a native application couldn't do better.

In your universe, heroic efforts were made to attack the first two
problems. href="http://java.sun.com/products/hotspot/">Cutting-edge
technology was developed to make Java code fast, while others
tried to mimic
platform-specific GUI widgets in Java

But in another universe, a different question was asked... not
"how can we make Java fast?" or "how can we make Java
pretty?", but rather, "how can we make Java

They happened across a remarkable answer.

The Coming of jTunes

The release of jTunes was met with a mixture of delight and
skepticism. Critics wondered why anyone needed another MP3 player.
But fans were delighted to have a capable player that they could use
anywhere: at home, at work, even in remote locations by uploading
their music to a website and then launching jTunes as an applet in a
web browser. In each case, they enjoyed the same interface and the
same functionality.

It helped that the interface had been outsourced to experts in
human-computer interaction, designing it for ease-of-use by typical
users... a massive shift for a Java community that had too often
focused on tools by developers href="http://wwws.sun.com/software/sundev/jde/index.html">for

But moreover, this was the sign of a new strategy, a realization
that code and data are inextricably linked, that running anywhere
implied there needed to be something worth doing anywhere. By
letting users play their music and listen to net radio regardless of
location or computing environment, the
Java community had stumbled onto a brilliant tactic: hijacking
content to spread Java
. The popularity of MP3's came with an
implicit need for software to organize, play, and enhance it. jTunes
shrewdly satisfied this need.

But hopping from desktop to desktop wasn't enough, not in a world
increasingly tilting to the Windows platform. They also needed to hop
off the desktop. Java had long been a success on the server, but that
kind of success is invisible. What was needed was something that you
could grasp.


The next java media success could be grasped -- literally. The
Dukester was a portable MP3 player, shaped like Sun's
soon-to-be ubiquitous mascot, standing six inches from tip to toes.
Critics balked at the impractical shape, but consumers said
"awww, cute!"

Cute wasn't the only thing Dukester had going for it. A J2ME
version of jTunes brought the desktop experience to the small device.
Users appreciated the familiarity. Moreover, to get music into the
device, it had to provide USB and FireWire ports, which in turn
required API's to use these ports from Java. With a public release of
these API's, Java suddenly became instantly useful to device makers.
Long sick of being goaded into producing connectivity and driver
software for the small Mac OS X community, and even more sick of being
hacked by a Linux community that sought to provide its own access
software, the device makers realized that they could write their Java
code once and satisfy all these communities. The original Java vision
became more of a reality.

With small devices now requiring not a desktop computer but rather
just a Java environment, makers of other consumer electronics got
interested in Java. Console game makers had long hoped to be the
center of the household entertainment suite, but had little appetite
for delivering the software and services themselves. But in the end,
they didn't have to, not with users clamoring to hook their Dukesters
up to their PlayStation 2s... all that was needed was a network
connection, a USB or FireWire port, and a Java runtime on the console.
Game consoles and set-top cable and satellite boxes soon offered Java
compatibility as a selling point, with the playful Duke logo becoming
a ubiquitous symbol on consumer electonics cartons in stores.

In a sign of remarkable openness, the Dukester even allowed small
J2ME applciations to be downloaded to it. This drew both beginning
and experienced developers to write appointment calendars, to-do
lists, games, and other handy little apps for the Dukester.
Moreover, J2SE was redefined to be a full and proper superset of J2ME,
so any particularly useful apps developed for the Dukester could also
be run in any other Java environment. "Write once, run
anywhere" was starting to pay off with more and more apps, and
more and more "anywheres" to run them in.

Perhaps more importantly, all these java implementations generated
license fees, which was poured back into new java development.

jMovie and jPhoto take the stage

Released the next year, jMovie seemed almost obvious - a
tool to make home camcorders more useful by providing first-class
editing and post-production tools that worked on any computer or
equally-powerful device. Again, Java technology latched onto the
popularity of another technology to spread itself.

Perhaps more importantly, the technology was now powerful enough to
help set standards. While scanners generally supported the href="http://www.twain.org/">TWAIN standard, there was no
equivalent for capture of dynamic data, such as from a video or audio
source. This had led href="http://java.sun.com/products/java-media/jmf/index.html">earlier
Java media frameworks to only support capture via native code
specific to each platform. With Java constantly spreading onto new
platforms, this position was untenable, and undesirable anyways, so
jMovie's introduction was accompanied by the release of proposed
standards for audio and video capture, with jMovie providing
implementations for the most popular devices. Not wanting to be left
out, device makers quickly embraced the standards.

Eventually, connecting camcorders to computers, set-top boxes, and
console game systems was something users would do without a second
thought. They simply expected such things to work anywhere, and with
Java's ambitions of ubuiquity and standards-based simplicity, it was
more or less true.

By the time jPhoto was rolled out, this idea of ubiquitous
access was well-established. The application, which allowed users to
organize and enjoy digital camera pictures, supported practically any
camera out of the box.

Moreover, a camera with unique features could
offer device-specific code to the application at runtime, without an
installer CD, using the principles of href="http://www.jini.org/">Jini to pick-up implementations of
well-defined service interfaces at runtime. Jini's value proposition
had always depended on a ubiquity of Java VM's as an environment for
its ad hoc Java-to-Java networks; the success of the jApps provided
Jini with fertile soil in which to grow.

Within a few years, computing and consumer electronics had been
changed from a balkanzied battlezone of conflicting standards and
power-grabs to an industry powered by a virtuous circle of
inter-connectivity, thanks to these Java-based applications that
piggy-backed digital content to enable the content to move around
networks and devices, and in so doing, spread Java from the desktop to
all manner of connected devices.

Another Reality, But Not This Reality

But that is not how things have turned out in this reality. Here,
the iApps are a collection of media applications that run only
on Apple's operating system. Moving media from one platform to
another is still fraught with peril, thanks to incompatible
"standards", deliberately fractured by players trying to
capture the media market to lock users into other products and

Despite Apple's media prowess, the idea of media apps actually
makes more sense as platform-agnostic Java apps, like these
jApps. Wanting to enjoy music or photography shouldn't tie a
user into a specific operating system, or even make them use a desktop
computer at all, when other household devices have equivalent power
and better output options - why wouldn't you prefer to enjoy your
media from the couch on an HDTV with surround-sound?
Yet the idea of capturing video with a
home computer, with no concern for camera compatibility, then editing
it in the living room on a game console, and then sending it over the
network to another device, is simply fantasy in this world.

In this world, the Java media APIs lay in a state of utter decay,
incomplete and largely abandoned, unsuitable for the task of
revolutionizing media and spreading Java. J2SE isn't a superset of
J2ME (no javax.microedition in J2SE for example), so apps for the
device tend to stay on the device. A Java USB API remains href="http://www.jcp.org/en/jsr/detail?id=80">on the drawing board
and FireWire connectivity exists only in dreams. Jini's
assumption of a JVM-rich network isn't true, so it has few
environments to run in. And two years after its announcement, href="http://java.sun.com/features/2001/06/sony.html">Java for the
PlayStation 2 remains vaporware, perhaps because there's little
apparent point to it. Instead, Java enjoys its success on the server,
and to a far lesser degree in device-specific mobile phone scenarios,
with neither making genuine cross-platform Java particularly relevant
or even visible to the common user.

Having seen what could have been, this is what is.

WHAT IF... you had a response to this blog? You'd add it to the discussion below...


2003-10-16 18:49:00
Interesting, but beside the point.
I think that this article, while well stated, misses the point about why Java has not prevailed on the desktop. It is easy to teach a variety of computer systems to compute in the same way, it is not easy, nor desirable, to teach a human to interact with a program in exactly same way in starkly different contexts.

Different platforms have different ways of doing things which must be conformed to in order to produce a decent user experience. The whole concept of write once, run anywhere makes sense when only computation is involved, but is utterly oxymoronic when users have to interface with these applications on different platforms. In order for write once, run anywhere to work all platforms would have to be identical, which defeats the point of having multiple platforms.

In order for Java to be a success on the desktop it must promote a model of writing the core of an application in standard Java, and writing the interface of the application in platform-specific Java. I want my Java applications to be adapted to my platform. I WANT it to be written specifically for my needs. Not all platforms are created equal, so how can all applications be?

2003-10-16 18:54:22
The reason that Java HAS been so successful on the server is because all interfaces that servers deal with ARE created equal -- web browsers (except Internet Explorer which is an invalid). Desktop platforms use vastly different paradigms in their interfaces with users.
2003-10-17 02:35:50
Depends what your definition of an application is
Does a web application behave differently on different operating-systems? How 'bout a DVD (ie, the menus, features, and other interactivity supported by the DVD scripting language)? Mac OS X doesn't try to "Mac-ify" these experiences, nor does Windows try to "Windows-ify" them. And nobody would want them to.

These are cases where *content rules*, not the application to get to them. I don't have to have a super-nice Mac experience to play a DVD or buy plane tickets, I just need it to work. That's where I'm going with the concept of "hijacking content to spread Java".

More at the conference session. Hope you can make it.


2003-10-17 04:30:57
Depends what your definition of an application is
In 1995 Sun had a complete working implementation of the OpenStep api (now Apple Cocoa of course), implemented in Objective-C and running under X-Windows. In the same year, when they introduced java, they just dropped OpenStep completely, even though the AWT api wasn't remotely comparable in power. Why didn't Sun keep OpenStep and add java bindings (c. 1-2 man years effort), instead of developing Swing? Why did they apparently learn nothing from OpenStep, although they did use the work of some ex-NeXT guys via Netscape to get Swing going?

What if Sun and Apple had a common crossplatform desktop api today that worked well enough to produce apps that real users would want? That's the alternative reality I like to dream about. I'd like to see java apps which are as good as the ones Lighthouse Design produced 10 years ago for the NeXT platform. And even now, where is there a java UI builder that is as good as InterfaceBuilder?

-- Richard

2003-10-17 04:37:14
Different platforms have different ways of doing things
This will be interesting to watch in the next coming months now that Apple has ported iTunes to Windows. Will it be successful of is the difference in platforms enough to keep it from being successful. An application can be written in Java and still be tuned and customized for different operating systems (more than just changing L&F).


2003-10-17 05:10:17
Depends what your definition of an application is
What a lovely idea... as a long time admirer of NeXT I am enjoying OS X immensely, and until now had thought it supported Java pretty well. Your comment about Sun missing the chance to use OpenStep instead of Swing almost breaks my developers heart.
2003-10-17 16:42:15
Technical Issues
What you say makes sense, but falls down for basic technical reasons. Cross-platform software doesn't work in many contexts - you simply can't run a program designed for a PC on a phone. The screens won't fit.

On a more fundamental level, the Java multimedia APIs are not viable, which is why they have been essentially abandoned. It's possible that throwing development resources at the problem may result in something that works - but it would still be a generation or two behind native multimedia APIs.

2003-10-17 18:33:08
Re: Technical Issues
Thanks for the feedback. Two re-rebuttals:
1. I didn't advocate running the same interface on a phone. In saying that "jTunes" could run on a "Dukester" (obviously a nod to the iPod), I said "a J2ME version of jTunes brought the desktop experience to the small device." Obviously, it would be different, in the same way that "Word" on a PocketPC is not the same as its desktop equivalent, but tries to offer some appropriate similarities. On the other hand, I do think that J2SE apps can and should run unmodified on something like a set top box - game consoles and modern set-tops have plenty of power for J2SE and shouldn't, in our ideal world, be crippled by only supporting J2ME.

2. I agree that the Java Media API's are currently useless, in fact I said as much. But catching up might not be as hard as you suggest - IBM has MPEG-4 authoring and working in an all-Java implementation ( http://www.alphaworks.ibm.com/tech/tk4mpeg4 ), and maybe they'll keep adding more of the spec. MPEG-4 is way bigger than people think - it specs have interactive sprites, scripting and Java, 2D and 3D graphics, etc. A "complete" MPEG-4 implementation in Java, with API's to create, edit, stream, and play the full suite of MPEG-4 media, would dwarf QuickTime and could well be all things to all people. That said, IBM's implementation is license-ware and Not Cheap, so it's not likely to solve Java's problems.

Thanks for reading!


2003-10-18 05:34:15
same old, same old
Still, I think that Apple's history is going to repeat itself precisely because they haven't taken advantage of Java.

I've said many times that Apple does something insanely brilliant about once a decade, then retreats into deep mediocrity. So--they've done the brilliant thing; when are they going to retreat? I hope not; I hope they've broken this vicious cycle.

Really, the problem the last time was that lost their developer community. And for good reason--why should application developers develop for OS

Now, Apple has this really, really cool machine and operating system. Developers are in love with it. And they've increased their share of the total market to, maybe, e*2 or e*5. Still a small number. So, what choice does a developer have? You can develop in OS X native, where you can sell to a market share that's a couple of percent of the total, or you can develop in Java, and sell to the entire market.

So far, it looks to me like developers are saying "But OS X native applications are so COOL!" Still, I see nothing that has changed about the basic economics of the situation. An OS X app, no matter how cool, is only useable by a small minority of the total market. If you develop in Java, you can work on your cool platform, and you can sell to the entire market. I don't think Apple execs really get this, or how important it is to their future. I think their message is "this is really cool, all the world is running to us..." Well, maybe that's true. They've probably tripled their market share. 3 times epsilon is still a very small number.

The problems with APIs like Java Media are real, but certainly fixable. (I've had to use JavaSound recently, and it was surprisingly easy to get stuff going. I didn't have to do anything complex, I admit.)

I admit that I'm sounding like a Sun marketing hack when I say stuff like this. But there's a reason economics is called the dismal science. Unless Apple can do something to change the market itself, economics will drive them back to the next decade of deep mediocrity. And the only way I see of changing that situation is to encourage developers to write cross-platform applications. In Java. And that may require saving Sun's sorry ass by fixing some of the APIs that they've abandoned, so that the Java platform is as complete as it should be.

2003-10-18 06:29:53
Interesting, but beside the point.
I don't agree at all. The idea that people only want to use apps that look like their os is silly. Have you every heard of the internet, html, flash. I mean common. That just flies in the face of reality.
2003-10-18 06:43:12
You're right...
You're exactly right. What boggles my mind is why this hasn't been done already. Java is portable and the average person 10 years from now is more likely to be using some sort of advanced high resolution cell phone than they are a pc.
2003-10-18 07:04:07
A bigger issue...
Why does ms control 95% of the desktop today. Is it ms office? Ten years ago that would have been true, but today ms controls the desktop because of ie. I go to work and I interact almost exclusivey by e-mail with my customers. I use many web apps with UPS, software updates, etc. What is ie ( and for that matter windows ) turning into? A portal for web apps and multimedia. Five years from now no one will care about printing hardcopy to printers or file io or any of the other mundane os stuff that most people think keeps ms on top. Java, Apple, Macromedia cannot only compete, they are better positioned than ms on these things. How should software companies compete in this environment. Write stable useful apps that focus on content development and make it easy to use. Can you imagine an apple-java app that would run everywhere from apples to pc's to pda's to cell phones? I can.
2003-10-18 07:20:05
A slight correction Currnetly Sony is hiring Java developers to produce java games for playstation..you can find the job ad in several places including gamasutra.com
2003-10-18 20:31:29
Depends what your definition of an application is

OpenStep on X11 had serious problems with no clear solution. Openstep on NeWs would have be usable. Adding java on top of the OpenStep stack would hava further decreased the usability of the platform from very poor to god awful. I did port JFC directly to NeXt's postscript window manager during this time and it worked well. But what your suggesting X11/Openstep/Java is most probably still not possible.
2003-10-19 11:32:39
Desktop? Server? Does it matter?
And who cares about the underlying language/libraries that an app may or may not be written in... what matters is what the app does... not it's accidental implementation:


2003-10-20 06:10:23
Interesting, but beside the point.
And how would you compare the user experience of HTML or Flash applications to native applications? When you use an HTML or Flash app, you KNOW you're using HTML or Flash. Same thing with a Java app; you can tell from the moment you launched it that it's written in Java. And you shouldn't be able to. It should look like a native application. But today, we're not there.
2003-10-21 09:37:51
An overlooked issue
There is one other issue why Java never made it on the desktop, and this one is perhaps the most important reason - intelectual property rights.

With the comprehensive de-compilers of Java available right from the start, companies have had little incentive to produce significant applications which competitors can then rather easily steal. Obfuscators help to some extent, but even these are not foolproof. There needs to be a way to protect published byte-code so it becomes much more difficult to generate useable source code from it.

Besides the above issue, the Java community continues to fight the mindset that Java is slow, even though there have been significant speed improvements of both hardware and Java core software.