A Desktop Java Renaissance

I finally got used to the new look of JavaLobby and am glad that the gliding nav toolbar stopped gliding. That’s one of those features that seems glitzy but just ends up distracting the user. Anyways, I responded to two posts and found myself thinking… there is going to be a Desktop Java Renaissance.

Why so? Hasn’t Microsoft frozen the JDK out of Windows? Sun has a workaround for that, with Java WebStart, the consumer-oriented Java.com, and the Java Auto Update system tray icon. Also, Java is installed by default on Mac OS X, SUSE Linux and Java Desktop System.

Doesn’t Swing emulate everything and make your apps seem slightly out of place? Sun has improved the L&Fs of Swing in 1.4.2 and 1.5, but if those aren’t native enough, you can use the Eclipse Foundation’s SWT / JFace.

Are there any Desktop Application Frameworks, so I don’t have to roll my own every time? Eclipse refactored the Rich Client Platform (RCP) out of itself, due to popular demand. Trivia: The RCP Birds of a Feather (BOF) session at EclipseCon 2004 was the most popular, leading people like myself to write my name sideways in the margin to jam myself in there. Thanks again to Ed Burnette for spearheading the RCP effort.
If you’d rather use Swing (since RCP requires you use SWT / JFace), then you have Spring Rich or NetBeans to choose from as a framework. I’m interested in trying out Spring Rich and will share my experiences with you.

Are there any components available, ala Visual Basic or Delphi, to speed my development? In VB or Delphi, there’s a large assortment of components that you can buy instead of build, which shortens your dev cycle. This has been lacking in the past. However, now there is a multitude of Eclipse plug-ins, most of which can be used in the RCP, with more being developed every day it seems. If that’s not enough, you can even embed native components (like ActiveX on Windows or WebKit on Mac OS X) through either SWT or JDIC (which integrates well with AWT / Swing.)

What about Enterprise Java? Don’t worry, that’s still alive and well and thriving. Not only will J2EE focus on ease of development, but there are alternative frameworks like Spring.

The reason all of this is occuring is due to plain and simple market competition. Eclipse raised the bar when it came to look and feel and plug-in infrastructure, RCP on the framework side, and Spring on the enterprise side. Eclipse plug-ins started to multiply as the platform became more viable. While this can cause some divisions for those deeply invested in one specific technology, I think this is good for the Java community as a whole, because the choices this competition creates lets us developers decide our own fates. (And if our choice is open source, we can even contribute to the production and not just be a consumer.) All the pieces seem to be falling in place for a renaissance for Java on the desktop. Things should get even better, once Eclipse 3.1, with its extensive support for developing RCP apps, is released, its alternative Spring Rich matures, and as the plug-in market continues to grow.

Interesting developments to watch: There seems to be an effort to make RCP easier to install via either: 1. RCP support for Java WebStart or 2. natively compiling Eclipse / RCP apps.

4 Replies to “A Desktop Java Renaissance”

  1. Hey – glad to hear you’re looking to try Spring Rich! It’s still evolving, but there already quite a lot there to have fun with.

    Think of Rich as a eclipse RCP lite built on Swing with a strong J2EE-app focus (nicely integrated with core Spring, of course.) Feel free to join in on our forums, mailing lists! We love the mind share!


  2. Java is *NOT* included on most major Linux distributions. In fact I’m pretty sure it’s only included on Java Desktop System and Suse. Sun’s licensing agreement won’t let most Linux distributions distribute the JDK at all.

  3. Keith (Lea, the 2nd one :) ),

    Thanks for correcting me on pre-installed Java on Linux distros. I updated the post. I found this long Javalobby thread on JDK/JRE on Linux Distros. I verified that it is on SUSE Linux and Java Desktop System.

    I use RedHat 3.0 and Fedora Core 2. If you look at the Fedora Core package list, you’ll find Ant, Junit, Struts, and Tomcat, which is kind of odd when you think that you need to get a JDK to make these things run. Since I’ve been developing in Java for so long, one of the first things I do when I get a new system is to get the latest JDK for it and make sure it runs. Note that RHEL apparently has an IBM and a BEA JDK on one of the included CDs that it ships with.

  4. There is another framework on the horizon that should give Swing developers similar, if not more capabilities than the Eclipse RCP. My URL (presently the new site we are working on is not yet ready to post) will lead (eventually) to a number of open-source projects. The core project is a plugin engine very similar to Eclipse’s engine, yet a bit different. On top of it is our framework, one that again will resemble Eclipse in some ways, yet offer differences as well, such as a weighted dynamicaly action updated menu system that caters to dynamic plugin loading and unloading at runtime, a small (but growing) set of components that could make developers lifes a bit easier when developing plugins for their application needs that are bundled with the initial framework. A decent set of plugins, all of which can be used or not used for their own applications. Other than the initial core plugins, you can use or not use the preferences, file i/o chooser, help system, non UI related systems like email services, web services, ftp, and more. A number of other features will be added soon after we get the initial rollout of the base framework, probably within two months. A “view” system similar to Eclipse, but different in some ways will be part of the base system, along with the weighted menu system and a context/focus based action system that can be worked from dynamically loaded plugins and update menuitems and toolbars including the ability to specify short/long menus (like MS style where a short menu shows only frequently used items and/or items that should always be shown). Another area we are planning on adding soon is access rights to plugins and areas of the UI. While not fully scoped yet, the idea is that an application may be used by different “levels” of users in an organization such that an Admin can see/do all, but CR’s only need access to a few of the areas of the app. Internally the core plugins that make up the UI and menus/toolbar buttons will make use of this to either enable/disalbe or hide/show items and buttons (groups included) allowed to be used based on the access level of the user using the app.

    The components library is also a project located there, the same components bundled with the framework.

    There is much to be done, but it’s coming along and should prove to be a very capable and robust framework to build applications on. We have a set of tools that will be hellpful for developers, including a plugin builder project tool to easily create/manage plugin projects, and soon an auto-update plugin with an auto-update UI tool that can “push” plugin updates out to clients, as well as allow a remtoe “look” at what plugins are running, activated and so forth of clients. This last feature is useful for both IT shops that want to push updates to a series of computers with applications using the plugin engine and/or application framework, and could even be helpful for CR and others in a company that get support calls, where they could use this tool to “peer into” a client’s running application (assuming firewall and other issues were overcome) to get a glimpse at the plugins running, versions, and so forth.

    Anyway, I am hoping to see our framework move on up with the likes of the Eclipse RCP and Spring Rich Client.

Comments are closed.