Summary
The Java backlash has been building up steam, and we’re
starting to see some fundamental shifts because of it.

Advertisement

Several of Bruce Tate’s books focused on the flaws in Java
and the need to let go of some of the ideas that haven’t worked out. And blogs
like this
and this
have been appearing more frequently. And of course there’s Steve Jobs
now-famous quote (referring to the iPhone): “Java’s not worth building in.
Nobody uses Java anymore. It’s this big heavyweight ball and chain.”

This backlash has only been necessary because of Sun’s death
grip on the idea of ubiquitous, omniscient Java. It was admirable once, but a language
only evolves if its designers and advocates can acknowledge problems.
Pretending that a language is successful in places where it’s not is just
denial.

Some adaptations have occurred. Finally admitting that EJBs
have cost the world enormously, the EJB3 team took lessons from Hibernate and
Spring, but not enough to really fix the problem. Most people seem to find that
Hibernate and Spring are still simpler and more straightforward than EJB3, so
the lack of a rush back to a technology that had such a heavy cost in the past
shouldn’t be a surprise.

Java 5 was a tacit admission that Microsoft was doing some
very interesting things with C#, and proposed features in Java 7 support the
idea that Java is now playing catch-up with C# 3.0. Competition is good, and
Java is not dead. It continues to evolve, and the appearance of new languages
built on the JVM, like JRuby, Scala and Groovy, is a sign of vitality in the
world of Java.

The Web is a Mess

Seeing possibilities is great, but the downside is that it
can be hard to acknowledge when something isn’t working. The concept of the web
was visionary, but much of the web is a failure. Yes, we’ve been able to force
it to work. But it could hardly be said to “work well.” In particular,
applications of any complexity using HTML, CSS and JavaScript are difficult and
expensive to develop, and it seems virtually impossible to get identical
appearances across browsers. Even simple pages look different because of font
issues.

If you use Firefox, how many sites do you visit that are at
least partially unreadable because they’ve been created only for Internet
Explorer (IE)? It seems to me that things are getting worse; I’m seeing more,
not less sites that don’t work right with Firefox…to the point that I’m seriously
considering going back to IE.

The noble promise of CSS has not panned out. After years, it’s
still implemented inconsistently across browsers. As long as you’re using HTML
and CSS, you’ll always wonder if what you’ve created is going to produce an unpleasant
effect on different browsers. Browsers other than IE or Firefox can often get
it even worse.

JavaScript has been around since, effectively, the beginning
of the Web, but the browser wars made JavaScript inconsistent and thus painful
to use. A key part of Ajax is that someone has gone to the trouble of figuring
out cross-platform JavaScript issues so you can ignore the often radical
inconsistencies between different browsers.

There are two problems with this approach. The first is that
JavaScript is limited in what it can do. Although Ajax is an excellent hack
that gets the last bit of mileage from JavaScript, it is nonetheless a hack,
and the end is in sight. The second problem is that you are relying on Ajax
libraries to handle cross-browser issues. If you want to write your own code,
you must become an expert on those issues, and at that point much of the
leverage of Ajax goes away. Ajax improves the experience a lot, but it has
limits and I suspect we’ve already seen most of the tricks that Ajax is going
to offer.

Even more impressive is the Google Web Toolkit (GWT) which
translates type-checked Java into cross-platform JavaScript in order to speed
the development process. You write code in Java, and GWT compiles it into
cross-browser JavaScript. JavaScript, then, becomes the intermediate code that
will run on all platforms. But it took Google’s brain trust to solve the
problems that shouldn’t have happened in the first place. And if the library
you need isn’t there, you must, again, be a cross-platform JavaScript expert in
order to write new code. As brilliant as GWT is, I think it will still run out
of gas due to the inherent limitations of JavaScript and browsers.

