Sun and 3Com agree to embed Java into Palm Pilot
killbill writes "3Com and Sun have agreed to put a Sun Java virtual machine inside the Palm Pilot.
Attenders of the JavaOne Developer Conference can purchase a Palm V with the Java VM already installed as of today, and I assume it will be available to the general public as soon as you can tap your "beam" button.
"
Some language bigot will say "Java Sucks"
Some other bigot will say "Why not Linux on
the Palm V instead of Java, with GTK apps
ported to the Palm"
Someone will suggest running a BeoWulf cluster
of these babies, as if it mattered.
Obligatory bashing of MS and WinCE devices
Did I get all of them? Oh yeah, "First Comment",
or is that out of Fashion?
Sun has a white paper describing the implementation of the JVM for the Palm system,
b stract-73.html
codenamed "Spotless" It goes into detail about the design of the system. At the end it include a short description of some stuff they've implemented in Spotless.
http://www.sunlabs.com/technical-reports/1999/a
Mr. Peabody
I was invited to Sun's ConsumerOne event yesterday as a Java software provider. At the end of the event, all the participants were given a Palm V with kJava and the JavaOne event schedule pre-loaded.
Our company develops industrial-strength Java code, and we've been working with all kinds of JVMs, from embedded devices to HP/UX passing through Linux, Solaris, Mac, and (yuk!) all Winblows flavours including CE. We're currently evaluating non-desktop JVMs and we'll probably focus on two: KJava, the one in the Palm V, and Jeode from Insignia.
So far, after having played with the Palm V for only 3 hours, I can say this: kJava rocks! Here are the specifications reported by the Palm V info:
Preloaded Java classes:
Each Java class can be loaded or removed on demand, and its memory usage can be checked on a per-class basis. There seems to be no performance difference between the Java applications and the other Pilot goodies; in fact, some of the games can be played faster than the stylus or the human eyes can catch with them.
If anyone here is interested, I'll write a review of KJava in the Palm V after we run our compatibility and performance tests on it. A large number of classes in our products are written in Java assembler, so this will be a great chance to check if Sun/3Com are keeping the JVM specification honest.
Cheers!
Eugenehttp://eugeneciurana.com | http://ciurana.eu
Those of you who are thinking Java on the PalmOS is a silly idea don't really get the whole thrust of what Java is going to do. Like a few people here have already posted, writing Java networking code is simple, but that's not the main reason to get Java on the Palm. Other people have complained that the KVM won't let them port applications to the PalmPilot -- they're completely missing the point.
The reason to get Java onto the PalmOS is that 3Com and Sun are looking to push the "Network Appliances" theme. They're not looking to port existing applications onto a PalmPilot (do you really want to run a spreadsheet on that thing?), they're looking to make it networked out the wahzoo. Java (and Jini) provide easy ways to get machines sharing code and objects, which makes writing client/server applications a no-brainer.
That's the focus of this whole thing.
--Mid
I agree with most of the latter part of what you said, but you have to admit that forking something like JavaVMs would be a little more problematic than forking something like a library, a compiler, or, say, Emacs. Those are used by one person. The dependency begins and ends with the user, but that isn't the case with Java. If the JavaVM is just a little bit broken, it's no good at all. As long as there were decent standards, it would be ok, but as we see with Web browsers, it's tempting to avoid standards. It's more akin to forking C than gcc. If I fork gcc to change C in an incompatible way (no matter how cool it is), we've got problems. If only there were ANSI Java!
Java is interpreted and slow.
The virtual machine is always bulky and slow.
Java can't access any sort of native methods.
Write-once-run-anywhere is a complete lie.
Besides, Microsoft killed it anyway.
Of course, I've never written a single thing in Java. Oh, did I mention that I believe every piece of Java misinformation that I read?
/* Yes, this was sarcasm */
Save the whales. Feed the hungry. Free the mallocs.
KJava looks to be really useful, if it gets to be as widespread as it looks like it will be. Here are descriptions of some of the interesting demonstrations I saw of KJava in action at today's JavaOne keynote (which I sadly had to watch over webcast instead of live):
* Two Lego Mindstorm tanks, each with a Palm attached to the top running the KVM. The Palm's controlled the tanks, trying to play a game of tag I think... the Palms used the IR ports to talk to each other. Just imagine the tanks also being able to pass new behavior or scanning updates to each other as well!
* A demo of transferring a program from a Palm to a Motorola pager (both running the KVM) over the IR port. In this case it was a Tetris game, but imagine being able to load some custom home monitoring software into whatever device you happen to be carrying with you that day, or searching out some custom mapping software for the area you're in.
One example of such a custom application was a custom conference schedule/map they had avialiable for JavaOne attendees - you could select a session you wanted to go to, and it would pull up a map of the conference center to tell you just where it was.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I can't believe I'm mentioning this, but:
IIRC, K&R style has the opening bracket of a function on the next line:
int foo()
{
return bar;
}
While "Java" style generally puts it on the same line:
public int foo() {
return bar;
}
Yep, it's a minor difference. Believe or not, I actually spent time agonizing over which code style to use and where. If you care which I personally prefer, you should really get out more.
Save the whales. Feed the hungry. Free the mallocs.
Don't laugh. A little over a month ago, I started researching, in earnest, how feasible it would be to create a JVM for the C64 (for the fun of it). I quickly decided that the VM itself would be no problem (almost a natural fit) on a 6502. Written in 6502 assembly language, I could probably hack out a rudimentary VM in a couple of weeks. The problem was the class library. Just to print "Hello World!" would require several hundred kilobytes of classes to be loaded. I needed a stripped down, simplified class library, but I didn't feel like trying to rewrite the Java class library myself, so I put it on the back burner.
Enter Spotless. I just finished looking at their stripped down java.lang.Object, java.land.String, and java.lang.StringBuffer. Perfect. Just a few K.
Java on the C64, here we come.
Here is a link to a Hacker's Jargon Dictionary with an explanation of foo() and bar(). "Cause everyone else does" is pretty much it. It's just one of those silly programmer tradition things.
;)
Kind of like sig lines with geeky memory-management jokes.
Save the whales. Feed the hungry. Free the mallocs.
a simple search at http://www.javasoft.com revealed...
l
http://www.javasoft.com/features/1999/06/j2me.htm
http://www.javasoft.com/products/kvm/
http://www.javasoft.com/products/kvm/faqs.html
faq
14. How will the K virtual machine be made available?
The K virtual machine will be made available on the web through the Sun Community Source Licensing process and from the Sun sales force. For more information on Sun Community Source Licensing, see http://www.sun.com/software/communitysource/
peterrenshaw ~ Another Scrappy Startup