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."

15 of 162 comments (clear)

  1. We are prototyping by Clockwrk · · Score: 3, Informative

    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.

  2. Java on Palm OS by ardiri · · Score: 5, Informative
    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.

  3. Code Reuse by Maik · · Score: 2, Informative

    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.

  4. I'm starting to see interest by taj · · Score: 2, Informative

    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

  5. Get to JavaOne by deanj · · Score: 5, Informative
    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

    1. Re:Get to JavaOne by macpeep · · Score: 3, Informative

      "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/).

  6. Java-like by chipwich · · Score: 2, Informative

    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.

  7. J2ME MIDP & PDAP by jon_eaves · · Score: 5, Informative

    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.

    1. Re:J2ME MIDP & PDAP by d6y · · Score: 2, Informative

      Another issue with MIDP is that you can't access any of the internal databases (address book, date book, to do, memos...). It's a security thing (you don't want apps you download to be able to read/write your contacts). But it's also annoying for anyone wanting to write apps that do things with the information you already have on a palm.

      The Java Spotless system (the forerunner to MIDP/CDLC) did allow you to do this and from memory had a richer UI... but it's dead now. See MIDP4Palm FAQ. I hope the PDAP picks up some of the Spotless systems' abilities.

  8. Java on linux handhelds by nowt · · Score: 4, Informative

    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)
  9. From experience... by Anonymous Coward · · Score: 1, Informative
    I used to work at a company developing wireless applications and solutions. Back when wireless data was big hype december 99, there was a lot of confusion about which kvm or java technology was better. 3 years later, things are finally starting to become more standardized. I know CDMA better than GSM or TDMA, so I'll stick to what I know.

    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:

    1. wireless interfaces are still very difficult to enter data rapidly
    2. carriers refuse to deploy network-based location determination
    3. w/o location determination, wireless is practically useless
    4. w/o implicit and explicit personalization in the wireless world, it's a waste of time
    5. w/o useful data that's geocode (long/lat), there's no point
    6. w/o an affordable pricing plan, people aren't going to pay per minute
    7. there aren't any wireless games or applications that have indisputable value
    8. the carriers still want to charge something like 1/10th of a cent per location request
    9. the carriers want to be the broker and get a cut of every transaction
    10. very few people understand the power of location intelligence in wireless environment

    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.

  10. Another source of Java runtimes... by Anonymous Coward · · Score: 1, Informative

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

  11. Re:Realistic uses of Java in Handheld Devices by elem · · Score: 2, Informative

    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

  12. Re:java == slow bloat by Chris+Z.+Wintrowski · · Score: 2, Informative

    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 ]
  13. Waba and Jump is fast on a Palm by stepheneb · · Score: 2, Informative

    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