Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Programming

Java on Handheld Devices? 162

Posted by Cliff from the would-you-like-coffee-with-your-palmtop dept.
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."
This discussion has been archived. No new comments can be posted.

Java on Handheld Devices? More

Java on Handheld Devices?

Comments Filter:

  • Networking (Score:3, Interesting)

    by Blinkenpilzen ( 565515 ) on Saturday March 16, 2002 @08:27AM (#3172732)
    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 (Score:3, Informative)

    by Clockwrk ( 467103 ) on Saturday March 16, 2002 @08:29AM (#3172740)
    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.
    • If you really want to do Java don't use palm, or palm based products, it really is that simple. Compared to modern handhelds they are very slow and limited, and I don't think anyone has the full JavaSE on palm. Try an nice arm powered unit.

  • Realistic uses of Java in Handheld Devices (Score:3, Insightful)

    by AlaskanUnderachiever ( 561294 ) on Saturday March 16, 2002 @08:30AM (#3172741) Homepage
    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 (Score:5, Informative)

    by ardiri ( 245358 ) on Saturday March 16, 2002 @08:31AM (#3172742) Homepage
    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.

    • Why not just natively compile java source down to native for maximum speed and memory efficiency? (Kinda like what GCJ or JET or JOVE does) Yes this will require compilers for each platform, but each VM/JIT is essentially a compiler already! What difference does it make if the code is compiled JIT or ahead-of-time? Why must Java be so obsessed with a portable bytecode which will work on multiple VMs when the language is already well-tweaked for portability and would probably compile correctly across multiple native compilers? This would end a lot of the complaints of Java being slow and a memory hog.
    • i am a Java programmer myself
      I would have assumed you to be a LISP programmer, judging by all the parentheses in your post. (Sorry, couldn't resist. ;-)
    • I've done my master thesis with PalmOS 3.5, a Palm Vx and J2ME on Linux at IBM. Unfortunately it's confidential what I did - but for beginners (I'm teaching high school kids now) I've made a starters project at http://dvx.d2g.com/~david/j2me/ - nothing with kSOAP an kXML as in my thesis and it's really easy and it doesn't need much of understanding of PalmOS or J2ME, but hey - you need to show the kids some easy stuff they understand and make them hungry to learn more by themselves.

      Would you please give me an URL to the projects you did with PalmOS and Java so I can check why your Java projects have not been successfull? Or your C/C++ projects? I mean, you must have a lot of experience doing Java on PalmOS, because you're doing this for 7 years now. So share your knowledge.
        • Would you please give me an URL to the projects you did with PalmOS and Java so I can check why your Java projects have not been successfull? Or your C/C++ projects? I mean, you must have a lot of experience doing Java on PalmOS, because you're doing this for 7 years now. So share your knowledge.

        www.ardiri.com = our palm development site.

        when you visit, you'll see why we didn't use java at such a level :) i explored the kvm back in 1999 when the palm v was given out cheaply with the kvm installed (at javaone). it just didn't have the balls to do what i wanted - so, i dug up the gcc compiler for palm (and, eventually ended up maintaining pilrc - the resource compiler).

        as for the java projects and what i do with java, i primarially use it for server side solutions these days and the occasional quick and dirty ui (heck, i aint gonna use VC++ in win32) when coding some interactive applications. bottom line is that without the CPU power, java on pda's isn't worth the effort. j2me is also too simple for doing anything real :) [esp from gaming point, no direct frame access]

        native compilers are the way to go, but, they have been few and far between - either massively out of date, or, not enough development push behind them to make it worth while [a few sdk releases behind or lacking many major system level features]. java is nice, but, like many other things in life - it has its time and place :) [<pun>long live c!!</pun>] - soon, it'll be worth it - it just hasn't been up to this point in time :)

  • how much pain does your customers deserve ..... (Score:1, Interesting)

    by Anonymous Coward
    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 ???

  • "No one's using it". Know why? (Score:4, Insightful)

    by dmorin ( 25609 ) <dmorin@@@gmail...com> on Saturday March 16, 2002 @08:42AM (#3172755) Homepage Journal
    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?

    • I'm confused by your concerns on the palm, and how they differ from developing Java applications on any other platform. You say

      "If the device was inherently able to run Java, and I could just send out JAR files,"

      Okay, that would be nice, but your PC doesn't inherently run Java either.

      Then you continue to say

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

      Again, this is *exactly* like installing a Java application for your PC customer. You need the VM first. Well-made installations for Java programs install the VM right along with everything else, and in fact, don't even have to 'confuse' the user by mentioning Java. This makes your comment of

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

      Equally as confusing. Is there something I'm missing about installing Palm applications that doesn't allow you to install the VM at the same time?

      I thought your question of "Why would Palm care" a good one,though. The only answer I can come up with is more languages supported == more developers == more applications == more versatility for their product. :/

      $.02

      Zipwow

  • Code Reuse (Score:2, Informative)

    by Maik ( 566860 )
    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.

  • We're developing a java-app for handheld (Score:5, Interesting)

    by Hektor_Troy ( 262592 ) on Saturday March 16, 2002 @08:44AM (#3172760)
    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?
    • Heh I've already done this and writting a small application isnt the problem. Is the damn size of Java that hurts. Oh and startup is under 1 second on a 206Mhz Arm.
    • 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. :)
  • 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.
  • 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
    • The CE appears to be comming along faster than Palm here but that could change.

      For Field Force devices which can spend 20 hours out in the field at a time, the Palm device has better longevity from the battery. IMHO WinCE devices are great when there is a power supply consistently nearby.

      mocom--

  • Get to JavaOne (Score:5, Informative)

    by deanj ( 519759 ) on Saturday March 16, 2002 @08:52AM (#3172776)
    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 (Score:3, Informative)

      by macpeep ( 36699 )
      "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/).

    • I aint going to javaOne because I despair at sun trying to control it too much; for example they wouldnt allow sessions on the Eclipse windowing stuff, which is an interesting alternative to swing. Too much control like that stops conferences being interesting; makes them more like reruns of the XVI congress of the communist party of the union of soviet socalist republics: "the java developers of the 13th Gulag would like to praise commissar McNealy for adding the assert statement to Java", that kind of thing. Same reason I dont go to any Windows conferences either.

      Go to things like the Ubicomp conference and you get to see some really interesting stuff, like people putting a java web server inside a normal GMS handset (via a java smartcard), which responds to requests proxied over SMS. Slick.

  • Java-like (Score:2, Informative)

    by chipwich ( 131556 )
    There are also java-like development platforms for the palm such as superwaba (www.superwaba.com) [superwaba.com] and waba (www.wabasoft.com) [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.

  • Ack!! (Score:3, Insightful)

    by MrBandersnatch ( 544818 ) on Saturday March 16, 2002 @08:56AM (#3172782)
    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.

  • The Sharp Zaurus (Score:2, Interesting)

    by bflong ( 107195 )

    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 [sharpsec.com].

    • Sharp is certainly trying to push Java on thier handhelds, as thier Zaurus in Japan uses a proprietary OS that can run java, but not linux. So if new hardware is budgetable, try it out.
  • Not that I like Java or intend to use it, but Sharp seems to build their entire handheld software on Java. Here is the developer site [sharpsec.com]
    Since it's a Linux PDA and has a fast CPU, I will probably get one. But I will put X11 on it, so that it gets really useful.
    • "Sharp seems to build their entire handheld software on Java"

      How did you come to this conclusion??? Most of their software is based on Qt/Embedded and QPE, which is all C++ compiled to natively run on a StrongARM processor!

  • I oft develop against MIDP profile (Score:2, Interesting)

    by Anonymous Coward
    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.

  • J2ME MIDP & PDAP (Score:5, Informative)

    by jon_eaves ( 22962 ) on Saturday March 16, 2002 @09:12AM (#3172799) Homepage
    If you go and read the Sun Wireless sites [sun.com], 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 [eaves.org]

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

    • Re:J2ME MIDP & PDAP (Score:2, Informative)

      by d6y ( 47741 )
      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 [sun.com]. I hope the PDAP picks up some of the Spotless systems' abilities.
  • About an year back, I was researching Java development for Palm. I was able to write a simple test program (Hello World!) for my Palm IIIc. I did have to load the JVM on it. But Java works on Palm since at least IIIc.

    Anyone knows if WinCE supports Java ;)
    • Java works on all the III series if you have enough memory to hold the JVM (which even just the III has... you just won't have room for anything else.) I used to use it on the IIIxe. I don't know where the Palm V era figure came from.

  • music applications (Score:2, Interesting)

    by thanjee ( 263266 )
    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.

  • Why? (Score:3, Interesting)

    by SteveX ( 5640 ) on Saturday March 16, 2002 @09:20AM (#3172805) Homepage
    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 think this discussion illustrates the effect of IBM opening up the PC architecture. Even then, I still remember the TI PC, the tandy 2000, etc. They had incompatible graphics and sound etc. and writing software that ran on all of them was pretty difficult and expensive.

      Around 1989 I started working with Smalltalk 80. It had a IDE, robust object model for application development, and could be deployed on MSDOS (with a mouse), Windows, Macintosh, Unix (Sun, Apollo, etc)

      If history had been a little different, Smalltalk could have enabled us to maintain more hardware and OS diversity than we have now. I wonder how these hand held devices will go? .

      • It's funny you mention both handhelds and Smalltalk. I'm working on Dynapad [sf.net], a PDA operating environment written in Squeak, a derivative of Smalltalk-80. I'm doing so mostly to make up for the pitiful state of handhelds, at least as far as I'm concerned. I want a system that works for me, not some toy.
    • That all applications must take advantage of the native abilities.

      In fact many don't need these. Very useful applications can and are being written. We work at a higher level, where we don't necessarily know where the application will be run - or we don't want to limit the possible uses.

      Bill
    • (I posted this in another thread) Why not just natively compile java source down to native for maximum speed and memory efficiency? (Kinda like what GCJ or JET or JOVE does) Yes this will require compilers for each platform, but each VM/JIT is essentially a compiler already! What difference does it make if the code is compiled JIT or ahead-of-time? Why must Java be so obsessed with a portable bytecode which will work on multiple VMs when the language is already well-tweaked for portability and would probably compile correctly across multiple native compilers? This would end a lot of the complaints of Java being slow and a memory hog.
      • Because jitting the code and doing runtime optimizations is faster than the static analysis gcj provides? The speed problems with java have nothing to do with the jit. Speed is lost because of the runtime safety checks for null pointers, array bounds, and dynamic casting, inefficient garbage collection on almost every major implementation, and a language definition that makes (nearly) every method call indirectly.

    • Re:Why? (Score:1)

      by Carey ( 2195 )
      The Mobile Information Device Profile has been developed to address these concerns. (MIDP APIs [sun.com]).


      Using these tools, the same application can be written to any device that has a profile. If the handheld has a different interface or implements different network protocols, developers can just change the relevant portion of their application to conform.



      The same idea is also being used for games across different systems (PC, Playstation, etc.) so that games can be written in Java without worrying about the different implementations.

  • It seems like a great deal of effort has been used in getting Java on these platforms, but nothing's really utilizing it.

    Hey, this is no time to wimp out because nobody else has pitched in with a worthwhile product yet... you've got the first mover advantage as the dot-bomb people called it, similar to First Post here on Slashdot. Sure, you might get modded down, but it's exhilarating while it lasts, eh?

    note: irony intended [usatoday.com]

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

  • No porting necessary! (Score:2, Interesting)

    by SashaM ( 520334 )

    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 trouble with the KVM (aka j2me, the Java platform for Palm Pilots et al) is that it's a really really limited platform. Doing anything even remotely complicated is difficult.

    It's not the same Java you get in your browser. It's upwards compatible, meaning stuff you can run on your Palm you can run on a normal Java machine but not the other way round.

    You don't have the windowing system. You don't have all the nice GUI stuff - you have to write that yourself. Now you have to do it on a platform that has no libraries for drawing filled ploygons. Hell, you don't even have floating point numbers or no direct access to the screen - makes it a little hard to draw stuff!

    Java may take off some of the learning curve here but there's still a lot of pretty hard core stuff you have to do to program an app - it's not just a matter of using your visual editor anymore - and your existing Java skills are not going to be enough.

    • No Jini support isn't strictly true. I've done apps using the Surrogate Host Architecture stuff in Jini, and it works fine.
      • I thought you needed RMI to do JINI, and from what I remember the KVM didn't have it.

        Is the Surrogate Host Architecture some kind of proxying system where by the KVM connects (via some other means) to a normal Java machine that 'speaks' JINI, or is it that an add on system for the j2me where by you add JINI to it.
        • Jini is a spec, of which the contributed Sun implementation uses RMI. There are other implementations that do not use RMI, since it is not required. Part of the beauty of Jini is that it is protocol neutral... you bind to the service at the last possible moment - the proxy. Services are defined by API, as with Java you can move the code around.

          Bill
        • Yes, that's basically it.

          The surrogate host stuff works like this:

          There's a protocol that you implement to locate a machine running a Surrogate Host. (This can either be done via multicast or unicast, under the TCP/IP implementation). Once it's located, the device sends a JAR file to the Surrogate Host, which opens the JAR file and runs the code in there. That code registers itself with the Jini network, and has a way (that you decide) to communicate back with the device. It looks like a regular Jini service to the lookup services and so forth. The device code can be implemented in any language. There's no RMI involved in the communication between the device and the Surrogate Host. It just has to get a way to get the JAR file over to the host. There's a spec for TCP/IP, and many other specs underdevelopment (USB, etc).

          I did this on a Palm device; others have whipped up stuff that work on smart cards and even Motorola phones. It's pretty cool.

    • I've been playing with an older version of the KVM on my Visor, and for me the biggest problem has been that it's a battery hog. Playing with the 'Many Balls' demo for a few minutes will take a noticble chunk out of the battery.

  • Blackberry (Score:3, Interesting)

    by NoseyNick ( 19946 ) on Saturday March 16, 2002 @09:36AM (#3172828) Homepage
    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.
  • JXTA [jxta.org] is an open networking protocol whose development is being supported by Sun Microsystems. It is designed to bring peer-to-peer and web service functionality to anything from a handheld to a server. There are several reference implementations, including one for J2SE that can run on any handheld that supports a J2SE VM (iPaq, Yopy), and there is one for J2ME [jxta.org], which works on a number of Java-enabled cell phones and light PDA's. A Java 1.1.8 port also allows JXTA to be used on some of the Palm PDA's. A C reference implementation [jxta.org] that uses the Apache portable socket library is also in the works.
    • Which is not so great when smaller devices have to spend cycles on parsing this. It's also extremely inefficient for transporting across the slower networks to small devices like cell-phones.

      Not that I think JXTA is bad, the ideas are great and obviously people think highly of p2p as a next big thing but I don't like how JXTA defines "the bits on the wire" so to speak.

      Bill

  • Java on linux handhelds (Score:4, Informative)

    by nowt ( 230214 ) on Saturday March 16, 2002 @09:55AM (#3172850)
    Try here [handhelds.org] for more information on java for strongarm-based handhelds & pdas running linux.
  • 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.
  • There's a great project hosted at www.jini.org called Surrogate which basically provides an elegant mechanism for non-java or small java devices to connect and interact with Jini networks.

    I'm heavily involved in using this at my company and we've used it with J2ME phones and Blackberries, and KVM pdas with great success.

    Others have pointed this out but the cross platform nature is great. Creating an application for one device that works on others is great - saves time and money. Of course, you lose some capabilities because you abstract to a higher level.

    So, I guess to answer your question: Yes, this stuff is being used, and used in unique and clever ways by a lot of people.

    Bill
  • As I look here at my Handspring Visor, the Java Runtime is 585K....just so I can get my apps started?

    Then there is the issue of speed. Java is slow on my Visor Prism.

    From a development point of view, its nice that I can program a button click and it will work OK on a bunch of different devices....but from a users point of view

    1) It takes up alot of space
    2) It is noticeably slower than all the other non-java apps.

  • We were forced back to Linux (Score:5, Interesting)

    by PyroJimmy ( 548200 ) on Saturday March 16, 2002 @10:32AM (#3172941)

    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 [linux.org.uk] on it, which allowed us to install Blackdown's Java-Linux [blackdown.org] runtime environment. Beautiful.

    • Swing works on JDK 1.1 (Score:2, Interesting)

      by SashaM ( 520334 )

      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.

    • SavaJE XE (Score:2, Interesting)

      by SashaM ( 520334 )

      we snagged an iPaq 3670 and installed ARM Linux

      What you should have done instead was install SavaJE XE [savaje.com] 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.

  • Well, there's the AmigaDE Player (Score:1, Interesting)

    by Anonymous Coward
    Don't think it's been mentioned, and to be honest I know only a little about it, but the AmigaDE (now Amiga-Anywhere) [amiga-anywhere.com] is supposed to be on the Sharp Zaurus thing. It has a 2D and 3D API, and supports Java, but it is actually some other Java-a-like. It looks pretty cool, and there's some games available.

    Anyway, it might be useful to check out.

  • BlackBerry (Score:2, Interesting)

    by Mike McTernan ( 260224 )

    The Blackberry [blackberry.net] 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.

  • From experience... (Score:1, Informative)

    by Anonymous Coward
    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.

  • emulating 64b mach. from 32 (or fewer one) - why? (Score:1, Interesting)

    by Anonymous Coward

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

  • Another source of Java runtimes... (Score:1, Informative)

    by Anonymous Coward
    ... is IBM. These are clean-room VMs and class libraries bundled with a development environment. See http://www.embedded.oti.com [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.
  • I recently wanted to get into programming for the Palm handheld devices (using OS 3.5), so I set out to program the same application in C, C++, and Java. What I discovered was that with the tools available to me (GNU toolchain), the only language that seemed to fit the bill was C. Between C and C++ (converting my C code into a full OO implementation) my .prc size doubled (approximately). The execution of the code was also noticeably slower than the C equivalent. This on an application that was *quite* simple (basic nslookup functionality), with no integration with the built-in Palm apps (calendar, etc.) After completing the C++ port of the app, I decided not to try the Java port since it would inevitably be slower and possibly larger than its C++ counterpart (even if it was compiled for the Dragonball processor).

    At a recent conference in town, I had the opportunity to talk with someone from a local software engineering firm that had also done some experimental development on the Palm, targetting Java. They reported the results that I had feared: slow execution and unacceptably large .prc sizes.

    I think Java on handhelds has potential, but until either the processors get more oomph or the executable (byte-compiled or otherwise) for Java becomes a bit more optimized, I think developers wanting to build in significant functionality to their apps will still use C, the embedded world's darling language.
  • i work with J2ME day in day out. the best env for using it right now are the nextel i* series of phones. they can have full j2me with an IP based network (with a publically routable IP if you get the right plan).
    the drawbacks to this technology. its early. lots of bugs. the tools/ide's suck. [thats right motorola, im talking to you, your web based application loading tools suck. what happend when my or your net connections go down: no ability to load apps] the environments are very small and nobody really has the phones.
  • It is cool, you can play on the web using an applet and you can download it on your palm as a native application (compiled through jump) or else you can run it just about everywhere as JITed bytecode (wince, palmos and so on).

    Sokoban [ondelette.com]
  • Take a look at:

    http://www.ibm.com/software/ts/mqseries/everyplace [ibm.com]

    This is a variant of the MQSeries enterprise
    messaging product aimed at pervasive devices.
    It is optimised for security and size (both
    in terms of message size and footprint
    on the device).

    The interesting observation is that although
    this is a fully Java-based implementation, IBM
    has produced a C-programming language version
    of MQe targetted at Palm devices (for example).

    In answer to the original poster's question,
    I would suggest that there is a market for
    Java-based applications on PDAs but if you want
    success on all platforms, you need to take into
    account the support for - and the performance of -
    Java on some of the lower-end machines and
    design your implementation to support a C version
    if customer demand requires it.

  • Put yourself in Nokia's, Ericsson's, or any other handset/wired PDA manufacturer's shoes. You want people to be able to develop great new applications for your devices, but at the same time, you don't want people's applications preventing your devices from functioning. In steps Java (J2ME), which offers you a great sandbox for those apps, free documentation on how to actually write these apps (which would've been costly and difficult to develop), as well as decent functionality through the few APIs that it supports. Furthermore, Java offers your developers a set platform for these apps. As long as the standards don't change, the same Java app will run across any new Java phones that you manufacture.
  • See Espial's [espial.com] website. (disclaimer: I used to work for them). They do some neat stuff in Java, and target handhelds, PDAs, cell phones, etc... Their DeviceServer platform is nifty.

    You might also want to look at DeviceTop [devicetop.com] - it's a reference site for people doing just what you're talking about - developing and running Java apps on mobile devices. (again, sponsored by Espial and Sun, among others I believe)...

  • Not when running on a machine with a Java-proc (i.e. a proccessor that can run Java byte code nativly, which quite a few embeded MIPS proccessors can now).
    Same with it's size, it does shrink quite a bit when it's only the base class libs.

    Mlk
  • I've only seen one reference to Waba here, and none to SuperWaba [superwaba.org] or EWE. These are both Waba/Java derivatives, with SuperWaba in particular being a practical development tool for the Palm. EWE is apparently a variant for the WinCE platform, but I've not been there.

    The maintainers of SuperWaba and EWE have got together and agreed on bridging code and hopefully eventual merging. Then once more code will run on Palm and WinCE platforms unchanged.

    Why go to all this trouble? Size & speed. Waba drops much of the crud that is irrelevant on PDA-sized devices, and has a very, very tight VM in terms of code size and speed. It is a Java subset, so if your app runs out of poke you can try switching it to real Java - if you have the hardware resources on the device. It even runs in a browser and there's a demo on the homepage.

    And yes, people are writing apps for it. There is even support software like app builders for those who don't use Jbuilder etc., tutorials, documentation yada yada.

    Oh, and the VM is Open Source.

    Vik :v)

  • 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 [concord.org].

    Find out more about Waba at: http://www.wabasoft.com [wabasoft.com].

    Find out more about WabaJump here: http://www.wabajump.org/ [wabajump.org].

Slashdot Top Deals

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Close