Some initial, random thoughts / wild speculation on Android, given the limited amount of information currently available.
I don't think the mobile app 'problem' has ever been about the programming experience. Frankly, all the wonky tools, languages, frameworks are nothing but an enticement for interested hackers. More puzzles. Certainly, that's why I got involved with these guys about ten years ago. I'll go ahead and make the obligatory Smalltalk reference now, and then just shut up about it, mkay?
No, the problem with the mobile app 'problem' has always been about lock-in by the various entities. Service providers that charge exhorbitant prices for network data access; that don't allow the download and install of Joe Rando application, instead, monetizing the application story; not even having a toolkit available to build apps in the first place. Maybe times have changed since I stopped paying attention to the market, but I doubt it. Perhaps Google and indirectly Apple can help break down some of these barriers. That's the real problem to be solved. Or perhaps Google could more directly fix the problem. I should be able to write an app for my mom that she can easily install on her plain old phone. That's got to be the long term story, anyway.
Android is Java, and not Java. You write your application in Java, but it's translated to Dalvik format for running on the Dalvik VM. The Dalvik VM is not a Java VM, presumably.
Dalvik is a register
ed-based VM, instead of a stack-based VM. What does that mean? A friendly link in the android mailing list points to an document describing the inferno VM. Note one of the authors, Rob Pike. How conveeeeenient. :-) BTW, he's got a great email address!
I've heard folks claim "it's not J2ME", or whatever it's called today. Not quite right. Esmertec says it will support J2ME per customer request. Presumably, customers being service providers. But you could imagine Sprint charging you a few bucks for a MIDlet capability. Of course, your MIDlets will have to be modified to Dalvik VM format, presumably, before run.
There are actually three J2ME-ish packages included in the android.jar file that shows up in Eclipse when you create an "Android project". javax.microedition.[khronos.opengles|lcdui|lcdui.game], though the packages appear to be radically stripped down. Why are they even there? The khronos.opengles package appears to be 'public', not sure why the others are there.
Apache Harmony classes are included. Any Java lover that ever dissed Apache Harmony as pointless, needs to eat crow right now. Because, had it not been for Apache Harmony, you might be programming Android in Python instead of Java. Or C++.
Includes an XML pull parser. Thank &diety;! Well, it's in the android.jar used in Eclipse, but I don't see how you get to it via published API.
Includes SQLite. I'd rather have seen LittleTable. heh
The .class files in the jars seem to have (or at least some have) debug information. Decompile away! Though you're probably not allowed to per whatever click-through license you clicked through.
Ian Skerrett has a blog post titled "What Does Android Mean for Sun's OpenJDK" which is pretty self-descriptive. Read up, if you're interested in licensing hoo-haa, especially the Java variety.
Miguel de Icaza has some thoughts on "Android's VM" and Mono. We'll see a lot more of this, including folks wanting to target existing languages to the Dalvik VM, presumably. I wonder if any of the PyPy developers work at TheGoog?
Could 'typical' JavaDoc have been so hard to build?
I got to install Gutsy in a VMware session on my MacBook, and then Java, and then Eclipse, and then the Android SDK, then the Android plugin. Because there's a little problem running the Android plugin in Eclipse for some Mac users. Perhaps that's why there's soft keyboard in the emulator?
Personally, I think Google is shooting a bit low here; the platform sounds like it would be good enough to run little 'mini-apps' on your desktop. Like say, AIR does. Or like Google Gadgets.
It's not a real platform until it has IDL. Woo Hoo!!