Posted by georgez
on July 25, 2005 at 2:58 AM PDT
Beginning with a late report of JDIC at JavaOne 2005, this article takes an exploration of missing features in the scope of desktop/Java integration and solicits inputs to prioritize them to enable deeper desktop/Java Integration.
This blog gives my late report of JavaOne 2005, basically staffing the JDIC
show, and an exploration of missing features in the desktop/Java integration territory,
the focus of the JDIC project. Bridging such gaps would backup Java at the
center of client-side development.
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
- Session management with multiple pop-up browser windows
This was fixed someway but we need a legal confirmation from the
- Using the Browser component (an AWT component) in a Swing application causes some
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
- 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
- Access to Windows Registry
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
- 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
- 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
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.
- 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
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
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
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
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!