George Zhang's Blog

JDIC@JavaOne 2005 and Deeper Desktop/Java Integration

A Recap of JDIC@JavaOne 2005 

It's my second time attending JavaOne and the first time to be a speaker (of the JDIC BOF session). I was more excited about this JavaOne, because of all sorts of cool stuff and most importantly, meeting with many friends and JDIC participants after a long time email communication.

JavaOne 2005 is a yearlong milestone of JDIC, since its inception at JavaOne 2004. This year, we hosted a BOF session and a booth. The BOF session was well attended, with nearly 100 audiences, despite 15 BOFs going on at the same time. It went on with a 30 minutes presentation (slides), followed by a 20 minutes engaged discussion.

In the pavilion area, a middle-sized visitors dropped by the JDIC booth. I spent most of my time in the booth answering questions, showing off demos, and it's quite rewarding to get new ideas. Though, I would very much like to spend more time on those sessions.: )

A couple of bugs were brought to us, most of them relating to the Browser component, including:

• Session management with multiple pop-up browser windows
  This was fixed someway but we need a legal confirmation from the contributor.
• Using the Browser component (an AWT component) in a Swing application causes some issues.
  Browser as an AWT component comes from its implementation, which paints a native embedded browser window to a JAWT parent window. Allowing mixing of heavy and lightweight components is a known issue (Bug 4811096) in JDK. Hopefully, it can be resolved within JDK.
• Browser support on Linux/Unix platforms
  As Browser only supports embedding Mozilla on Linux/Unix, if Mozilla is not available, it fails. On Windows platforms, we are falling back to Internet Explorer if Mozilla is not the default browser. We've got in tough with NetBeans that, we may be able to make a NetBeans provided Browser component a backup if no Mozilla available. Though it needs more communication.

A list of new proposed features at the conference, with a few comments from my perspective:

• Java API to invoke native input system
• Java API to control native application windows
• Embed MS Office Excel or StarOffice
  This is just like the Browser component embedding a native browser. Embedding MS Office Excel wouldn't be cross-platformed, as Excel is not available on Unix/Linux. Embedding StarOffice can be a better alternative. Though, it depends on StarOffice, and we need to identify what specific functionalities are needed.
• Access to Windows Registry
  JDIC Filetypes API (package org.jdesktop.jdic.filetypes) resolves this problem in a cross-platform way. Though it's not as flexible as the Windows Registry API, it's cross-platformed, and provides pretty much the functionality needed by most applications.
• Access to network parameters
  Though this feature fits nicely into the JDIC SystemInfo incubator project, it's approved for inclusion in Mustang (See bug 4691932). So we won't do that within JDIC.

Some more general questions about the project were raised, including the platform support matrix, stability, JDK integration, etc, which were covered in the JDIC website. In short, JDIC got more visibility both in the community and among JDK teams, and we introduced it to many new users this year.

Features on the road

Right after JavaOne, some new features are being added to the project or under investigation:

• Most Recently Used document API
  This small feature adds a specified file to the Most Recently Used (MRU) list of documents, which are shown in the Start Menu of Windows platforms or Gnome/KDE desktops. To see how this API is useful, run the JFC demo Notepad bundled with JDK, the opened/edited files are not added to the MRU list of documents. This API provides such functionality in Java. It's to be included in the JDIC FileUtil incubator project. See the discussion thread for the API specification.

• Music Player Control API
  This incubator project provides a set of Java APIs to control native music players, e.g. Winamp, Rhytmbox, iTunes, etc. So, you can control your favorite music player to listen to music without ever leaving your Java application. See the project homepage for more information.

• Browser component support on Mac (embedding Safari)
  This has been under active development by Christopher Atlan, with a few issues to reconstruct the implementation to make it an AWT Canvas component. See issue#222 for updates.

• Browser plug-in container
  The first goal of this container is to provide a way to embed these plug-ins into Java applications through NPAPI, so developers could make use of these content viewers in their Java applications.
  
  The second goal is to use it to resolve the C++/ABI problem we have with the JDIC Browser component embedding Mozilla on Linux/Unix, as it has native C++ code and needs to work with a standalone Mozilla instance. We can wrap the Mozilla browser as a NPAPI plug-in, so the external interfaces will be NPAPI/C based, and then embed it into Java through the browser plug-in container feature.

Some guidelines for incoming features

Besides the features under working, we've got lots of feature requests on the plate, and more are coming everyday. Below are some suggested guidelines we accept or host new features in JDIC later on:

• Base on the votes and prioritization of feature requests through Issue Tracker
  Later on, all the feature requests should go to Issue Tracker, and be tracked there. There are vote and prioritization fields, just like the JDK RFE reports. If you want to see a feature in JDIC, you can vote on it or increate its prioritization with justification.

Many features are addressed by more and more incubator projects, each of them providing a set of relevant APIs. We filter those more desirable features to be hosted in JDIC from three perspectives: desktop/Java integration, cross-platform and availability in JDK. Those features on desktop/Java integration, having a cross-platform support and missing in JDK would have a higher priority, and a better chance to be hosted in JDIC.

• Align with JDK (Mustang, Dolphin) development
  Though we are not doing the project specifically for JDK, JDIC has many intersections with JDK. We can align the work to avoid duplicate. While we introduce new features into JDIC, we can first access the Java technology Bug Database, to see if similar features were already registered, planned or developed for JDK. Then we can communicate with JDK teams to see if there is an alignment. Some JDIC features were also registered to or planned for JDK, including the JDIC Tray Icon API integrated in Mustang b39 (Bug 4310333), and JDIC Desktop API to be integrated into a later Mustang build (Bug 6255196).

  On the other hand, Mustang won't be available until mid of next year. Despite lots of new features introduced in Mustang, there are many bugs around desktop/Java integration registered in the Bug Database, which fit into JDIC. If we work on such features, then would benefit the Java community more and have a better chance to be accepted as part of JDK someday.

More on desktop/Java integration

Besides JDIC, there are many relevant work or requirements out in the community. Read Colm Smith's blog Java and Desktop/Platform Integration, which commented on a couple of desktop/Java integration projects. It covers an interesting Java Service Wrapper project to enable a Java application to run a system service.

Another blog Why I can't get excited about JDIC by Elliott Hughes gives a long list of desktop/Java integration features that are missing for Mac, most of which are also missing on Windows/Linux/Unix platforms.

With all the listed feature requests falling into the scope of JDIC, we want your input to prioritize them and work together. Please raise your ideas and vote for your favorite features to the JDIC project !

Last bits ...

Coming to the end of this blog, I read ClientJava.com's interview with the developers behind Columba - Java Email Client, which "... proves that with the new direction Java is going so far, it can leave its bad reputation behind and be a good foundation for a modern desktop applications." That "new direction" means desktop integration. It's worth a read!

Comments

• As a self-comment, Christopher Atlan pointed a good OSS project http://www.roydesign.net/mrjadapter/ with some features requested in Elliott Hughes's blog. We can see how to work together if we address those features later.

  Posted by: georgez on July 25, 2005 at 06:48 PM

• I'm going to try posting this in the forum, but thought you might be a good person to ask the same question. Is there a project in Java similar to Konfabulator (soon to be Yahoo! Widgets)? I just tried it out and it's pretty cool, but I can think of many things that could be done with a Java API that it can't do. JDIC would be a good point for the base engine - for example, the Konfabulator engine provides details on CPU, RAM, disk, and other hooks to the OS, and the widget author just references those from JavaScript.

  Posted by: gerryg on July 26, 2005 at 08:37 AM

• Hi, I tried Konfabulator as well, which is very interesting. I myself don't know other Java projects similar to Konfabulator. As JDIC provides a varity of APIs/features like the SystemInfo project containing a couple of APIs to access system information. It can be a base for some kind of the widgets.

  Posted by: georgez on July 27, 2005 at 12:47 AM

• What's the best strategy for creating a lightweight Swing version of the browser component? i was thinking having the WebBrowser class extend JComponent instead of Canvas in order to take advantage of JComponent's z-ordering code. However, this causes the webpage to no longer draw anymore. Before i start on what could be a long journey, I wanted to verify if this is the correct path. I am looking to embed a WebBrowser inside of a JPanel in a JInternalFrame. Any assistance or advice will be greatly appreciated. to contact me by email: markf78 AT yahoo.com

  Posted by: markf78 on October 17, 2005 at 12:25 PM

• p.s. i forgot to mention (although perhaps it is implied from my above message) that i would then override void paintComponent(Graphics g). Inside that function, I then imagine I would need to (somehow) send messages to the browser to redraw.

  Posted by: markf78 on October 17, 2005 at 12:43 PM

• wow power leveling wow powerleveling wow power leveling wow gold wow items feelingame.com wow tips Most Valuable WOW Power Leveling Service wow power leveling faq cheap wow power leveling wow power leveling wow powerleveling wow power lvl

  Posted by: rinimade on December 24, 2007 at 06:49 PM

This work is licensed under a Creative Commons License.