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.
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'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.
Find out about my new childrens book: SS Death Camp Criminal Batallion Go To Monte Carlo For The Massacre
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 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?
www.HearMySoulSpeak.com
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.
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.
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.
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 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.
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.
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
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
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>
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)
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? .
I want to be alone with the sandwich
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.
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
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).
.prc sizes.
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
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.
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.
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.
You might also want to look at DeviceTop - 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)...
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.
It's funny you mention both handhelds and Smalltalk. I'm working on Dynapad, 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.
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
I've only seen one reference to Waba here, and none to SuperWaba 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.
:v)
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
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 ]
Java isn't the greatest language anyway and will soon be phased out in favor of modern functional languages (O'Caml, Haskell, SML, etc.)Java isn't the greatest language anyway and will soon be phased out in favor of modern functional languages (O'Caml, Haskell, SML, etc.)
Modern as in LISP?
I'm not trying to point out chronology (ML is fairly new, LISP is fairly old). I mean that, if I'm not mistaken, LISP has had most of that functionality for decades, is better proven as a practical language, has a very rich library and an active community... and yet, imperative languages rule the world (LISP is not the phaser, it is the phasee).
I love SML; although I'm fairly new at it and have trouble thinking about how to use it in some applications, for most mathematical functions and list operations there's really no comparison in clarity.
But I'm really skeptical about these languages displacing imperative programming simply because there is no need for them to do that. They don't solve any problem that is not more easily solved by integrating some of their features into imperative programming (recursion, garbage collection, etc).
People are happy with C-like languages, and imperative prog. has become the euclidean geometry of computer science: it's the layman's world, and alternatives are constrained to very small and specialized circles, with new benefits and discoveries percolating down slowly.
Freedom is the freedom to say 2+2=4, everything else follows...
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
download
here
or here)
and
the core source
code is available (costs $300 and allows
commercial development).
most of the source code (applications, libraries, etc)
is free and open source.
i believe this compares favourably with Linux (many
embedded linuxen have proprietary bits) PalmOS
(where's the source code to that?), and many other
embedded systems such as QNX and VXworks.
not to mention being the coolest OS on the planet.