Does Java Work On Handheld Devices

DoesJavaWorkOnHandheldDevices? Does someone know a Java device that has neither failed technically nor failed at market? -- SunirShah

Check out the SharpZaurus. - BillZimmerly

The SavaJe? folks are doing some fantastic stuff with their Java based OS on the Compaq iPAQ (See http://www.savaje.com/). They've solved the speed issues mentioned below by avoiding the use of a VM on top of an OS and simply making the OS, itself, the VM. Also, this isn't some stripped down version of Java, it's a complete J2SE version of Java on a small, but powerful device. -- MarkCrocker

That depends on what you mean by "Java". And what you mean by "Java device". There are plenty of SymbianOs boxes out there running P-Java, but the interest now is in KVM and MIDP (MobileInformationDeviceProfile), and there are already a bunch of phones out there quite happily running MIDlets, and plenty of slightly gimmicky MIDP applications to download onto them. MIDP implementations are coming thick and fast for the other PDAs; PalmOs has a pretty good one.

No-one is going to by a phone or PDA because it has a JVM on it, but being able to download and run MIDlets is viewed as a nice value-add right now. And many hardware manufactuers are betting that it's going to be a must have standard feature sometime over the next few years.

If the proposed blurring of the hand-held market takes places as advertised, MIDP/CLDC (or MIDP-NG, whatever that turns out to be) could very well become the preferred environment for applications on communicators. How much sense it makes to deploy onto a device with a big colour display and a few meg of ram using a platform optimized for phone handsets is another, interesting, question. -- KeithBraithwaite

Our analysis shows the KVM is 15 times slower than native code for simple arithmetic and array manipulation. To give others an indication of what this means, this would turn a Palm III into a sub-1MHz machine. Similarly, it turns an iPAQ into a Palm III. Since people do in fact use Java on handhelds, I'm guessing I'm missing something big and important. ??? -- SunirShah

The KVM exists to put Java onto phones; its goal is to have people write in Java when they write apps for phones. Sun's reference implementations suck, of course. So use the platform vendor's (some of them suck too, but not as much, or differently, anyway).

Meanwhile, what you're missing is, one: that the KVM is targeted at "smart" phones, not PDAs, and that the kinds of applications that people deploy onto smart phones require almost nil in the way of arithmetic or array manipulation, or indeed computation of any kind. They do very simple things, very simply. A lot of them are (very) thin clients of one kind or another, and most of them tend to be task-based, the user starts the app, does some simple thing, then shuts it down. On a device with a 60X80 mono display, you need very little in the way of BogoMips to do smooth animation even.

Sure, the KVM is slower than native code, but it's also much, much easier to write for, and CLDC/MIDP is a lot closer to write once run anywhere than J2SE ever was. CLDC and MIDP together give every device they run on (which doesn't imply a KVM, by the way) a JAD environment. Compare the effort needed to get a minimal MIDlet app written, compiled and deployed vs that needed to get a minimal EPOC C++, for example, app going. J2ME is easily an order of magnitude quicker to work with. Plus the world is full of .com refugees who can learn J2ME in hours, versus the handful of people that know whatever horrific native platform the phone in question runs.

The second thing you're missing is that to the mass market the slow-down from having an iPaq running at full tilt to having an iPaq running like a Palm III is, in the general case, of entirely no interest whatsoever. The /92[19]0/ is the best selling PDA in the world. Because it's fast? No. Because it's easy to use? Good god no. Because it has lots of powerful apps? Nope. Those machines are a not so great implementation of an iffy design (as Nokia aren't ashamed to admit), and they still sell by the skip load. There will be some performance threshold that, if below it, a PDA will lose sales. Even with the shackles of KVM around their feet, the current, and next, generations of PDA will we well over it.

What the PDA folks get from CLDC/MIDP is that same JAD environment + hordes of programmers, plus buzzword compliance, plus the ability to claim a huge body of apps ready to go on their box. What they get from KVM is more breathing space in their ROM budget, given that they get all the stuff mentioned in the last sentence. So the app is a little sluggish? Most PDA platforms have the GUI bells and whistles to distract the user from slow responses, to the point where they don't notice, if it becomes an issue, which often it doesn't. -- Keith