We do see relatively amazing Ajax-based tools like GMail and
the other Google tools which are slowly seducing me (but I repeat: it took
Google to create those, not Joe garage-programmer). Very nice, but is this the
best you ever want to see on the web? You’re seeing, if not the limit, then very
close to it in those applications, and even then they don’t work consistently
(yes, I know Google tools are “still in beta”). In GMail, for example, you’re
supposed to be able to press keys like ‘r’ to reply to a message. Sometimes
this works, often it doesn’t, to the point where it’s maddening. And more and
more often, when I use web applications like GMail, my “control-c” copy
operation stops working. It could be Windows, Firefox, JavaScript or something
else but it seems to be associated with web apps and it’s been happening for at
least a year. And frankly I don’t care why it’s happening, and neither
does any other consumer. When things this simple are broken, the outlook is not
promising.

How much effort must we expend to compensate for the long
sequence of misguided decisions that has produced today’s web?

Rich Internet Applications

At some point we must ask why Java applets haven’t become
ubiquitous on the internet as the client-side standard for RIAs (Rich Internet
Applications).

This is an especially poignant question because Gosling and
team justified rushing Java out the door (thus casting in stone many
poorly-considered decisions) so that it could enable the internet revolution. That’s
why the AWT and Applets were thrown in at the last second, reportedly taking a
month from conception to completion. Bill Venners
quotes Patrick Naughton as saying: “It was a timing issue, there was only
about a three-month window in which the whole Java phenomenon could have
happened. We barely made it.” I’ve heard that argument before,[1]
and this attitude always seems to be a mistake when building programming
languages. You’re creating the fundamental architecture that you hope people
will adopt and use for many years. This is the place that requires careful
thought, not rushing.

I can see why the Green Team took this attitude: it’s the Microsoft
Way. Throw a product out there in order to get your foot in the window. The
product doesn’t have to be perfect; it just has to hold the market space. Over
time, you can fix up any flaws that occurred from rushing the thing out. It’s
the marketing version of agile methods.

This approach is workable for dynamic languages. One of the
most popular languages ever, Visual Basic, has evolved over the years. Python
has fixed some things that would even break old code, in order to clean up the
language. Reportedly Ruby is planning to do the same thing.

But for static languages with a large code base (verbose
languages in particular), fixing things up doesn’t seem to work so well. All
the code must be recompiled and possibly changed—although I would argue that
Java could have taken the Python approach: just don’t upgrade if you don’t want
to change. There are lots of companies that don’t upgrade to newer Java
versions, anyway.

The Installation Problem

So Java has been around for 10 years and applets are not the
primary way that we interact with the web. I think the main reason for this is the
installation problem, another area of Java that wasn’t well thought-out. In
fact, why do we like Ajax?

It’s clearly not because JavaScript is so easy to work with—JavaScript
cross-platform problems are the reason people have avoided it in the past. Ajax
is popular because we know that the necessary software for the client side is already
installed. Someone had to figure out how to deal with the cross-platform
issues for JavaScript first, but if JRE installation was trivial, everyone
might have just created Java applets. But they didn’t, applets are not
ubiquitous, and everyone got excited about Ajax instead. So Ajax became the
favored technology for RIAs.

Although it’s gotten significantly better with ECMAScript
standardization, I would still rather program with Java than JavaScript, the
main reason being inconsistency. Maybe in eight years the current version of
ECMAScript will be standard across almost all browsers. But the current version
of JavaScript, despite the random implementations, is already available, and
there are zero installation issues. I think that’s a fairly good proof that the
reason Java hasn’t taken over as the RIA language of choice is the installation
problem.

Various fixes have been attempted for Java over the years,
but I think the basic issue is that whoever is trying to solve the installation
problem is someone who has a more inward technical focus rather than what’s
really needed: an outward user-experience focus.

For example, I was stymied by early Linux distributions
because of the challenge of installation. About once a year, I would try to
install Linux, and it would immediately start asking me questions. Only a
hard-core Linux geek would know the answers to these questions. I couldn’t even
fake my way through, so I would give up and try again the next year. Then Red Hat
came along (at least, I think they were the first to focus on the installation
experience) and set it up to install Linux without asking questions, or at
least to give me reasonable defaults. That’s when Linux started becoming
popular (more recently, Ubuntu seems to have taken the lead in solving the
Linux friendliness problem).

