Followup: Why Java on the Desktop Just Doesn’t Matter

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…


Deprecated: link_pages is deprecated since version 2.1.0! Use wp_link_pages() instead. in /srv/www/friday/bbum/wp-includes/functions.php on line 4713


Leave a Reply

Line and paragraph breaks automatic.
XHTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>