Posts tagged 'java'


I'm a bit late with my obligatory Android post. Partly that's because I wrote this in a lab at university a while back and forgot to post it.

The announcement of Android and the release of the "early look" SDK have created quite a bit of hype. There have been numerous similar announcements by other initiatives to get Linux on mobile devices, so what's with the excitement about Android?

Of course, it's backed by Google. Whether you like it or not there isn't going to be a way around it. But that's not all there is to it. The engineers behind Android have simply done an excellent job judging from the SDK. And there's a lesson or two to be learned by the open source world:

  • The Linux kernel is good at what it does. Userspace is generally not worth bothering with.

    I found this very striking. If you have a look at what's running in the emulator (which is based on Qemu), you'll notice that there are just a few processes and the only standard component among them is dbus.

    Android uses a custom (launchd/upstart-like) init replacement. Traditional, SysV style, init systems waste a lot of time just forking shell processes. And doing stuff in shell also opens the door for monstrous shell scripts that spend ages performing simple tasks such as creating a few files and directories (that script takes 5-10 seconds to run). It still takes a while for Android to boot though, which I hope is just because my laptop is slow.

    Android also doesn't bother with providing a complete Unix commandline environment, since, hey, the user isn't going to see that anyway. It's funny how it's never occured to me to stop shipping the lower layers (non-essential bits of busybox, login). But then again, I'd probably have been yelled at for that by some users...

    I have yet to check whether udev or a udev replacement is involved as that tends to be a bit of a bottle neck on resource constrained devices. It would certainly be nice to either get things to work without udev or with a more efficient replacement. The other thing I have yet to figure out is whether any type of X is involved in windowing. At a glance, it doesn't look like it though.

  • You can build efficient security models that are still simple enough for people to actually use them.

    Most PDA/phone stacks make the assumption that only one user uses the system. Personally, I prefer multi-user environments so I can lend devices to friends/family, but for the average user that assumption is reasonable.

    In a multi-user environment you need technologies like SELinux to separate individual applications run on behalf of a single user. Mobile stacks have to my knowledge (apart from an extremely locked down set of Motorola phones) up to now never bothered with that. Applications either all run as (yuck!) root (Qt/Embedded, Qtopia) or as a single user (GPE, Maemo, Poky, OpenMoko) without any significant restrictions as to what individual applications are allowed to do.

    Enter Android... Why not re-use the space freed by the single-user assumption and run each application as a separate user? Sufficient for most use cases and still very simple to understand. Security models only matter if they are simple because they won't be used otherwise. It remains to be seen how well the Android security model works out in practice but I like the concept.

  • It's not a platform unless it comes with a comprehensive API and an easy to use, well-integrated SDK.

    I found it rather amusing how people referred to OpenMoko as the first open platform in reaction to the Android SDK release. At present OpenMoko is a prototype device plus a number of mockups and a few prototype applications. There's a long way to go to turn that into a platform.

    First of all, developers will want a comprehensive API. From experience talking fellow developers through GLib/GObject/Gtk+/etc. development basics, it's fairly obvious to me that just throwing a bunch of libraries at people doesn't do the trick. People get lost too easily around the borders between the territory covered by the different libraries involved. Arguably, this is mainly a documentation problem, but there's more to it. Following the development of the Gnome desktop throughout the years shows that people spend a lot of time discussing at which level to implement functionality, shuffling bits around, etc.

    Android takes a different approach. Using the Java programming language allows integration with Eclipse (or similar commercial IDEs) which provides developers with API documentation right in the editor. Combine that with refactoring/reenginering features of modern Java IDEs and you'll never look back to anything else.

    And the level of integration goes beyond that. You don't even have to leave Eclipse to upload your application to the devices. It's all just a matter of clicking a few buttons. For an "early look" SDK that's rather polished and provides a new level of efficiency compared to what I'm used to on other Linux based systems.

  • The primary goal must be to attract developers. The larger the set of potential developers the better.

    If you want people to use your stuff you'll have to make it easy for them to hop on the train. As simple as that may sound, most of the time it just doesn't work like that.

    I believe the choice of Java as the programming language was the right one. Personal taste aside, there is hardly any way around Java. It's the de-facto standard first language in teaching around the world.

    It remains to be seen whether there will be other language bindings in the future. It doesn't seem very likely to me though, since Google probably wants to avoid a mix of languages which easily leads to a giant mess.

  • Avoid cross compilation and complex build systems.

    People tend to spend a lot of time setting up a cross toolchain, fighting applications that won't cross compile cleanly, etc. That's a major waste of time.

    Of course there are various meta-level build systems, which try to hide that sort of thing from you. But that comes at the price of another level of indirection and complexity. There are very few people who actually understand how, say, OpenEmbedded works under the hood in every detail - the problem being that in certain cases you need that level of understanding to get your work done.

    Android's take on this is to avoid cross compilation and build systems altogether (for application development anyway). I like the approach. It's very refreshing to find a development environment that you can instantly work with after downloading. My first simple application ran in the emulator within minutes.

People have raised the question whether Android renders various other projects obsolete. And, realistically, I think it will once fully open source under a permissive license. The impact will be dramatic. As outlined above, traditional handheld distribution paradigms along the lines of a "base system" are shown to be irrelevant and there's been a clear focus on creating a fun developer and user experience.

Do I sound overly optimistic for the success of Android? Perhaps. I haven't held a device running Android in my hands yet after all and there are licensing questions to be sorted out, too. Given the list of consortium members behind the Open Handset Alliance, however, I'm confident there's some exciting, well engineered stuff ahead.

DevJam Pictures

Kurt Gramlich put up some pictures of the DevJam meeting. Make sure to check the main wiki page for more subpages containing pictures Kurt is uploading right now.

Familiar 0.8.2 and Free Java Binary Backages

Familiar 0.8.2 has been released. It comes with all Free Java packages mentioned earlier in the feeds. (That's not quite true, actually. Kaffe will be added once I get it to work properly.)

People interested in binary packages (Thanks to Mark for pointing me to that one. I'm not subscribed to that list.) may want to check the 0.8.2 feeds.

SableVM 1.11.3

The issues with SableVM I mentioned earlier appear to have been fixed in SableVM 1.11.x. The apparently ARM specific random crashes don't seem to happen either. Good job guys!

JamVM 1.3.0

JamVM 1.3.0 is out.

JamVM running on an iPAQ H3800.

A simple demo application using AWT and Gtk+ peers.

Actually plotting a function.

And another one.

Current SableVM Confirmed Broken. JamVM works!

It is kind of sad to hear that "the AWT/Swing in 1.1.10 and current staging are horribly broken".

In other news, JamVM 1.2.5 appears to work fine with GNU Classpath 0.14 (at least for AWT applications). This is the first JVM to run AWT apps flawlessly on my iPAQ (and will be the first free one to do so in Familiar as part of the next release).