No Android Army
I ran into Bob Lee last week and found out he’s been working on Android at Google and doing a lot of C (gasp, horror). Now that it’s out I took a look at some of the videos and docs and stuff and it looks kind of cool. If I ever actually used my cell phone, I’d love to hack on it with Java!
Actually, since I work at Terracotta, a company that makes a Java clustering technology, my first thought was “Cool – now I can write a Java app with Terracotta and share clustered state on a bunch of phones!” It’s like the Android Army!
But sadly, that ain’t gonna happen because Android is not really Java, it just looks like it. Apparently the API and IDE use Java syntax and work under Eclipse and use Apache’s Harmony class library, but ultimately it’s all getting translated to run on this Dalvik VM thingie. Dalvik is not Java and apparently works by translating .class files at some point along the way. You can find some interesting thoughts on this strategy by these fine people:
Very interesting approach to leveraging the open and popular parts of Java but sidestepping the legal and IP (and monetary) issues to using the J2ME runtime.
In any case, Terracotta relies on hooking into the JVM at startup by using some modified classes in the bootclasspath. (Note – not modifying the JVM, just a few of the core classes like ClassLoader so we can instrument code at load time.) And that’s surely a little too deep to possibly work over Dalvik.
Of course, I have no practical reason to want to do this, just thought it would be cool.
Hi! My name is Alex Miller and I live in St. Louis. I write code for a living and currently work for 
Coming down to something more simple, this means that we won’t be able to use 1) mobile code (e.g. RMI proxies) and 2) things such as Hibernate. Not good.
Hi Alex,
we have a very similar issue around modifying class files for db4o Native Queries but I think there is a very easy solution:
Why don’t you modify class files at compile time, before they get deployed to Android?
If you take a look at an Android project in Eclipse, there are four builders:
“Android Resource Manager”
“Android Pre Compiler”
“Java Builder”
“Android Package Builder”
I haven’t tried this yet myself but I would suppose that you could hook your own builder in there in the right place to modify class files before they get deployed to the emulator or the device.
If you are on the lookout for a library to modify class files: We are quite happy with using bloat. Other possible choices would be ASM, BCEL and Serp.
@Carl: Yeah, we use ASM and Aspectwerkz now and you could definitely get most of the way there via compile-time modification and weaving. But I suspect there are still things we would need to hook at runtime. Might be an interesting experiment someday.