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.
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.
Comments
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
Also, Guice (w/o AOP) works great on Android. We use it in the Square client.
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.
http://news.cnet.com/8301-31021_3-20020338-260.html
Is the only reason because Apple is promoting native apps?
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.