Installing the JRE requires the end user to answer
questions. To a techie, the answer to these questions is easy or obvious, but
to the rest of the web users, questions frighten them during installation. Here’s an
article, and comments, that illustrates the problem with Java
installations. Although this article is primarily complaining about updates,
there is also a lot of confusion about keeping old versions of Java around. Here’s
another “installation matters” blog.

JNLP, a.k.a. Java WebStart, was supposed to solve some of
these problems to create easy-install desktop applications. I think the reason
that JNLP hasn’t become commonly used can be summed up by looking at https://aerith.dev.java.net/, a page
for one of the flagship “Cool JavaOne Demos.” If you click on the JNLP
version link on that page, it will appear to start up,
downloading a bunch of stuff and asking you questions. And then it does nothing.
No error messages or any information to tell you what happened. Repeated attempts
yield the same results, only faster because the requisite files have already
been downloaded. At least, that was my experience. If it worked for you, I’d
say that’s even worse—it randomly works on some platforms and not others. How
do you debug such a thing?

It’s not impossible to build GUI applications with Java, but
it’s been 10 years and there are still installation hiccups with applets, Java
WebStart, and regular applications. After 10 years, people don’t trust it
anymore. If it’s not there after 10 years, then I’m going to go out on a limb
and say that someone doesn’t consider this problem important enough to fix. And
even if they did, there have been so many bad experiences among consumers that
it would take years to get the trust back.

Experience with Java Applets and Applications

The initial user experience with AWT did a lot to dampen the
enthusiasm about Sun’s Java fanfare, and I don’t think applets ever recovered.
As a result, Java never became mainstream for RIAs.

Even now, I’ve had bad experiences trying to run Java
applets from a web site. They just fail, with no clue as to what’s gone wrong.
Worse, they can sometimes leave cruft behind that has even prevented Firefox
from opening new windows, until I reboot the machine.

A common response to the “applets are dead” statement is “No
they’re not. I still use them.” Applets aren’t useless; people still create
very impressive things with them. The Java
Posse highlights one or more applets each week. The statement should
instead read, “Applets are dead for Web RIAs.” The installation process for the
JRE and for any particular applet is not reliable enough for anyone to depend
on them for a general-purpose website.

Desktop applications have also suffered, and left bad marks
on Java in general, further sullying applets by association. I had an
experience with a Java product called Memorex exPressit. The UI was terrible
and buggy. I had a contrasting experience with the Logitech IO pen support
software (written in .NET), which worked cleanly and looked nice. You could
argue that the Memorex programmer(s) were just inexperienced, but the Logitech
software was just a small application that worked well without, it seems, any
Herculean efforts on the part of the programmer(s), whereas it’s hard to think
of any application that I use on a regular basis that’s written in Java.
Eclipse is a brilliant piece of software, but I think “Herculean effort”
applies.

Consider Corel’s attempt to create a word processor using
Java (I don’t remember whether they were trying to port WordPerfect or write
something from scratch). It was obviously too early to try it, since all they
had was the AWT. But only obvious in hindsight—if you were listening to Sun’s
marketing hype at the time, it was the right choice. Shrugging it off as no big
deal doesn’t work, because this kind of failure scares people away from doing
things in Java.

OpenOffice is not written in Java, but in C++. I don’t
believe it was because the programmers wanted to struggle with the
cross-platform issues presented by C++. It was speed, and perhaps the need to
more directly control the underlying platform. Despite the party line that has
always come out of Sun (Many years ago, I attended a press conference where
Gosling stated that “Java has always been as fast or faster than C++,”
something that puzzles me to this day), Java is not the right solution for all
problems.

Not Cross-Platform Enough

I struggled for years to deal with cross-platform problems for
products like the Hands-On Java CD. It’s effectively the same as the RIA
problem, because I want installation to be as easy as possible, I want
everything to work seamlessly the first time, and I don’t want to be forced to deal
with platform issues. Often my solutions would work, but sometimes customers
would email saying that it wasn’t working on their machine, and I had no idea
what the problem was. The best I could do is say “try it on a different
machine,” and often that solved the problem…whatever the problem was. I never
want to hear things like this; I just want everything to work.

