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 are prototyping

[Clockwrk]

My company is starting to look this direction. We do field data capture on Palm's already. The next gen we are looking at java-enabled devices. But is seems that java is still too slow on these devices. Maybe as processors speed up, this will be a better option.

Realistic uses of Java in Handheld Devices

[AlaskanUnderachiever]

I've seen a few programs on Palm OS (3.5 and higher) that utilize Java but they all seem to be (comparatively speaking we are talking Palm here) to be a bit bloated and resource needy for what they did (one was a game and as I recall the other one I used for a bit was a training log of some sort for sports). I am not a programmer myself, nor claim to have any experience with Java, but based on personal experience with Palm and Java it seems to me that it's just another added layer of unneeded complexity on what is a relatively tightly coded device. I think we might see more Palm "ports" of java in the future, but for now I doubt it's going to be very usefull in it's current form.

Java on Palm OS

[ardiri]

Java on the Palm has not been a major success primarially due to the processor speeds :( a number of virtual machines have been available (KVM (now, official j2me), waba) - and, there was even a project called "jump" which would compile java code natively into m68k code on the palm (but, lacked a lot of support) - [find it on sourceforge.net].

i am a Java programmer myself, been doing so since mid 1995 (heck, remember the 1.0 beta) :P but, i have spent most of my development on the palm using C, and, where necessary for speed - resorting to native m68k assembly routiens. it just isn't possible to do something "impressive" with the Java engines are they are now - unfortunately :) but, it all depends on what you need it for.

"No one's using it". Know why?

[dmorin]

I was at JavaONE when they gave out hugely discounted Palm V's as a way to promote Java on the Palm. That was years ago. People still aren't writing lots of apps for it (I have heard about some dedicated, internal applications where you can give your people a pre-configured Palm w/Java). Know why I think that is? Why hasn't Palm managed to put the JVM into the machine by default? If the device was inherently able to run Java, and I could just send out JAR files, I think it would be a huge win because your typical customer doesn't really care about the difference between an executable, a data file, an interpreted bytecode, etc... But if for any application I want to make I have to include a whole lot of junk that is just going to confuse them, that stinks. Also, it makes my app smaller. Imagine the subliminal message that's sent out when you say "In order to run my 100k program you need to download and install this 5 meg program." (sizes made up, of course). It makes people think that your program is tiny, and that this other "support" code thingie is going to be wasting all of your precious memory.

I wonder if the introduction of Java as a supported development platform for Palm would help them with market share? I mean it's not like there's a shortage of applications for the Palm now. What's the big hook from Palm's perspective to do this? I can understand why I as a Java programmer want it, but why would Palm care?

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. :)

Get to JavaOne

[deanj]

First, if you can do it at all, get yourself to JavaOne. It starts on March 25th, and usually has the handheld things that are either just coming out, or are about to come out.

Off the top of my head: Sharp Zaurus PDA, IPAQ (either running Windows or the complete Java replacement OS, the name of which escapes me at the moment), Palm (you know that already). Bigger "handheld" Windows devices, like tablets, can also run it, but you have to look at which chipsets these things support.

Phones can do this too... some are Palm based, so you can use those. Others, like Motorola's i85s (you can get this via NexTel) have been running Java for a year. No idea what the cost to run this would be for networked apps.... these phone companies like to charge out the ying-yang for service. There's a new wireless service in South Dakota that gives all you can eat wireless service for $50. Not sure how widespread that'll be, but hopefully it'll become more commonplace.

Nokia is building Java into all their phones,and Sprint is working on stuff too. I don't know if they'll have products announced at JavaOne or not, but they both have either regular sessions or "Birds of a Feather" sessions planned for during the conference.

good luck

Re:Get to JavaOne

[macpeep]

"IPAQ (either running Windows or the complete Java replacement OS, the name of which escapes me at the moment)"

You are probably thinking about SaveJe (http://www.savaje.com/).

Ack!!

[MrBandersnatch]

Im not a major developer by anymeans but for what its worth I've been writting a Java application that works on both handhelds and PCs for the last year.

And let me tell you it is a pain in the arse.

The JREs that are available tend to be commercial and on WinCE certainly - far slower than the (free) beta JRE that Sun (silently) dropped support and development for last year. Add to the speed problems the fact that the supported JREs (if they are not embedded already into ROM) add SERIOUS bloat to memory (3-6 MB ) and being tied (realistically) to 1.1.8 (if not 1.0.2 in some case) in order to obtain wide portability and you have some major hassles in store if you want to develop a single codebase for multiple platforms.

I would STRONLY advise anyone considering developing any substantial application for handhelds to avoid Java like the plague and instead concentrate on writting efficient portable C or C++ code.

J2ME MIDP & PDAP

[jon_eaves]

If you go and read the Sun Wireless sites, then you will understand what's going on.

The reason there has been a delay is that there is two configurations for J2ME. The MIDP (Mobile information device profile) is destined for the mobile phone/pager market. This has been implemented first, for reasons that I suspect have to do with the power of the phone manufacturers compared to the handset manufacturers, and because the phones have build in networking compared with the Palms which for the vast majority don't.

The MIDP doesn't work well on a Palm because the display capabilities are aimed at a mobile phone which is less sophisticated, as compared to a Palm.

However, the good news is that the PDAP (pda profile) has now reached the stage for community review which will mean that a fully fledged profile for use on PDA devices is now available.

Basically, there's been fragmentation (between KVM, MIDP and PDAP) for development on the Palm, and until now there hasn't been a coherent strategy for companies to follow.

I expect there will be a massive increase in development on these platforms with the support that is now available, and the direction of the profiles.

If you want to see what can be done, and a presentation that I gave about J2ME, then have a look at : my J2ME page

If you want to contact me directly, I can provide further information in this area.

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.

Java on linux handhelds

[nowt]

Try here for more information on java for strongarm-based handhelds & pdas running linux.

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.