Skip to main content

C Moon

Posted by editor on July 2, 2007 at 6:58 AM PDT

Native enough, or not yet?

Desktop Java developers who've felt a little fear and loathing over the Flash's encroachment on the desktop, in the form of AIR (the "Adobe Integrated Runtime"), might breath a little easier after reading Tim Anderson's Personal Computer World opinion piece Adobe’s AIR may leave customers deflated, which criticizes its dual-SDK arrangement (different paths for Flash- and HTML-based AIR development), and its lack of access to native libraries:

AIR applications have no access to native libraries, which ensures cross-platform compatibility, but also means weak printing, and little integration with other applications beyond clipboard support. Considered purely as a desktop platform, AIR is poor compared to either Java or .Net, which have richer runtime libraries and greater extensibility.

This lack of native access prompted Michael Urban to post a provocative opinion piece over on JavaLobby, titled Is AIR Making the Same Mistakes that Java Made? His premise is that resisting integration with native libraries and pushing a "write once, run anywhere" view of the world, which he thinks was a mistake:

Even Sun has largely abandoned the "100% Pure Java" campaign. In the end, 100% pure Java produced rather poor end user experiences since applications could not integrate with the host system at all. Thus, libraries such as JDIC came along. In the end, allowing no access to native libraries turned out to be a mistake. Is Adobe making the same one with AIR?

It seems like there's a bit of a mismatch between the two arguments, actually. Michael claims that pure Java "could not integrate with the host system at all", but Tim's original opinion piece notes that Java has richer runtime libraries, many of which are of course built on native code. For example, he notes that printing is weak in AIR. By contrast, Java's AWT has a fairly extensive printer API. It's not a hook to any native printing API, but rather a platform-independent layer above it. So while Michael complains about the de-emphasis of bringing in native libraries, he seems to undervalue the libraries already provided by Java, which in many cases are meant to satisfy the needs you might otherwise have to go native for. AIR's libraries apparently aren't as good, and it can't go native either.

This ultimately comes back to the core question of the relationship of Java, AIR, or any VM to its native platform. Emphasize the use of native libraries, and there's a good chance that few if any apps will be cross-platform, since developers would need to find equivalent libraries for each platform they intend to support. Quite plausibly, this scenario reduces Desktop Java to being another way to write Windows apps. On the other hand, making Java provide this isolation layer for everyone is a monumental task. iChat developer (and former Apple Java team member) Jens Alfke wrote "Desktop Java never worked because Sun tried to build their own OS on top of the real OS, duplicating every API and feature. This led to terrible bloat, making every app as heavyweight to launch as Photoshop."

Is AIR's approach to this problem simply to ignore it, to neither offer a tie to native libraries nor to develop its own OS-like layer atop the native libraries? Did Java make the right decision by taking on this challenge, and did they do it right? Or is the whole idea ultimately impractical, and are we resigned to native, single-platform apps anytime we want to fully engage the desktop user?

There's a few discussion topics for a slow week. Enjoy.

Also in Java Today,
the latest Core Java Technologies Tech Tips column covers cookie handling in Java SE 6 and advanced drag-and-drop. On the latter topic, author John Zukowski describes how to handle drag-and-drop with complex components like trees. "The text components offer built-in drop support, as does the JColorChooser component, but adding drop support to any of the other Swing components -- like JList, JTable, or JTree -- requires a little bit of extra work. The task might sound complicated, but thanks to the help of the new to 1.6 inner DropLocation class of TransferHandler, the task is relatively easy."

The latest edition of the JavaTools Community Newsletter is out, with tool news from around the web, new tools in the community, announcements of two graduations (DotNetFromJava and JEasyTest), and a Tool Tip on updating your project's info in the JavaTools project directory.

Our latest JavaOne Community Corner Podcast is
Java Mobility Podcast 10: Nelly Moser the Mobile Media Specialist.
"Dave Most, Mobile Application Manager at Nelly Moser, talks about the challenges in providing mobile media on a variety of handsets and how to separate form (UI) from the function to deliver a rich, satisfying experience to the user."

In this week's Spotlight,
the OpenJDK community has posted information and the first early access source for JDK 7's Modules. "This page covers the implementation of the modularity specifications defined by JSR 277 and JSR 294 as well as the related work in the JDK. [...] The Modules project hosts the reference implementation of the new core functionality and serves as an umbrella for other related work items developed by other OpenJDK groups."

In today's Weblogs, Bruno Ghisi
asks Does "High-level x Low-level APIs in MIDP" Mean "Portability x Usability"?!
"In this entry, I briefly talk about the differences between high-level and low-level APIs in MIDP, crossing usability and portability concepts. Then, I introduce three new high-level components that we will have in MIDP 3.0."

Mike Duigou has an update on
The JXTA Migration.
"For the last couple of weeks the JXTA project has gone through the difficult process of moving. Moving an open source project is, in most ways, easier than moving in the real world."

Finally, Kohsuke Kawaguchi discusses how to
Configure logging from the command line in GFv3.
"Logging improvement --- another small improvement to GFv3 development process."

In today's Forums,
fester wonders if there's a
notification of dividerlocation of JXMultiSplitPane?
"I am replacing a set of nested JSplitPane's with JXMultiSplitPane. With a JSplitPane, there is a property "dividerLocation" that you can listen to. I was searching for an equivalent in JXMultiSplitPane, but I found none. I want this to resize things inside one of the leafs when a user finished dragging the divider. Is there a way to do this with JXMultiSplitPane?"

cij100 has some implementation questions about ImageIO in
Artihmetic/Huffman lossless jpeg.
"I've been having issues with one of the readers that I use for testing images I produce when viewing lossless jpegs. The images are being wrapped in a NSIF/NITF file. The application can view the intermediate lossless jpeg that imageio produces, but when in a NITF file it contains lots of white pixesl/artefacts and some artefacts that span a line. [...] I now believe the issue is that the imageio is encoding the JPEG lossless using the Huffman principle (process 1), where as the NITF reader is expecting it encoded using the arithmetic (process 2). I understand the latter is normally avoided, but is there any easy way or translating between the two, or does anyone know of an encoder that can encode a Lossless jpeg with arithmetic processing (assuming ImageIO can't)."

hellraiser123 wonders about the prospects for
JSR 172 JAX-WS Support? "Is there any chance that JAX-WS getting integrated into JSR-172? Currently it supports JAX-RPC where as server side has already moved to JAX-WS 2.0. Since both JAX-WS and JAX-RPC architectures are different, i wouldnot like to build something on JAX-RPC1.1 if its going to become obsolete in say next 6 months."

Current and upcoming Java

Registered users can submit event listings for the href=""> Events Page using our href="">events submission form.
All submissions go through an editorial review before being posted to the

Archives and Subscriptions: This blog is delivered weekdays as
the Java
Today RSS feed
. Also, once this page is no longer featured as the
front page of it will be
archived along with other past issues in the href=""> Archive.

Native enough, or not yet?