Slashdot Mirror
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."
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.
You already know the "starting java .. " pain on an otherwise fast PC. How would you think your customers would react to java applications on a handheld ???
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?
We do not live in the 21st century. We live in the 20 second century.
At work we produce desktop and workstation applications for a clients. We use Java quite heavily, but since most of our stuff is written for a particular client, you would only ever encounter it, if you were a user it was installed for. As a member of the general public, you will never know about it.
While there is a certain potential for J2ME generic applications, I think it works pretty much the same way. J2ME clients will be written largely for internal corporate applications. Since many corporate web based applications are based on JSP, Servlets, or even J2EE, using Java at both ends has lots of advantages.
At a previous employer, we were doing just that. It would have made things drastically easier, if we could have written for J2ME cell phones, instead of the various cell-phone "micro-browsers" we had to write for.
The new Sharp Zaurus has a JVM installed in it. I'm not sure how many developers are going to use it, but it's there. You can check out some details here.
Why is it so hot? Where am I going? What am I doing in this handbasket?
Often I develop against the MIDP profile. The resulting "midlet" runs on the Palm, PocketPC and any java enabled phone which conforms to the MIDP spec without modification. The GUI components are limited as compared to AWT/Swing but good for small devices with small screens.
The best part is that the midlet can be distributed to the handheld via a regular old web server such as apache.
The tools I use to develop handheld apps is NetBeans but sometimes I use GVIM or any other regular text editor in conjunction with ant, the Java build tool. Sun also has a tool which makes writing midlets much easier called the Wireless Toolkit. With it you simply click a button to build your project and another to fire up the phone emulator and run the app.
When I'm done with the software emulator I throw the app onto my Palm III or my Visor Neo to test on real hardware.
I use the handhelds to parse XML from servers to present information to the user instead of doing the heavy lifting on the device itself. Heck, with kXML or nanoXML I pre-parse XML before ever starting up the GUI. That way the user thinks that the app flies! If a new XML document is retrieved then I just put the message in a scrolling ticker informing the user.
The more I develop java apps on handhelds the more more I realize that the processing speed issue isn't an issue. Just like picking the right tool for the right job, pick the right platform for the right application.
In my experience, I was able to get up to speed to develop java apps for handhelds than I was able to get all the GCC RPMs in place to develop for handhelds. As I already mentioned, if one develops against the MIDP profile, you're targeting that profile, not just the Palm or any phone in particular.
I do quite a lot of java programming for my music degree. We have plans of getting our jMusic applications running on a handheld unit because it would make performances much easier if you only have to worry about a small handheld unit, rather than a computer tower. From what I know though we will have to make it compatiable for Java Micro Edition which means all integer calculations. One guy in my course has already trialed his music generating paint program (called MooZk) on a hand held.
For my own personal use it is still a dream as the sound synthesis process I use gives my 800Mhz processor a really hard time, so I don't even want to think about how badly it would work on a handheld device, at least not for a couple of years.
Sure I am not talking big company stuff, but it is becoming useful for our mobile musical performances. It just needs better Midi support.
Saying your OS is the best because more people use it is like saying MacDonalds make the best food
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
I work for a company that started with a wireless thick client app for the Palm with Novatel's CDPD modem. It was one of the first of its kind and had some success. Being a Palm app it was written in c.
Then along came the RIM Blackberry devices, so we wrote a client for it. Naturally, that was in C++.
Then along came the iPaq with the expansion jacket and CDPD card. Naturally, we just had to write a client for that. Oh and guess what, new code base.
It's a pain for our developers to have all those platforms, and what we see happening is that our business people are saying they can only afford to develop for the most popular platform, which for this app is the RIM.
RIM is really playing up the use of Java for such apps on its next device. We're doing other apps on the Sharp Zaurus, not all in Java, but at least it is an option and the processing power is sufficient to run at a decent speed. It is quite possible that very soon, all our thick client development will be done in Java.
Oh, yeah, it's not easy to pad these out to 120 characters.
We've developed a very fast map displaying application (the map is rendered on the client, with antialiasing, so it looks really well, and the amount of data to transfer to the client is very small), originally meant for the web, but now we've been given the task of implementing it for PDAs. While we plan a whole different architecture for the lower end PDAs (Palms etc.), we found that the only things we needed to do to port the application to PDAs such as the iPAQ, Zaurus or other high end (16MB+, 200Mhz+) devices was to improve the performance slightly and design a new user interface to fit the small screen/resolution and to be usable without a keyboard.
We didn't need to change one line of code besides those two changes because our application was originally an applet written for the web, so it was JDK1.1 compatible and PersonalJava (what runs on most mid to high end PDAs) is almost completely compatible with JDK1.1.
I'm also planning to port my pet project (see my URL) to run on PDAs and all I need is to rewrite the UI a bit. Java is great - who said platform independence was a dream promised but not delivered?
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.
Nick Waterman, Sr Tech Director, #include <stddisclaimer>
We have developed an order placing app for the Palm (mostly for use on Symbol devices as they have built in scanners). We did it all in C. We are mostly a Java shop, and it would have been extremely convenient to use Java as we could have reused a ton of code. However, when we looked into Java, it just wasn't ready yet on the Palm. The top requirement for our app to be successful in its target market:
Fast. It had to be extremely responsive, and extremely fast. It should be fast enough that the end user doesn't even think about the speed. If the user ever becomes concious of the speed, then we lose. This includes the time it takes to enter/leave the app, and operations within the app.
The goal was an app that used a built in database that could manage over 10,000 "items". We developed an entire relational database for the Palm, including SQL parsing and support! Java just wasn't able to handle this on a Palm. Too much overhead. When looking at the various solutions, we kept running into various issues with each VM. One took too long to start. Another did not use the native Palm UI (which was also a requirement). Another did not offer enough support for the device, requiring us to mod it up to get access to the parts of the OS we needed and the level of Java compatibility we needed. And so on... it ended up being easier to code it in C. For us, the best solution would have been a Java platform with at least 90% code compatibility with Java Standard Edition that we could precompile into native code for the target device. Jump was the best thing in this regard, but it just didn't have enough functionality and it ended up taking less time to code it all in C than to mod Jump.
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.
Anyway, it might be useful to check out.
The Blackberry from RIM is a most impressive Java based handheld, although I suspect that the reasons for Java being used on this handheld were to reduce the time and cost of developing the UI, and not particularly to allow other developers to add extra code and features to it.
In fact, I would suspect that the main reason for Java being suported by handhelds at the moment is to allow rapid development to robust components for the device as opposed to enabling every man and his dog to roll their own applets/applications for the device - something that could lead to broken devices and support nightmare if not carefully though about.
-- Mike
One great thing about the JVM: no worries about how big an int is now is there? It is not like that confusing C or C++ or asm stuff is it? Much easier for the programmer.
Have you noticed the number of posts here (and other times java is a topic of discussion) wherein the poster mentions "I am not much of a developer" or "I do not have a lot of experience with other development environments". This should be a tip off that a lot are posts from folks fresh out of college or some other industry who have been suckered into a startup where management (not an experienced small device systems programmer) decided to implement some new innovative bit of software in java.
Just one of the many problems with java on any platform, but is particularly exacerbated on resource limited ones such as PDAs, is that the JVM is a software emulation of a 64 bit machine that does not exist (to this day the latest 64 bit Ultra-SPARC whizzbang XXX from Sun/T.I. does not fully implement the JVM instruction set. It implements instead the distinct SPARC instruction set). Have you any experience running a PDA virtual machine on an X86? Did you notice that keypad and other I/O seems slow? Did you notice that processing seems slow? That was dismissed as the inherent slowness of running an emulation of one machine on a machine whose native instruction set was not the same (perhaps you were emulating a dragonball or or motorola mXXX - but it was slow when run on the x86 emulator).
Why then is it the case that folks cannot seem to make the connection that emulating a JVM on a processor that is not a Java Machine (virtual or hardware wise) is going to be intrinsically slow: instructions need to be translated, some need to be mapped to more than one instruction, fetches and stores take longer for 64 bit quantities when you can only do them 32 (or 16, or 8 for some of the embedded microprocessors that were all supposed to be java-fied by now) bits at a time, etc.. Note the mention of buzzword-in-time compilation. That is, rather than running a *.class file through a real pokey JVM you have a separate (and slow) step to prepare faster native execution code. Sure this helps speed up something that was originally writtin in java just a bit, but it does so at the expense of doing away with that cross platform JVM interpreter. Why not code in native instructions explicitly and squeeze performance out of your application? Why not code for minimal space? Why not code for maximum touchpad response time rather than having UTF-16 character strings bloating up every application that you try to write?
Why did Sun and IBM drop development of the JavaOS? Where has the HotJava web broser gone? If big applications like that cannot be made to run reasonably efficiently what hope is there on resource constrained small computing platforms? Note that the history of Java includes a discussion of OAK and how it was intended for Toasters and Coffe pots. When was the last time you saw a toaster or coffe pot for sale from Sun Microsystems Inc. or one of its Oak or Java licensees? A: they never made it to market. It was just sales hype from the company that is trying to be the next best thing to Microsoft, only with a SysV unix base (Solaris).
Swing 1.1.1 works beautifully under JDK1.1. See my URL for a JDK1.1 fully compatible application which uses Swing.
There is a bug report on Sun's bug reporting database claiming that Swing doesn't work on PersonalJava because Swing checks for the existance of some security related class to find out whether it runs under 1.1 or 1.2 and PersonalJava is essentially 1.1 with 1.2 security. Despite this bug, I've seen small demo applications using swing running under PersonalJava.
Note that all new iPAQs come with Insignia's Jeode JVM preinstalled.
we snagged an iPaq 3670 and installed ARM Linux
What you should have done instead was install SavaJE XE on it, which is a Java operating system which fully supports Java 2 and runs much faster than any JVM that runs on top of an operating system.
Yeah, at work.
Are you sure Java has gotten faster and it's not simply the hardware that's caught up with Java's performance hog.
My main application at work, Matlab 6.x, has its front-end coded in Java. Otherwise it would be a nice IDE with an editor, debugger, file history trees and everything, but it is simply too slow for hardcore use on my five year old PII 300 MHz PC. I almost downgraded back to Matlab 5, but fortunately most of the windows could be disabled. The only remaining window, the command line interface, is sluggish in comparison to Matlab 5 but at least I can work with it. It still requires several hundreds of megabytes for the Java engine, though.
The owls are not what they seem
I am using java on compaq IPAQ and blackberry 957 to run ssh client. See IPAQ client at http://www.movsoftware.com/sshce.htm and the blackberry ssh client at http://www.airstreamws.com/ourproducts/sshtelnet.h tml. Have also been able to load from our webserver the ssh enabled vnc client that is written in java on the IPAQ