Java, with its promise of write-once, run everywhere, was an
attractive contender. Unfortunately there were, at least at the time,
significant delays in Linux support (and to a lesser degree, Mac support).
Linux and Mac users may be in the minority, but they are vocal.

The show-stopper was Java’s lack of support for MP3s and
multimedia in general. As Dick Wall of the Java
Posse has pointed out numerous times, the Java Media Framework (JMF) has
been virtually ignored for many years. At the time I made my initial decisions,
there was no support for any kind of compressed sound format (I would have been
willing to use something other than MP3). Even now the only support for MP3s is
through open-source software, which is great in concept, but I don’t want to
test it and discover platform issues—again, I just want it to work; the only
thing I want to hear from customers is “great!”

It seemed like the only thing that might work was the RealPlayer,
so I used that for the HOJ CD, 2nd
edition. But the RealPlayer installation process is always trying to trick
you into buying the paid version; I must tell people how to find the free
version. And it’s intrusive—it takes over MP3s even though you tell it not to.

And for all that, the RealPlayer is unreliable. The
installation occasionally causes problems, and I get emails from people. I
generally have no idea what’s causing the problem—which is frustrating—and the
customer is usually convinced that there’s something wrong with the CD. The
Daily Show, for years, used RealPlayer and it was not only painful because it
was always starting and stopping (you couldn’t download everything beforehand;
it forced you to stream), but it always had these streaks on the left side of
the picture. Now Comedy Central has changed to a new system but that only works
intermittently. So I end up just waiting for them to be posted on YouTube.

The Flash Solution

So here’s my question. Allow for a moment the possibility
that, after 10 years, Java is not going to take over the world of RIAs. Further
allow that Ajax is just “how JavaScript was supposed to work in the first
place,” but that the limitations imposed by browsers, HTML and CSS committees
seem unlikely to let it expand beyond its current bounds. What are we going to
use to build RIAs?

In my own search, I’d really like such a system to solve not
just some, but all of my UI problems. If I’m going to go to the trouble
of learning it, I don’t want to run into a wall just when I start to develop
some speed. That’s happened plenty of times already.

The only obvious solution is Flash. Flash has always been all
about cross-platform multimedia experiences and user interfaces. People are
very familiar and comfortable with Flash, and it is installed on almost all
machines in the world. It’s trusted, stable and reliable.

Installation is a no-brainer for everyone. You don’t have to
answer questions or do anything special; it just works. That’s why it’s already
ubiquitous. Current and future versions of Flash are now released concurrently
for the three main platforms (yes, except for 64-bit Linux, but they’re working
on it and that user base typically has more than one computer, and so has
alternatives in the meantime). The standard Flash installation plays MP3s and
various types of video, so you’re not stuck with “write-once, run
everywhere…except for multimedia.”

And you can’t deny that Flash produces very pleasing user
interfaces. What did Flickr and Picasa both use? Not Java, not Ajax, but Flash.
Google videos, written with Ajax, must not have been going anywhere because they
bought YouTube, which uses Flash. Even the most die-hard Swing fan secretly
wishes their UI could look this good, especially without all the extra work
Swing would require.

There’s a very impressive Flash web app called Gliffy that imitates Visio (this was created
with OpenLaszlo, which I’ll mention later). No one could even think of creating
something like that with Ajax, although someone did an imitation of the much simpler Microsoft
Paint using HTML, CSS and JavaScript. Very impressive, but you get the sense
that this is close to the limit of what those technologies can do, whereas
Flash would just be getting started. Plus the Paint clone is a bit slow and
clunky and the UI is inconsistent across browsers.

While amazing things have been accomplished within the
confines of JavaScript with technologies like Ajax, JSON, GWT etc., these are
nonetheless confines. We bump up against their limits every day, and those
limits are not going away.

Solving the UI problem

One of the difficulties of GUI programming is choosing a GUI
library. Sometimes there’s a standard library, but that can change. In Java, we
started with AWT, which turned out to be a mistake so we had to be patient as Swing
was developed, until IBM and Eclipse came along and offered us the additional
choice of SWT. In Python, there are many GUI libraries, including the built-in
Tkinter (which reduces the installation problem), WxPython, Qt, and more.
Windows-specific libraries have similar choices, but if you want to create
cross-platform applications, those libraries aren’t available.

