Bill Bumgarner

Boy, am I glad I found the answer to this question!

Where are my socks?

And, all this time, I thought it was the elves...

Yeah, someone busted me on actually failing to answer that question. So, a highly opinionated set of my observations.

---

In the interim years between which the Java promise was made and broken (again I'm only talking about the shrink wrap Application market here), there have been a number of other tools and technologies that have come along to make the whole WORA point not terribly interesting.

Beyond the development tools on the major platforms maturing significantly, there is also better support for building cross platform non-GUI code. Scripting languages are more easily integrated now than ever before, creating a high level portable solution for implementation of a good chunk of applications. Similarly, the support for C++ (and, really, Objective-C) in cross-platform environments has matured significantly in that write-once-run-anywhere-with-the-right-compiler-flags is a commonly used paradigm these days.

As well, the approach with which software is developed has matured. Developers recognize the value of separating user interface code from their data containment code. Model-view-controller is an obvious and commonly used design pattern that does exactly that. There are other design patterns that achieve the same goal. It is also interesting to note that the growing popularity of unit testing naturally leads to a better separation of user vs. non-user functionality simply because it is so difficult to unit test user interfaces (that is what functional and acceptance testing is all about).

And the tools available for separating data from user interface have also matured significantly. Beyond design patterns, there are now a number of tools that vastly simplify client/server style communications (even when a network connection isn't really involved-- SQLite, for example). Use of client/server also naturally leads to a stronger separation between the platform specific user interface code and the platform agnostic data management and core functionality.

So, while the Java market was largely focused upon providing solutions-- some awesomely powerful-- for developing internet related or internal/vertical applications, the rest of the market was not sitting around.

Likewise, the platform specific development models have advanced significantly. On Mac OS X, Windows, and Linux/BSD/X, there are many relatively new tools and APIs that make pumping data into a user interface both a heck of a lot simpler (fewer lines of code) while also enabling the ability to create custom visualization tools that are strongly tied to the native APIs. Certainly, Java is providing support for a similar mechanisms via some of the newer APIs, but the development experience still lacks the tightly bound fluidity of using tools designed specifically for the platform.

There have also been a number of APIs and technologies built that also promise write-once-run-anywhere style solutions for cross platform deployment. While all suffer from similar look and feel problems as Java based solutions, there are some very high quality solutions in this space that often have significant advantages over Java -- smaller installation footprint, less overhead, simpler development, or some combination therein.

---

So, as a result of both the significant advancements in platform specific technologies and in the cross-platform tools market, Java is simply yet another solution to an already solved problem.

All of the above combined means that Java just won't matter on the desktop unless it can offer a compellingly superior solution to some set of problems. At the moment, Java does not.

The Java specific IDEs are really powerful, but none offer truly compelling user interface development tools.

While writing cross-platform non-UI specific code is both easy and quite attractive with Java, cross-platform GUI code really doesn't exist without sacrificing the quality of UI that can only be had with native tools. That, combined with the increasing quality and simplicity of tools such as wx*, TK, or a number of commercial products (Real Basic, Runtime Revolution, etc..) for cross platform development further dilutes Java's potential.

Given the discussed roadmap of Java these days, it doesn't look like Sun -- or anyone else -- is really putting up much of a fight for the desktop.

That last post certainly deserves a followup. It generated quite a bit of commentary, some of which was interesting and most of which indicated that the author didn't actually read what I wrote (or I did a poor job of conveying what I intended).

In any case, thanks to all that responded. It was a remarkably flame/fud/troll free set of responses for a topic that is generally quite volatile in nature.

Some random points of response:

What Carmack Said I know that Carmack's comments were directed at development of software for cell phones and other embedded devices. The point of my post was to take this particular observation and apply it to what I perceive as a significant failure in regards to the original promise of Java. Java spent a good chunk of the latter part of the 90s being marketed as the end-all, be-all, write-once-run-anywhere, solution for application development. That promise never materialized.

Java, the Language I like Java, the language. I have written tons of Java. It was mostly pleasant, mostly interesting, and often quite entertaining. About the only bits of Java I really found miserable had to do not with the language, but with dealing with other people's code that was exceptionally poorly written. Java certainly does not own a monopoly on crappy code. However, as a result of so many really bad ideas getting funding during the dot-bomb years, many bits of code that should never have seen the light of day were shipped as "final" products. Until working for Apple, much of my professional time was spent cleaning up other people's messes. While lucrative, it also meant that I spent a large amount of time de-tangling really crappy code from a client's environment, often well after that client had spent a boatload of $$$ on said solution. Often, it was a better bet to put up with the crappy code to make the client feel like they didn't get completely ripped off than it was to do the right thing and throw the garbage out.

One of the promises was that Java development would be efficient. We have seen tremendously powerful features come forth in the various IDEs, but one area that seems entirely lacking is the UI development tools. This is probably one of the reasons why Java as a desktop application development environment (where, again, "desktop application" is "stuff you'd see in a shrink-wrap box at CompUSA) just never met the promise. The tools for building applications sucked when the promise was made, and continued to suck until long after the promise was broken. I have started to see some promising tools in the last couple of years, but none that seem really aimed at building generic applications -- most seem to be either tied to some enterprise related back end framework or to solving a particular niche problem such as reporting.

And, yes, Java is not slow. I know that. I wrote many a hunk o' Java code that had to be fast as hell and it was always possible to eek out the performance I needed. But Java desktop apps, on the other hand, generally are very slow, or unresponsive, or bloated pigs, unless the developer expends an unbelievably huge amount of effort to make them otherwise.

Real World Java Desktop Apps Java promised write-once-run-anywhere style development where the end result would look-n-feel like a native, or near native, app on the target system. That promise was quickly amended to account for that fact that different desktop environments behave differently and some of those differences would require compensation within the codebase to ensure a native look and feel. This is certainly not a flaw of Java, but merely the reality of building desktop apps. However, even that is not really true. Achieving a native look-n-feel while also creating a responsive application -- one that doesn't "feel" any different than any other app on the platform -- just doesn't seem to have happened very often.

What many people missed was that I was specifically talking about commercial applications targeted to the wide market. Not to niches, not development tools, but addressing the original promise that Java would be a major player in the applications market. Sure, many many people are using Java quite successfully to build in-house, niche, one-off apps. I was in that group for a long time and assuredly will write new Java one-offs for my own or other internal uses in the future. Visual Basic has achieved an even greater success in such a role. But that wasn't the promise! The promise was that Java would be the solution for creating desktop applications of the kind you would see in shrink wrap boxes at the likes of CompUSA or Amazon.com.

So, of course, a number of people responded to the original comments by pointing out various "example" applications that are written in Java, have achieved some level of widespread distribution, and are targeted to the desktop environment.

Azureus, LimeWire Actually, I used Azureus pretty regularly when grabbing etree content. Painful user interface, not very responsive, and made no attempts to look like a native app. But, yes, very very powerful and did a wonderful job of what it did. Certainly not something I would call a "commercial quality" application. But, then again, my standards-- having come from a NeXT and Mac background-- may be exceptionally high. LimeWire, last I looked, was a similar kitchen sink's worth of powerful features shoved into a single app with little thought for usability. Both are bloated, too -- consume huge amounts of memory.

Java IDEs Yup -- there are a number of IDEs written in Java that are awesomely powerful. Java lends itself really well, much better than Objective-C, to building things like complex and very powerful refactoring tools. As a result, the Java IDEs can do some really amazing stuff with code.

But, boy, talk about bloating pigs! IDEs, in general, are typically 10s, if not 100s, of megabytes for the app along + often 100s of MB more for the supporting materials. And there is no easy way to approach the IDE. You are pretty much left with "run the app and hunt until you figure out how to create a new project... then a new file... then to build... then to debug...etc...". Worse, many of the IDEs seem to have invented their own UI paradigms that guarantee that the look-n-feel is going to be far away from anything native and often quite a bit aside from the "generic Java" l-n-f.

So, while I consider the Java IDEs to be a testament to the power of Java and to the maturity of certain segments of the Java market, they are certainly not examples of "wora, looks great, native look-n-feel, shrinkwrap package on a shelf" type apps!

Quantrix Someone mentioned Quantrix, which has been ported to Java. If it works half as good as the original Improv, that is one hell of an achievement and they should be applauded. However, given pricing it would seem to be relegated to a vertical market or niche at this time.

Enough of this...