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.