Monday, November 22, 2010

Android and Java Portability and bloat.

I have seriously gotten back into development. For the past 2 month, I have been toiling away on Open Remote's controller, porting the ORB (our java base controller) to android.

First I must admit to being profoundly amused and tickled. It is obvious to me that Android is way on the path to becoming the center of everything in home automation.

There is a simple reason for that, it is a standards based platform (linux+java) that ships with reference hardware at a unbeatable price. It is also sexy, at least if you are into that sort of fetichisme.

Google TV also promises to push Droids in your home, whether you like it or not. So what has been dogging the industry for so long, the lack of an available standard platform that is mass distributed and available everywhere, is about to be a non-issue.

At OpenRemote we also take a slightly different angle on the droid thing. Not only is it a cool panel, we also view it as a server. Whether with a panel or headless, it is a cool controller. Those things are ARM6 class CPUs and can run ORBs.

We are so convinced of this fact, that I am looking at what it takes to port from java6 to android. Ideally we would have a framework that works on both. So we develop on Android but also ship *the same binary* on java6.

And this is where the rubber meets the road. It is hard to "write once, run everywhere" in this brave new world. It is funny, because Android was largely influenced by two people I know: Bob Lee and Cedric Beust. Both respected Java old timers.

It is a stark reminder that java portability needs both languages and libraries. In the past when we refered to "java" we always mixes both, and why not? libraries were cheap to include. Today availability of libraries on android is vastly different than j6.

A bloated 100Meg binary is not something that goes down well in the android world. So you do extra work to remove dependencies and you ask yourself: do I really need this? tomcat? spring? logger? xquery?

In a way going to the Droid is like putting your app on a treadmill and sweating the fat off the hog. A lot of java's bloat is "scaffolding". Nice to haves but not must haves. Sometimes it is hard to see the building from the scaffolding.

And vice-versa, it is easy to create dependencies to android in your binary. Which would create non-portability to the java6 world. Many class libraries are present on the Droid Only. (Context anyone?)

To be fair to Bob, Cedrid and crew, it is obvious that "server" was not on their mind when they put this framework together and that the hardware has made leaps and bounds in the time since their started Android.

And with time we will be able to afford all the bloat in our smartphones/mini-servers, but for now, i actually enjoy the mental excercise of getting OR stronger and more fit because of it.

5 comments:

/L said...

Hi Marc,

glad to hear that you are back on track with the development - guess it's time to have a closer look into this project :)

regards,

Lennart
Redpill Linpro

Bob said...

We used Jetty in addition to other open source tools to test Android in the early days.

Also, Guice (w/o AOP) works great on Android. We use it in the Square client.

Marcf said...

Hey bob,

thanks for dropping by. Android is a most amazing phenomenon, congrats.

I assume you mean you ran jetty on the droid then. I saw iJetty and might test it.

I knew, Guice would work ;) it was cedrid who said he didn't know of any IoC for Android.

mattlf said...

Hey Marc, Not completely related to your post ... but would love to hear what you have to say on why Apple decided not to support java on MacOsX
http://news.cnet.com/8301-31021_3-20020338-260.html
Is the only reason because Apple is promoting native apps?

Marcf said...

I don't think it matters AT ALL what apple thinks or doesn't think when it comes to server side IT. Of course very different from embedding a language in a mobile or even a browser on a PC platform.

As the article states most folks don't care. Either they care about java and then they don't care because they will probably reinstall JDK or they don't care about java and then they don't care at all.

So at the end of the day, not that I care to analyse it further, since I don't care either, but I would put it down to "no one caring whether apple ships with java or not" as the bottom line as to why apple itself decided not to care and cut the cost.

I wouldn't read more into it.