Skip to main content

JDIC@JavaOne 2005 and Deeper Desktop/Java Integration

Posted by georgez on July 25, 2005 at 2:58 AM PDT

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
component, including:

  • 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
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
  • 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
    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

  • 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
    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
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
    , 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
    ), and JDIC Desktop API to be integrated into a later Mustang
    build (Bug

    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
'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
project !

Last bits ...

Coming to the end of this blog, I read'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!

Related Topics >>