Java on Handheld Devices?

superfred queries: "I work for a Java-based software company, and have been tasked with researching Java on handhelds...I've managed to dig up information on which handhelds support Java (most of the major ones do), but what puzzles me, is if any company is actually *using* this for any reason (besides Java-based handhelds/phones). The Palm OS has apparently supported Java since the Palm V, but has anyone written any software to take advantage of it? Are there any major software developers working on Java applications for handhelds? It seems like a great deal of effort has been used in getting Java on these platforms, but nothing's really utilizing it."

Comments

Networking

[Blinkenpilzen]

I dunno about major players but we've been using it to port some of our networking code to the Palm platform. Not having to rewrite everything for gcc was quite a time (and $$) saver.

We're developing a java-app for handheld

[Hektor_Troy]

Well - it can run on handhelds, and considdering the point of the program, it's a neat idea to do so. It's a building automation monitoring applet running off a _very_ small embedded webserver, meaning the entire program has to take up less 256 kbytes.

This limitation means the program has to be lean and sleek, and it starts in less than one second on an average office PC. Of course, this probably means a five to ten second startup time on a standard handheld, but in this case, being a fast starter isn't a requirement. Taking up less space than your average word-document _is_.

The fun things about making such an application are the limitations you're stuck with. Since I've started I've been forced to scrap several ideas for implementing stuff, simply because it takes up too much space. Right now I'm 97% finished - and I've cut the program down to 22 kbytes. Who said that programming in java means programming bloated applications?

Re:We're developing a java-app for handheld

[evilfrog2]

I work for a company which is doing J2ME development. The device constraints are even more severe on cellphones! Total application size can be limited to something like 50-90K.

We develop "enterprise" applications, ie the usual database-driven screen/field kinda stuff. I wrote a stripped-down SQL database for J2ME which takes up less than 20K. (Originally we were using a commercial 3rd party database but it was too big and way too slow.)

Like the previous poster, I found it to be a fun challenge. By today's standards, it requires "Real Programmer" skills, as opposed to more typical "Java developer" skills.

Of course the market is tough, but there does seem to be some interest in this sort of thing, primarily on the basis of cost savings (to the customer). Mobile empoyees already have cellphones, maybe even PDAs, so the cost of the "solution" is low. But enough of that; I'm a Programmer not a Marketroid. :)

Why?

[SteveX]

Java, when it comes to handhelds, is theoretically great for the developer, because the developer gets to write an application once and have it run on all the different handhelds..

But it sucks for the user, because they're getting an application that's not taking advantage of the native abilities of the platform. When the platform is as limited as a Pilot or an iPaq, software that is written natively for each particular platform or device to get as much out of it as possible will be much better than software written for the lowest common denominator.

In a situation where the developer has a pretty good idea of where the software will be running (ie someone targetting PocketPC or PalmOS) the "write once run anywhere" benefit of Java doesn't really apply. Or at least, it applies to Java as much as it does to C code - to get the code to run well on both a Pilot and a PocketPC, for example, it's going to have to be somewhat different.. and if you're building a native build for each target anyway then why use Java?

That's one of the reasons Java is doing so well in the server market - the "write once run anywhere" part is really useful, and there aren't really any native GUI features or hardware aspects of the local system that the software needs to exploit; to a developer, pretty much any web server is conceptually the same (and if there isn't enough RAM, the sysadmin can add more, and if it's too slow, well, upgrade the box).

When you're talking about devices as diverse (in CPU speed, RAM, input methods, IO, etc) as handhelds, it's a different story.

For example, in my Java applet if I want to read whether or not the button on the top left corner of the device is pushed in or not, how do I do that? And if I do it so it works on my iPaq, will that same code "write once run anywhere" on the Clie? What button will provide the same input? Will I be able to use the jog dial of the Clie? I don't know the answer to that, but I expect not..

I don't see a lot of desktop Java applications, and the ones that I do see are generally slower and more, um, clunky, than the stuff written natively. And slower and more clunky is the last thing you want on a handheld.

- Steve

Blackberry

[NoseyNick]

The Blackbrry wireless email gadgets in NA are C/C++ based, but the European ones (and the one slashdot showed recently with the headphone) are java based, the "OS" is a J2ME VM, all the apps (including email, address book, even the phone) are java, and there's a fair movement of 3rd-party developers writing stuff for it too.

We were forced back to Linux

[PyroJimmy]

We've had a couple of people in my lab looking into handheld devices with Java solutions. The fact is, many of the devices and OS's that claim to support Java only support a subset of the packages.

Since we wanted to use the Corba classes in Java, many of the options we looked at simply didn't have that implemented. And few (if any) devices actually support Java 2 1.3.x, which we needed to use the Swing classes.

In the end (and I know the Slashdot crowd will love to hear this), we snagged an iPaq 3670 and installed ARM Linux on it, which allowed us to install Blackdown's Java-Linux runtime environment. Beautiful.