Skip to content

SAS07 – Java for Breakfast: GUIs and More

As with the other RedMonks, I’m here at the Palace Hotel for the Sun Analyst Summit. This morning I talked Java SE and ME over breakfast with Anne, Jean Elliott, and Laurie Tolson, hosted by Jacki DeCoster.

Life in a Closed Network

The idea of there being many devices — not just the desktop or even “network computer” — came up several times. Of course, that idea is implicit for ME. One of the interesting things that I’d missed when it was announced were that the SE, ME, and Java Card lines were merged together (at least in marketing aspects), now under the charge of Laurie Tolson.

The limitation in North America, as I often point out, for the many, small networked devices are the telcos locking down their networks and devices. At the moment, the only technological disintermediation is SMS, taken advantage of by scads of services like dodgeball and flickr that don’t want to bother with the carrier gate-keepers. And good for them.

For Java, the wiggle-room there is on the server — why not add in some SMS APIs to help normalize how each network handles them? — unless Sun and others engage with the afore mentioned carrier gate-keepers more. That is, it’s a business problem vs. a technological one.

Java GUIs

Another trend we talked about was the slight uptick (from my perspective) of interest in doing Java GUIs (based on SE APIs, Swing, instead of Eclipse). For a long, long time, “Java GUI” wasn’t done: you just had web applications. So why did it change, Jean asked. My theories:

  • Ajax – people realized that UIs could be more than just text inputs, radio buttons, and check boxes. Joel had complained about “the loss of the GUI” several years ago when web UIs became the poster boy for what UI’s were. Ironically, then, thanks to Ajax, I think the developer world has realized that you can (and should?) have more.
  • Fixing Swing and Friends – whether it’s from Eclipse or the Sun/JCP community, there was a collective acknowledgment that Java GUI development was icky. Instead of sticking to the API, the java community tried to replace or fix it.
  • OS X – this is the most theoretical of explanations. My theory is that as more Java developers have been using OS X, they’ve re-discovered the desktop. As I outlined on a recent DrunkAndRetired podcast, when I used Windows, I so disliked the GUI that I tried to move all of my applications to the web. As I’ve been on OS X over the past 3 or 4 years, I’ve started using more desktop applications. Now, this isn’t a panacea of web UI -> GUI shifting: the point is that I and others consider using desktop applications when previously we only considered using web applications.

I didn’t think if it at the time — probably because I had my Java blinders on — but, of course, Microsoft and Adobe have been doing a lot to remind people of GUIs vs. web UIs. Eclipse has done quite a bit as well with their platform, but without having to put down the web as moribund. To be completely fair, that tone has changed to helping out the web, which is much welcome. Still, the outward PR and messaging from Microsoft and Adobe has put a nice chink in the idea that Ajax is the only way forward for application development. It’s still a wonky balancing act, but each side is adapting to the other quickly and (I hope) navigating the balance between old and new.

Pretty is a Feature

Getting back to Java GUI’s, the challenge in this potential Java GUI renaissance is coming up with countless Java GUIs that are pretty. When shifting from one UI platform to another, you lead with sexy, and then follow-up with quick, followed by functional. On paper, of course, you want to provide integrated tools and builders to address the concern that development will take a long time if those tools are lacking. But, the first beach-head is establishing that the UI is gorgeous. Otherwise, why worry about all those paper concerns?

Put another way, as Schwartz said in his key-note this morning, new technologies will be “differentiated by fashion.” iPod!

As an off the top of my head suggestion, I thought of all the new Web 2.0 services that come out (seemingly) every week: Twitter,, etc. Each of those “little services” has an API, and once they gain a base level of momentum (everyone gets their network of friends over into it), people start building desktop applications or “widgets” to work with it.

As you may be thinking then, building Java GUI “widgets” around those services would be a quick-and-easy way to start showing off The New Java GUIs, esp. to the core early adopters: those roving bands of Web 2.0 nomads that hop from service to service.

Now, you might be thinking that battles already lost, but I’m not sure. People are building Cocoa applications around these little services, and if they’re willing to put in the time and passion to learn that style of UI development, why not Java? More importantly, if no one’s even trying, of course it won’t work (thanks to my inner Tautology Boy for that one).

Disclaimer: Sun is a client, as is Eclipse and part of Microsoft.

Technorati Tags: , , , , , , , , , , , , ,

Categories: Conferences, Development Tools, Java, Programming, Social Software.

Comment Feed

3 Responses

  1. Cote,

    Having worked with Java GUI's since 1997, Java 1.4 and Java 5 have brought great changes to Java GUI's. I keep hearing that Java GUI's are slow and cumbersome. And that used to be the case, however, in their current state they are not slow. As a company, we just celebrated our 5th year successfully selling a product that is entirely based on Java. I hope your article gets people thinking.

    I am a recent listener to your RedMonk and Drunk and Retired poscasts, I enjoy both formats. Keep up the good work.

  2. Thanks for the note, Brandon. And I'm glad you're enjoying the podcasts 😉

Continuing the Discussion

  1. […] I’m at Sun’s Analyst Summit in San Francisco along with Steve, Cote’, and James. Sun seems to have done a great job of turning themselves around–witness their “solidly profitable quarter“–but they still don’t get the kind of respect their technical achievements probably should deliver to them. […]