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."
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.
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.
I am currently looking into Waba (a subset of Java, look at http://www.wabasoft.org) to use much of the same code both for an applet and a Palm application (and possibly later on a CE application if our client requests it). While the UI stuff has to be different, all the business logic should be portable.
This is interesting to me too. You never know what direction open source will go.
As maintainer of a Java API, I'm starting to see corperate interest in Java on PDA's. I've seen interest come and go (BeOS) and interest come and stay (Mac OS X, HP-UX, Win32, Sol2, linux). The PDA group as a whole appears to be fairly intent on making things work.
The CE appears to be comming along faster than Palm here but that could change.
Your experience may be different.
--
Trent Jarvi
maintainer www.rxtx.org
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
There are also java-like development platforms for the palm such as superwaba (www.superwaba.com) and waba (www.wabasoft.com).
These platforms allow you to use your favorite java tools IDE (eg, Jbuilder) and give you a lean VM that runs on the palm. There are some tradeoffs and the UI libraries are differe,t but IMHO the simplicity of these platforms and the open-source nature make them very attractive.
These platforms have also been ported to Palm, WinCE, Zaurus, TI-calculator (really!), Newton, 386, etc, as well as running under standard java as an applet. Many alternatives.
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.
Try here for more information on java for strongarm-based handhelds & pdas running linux.
A strange game. The only winning move is not to play. How about a nice game of chess? - Joshua (Wargames)
The early CDMA reference boards came with either 1 or 2 megs of memory total. The CPU was x86 (might be wrong, but I think it was 286) and memory management was a bitch. For high end phones, manufacturers had to write their own software or license it from a third party. Most of them used paging to swap memory back and forth due to 64K thing on 286, 386 cpus. In late 99, qualcomm switched from x86 to RISC based chip for the reference boards. Immediately the memory configuration options increased. If I remember correctly, it was 1, 2, 4, 6 and 8 meg boards. The more advanced phones with built in PIM and full WAP browser from Open Wave used 4 or 6 meg boards.
Even with 4megs of memory, there were big battles over which division/application got how much memory. For example, a built in POP/IMAP email client on a CDMA phone used about 22-25K. Most of the phones using the older x86 reference board used the Open Wave microbrowser, which used the wap gateway to render the pages. It was only when manufacturers changed to Arm reference boards that full wap browsers were used. In 99/00, Palm network was pretty unreliable and coverage was spotty. Today it's much better, but transfer rate is really slow. The wireless world honestly still doesn't know where it's going.
Even though others may tell you otherwise, here are the reasons:
These are just some of the reasons, there are more. Having developed and used location intelligent applications on WAP phones, it is a great tool. Without the location part, who cares. Things like realtime mapping applications on mobile devices are great. We only had prototypes, but even with just prototypes, it was really useful.
... is IBM. These are clean-room VMs and class libraries bundled with a development environment. See http://www.embedded.oti.com. They run on palms, iPaqs and blackberries, as well as on pcs, and most platforms support midp and cldc (J2ME certified) as well as a bunch of other configurations.
Nokia seems to be using java already
One of their newest phones (the 6310i) uses it. From the specs:
Phone Features
* Tri-band phone - works in three networks on five continents
* downloadable personal applications via Java(TM) technology
* Support of Java applications download via WAP
IIRC the 9210i does as well....
Not tried either of them (yet) but sounds like it works... nokia also just had a java programming compo for their phones
You are severely disillusioned, my friend.
It really isnt suitable for handhelds which have low cpu (and storage?) resources available.
Perhaps you didn't notice this article, but the latest wave of mobile phones are all Java-enabled, a fact casting immediate doubt on your above claim.
[...] java was designed to be slower than other languages.
Bwa ha ha ha!!!!! Do you honestly think Bill Joy and pals sat down and wrote "Must be slower than other languages" into their Java design spec.? You moron. Don't you know Java was initially designed to execute on washing machine controllers, and set-top boxes?
The reason why Java is slow does not come from a specific design decision to make it such, rather, speed (or lack thereof) is a consequence of Java providing its own run-time environment with windowing API, class library, and a plethora of other useful programming toolkits.
Obviously, if you are running a Java Virtual Machine in a restricted embedded environment, you don't need the functionality for a complex desktop system. Thus, large parts of the Java virtual environment can be stripped away to leave a streamlined execution platform ideal for an embedded environment.
Take a look at Sun's J2 Micro Edition page, and learn something for yourself instead of regurgitating the same tired old nonsense perpetuated by idiotic anti-Java morons like you.
- Chris Z. Wintrowski -
[ Site ]
We are developing an open source application we call CCProbe which combines tools for collecting and analyzing sensor data with the capability to display these and other objects (images, drawings, notes, etc ...) in a compound document structure similar to a html page. Our application is written in Waba, an open-source java-like language specifically developed for handhelds.
We have CCProbe running on PalmOS, PocketPC, Windows, MacOS, MacOSX, and Linux.
On the Palm we compile the waba class files to 68000 machine code with WabaJump. The speed is suprizingly good, as fast as the interpreted version running on an iPaq. Our application is 750k on the Palm. On full-size OSes we run the waba classes on top of a Java VM.
You can find out more about CCProbe and download the software at: http://concord.org/ccprobeware/ccprobe.
Find out more about Waba at: http://www.wabasoft.com.
Find out more about WabaJump here: http://www.wabajump.org/.
-stephen