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.wormvirus, 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.