Ok, we all know that Java has the goal of enabling application portability to the most important platforms and devices, which in turn enables the largest possible market or user base for the application. But every now and again, I wanted to write a really slick desktop app that needed to do something on a platform that I could not do using a J2SE API. Shock, horror!

Although JNI is fine as a low-level universal bridge to native API's, it limits portability to the platforms supported by that native API. For those cases, it would be nice to have a portable Java API (perhaps not part of J2SE) but which includes appropriate a native backend "driver" to each of the platforms I need to integrate with (a little like Java Media Framework and its platform performance packs).

Well, the good news is that there are excellent solutions for many use cases, and there are some standard techniques for writing your own portable abstract API for use in your Java applications. I wish there was a good site to locate them all, but I don't know one - so I'd like to share a few of the best ones that I know about with you.

JDIC

The JDIC (Java Desktop Integration Components) project provides a set of independent API's under a common license (LGPL) and allow a portable Java application to use native features on many desktop platforms; your 100% pure Java code can:

• Launch or even window-embed a native browser (such as IE or Mozilla)
• Use the mailto: URL syntax to launch the desktop's registered mail application, open a Compose Mail dialog and set some attributes (subject, to, cc, etc.)
  
• Launch the desktop's registered handler application for a file type (such as a document or media)
• Register an application (such as your Java app) as the handler for a file type
  

The JDIC Packager is incredibly useful; if you create a Java Web Start (JNLP) setup to allow your application to be installed from any browser, you can use Packager to automatically create a native installer for Windows (MSI), Linux (RPM) and Solaris (PKG). Stunning stuff!

There are other JDIC projects in the incubator phase, including a Screensaver SDK (wrapper to allow a 100% pure Java screensaver to be integrated into the native screensaver system on Windows or X11 (Linux/Solaris) systems and the Tray Icon API (which appears in some respects to be even better than Systray for Java).

Java Service Wrapper

JDIC is far and away not the only resource for developers who need desktop integration. There is also the very useful Java Service Wrapper which can enable a Java application to:

• Run as a Windows service or as a UNIX daemon
• Re-start automatically if it terminates or hangs
  
• Have platform-dependent JRE configuration properties specified in a plaform-independent manner (using a configuration file), eliminating the need to write a platform-specific or path-dependent launch script
  
• Have its console output re-directed to a file or a system logger (Windows events or Linux/Solaris syslog)

While JDIC provides API's that  allow you to use features of the platform, Java Service Wrapper enhances your existing application to make it run better and more reliably on multiple platforms - very nice, to put it mildly.

OpenOffice.org technologies

Finally there are the OpenOffice.org technologies - UNO and the OfficeBean.

UNO (the ambitious acronym stands for Universal Network Objects) is a middleware for writing components or exposing API's that may be used from multiple languages, such as Java, C, C++, Python and even .NET-based languages. You can also implement components in most of these languages. The result is language- and platform-neutrality; component programmers can be productive in their favourite language, while application programmers can use those components in their preferred language. Whoohoo!

And the best part about the OfficeBean is that it is a component API written using UNO that allows an application to use or window-embed a pre-installed OpenOffice.org-based application, such as OpenOffice.org itself or a commercial product like StarOffice. UNO was designed to make it easy to add support for other languages simply by implementing a UNO Bridge.

Down to cases

Ok, so that's my shopping list of Java/desktop integration technologies - let's look at some use cases for these technologies; these are just a few that occur to me, using the example of writing a mail client using Java and Swing:

• you want to launch mail attachments using the standard registered desktop application (which could be native or Java) - simply save the attachment to a temporary file and use the JDIC-Desktop API to launch the app - job done
  
• you would like to give your users the option to use a full-power office productivity application to compose mail messages - you just need to write a simple HTMLEditorWrapper interface that can use either Swing's HTMLEditorKit or the OfficeBean - no problemo
  
• you want to render HTML mail messages quickly, but you also want to give the user full support for web standards if they need it; similar to the HTMLEditorWrapper you can create a HTMLViewerWrapper which can use the lightweight Swing HTMLEditorKit to display HTML, or you can use the JDIC-Browser API to embed the native browser in your Swing UI - quick and easy
• you want to be able to view document attachments right inside of your Java mail client; you can use the OfficeBean and OpenOffice.org-based applications to display Microsoft Office or OASIS Open Office (standard OpenOffice.org) documents - powerful

Roll your own Java/desktop integration API

I mentioned Java Media Framework earlier as an example of how you can provide a portable API that can use native components, but perhaps the best example of the right architecture is JDBC which provides an API for application programmers and an SPI (service provider interface or "plug-in" interface) that is used to develop installable drivers for different kinds of databases and/or platforms, including databases with native API's. Because each backend database (Oracle, Postgres, HSQLDB, etc.) is supported using an installable "driver", updates to the driver for a specific backend can be obtained or distributed independently of the wrapper/abstraction API and the applications that use it. Similarly, a Java/desktop integration API should consist of a portable abstract API, a mechanism for finding the installed set of drivers or plug-ins, and an SPI for writing and installing a driver. For example, the JDIC-Browser API could have one installable "driver" for Mozilla support, and another for Internet Explorer, etc; the best part is that the driver can be shipped with the backend (e.g. Mozilla) so that it is up-to-date, and because the SPI is Java, the driver can be linked reliably.

Epilogue

There are certainly more Java/desktop integration API's than I mentioned above. I'd like to leave you with some technologies and techniques for implementing your own portable Java abstract API.

• JOGL - an OpenGL wrapper technology used for example in Sun's Looking Glass project; JOGL is an example of a Java API that works with a portable native API; as long as the native API is feature complete and sufficiently portable for your needs, why not benefit from the RAD advantages of Java as a 100% portable application programming language and platform? (of course, Java has Java3D (now open-source) which is 100% portable and offers a very powerful model, but if you already know OpenGL top to bottom, JOGL makes good sense)
  
• com4j - a Microsoft COM API wrapper generator; alternatively you can use JACOB if you want to use only COM IDispatch interfaces and you prefer not to need generated code, and there are even more options listed on the Java/Win32 Integration resources page; com4j is not a portable abstract API, but it provides an effective means to write a Windows-based "driver" for a portable 100% pure Java abstract API
• SWT - I don't favour this technology because it attempts to solve a problem that's already solved in a 100% portable way by J2SE Swing; however, SWT's implementation approach (exposing the native windowing API via JNI using a 1-1 mapping to Java native methods) is worth considering as it has the advantage that most of the native adaptation code is in Java, although it has the disadvantage that it requires many fine-grained calls from Java to native code which impacts on performance

Hmm, that was a little more than I planned for one blog, I hope some of it was interesting to you.