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.


7 Responses to “No Android Army”
  1. 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.

  2. 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.

  3. Alex says:

    @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.


Check out what others are saying about this post...
  1. […] Update: apparently Android is not really Java, the JVM is different. […]

  2. […] Alex Miller – No Android Army: סיכום מ-וו-ת-ק של אלכס מילר על אנדרואיד(גוגל, סלולר, פלטפורמה גנרית), כולל פגישה עם בוב לי, הוונדערקיד שמאחורי ג’וס(כמו גם אנדרואיד, מסתברא), ואוסף לינקים משכנע. […]

  3. […] In the wake of Google Android, people from three different grid vendors have written about mobile grids: me from Terracotta, Bob Lozano from Appistry, and Nikita Ivanov from GridGain. I think Bob and I both had the reaction of…”cool, but what would you do with it?” […]

  4. […] Alex Miller (Terracotta) observed (as did I) that probably wasn’t enough … sure it would be cool at first blush, but what would we really gain? Just cycles? And? […]