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="https://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="https://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
matter?"
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="https://wwws.sun.com/software/sundev/jde/index.html">for
developers.
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.
Dukester
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="https://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="https://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="https://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
services.
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="https://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="https://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…
