« May 2004 | Main | July 2004 »

June 2004 Archives

June 3, 2004

JDIC criticism misses the big picture

One common problem you will see on news forum sites like SlashDot and their ilk is that sometimes the people who write comments to the posting don't read the article or only the first and last paragraph. But what happens when it's not an article but an open source project with big name sponsorship and instead of a comment it's a weblog post on the same sponsoring site? Less Comments.

When Jonathan ranted about how JDIC missed the point in reality Jonathan missed the point of JDIC. It appears that instead of reading what the project is actually about he skipped down to the screenshots and critiqued the sample application code itself and not the actual content of the JDIC project. But to make sure the causal reader who has 100 to 1000 aggregated weblog posts to read can get the point of my response I will use a larger font, write it in bold, underline it, and blockquote it. (I'd use the flash tag but no mainstream browsers support that anymore).

JDIC has nothing to do with Swing.

For those who are sill reading, I lied about the larger font, bold, and underlining. I just didn't have the heart to be that mean. But with enough whitespace around it a person who is scanning will see that the only realtion between JDIC and JFC/Swing is that they are written using Java.

To give Jonathan credit, showing the three different platforms for the same screen shots does lead one to believe that the demo apps are the real product. But in reality all the criticism levied in the article actually lands squarely on Swing because the demonstration of the features happen to be written in Swing . None of the classes from the project itself use Swing, and the only GUI component in the project is actually a subclass of an AWT class. I'd respond to the Swing criticism, but instead I'll direct interested readers to a previous blog entry I did on the same subject (executive summary: Microsoft Office XP and 2003 don't look like windows either). And there is a great projects on Java.net to address the GUI differences called winlaf. The dev builds of NetBeans v4.0 use this to great effect. But I'm going down a rat hole.

What does the JDIC provide anyway? According to the documentation link on the project page (the sarcastic commentary is my doing).

  • An AWT based web browser control.
    The reference implementation uses Mozilla, but why use HTML when you've gone tot he trouble to write a Java GUI? Oh yea... Ads.
  • APIs to open files for viewing, editing, or printing on the native system based on their file types.
    You can start an MP3 file with Windows Media Player, Real, iTunes, or whatever they have their OS configured to use. Better than Runtime.getRuntine().exec("c:\\my music\\stolen.mp3") because it's not owned by the opening process.
  • APIs to associate programs with said file types.
    Just what Java needs, more "JNN is not registered as the default News Reader, would you like to register it now?" dialogs.
  • APIs to open up the system mailer with a particular message.
    One step closer to the killbill.j2se.worm virus, or generating crash reports. Those are two different items right?
  • A program to wrap up your WebStart applications in to platform native installers.
    Clicking on a link in the platform native web browser must still be to hard, wizards are much easier. Especially since all of us use computers that are online all the time and we never install anything from a CD-ROM.
  • They are also looking at adding screen savers.
    Wasn't the SoBig worm sent through screen savers? Or is this for distributed.net?

A poorly written Swing application certainly could use these. And I am sure some of them will. And they will call the APIs in the event dispatch thread (despite all of the documentation instructions not to). Hence, people will think JDIC is slow, and not use it. So really this is a moot issue.

June 9, 2004

MovableType Surprises

Brian Duff has learned the hard way that public blogs don't exist in a vacuum. Fortunately I rarely discuss products I work on or co-workers (not current ones anyway), and I only write bile after sitting on the entry for a day. If I'm lucky I won't have to do a Blog mea culpa, but that's the chance I take.

But the problem is that the old permalink still goes to an actual page. Removing the info from a Movable Type database won't wack the old HTML files that are generated. And people who read via aggregates may still have their old feed entries. I also use MT and was surprised at this behavior. Perhaps a best practice would be instead of deleting an entry in it's entirety one should replace the text with either an reference to a future entry explaining things or some statement like "this isn't the blog entry you are looking for" and an image of someone waving their hand.

However, the last few lines are worth preserving IMHO...

Customers actually vocally complaining about the problems on forums makes a difference that all of our internal yelling seems to never achieve. So *thank you* Jdev forum customers. By yelling about this, you're helping to make it clear that this actually is a problem at last. [duff blog link may be dead]

The reason that I think it's interesting is typical usual corporate positions are that complaining in forums gets you nothing and you should use normal $upport channel$, for $ome $trange rea$on.

June 17, 2004

Java WebStart and Desktop Integration

JDIC or not I think some people at Sun are getting some issues related to desktop integration and building them in. Some of the chagnes in 1.5.0 are ho hum but some of them address JDIC type issues:

  • Ability to specify where in the Start menu to install the startup shortcut
  • Ability to add extra stuff to the menu, like ReadMe docs and support links
  • Ability to associate MIME types and file extensions in the desktop shell with your WebStart app
  • Ability to detect another running instance of your app and send startup info to that instance
  • An Import Mechanism, so you can install apps from CD from and have them update from the web

All of these are great, but today I saw the best surprise of all (better than GridBagLayout throwing array index exceptions). While re-installing FireFox I saw that my test WebStart program was actually in the Add/Remove Programs Dialog! No more hokey stuff about going to the WebStart panel to clear out an old version, now I can tell SEs over the phone "OK, click start, control panel, Add/Remove Programs. Now find..." "Look, I'm not that stupid I know how to remove applications" "Apparently you don't or you wouldn't have opened that ticket as Urgent."

June 24, 2004

JDNC and the SwingX Project

After a year from when it was announced finally we see something from the JDNC project. Let me say I think it has a brighter future than the JSF project. Web Clients have their role, but just like Television Actors sometimes they overextend themselves. On a quick pass it looks a whole lot like XAML will be for longhorn, except you don't have to wait until after the Star Wars Episode III Special Edition DVD is out to use it in production.

But I am straying from the point I want to make. XML is the topmost layer of the JDNC project. What I am more excited about is the standard swing component extensions, which comprises the lowest layer of the JDNC project. For the level of Swing that I have been coding at those provide the most tangible value today. Why? Couldn't I just write or fork a TreeTable or Form interface of my own? Yes I could, and it would forever live inside the walled garden that is proprietary apps. Don't get me wrong, I've already done it for a DataPicker widget. But what this offers is a common standard extension to the swing components from Sun, one where the components might one day make it into the JDK.

Back when JDIC was announce I nearly wrote an article calling for a STSC project: Standards Track Swing Components. Some collector project on java.net where common swing components could try and evolve in some sort of a standard environment and possibly be included in the standard J2SE one day. It's much to late late at night for me to recount the details of how it would have gone down, but it would have been a standard set of common widgets that have some brand of authority. For example: look at the number and quality of data picker widgets, wouldn't it be nice to have a standard one like MFC does? And look at the widgets that Java Look and Feel (and the advanced topics) describes that do not exist in the JDK: sorting tables (two ways none the less), tree tables, Wizards, badged icons, and even toobar drop downs. All this in a published "do this" standard and no common implementation. No wonder VBers run from swing, they see cool stuff like that and say "I'll stick with MS" when the article starts talking about TableModel, EventListeners, and when to call repaint().

The SwingX subproject in JDNC can fill this role in my opinion. In fact they have a good portion of the items I just listed as part of their standard package (althought the date picker needs serious help, I don't think it will be hard to get it). Two suggestions I would have would be first to formally make SwingX a subproject of JDNC. Next they need to either drop the LGPL for a variant of the MPL or require a dual license for all submitted patches so that contributions can be brought into the core Java Runtime in the Mustang or later release. A Joint Copyright Assignment is required to contribute code.

If those things are done then when a kewl component like the JSpinner is released, it can first be hashed out in SwingX and then placed in the JDK later. Telling people that they have to upgrade their client JDK just because I used a spin box for number entry got me some strange looks and a good bit of grief.

About June 2004

This page contains all entries posted to ... And They Shall Know Me By My Speling Errors in June 2004. They are listed from oldest to newest.

May 2004 is the previous archive.

July 2004 is the next archive.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.33