If you explore these GUI libraries, as I have, you run the
risk of getting broad knowledge that is not particularly deep. Each library requires
significant effort to learn, and each seems to have its own philosophy
regarding the activities that should be easy, and those that should only be possible.
Each one looks at the world of GUI programming in a different way.

I’d like to be able to learn one solution and use it for all
my applications. That way I could stop learning about GUI solutions and
start acquiring some depth. Ideally, this will be a real programming language with
consistent results across all platforms.

I believe that to solve the user interface problem, we need
the equivalent of a domain-specific language dedicated to the user experience.
For me, Flash-based technologies like Flex are the best solution to this
problem. (Full disclosure: I’m in the process of working out a consulting
contract with Adobe, to help them teach people about Flex. But long before
this, I became convinced that Flash, and Flex in particular, was the best
solution for the user-interface problem, and I began writing this article long
before Adobe expressed interest in my assistance).

What is Flex?

Traditionally, Flash content and applications have been created with the
Flash authoring tool, currently called Flash 8 Professional (it’s confusing, but
the decision to give the name of the tool the same name as the runtime was made
ten years ago). There was also a tool called Macromedia Director, a multimedia
production tool for CD-ROMs, which predates Flash and outputs a format called
Shockwave that runs in a Plug-In/ActiveX control much like Flash content, but
is an entirely different control. Shockwave had its heyday, and it is still
widely used, especially for games, but Flash is much lighter weight and achieved
mainstream adoption far beyond Director.

Flex is a way to develop Flash applications by programming.
It includes a declarative XML language called MXML for laying out user
interfaces, and a programming language called ActionScript, which is a superset
of ECMAScript (that is, standardized JavaScript), with extra features like
optional static type checking. ActionScript is a single language that works
across all platforms, so you don’t have to worry about differences. Because it
is based on ECMAScript, your JavaScript knowledge is not lost. All MXML
components are actually written in ActionScript, which is what you use if you
want to write your own components. Flex applications compile directly into SWFs
(Flash binaries), which are then Just-In-Time (JIT) compiled by the Flash
runtime, for extra speed.

Cost was one of the main things that originally held me back
from using Flex, primarily because of readers who were unwilling or unable to
pay it. In the initial versions of Flex, you had to buy the server edition just
to create static SWFs. The server edition is designed for dynamic content, and
is certainly worth the money for larger organizations that are creating dynamic
SWFs from databases and the like. But there was no reasonable entry point for
people who just wanted to experiment with it. It was hard for me to recommend
it if the average person didn’t have a reasonable experimentation path, including
creating static SWFs to deliver from their own server.

Now, however, you can download the free command-line Flex compiler
to create static SWFs, and you can deliver these from your web site without
paying any fees. The compiler, framework, and debugger are all free, so there’s
no reason to avoid using Flex.

You can buy the Flex Builder IDE to help you create Flex
apps. This is built on top of the Eclipse platform (instead of creating a new
GUI development system from scratch—a wise approach). It has the usual sorts of
things we’ve come to expect, like auto completion, context help, debugging, and
even a GUI layout tool. The layout tool can give you a quick start when you’re
beginning a design, although I found it more valuable to hand-tune the code
once the rough draft of the design was in place.

Here’s something else that caused me trouble in the past:
although the Flash player for Windows and the Mac have always been on the same
release schedule, Flash for Linux has formerly been released quite a bit later.
I didn’t know this until I put out the first beta of the Thinking in C eSeminar, and got
complaints from Linux and Mac people about it. After some investigation, I
decided to back-port the application (which isn’t that fancy, and doesn’t make
use of any features that don’t exist in Flash 7). This seemed to be the best
solution for me, because I didn’t have to wait for a final release of the newer
version of Flash, and in particular I didn’t have to worry about Linux. One of
my main goals for using Flash in the first place was to make the use of this
application transparent across platforms, and to reduce any installation issues
to a minimum.

However, with Flash 9 and beyond, all the players will be released
within weeks of each other, and this policy should hold for future versions of
Flash. So now you don’t have to worry about complaints from anyone. Build your
UI with Flex, and it will “just work.”

Flex as a DSL for Graphics

One of the most appealing things about Flex is
that Flash was created with the idea of UI first. In a very real sense, it’s a
domain-specific language (DSL) for graphics, multimedia, and UIs, whereas most other
solutions have been languages with UI libraries tacked on afterwards.

Because of this design goal, Flex and Flash provide a complete,
unlimited, flexible tool to build user experiences. From the standpoint of a
programmer’s time investment, you can learn a single language for building UIs without
worrying about running into problems or limitations later—issues like:

Installation problems

Constraints on what you can create

Sudden steep climbs in the learning curve

There are plenty of fancy components that you can just drop
in and use—the Flex Framework (part of the free download) comes with over 100
components. There’s an active marketplace for component creators, both
open-source and payware. One such library comes from Adobe: the Flex Charting
Components (in the few hundred dollar range), but there are also competing
charting components.

One of the more interesting aspects of Ajax, of course, is
the “A” for “asynchronous.” This allows information to flow between client and
server without doing a whole page refresh. For Flash, a much more sophisticated
version of this is provided by Flex Data Services, a publish/subscribe
API for data management. Flex Data Services automatically performs caching and
updating between client and server, to produce an optimal experience without
forcing you to write extra code. This allows you to work with real-time data,
build collaborative applications, and perform enterprise messaging integration.
You can use Flex Data Services on a single CPU for free; if your application
requires multiple CPUs you’re considered an enterprise and the licensing fee
kicks in. You can learn more about Flex Data Services here.

Earlier I mentioned Gliffy, which was built using OpenLaszlo.
OpenLaszlo was especially attractive before the Flex compiler and framework
became free. However, the OpenLaszlo group has decided that they will
accommodate the lowest common denominator technologies by targeting DHTML
combined with Flash, and this incorporates the limitations of DHTML. The reason
Flex is compelling to me is that it allows me to take advantage of things I can’t
do in the normal browser and those things produce the same results, everywhere.
On top of this, Flex is magnitudes faster than OpenLaszlo because it takes
advantage of the JIT compiler in Flash 9. Since Flex is now free, there’s no
reason not to go to the source.

Flex on the Desktop

Of course, if my dream is to be able to learn a single GUI
system in depth, is Flex the right tool, since it was originally designed for web
RIAs?

A Flex UI can initiate communication with its server, or any
other server it chooses. A server cannot initiate communication with a Flex UI,
which makes sense because of security (it would be effectively the same as
having an open port on your machine).

However, a Flex UI is not limited to communicating with a
server. It can also communicate with a local application. Thus, you can create
an application in any language you prefer, even a dynamic language like Python
or Ruby, and use Flex to build a beautiful UI.

Adobe is developing a new tool called Apollo, a cross-OS
runtime that allows you to use Flex to create desktop RIAs. This means that your
Flex skills can be further employed for creating smooth desktop applications,
but it also means that you can more easily build applications that will work on
both web and desktop (I’ve seen expensive and difficult-to-use tools that
allow other languages to do this).

Hybridizing Java

It’s clear that we can’t wait for Sun to fix all of Java’s
problems. Open-sourcing Java might, eventually, have a huge impact on repairing
Java’s deficiencies. For example, work on the JMF might get resurrected. Maybe
installation issues will even be fixed someday. The possibilities might be
limitless, but if you need to solve problems now, then the solution is
to hybridize parts of the language.

We do this already. You don’t insist on using a Java
database for an application; you use a specialized system like MySQL or Oracle.
Sun is directly supporting the development of JRuby for hybrid Java/JRuby
programming. We are seeing other special-purpose languages arise to solve
specialized problems. Why insist on using a Java library for UI if a
specialized system solves the problem better?

As shown in the TurboGears-Flex
demo I created with James Ward, it’s possible to use a language like Python
(or Java, Ruby, C#, etc.) as a back-end and build your user interface using
Flex. This can even be achieved for desktop applications (even more so with the
upcoming Apollo tool).