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.
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 ???
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.
OOh ooh! I know! A beowolf cluster of Palm III's running a virtual machine that uses java to play a game of pong! And not just any Pong. Pong with smaller paddles!
Find out about my new childrens book: SS Death Camp Criminal Batallion Go To Monte Carlo For The Massacre
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
Why? Its so incredibly clean, so much more so than any language I have seen (C++, etc). Its a little slow-ish, but Java 1.4 has significantly improved this, and they are getting better about it all the time. You can do practically anything with it, and it runs on almost any platform you can think of. And don't get me started on how much of PHP's ass that Java's JSPs and servlets kick...
"Software is like sex; it's better when it's free." -Linus Torvalds
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?
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
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.
***Quis custodiet ipsos custodes***
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.
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
http://www.ajaygautam.com
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
Our company did some development for J2ME - it looked at the different options available ( including waba, superwaba, etc). The problem with these is that they all need a separate package in order to run, and are often slow.
The solution, albeit non-open-source, is a product called JBed. It is a J2ME MIPD IDE, and compiles into palm native format. It actually runs off of a tiny, hotspot-like jvm, which means that after you run the application for the first time, it is as fast as a normal C application.
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?
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.
-- Sorry, I can't think of anything funny to say here.
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>
I removed Java from my machine for since almost last year. And to be honest, the only place where I am prompted to install it is within my web browser.
And you bet I wont install it just to see those stupid ad banners!
Conclusion: After more than 6 years now in production, Java miserably failed to deploy.
And by the way, for bashers, I work for a company developing a full-featured Java application (among other things).
JXTA 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, 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 that uses the Apache portable socket library is also in the works.
pi = 3.141592653589793helpimtrappedinauniversefactory7
Then again, maybe I'm biased, seeing as how I've written a FORTH code generator, several FORTH translators and designed a CPU to natively run FORTH instructions (at the gate level, sooner or later I may build one in TTL for fun).
Hardware, software, and blinking lights!
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
And a HIGH VOLUME hand held consumer electronics company at that.
The fundimental problem is the JVM size. Some of them are 3 to 4MBYTES.
If you are going to "market" a handheld with Java as a baseline to develop for then you've got a problem. You cannot trim down the JVM to something smaller - ie: They are not modulure.
It is like making a smaller glibc. You cannot split up 'glibc' to make it smaller, it is not practicle. You know what functions your app needs from glibc, you can't tell what functions I need. The only solution is to install the entire HUGE thing.
Until recently, nobody really has ever had enough space (ie: RAM/FLASH) on the device to make it a doable thing.
Zarus and iPAQ is close, but they are $400 to $600 . By the time you spend that much, you can spend a bit more and get a ruggidized real-PC.
Handhelds like Zarus & iPAQ have "geek factor" businesses need something that is durable (ie: Rugged) if you have the money to spend on an iPaq, you have another $400 to puchase a ruggedized pc. It's cheaper - they don't break that often.
Besides, once the platform is out there it takes a year or two to fully scale out various applications through a large enterprise.
I'd give another year.
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.
Read my comment on QuickBooks2002Pro, the Java app that blows goats.
If it was a server app, it would be OK. It's an end user app, and Intuit has no idea what's on the box running the accounting.
I support end users, the first thing I do is turn of Java, ActiveScrap, WinblozeMe Scripting Host, and other assorted troublemakers.
Java on server, well maybe. Java on the client, NEVER.
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
Upon seeing the box was too small, Schrodinger's Elephant breathed a sigh of relief.
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.
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.
I'm still working on a clever footer.
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
Upon seeing the box was too small, Schrodinger's Elephant breathed a sigh of relief.
(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.
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.
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
Upon seeing the box was too small, Schrodinger's Elephant breathed a sigh of relief.
Anyway, it might be useful to check out.
The Blackberry from RIM is a most impressive Java based handheld, although I suspect that the reasons for Java being used on this handheld were to reduce the time and cost of developing the UI, and not particularly to allow other developers to add extra code and features to it.
In fact, I would suspect that the main reason for Java being suported by handhelds at the moment is to allow rapid development to robust components for the device as opposed to enabling every man and his dog to roll their own applets/applications for the device - something that could lead to broken devices and support nightmare if not carefully though about.
-- Mike
The early CDMA reference boards came with either 1 or 2 megs of memory total. The CPU was x86 (might be wrong, but I think it was 286) and memory management was a bitch. For high end phones, manufacturers had to write their own software or license it from a third party. Most of them used paging to swap memory back and forth due to 64K thing on 286, 386 cpus. In late 99, qualcomm switched from x86 to RISC based chip for the reference boards. Immediately the memory configuration options increased. If I remember correctly, it was 1, 2, 4, 6 and 8 meg boards. The more advanced phones with built in PIM and full WAP browser from Open Wave used 4 or 6 meg boards.
Even with 4megs of memory, there were big battles over which division/application got how much memory. For example, a built in POP/IMAP email client on a CDMA phone used about 22-25K. Most of the phones using the older x86 reference board used the Open Wave microbrowser, which used the wap gateway to render the pages. It was only when manufacturers changed to Arm reference boards that full wap browsers were used. In 99/00, Palm network was pretty unreliable and coverage was spotty. Today it's much better, but transfer rate is really slow. The wireless world honestly still doesn't know where it's going.
Even though others may tell you otherwise, here are the reasons:
These are just some of the reasons, there are more. Having developed and used location intelligent applications on WAP phones, it is a great tool. Without the location part, who cares. Things like realtime mapping applications on mobile devices are great. We only had prototypes, but even with just prototypes, it was really useful.
But you need to work in a more stable environment.
Now that the country is officially out of a recession, its time to whore your skills out to the highest bidder, the way god(r) intended us to live.
The Hiptop by Danger, Inc. uses a JVM to power their wireless, always-on PDA.
Danger, Inc.
Various articles about the device can be found via Google; TechTV had a reasonable review of the device.
It isn't vaporware, it just isn't out yet.
I'm¦sorry,¦but¦one¦of¦the¦biggest¦reasons¦is¦true¦ embedded¦systems¦programming¦(and¦I'm¦of¦the¦opini on¦that¦many¦embedded¦systems¦concepts¦apply¦to¦sm all¦systems¦like¦Palm¦and¦the¦Cell¦phone¦platforms )¦requires¦fine¦tuned¦memory¦management,¦etc.
a nd ¦with¦the¦gcc¦tools.¦¦I¦would¦MUCH¦rather¦do¦it¦in ¦c.¦¦I¦do¦professional¦Java¦programming¦as¦well¦as ¦C¦&¦Perl¦and¦I¦find¦the¦so-called¦'memory¦managem ent'¦that¦Java¦employs¦to¦be¦*abhorrent*¦(I¦find¦t hat¦when¦you¦do¦proper¦variable¦scoping,¦etc¦that¦ Perl¦has¦a¦pretty¦solid¦memory¦management¦system). ¦¦¦When¦you¦are¦talking¦about¦modern¦Desktop¦and¦S erver¦platforms¦where¦memory¦is¦cheap¦and¦abundant ,¦this¦isn't¦as¦big¦a¦deal¦(Although¦I¦still¦disli ke¦it);¦if¦your¦app¦eats¦up¦memory¦just¦throw¦more ¦at¦it.¦¦When¦you¦are¦talking¦about¦a¦system¦that¦ has¦a¦very¦finite¦amount¦of¦memory,¦with¦no¦way¦to ¦upgrade¦it,¦being¦able¦to¦fine¦tune¦memory¦usage¦ is¦KEY.
l oc ate¦memory¦to¦a¦varaible¦that¦you¦KNOW¦is¦never¦go ing¦to¦use¦more¦than¦8¦bytes?¦¦Do¦you¦trust¦it?¦¦P ersonally,¦I¦trust¦char¦*myString1¦=¦malloc(8)¦alo t¦more.¦¦I¦know¦exactly¦how¦much¦memory¦is¦being¦a llocated¦and¦to¦what.¦¦Java¦might¦allocate¦8¦bytes ,¦or¦on¦a¦whim¦it¦might¦allocate¦80.¦¦Who¦knows?
' s¦ high¦overhead,¦slow¦and¦unwieldy.¦¦I¦hated¦way¦it¦ behaved¦on¦my¦palm¦and¦it¦is¦one¦of¦the¦reasons¦I¦ gave¦up¦on¦J2ME¦(Java¦2¦Mobile¦Edition).
t ¦I ¦think¦these¦push¦the¦primary¦points.
I've¦done¦some¦PalmOS¦programming¦in¦both¦Java¦
Do¦you¦really¦want¦to¦leave¦it¦up¦to¦Java¦to¦al
Then¦you¦must¦address¦the¦issue¦of¦the¦JVM.¦¦It
There¦are¦alot¦more¦things¦one¦could¦address¦bu
Combination¦of¦new¦Galeon¦and¦my¦laptop¦seems¦to¦b e¦doing¦weird¦things¦to¦spaces¦in¦my¦posts...
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).
... 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.
Saveje. It might not be for the palm, but it's amazing on an iPaq.
midlet.org has a huge list of midp applications (incl. links to vendors); most of them can be viewed in an emulator applet...
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.
ooops, forgot the http. correct link: midlet.org
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
Upon seeing the box was too small, Schrodinger's Elephant breathed a sigh of relief.
have seen (C++, etc).
compared to C++ you're right, but java really isn't
the clean language it's hyped up to be.
for a nice clean language that fits in the embedded niche,
you should check out Limbo, which
is a genuinely clean language (designed by the same
group that designed C).
the crucial thing about Limbo, though, is that, unlike Java,
it doesn't try to solve all portability problems in the language
itself. The Inferno OS effortlessly solves all
the problems that Java struggles over. It runs fast, packing
lots of functionality into a small footprint (1MB RAM is sufficient
to run significant GUI apps), and provides some extremely
powerful primitives for composing distributed applications.
we had a little distributed app that a colleague had
knocked up over a couple of days (two files, 800 lines of code total).
it implemented a "shared piece of paper" - i.e. all users
see anything that anyone draws on the app.
talking to someone that had tried to do a similar thing in
Java on a PalmOS based device, they were amazed - they'd
taken months to do the same thing, and it was slow, big,
and didn't provide as much functionality.
the real plus side is just how beautiful the environment
is to program in. it gives you power and doesn't make you
pay for it via huge and convoluted API interfaces.
(and that's why it's fast and small too).
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.
four-oh-four
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
This is very annoying, please stop that!
Take a look at:
e
http://www.ibm.com/software/ts/mqseries/everyplac
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.
I hadn't realized AI had progressed to the point we could have entire companies built of software!
Multiplayer quasi-game java apps running on cell phones are very popular in Japan. (Japan, even Korea are far ahead of the west in terms of exploiting cell phones).
Do a web search...
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.
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.
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.
I truly don't understand why people think Java is so incredibly slow. "A little slow-ish" IS just about right. If you are referring to applets in Netscape, that is a VERY bad example of Java. Have you not experienced an application written in Java in the last 2 years? Speed has significantly improved since Java 2 first came out...
-J
"Software is like sex; it's better when it's free." -Linus Torvalds
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)...
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
Microsoft has been working on its own VM for quite some time now (I was looking for PocketPC development in VS.NET, and I came across this webpage:e /compactfx .asp )
.NET Compact Framework. I have no idea when this will be available, but being able to write PocketPC apps in VB.NET will mean an explosion in apps.
.NET is good if you don't like to port your program to another language.
http://msdn.microsoft.com/vstudio/devic
If you can deal with the Microsoft extensions, you can probably move your code to a PocketPC with J# and the
Java is good if you like to program in Java.
That's my take, and I'm sticking to it.
Yeah, at work.
Are you sure Java has gotten faster and it's not simply the hardware that's caught up with Java's performance hog.
My main application at work, Matlab 6.x, has its front-end coded in Java. Otherwise it would be a nice IDE with an editor, debugger, file history trees and everything, but it is simply too slow for hardcore use on my five year old PII 300 MHz PC. I almost downgraded back to Matlab 5, but fortunately most of the windows could be disabled. The only remaining window, the command line interface, is sluggish in comparison to Matlab 5 but at least I can work with it. It still requires several hundreds of megabytes for the Java engine, though.
The owls are not what they seem
Okay, that would be nice, but your PC doesn't inherently run Java either.
Then you continue to say
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
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
I don't know which is more depressing, that 2/3 didn't care enough to vote, or that 1/2 of those that did are crazy.
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
Wow, I should not post when knackered.
inferno is not free and the code is unavailable. thanks but no thanks. i'll take a language i have a chance at using if the company goes outta business over a proprietary one any day.
umm...palm applications arent installed. they're synced to the device as PRC files with one PRC per app. that means the JRE will have ot have a seperate PRC and your app will have one or more PRCs which the user loads manually and runs.
thats the equivalent of installing the JDK on a PC *manually* and then installing the class files for the app *manually* and then running it from the command line while ensuring class paths are correct. A royal pain in the ass.
We've written a few apps that are in pilot at the moment for data capture on the palm. We started out using sun's J2ME, but found a few problems in the way it makes network connections and re-wrote our network app in IBM's J9, which allowed us access to the OS calls and is fast. Trouble is you have to use objects called 'Int16Ptr' and 'var.getShortAt(0)', which reminded me of a language I used to use.
I thought of using C++ and kinda looked forward to get back into it, but the trouble I didn't enjoy the prospect of writting double the code and having to do triple the debugging.
The thing with Java is you can develop faster, there is less debugging and you can share code accross platforms as long as its not GUI specific etc.
Another delight was playing around on a wince device but needing to copy code accross from a linux box, we synched a hacked java ftp server accross using a MS box and could then ftp to the device via linux.
There is a problem with spead, but it means you need to be creative and it really depends on who is going to use the app, our users have never touched a computer and don't have a spead expectation, its still a lot faster than all the paper work they would have to do.
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
...is marketed by my company, PointBase under the name PointBase Micro edition. At about 60KB, we don't know of any other commercial product that matches this in speed, reliability and footprint.
We also have a Synchronization solution that runs on handhelds and syncs data between our databases and Oracle as well as SQL Server.
We have a lot of partners that offer apps for Java handhelds. Visit our website for more info if you are interested.
Yes! SUN CLDC profile is a great step forward for embedded developer that want to write portable and secure code on a growing number of supported devices!
I worked on a native Java processor (J2me in sillicon) for 2years and now I started my own company doing a pure Java TCP/IP Stack. http://www.sinnetworks.com is where you'll get the info.
With Silk 1.0, our future product, you'll be able to network any device that support the CLDC profile to a TCP/IP network (The Internet...)
The very large software company that I work for uses it in Mobile technology that allows both online and offline access to sales data. I'd like to give you more information, but I need to first find out whether it's commonly known that our product uses Java.
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 ]
I was in Japan back in October 2001 at Tokyo Game Show and I saw LOTS of cell phones (most of which had color screens) where a whole bunch of game companies like Taito and Sega have written games in Java to run on cell phones. Apparently, cell phones users download them for a fee over the cell network onto their phones.
When I was in Akihabara Electric Town (the electronics area in Tokyo), I'd guess at least 70% of the cell phones for sale had color screens (mostly LCD and some were OLED).
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
Java enabled devices...
Looks like the AmigaDE is getting more attention towards devices these days.
Its fast, light weight (16k for each translator) very easy on resources... What more can anyone want?
Plus up to 3000 developers working on hundred of apps right now!! Soon, maybe in a month or so you'll be able to by a memory card witha number of games on it. This will allow you to plug this memory card into any PDA that supports the AmigaDE.. right now this is ipaq (2 modles i believe) zaurus and about 4-5 others.
A heap of WinCE devices now willhandle the AmigaDE so even more devices will be able to use these memory cards.
Same code, ran anywhere, very fast!!!
Cant wait...
You can turn off the GUI with a command-line switch. I'm at home, so I can't look it up, but it's there..
I am using java on compaq IPAQ and blackberry 957 to run ssh client. See IPAQ client at http://www.movsoftware.com/sshce.htm and the blackberry ssh client at http://www.airstreamws.com/ourproducts/sshtelnet.h tml. Have also been able to load from our webserver the ssh enabled vnc client that is written in java on the IPAQ
While CORBA may be a necessary evil, Swing is a hog even on an average over-powered desktop PC, and using it on a handheld would be just crazy.
Computers make very fast, very accurate mistakes
Well, we're building a "for real" financial application on a Java-enabled phone, the Nokia 9210 (European version). We could use some more processor power, but it's perfectly usable. The screen is beautiful (640x200, color TFT), the Symbian OS is rock solid, and the Java is . . Java.
A couple of us at Compaq Cambridge Research Laboratory did the initial port of Blackdown.org JRE 1.3.1 to the iPAQ running Linux a year ago. Blackdown finished the port, ran JCK, and it is now available from blackdown.org.
With Reuters/Instinet, we demonstrated a trading application running on the iPAQ using Swing, wireless, etc. at Java on Wall Street at the World trade center. It was really cool to be able to take an app that they had debugged on J2SE on a Win2K desktop and have it run, unchanged, on a handheld. Startup of the application was a bit sluggish, but runtime performance was adequate.
In addition to Java2 Standard Edition, J2ME, waba, and Kaffe are also available on the iPAQ running Linux. There are some notes about Java on the iPAQ at http://www.handhelds.org/z/wiki/JavaOnIPAQ
Savaje: http://www.savaje.com/ has ported J2SE to the bare ipaq (using the bootldr from Compaq CRL). This version is reportedly quite fast.
If you prefer PocketPC, Insignia has J2ME available.
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.