We do graphics on handhelds. I'm guessing from your description, we're in for a rough ride. The 15x slowdown was the platform's version. We've done a lot of magical things in C and C++ to make our implementation work well; Java is painful because it prevents all those nice things. Even a union would be nice. Fortunately, Java is all for argument's sake right now and consequently not my problem (yet). Thanks for the help, Keith. -- SunirShah

No problem. One of our areas of interest is "things to make life easier for Java programmers on communicators", so I'm always interested to hear about this stuff. In the MIDlet world, what you'd probably do in your case is write your own implementation of javax.microedition.lcdui.Canvas as a place to put your magical things. That blows WORA in one direction, MIDlets written for your go-faster library probably won't work anywhere else, but if you were smart about it, maybe graphics intensive MIDlets written elsewhere could run on your platform and get some speed advantage. Tricky. But, when you get right down to it, a partial answer to the question DoesJavaWorkOnHandheldDevices? is the same as to DoesJavaWorkOnDesktopDevices??: not if you need the full capabilities of the hardware. As mentioned elsewhere, it seems that if you really want to write sophisticated apps that run fast in small memory, there's nothing higher-level than assembler to beat OCaml. -- Keith

Well, you know me. I don't think Java works anywhere. But I don't get to choose who works in this industry, nor does anything I think matter. So, while it would be nice to put native code onto the devices, that isn't always possible. The thing is, not a single Java-only device has survived in the marketplace, so my continued opinion will be to ignore Java and it will go away. Of course, will my managers/customers agree with me? -- SunirShah

Ignore Java at your pleasure. Bear in mind that "Java only" devices aren't on anyone's agenda anymore (not after the JavaStation fiasco), whereas Java enabled devices are still a big, big market, that isn't going to stop growing any time soon. Not unless .net takes a big chunk of mindshare, anyway (I predict that .net will have about as many performance problems on small machines as Java has). You can choose not to be in the Java-on-handheld market, and good luck to you if you do. And I mean that most sincerely. Me, I'm not that proud anymore: it's nice to know someone still is. -- KeithBraithwaite

[You know, this is really difficult to talk about without getting sued from some party.] .NET isn't as much of an issue. First, the bytecode is only redcode, so it gets converted directly to machine code before executing. I haven't read into it yet, but I have to soon. I expect it will be to C as JASM is to Java: i.e. a direct translation (which is why Java bytecode is so bad). The problem then becomes understanding this redcode layer between your code generator and the final code generator, an extra layer of cruft. Second, wherever .NET will run, so will VC++ (I hope), so I'm not holding my breath.

My honours project is embedded virtual machines too. I'm fairly convinced now that it's more likely that handhelds will standardize on one processor (the StrongARM) and one OS (either PalmOS or WinCE, but think MacOS vs Windows in this fight) rather than on one VM. VMs are just the wrong answer. I honestly think people just don't get what a VM is. -- SunirShah

Have you seen the Tao Java environment? It's going on the forthcoming Sendo Stinger phone. They've clean-roomed AWT etc on top of their very fast "virtual processor" stuff. Looks interesting. Don't have any hard numbers for performance.

How about the RIM Blackberry (recent versions, not the originals)? All Java (the OS is Java), and it's surviving quite well in the marketplace. -- Bill Sheppard

Java on PocketPC

(as opposed to JavaOnThePalm)

"JAVA for PocketPC PDA" by Stan Berka http://www.berka.name/stan/jvm-ppc/java_for_pda.html

"Java on PocketPC (Unofficial FAQ)" by Vik David http://blog.vikdavid.com/2004/12/java_on_pocketp.html

See JavaOnThePalm, WikiOnPda

As of 2008 the answer is 'yes, on millions of devices'!

CategoryJava JavaLanguage