Friday, June 18, 2004

JDesktop Integration Components

A friend pointed me to the JDesktop Integration Components (JDIC) project, which aims to provide Java hooks for accessing native OS features. It seems to follow the same philosophies as BrowserLauncher and SWT: essentially writing platform specific code for as many platforms as they can think of. The underlying code, isn�t necessarily elegant, but it�s a job that needs to be done.

"there is no way to emulate integration"

It seems to me that Sun should have taken this stance a long time ago. Everyone (including those within Sun) seems to understand that AWT died because of its philosophy of supporting only the least common denominator of components. Although it�s not often talked about, Swing has a similar problem. It emulates the look of a native application (with arguably decent success), but there is no way to emulate integration. A Swing app has no clean way to open the user�s email client, or minimize to the system tray. Even if Sun had gotten the native look and feels down perfectly and removed any and all performance issues, a Java GUI application would still fall short of its native counterparts. Java apps would always be limited to a subset of a native application�s possible features.

Not to pick on Swing too much, SWT has the same issue. Using native components doesn�t magically allow OS integration. While SWT applications look more native and run quicker than their Swing counterparts, they still run in a vacuum, cut off from the native environment.

I�m glad to see someone is tackling the problem. I hope they get the support of the community; and I especially hope the community learns the importance of this type of platform integration to the future of Java on the desktop.

Labels:

Tuesday, June 15, 2004

Waiting for the Future of the Rich UI

Joel Spolsky was praising Firefox today (and with good reason), but towards the end of his entry he made a comment I�ve seen repeatedly over the last few months: �...there's a glimmer of hope that one day DHTML will actually improve to the point where web-based applications are just as good as Windows-based applications �.

I don�t believe DHTML, javascript or any of our current web technologies will ever evolve to the point that they can compete with native client applications. Not that you can�t do some really cool things in DHTML, but in order to be truly competitive with native client applications, the resulting product would need to be maintainable by future programmers and flexible enough to grow.

Even after browser standardization and the creation of feature rich open standards (both of which are still a dream), the code will be made up of many different syntaxes glued together as an afterthought. A simple rich web application might be made up of XHTML with CSS and embedded with SVG and ECMA-script. Some of the code may be dynamically generated on the server-side. Some validation may be repeated on the client side. The server side code could contain any number of technologies (Java, J2EE, Struts, XSLT, Tiles, JSP, perl, python, etc.).

While its interesting from an academic perspective that a simple markup language was able to be extended to support such a wide variety of features, it doesn�t provide a very practical solution for our problem. For almost 20 years, we�ve known how to create a rich interface between the user and the computer. The only thing we were missing was a safe and easy way to distribute these applications. Rather than solve the original problem, we found an existing technology that didn�t have deployment issues (html) and tried to retrofit it to act like a rich client.

I believe a better solution is to take a rich client technology and find a better way to distribute it. This has been tried before:

  • Java Applets � failed because of lack of support by Microsoft, and because AWT wasn�t useful
  • ActiveX � failed because it was insecure and only supported by Microsoft
  • Java Webstart � failed because it only runs Java apps, and Java never took off on the desktop
  • Avalon � not released yet, but this will also only be supported by Microsoft
(For those of you who are easily excited, the term failed is a relative term. I simply mean that these technologies didn�t live up to their potential)

As I�ve written earlier, Avalon looks to be an exciting technology. But in the end, it�s a Microsoft technology. It�s bound to be an extremely successful tool within the Microsoft camp, but never touched outside it.

What I really look forward to is the rest of the community looking up from their servlets to see the bigger picture. When that happens I hope to see several independent solutions from the open source community (I�m guessing the first would be from the Mono team). Until then, back to my web app.

Labels: