Holy handheld, Batman! They put Java where?!

When Sun CEO Scott McNealy talks about the advantages of Sun's technologies, he often refers to how everything the company makes is binary compatible . In a recent interview I did with McNealy, he once again noted the binary compatibility of Sun's entire range of systems --- from the smallest $1,000 box right up to systems costing millions. While there is some value to that compatibility, it should never be mistaken for this reality: The mission-critical ERP system running on a million-dollar server cannot be loaded onto the hard drive of a $1,000 system and deliver the same results. Footprint matters.

The same is true about Java, of which McNealy is equally fond. He and other Sun executives will often talk about how all versions of Java have the same security model, the same networking model, and so on. Their message could easily be misconstrued to mean that the same Java code you write for one client device will run on any client device that has a Java Virtual Machine (JVM) on it. It's not that simple. Again, footprint matters.

The gap between the JVM that many PCs are running --- Java 2 Standard Edition (J2SE) --- and the JVM available on many handheld devices --- usually some derivative of Java 2 Micro Edition (J2ME) --- is bigger than you might think. J2ME is designed to run in much smaller footprint environments than its bigger sister J2SE. For the most part, smaller footprint means less processing power and less memory. Naturally, J2ME entails some sacrifices.

One of the more notable sacrifices has to do with how easy it is to control Java's graphical user interface (GUI). All versions of Java have a low-level graphics system called the Abstract Window Toolkit (AWT). Using AWT, programmers not only can do just about anything with the GUI but, unfortunately, they have to do everything. As a result, Java programmers working with AWT must essentially write their own GUIs -- building everything from menuing routines to other GUI staples like buttons and scrollbars. That's where Swing comes in. Swing is basically an abstraction of the AWT. It uses AWT, but makes it a lot easier. Programmers don't have to worry about low-level programming. Building menus, for example, is a cinch. Swing is one of those sacrifices that programmers must make when moving from J2SE to J2ME. That's understandable since the attributes (especially size and resolution) of the displays most often associated with J2ME implementations (like mobile phones) are so unpredictable.

Another notable technology that gets sacrificed when moving from J2SE to J2ME is Java Database Connectivity (JDBC) -- Java's API for connecting to databases. For developers of enterprise applications that invariably rely on databases, the loss of JDBC is not insignificant.

Left to write their own APIs, programmers wanting to rely on the write-once run-anywhere promise of Java can reuse some, but not all, of their code. In some cases, programmers could find themselves writing bits of device-specific code that can't be re-used anywhere. The scope of the problem increases by orders of magnitude once vertical integration with customers and suppliers becomes a corporate imperative. It's one thing when device-specific code is required for applications being rolled out to internal staff, such as a CRM app for the sales team. To ease the burden on corporate developers, the IT department can standardize on the devices that will be handed out to the sales folks. But once the scope of the application stretches beyond the boundaries of the company into constituencies where there is no control over the client device, it's a whole new ballgame.

To boldly go where no J2SE has gone before
Enter a small technology company out of Chelmsford, Massachusetts: SavaJe Technologies.

If the company's motto isn't "to boldly go where no J2SE has gone before," it should be. SavaJe's promise is to overcome the limitations that force handheld manufacturers to go with J2ME instead of J2SE. In other words, SavaJe is putting a JVM in small-footprint handhelds without sacrificing the functionality of J2SE, or the performance of J2ME. As evidence of this, SavaJe co-founder Matthew Catino likes to show off a Compaq iPaq that's been stripped of Microsoft's Pocket PC and re-loaded with the SavaJe XE Operating System. The demo unit, which I've been carrying around since Comdex Fall, makes it evident that the best way to deploy Java-based apps in handhelds could be to dispense with OSes like Pocket PC and PalmOS in favor of a pure, high-performance implementation of J2SE.

SavaJe could be onto something, provided Java continues to win the hearts of developers. XE comes with most of the PDA prerequisites: calendar, browser, contact manager, note taker, task master, e-mail, a few games, and even an MP3 player. All are Java-based. But the real benefit of XE is that developers can get much closer to writing once and running anywhere. According to Catino, XE is outfitted with all the APIs found in J2SE. That means minimal code modification is required when deploying across a variety of targets such as desktops and handhelds.

For the same reason that most handheld implementations of the JVM are J2ME-based, one concern for most developers is performance. Surely, the thing must be a pig.

Not.

Catino's favorite demo shows how the XE-equipped iPaq can multitask 2D graphics and other applications like contact management without breaking a sweat. I was so impressed, I decided to show it around to a few other folks that might be interested.

PalmOS CEO and president David Nagel asked me to have Catino contact him. Same for Randy Smith, senior director of Samsung Electronics Wireless Terminal Division (the guys who make the PalmOS-based i300 cell phone). Even McNealy is excited by the prospect. When I showed XE to him, he said that part of his vision was to one day see Java 2 Enterprise Edition (J2EE) in handhelds. J2EE?! Talk about a challenge. Well, if that's his goal, SavaJe appears to be a lot closer to getting Sun there than Sun is itself.

About the only problem with XE right now is that there's no synchronization application like there is for Pocket PC, PalmOS, and other handhelds. According to Catino, that's next. I believe him. Writing a synchronization application is trivial compared to what the company has already done.