A Smartphone as a Java EE Server: Glassfish 4 on Ubuntu Touch

In 2012, following the release of the much anticipated Raspberry Pi, my colleague Steve couldn’t resist getting JBoss EAP 6 to run on it, which he managed with minimal effort! Not to be outdone, I’ve been inspired by the release of Ubuntu Touch – Canonical’s offering for mobile devices. Mark Shuttleworth’s trailer videos for the upcoming OS gave me a lot to be excited about; I’ve long been wondering what could be possible if only I could unlock the power of the computer I have in my pocket. Android is (at the moment) my favourite mobile OS, but it’s always disappointed me a little that there was no way to get Java running on it since it lacks necessary packages so when Ubuntu Touch was announced, it finally seemed that there was a New Hope!

How is it done?

Surprisingly easily, once you know the correct steps.

Installing Ubuntu on the Galaxy Nexus is as easy as a single command, provided you’ve already unlocked the bootloader. The installation process took a while – around 30 minutes I think. In any case, it was far too long for a keen early adopter to just sit around waiting! To fill my time, I downloaded the latest Java SE embedded from Oracle (a painful mistake) and the latest promoted build of Glassfish 4. (If you’re going to be an early adopter, you may as well do it right.)

Ubuntu installs itself very differently to how I expected and, being unfamiliar with Android administration, there was a bit of a learning curve! Using the Ubuntu SDK’s QT creator IDE, you can easily start an SSH session to your phone, once you have wifi configured. I expected the terminal to be limited to some degree, but what I didn’t expect was for it to lie to me!

After connecting, a quick pwd tells me I’m in the /home/phablet directory (phablet being the default user in Ubuntu Touch). The “phablet” user has limited permissions and I quickly found I was unable to switch to the root user. I’m an impatient man at the best of times, so rather than try to spend time fixing that, I simply used the Android Developer Bridge (adb) that QT uses to connect to the device. A couple of further pwds in various directories told me that Ubuntu actually creates /data/ubuntu and uses that directory as root, so although the “phablet” user couldn’t see outside of it to the Android files, the root ADB user could!

Installing Java

Installing Java was not a fun task. I tried various ways of transferring the downloaded file over to the phone using any method I could think of which would work on a full terminal. Finally, I resorted to ADB once more, using the push command. I then quickly found out that the terminal was powered by BusyBox and it simply refused to run certain packages. (At this point, I suspected a full conspiracy towards my failure by my phone and Ubuntu desktop.)

I am nothing if not stubborn, however, and, remembering that OpenJDK 7 is certified for ARM chipsets, I just tried to run apt-get on the right package from QT which, to my surprise, worked first time!

phablet@localhost:~$ java -version

java -version

java version "1.7.0_07"

OpenJDK Runtime Environment (IcedTea7 2.3.2) (7u7-2.3.2a-1ubuntu1)

OpenJDK Zero VM (build 22.0-b10, mixed mode)

Installing Glassfish 4

I wasn’t expecting much success after the trials of getting Java to run in an environment that was so foreign to me, but I had a go anyway. After getting the latest promoted build of Glassfish 4 from the Aquarium, I pushed the .zip over to the device with ADB again. After unzipping, I tried to start the domain: bin/asadmin start-domain domain1

Nothing.

BusyBox refused to execute asadmin (I ran chmod 755 just to be sure). Since I’d spent the best part of the afternoon on trying to get this to work, in desperation, I thought I would move the installation directory to /home/phablet and try to run the command over SSH, rather than as root over ADB.

I ran the same command and, to my surprise, Glassfish started to load. Surprise quickly turned to horror when I realised that I was running full Glassfish on full Java 7 without changing any heap settings!

After about 2 minutes of waiting with bated breath, the command returned that it had started successfully. I could hardly believe it, so I went to the admin console to check: