This is how you compile the jdk

Yeah – download the sources, install the required libraries, compile. Simple!

WHY would anyone want to do that?
Not entirely for the kicks, I must tell you. Or for the fact that it is open source and you can get your hands on the sources. Or for running your cpu at 150% and making it impossibly hot? Well if you are in search for drama – we can exchange laptops (Though I may be forced to get a replacement soon ūüėõ )!

I recently was on an ‘Advanced Concurrency’ training (No! I wasn’t the instructor) and that’s where I picked this idea of compiling the JDK (Wouldn’t it make a very good friend once you get to know him?). You can make some low level changes (Think: Go Deep! The JVM¬†level?). Our instructor did something very cool. He was trying to show us how modern JVMs, on runtime, do dynamic compilation and give massive performance boost. To show us that and for even much more (to look under the hood), he added his own code to the debug-jdk and from that marriage, something beautiful was born. He could map his source-code with the jvm-optimized-one.

JDK8 is required for the compilation process to begin so please get that first.

We’d be compiling JDK9 (which is still in Development).

# scm is done using hg - mercurial
$ sudo apt-get install mercurial
# tell hg your name
$ echo "[ui]" >> ~/.hgrc
$ echo "username=nikunjlahoti" >> ~/.hgrc

# clone the dev branch of jdk9 to a folder called 9dev
$ hg clone 9dev
$ cd 9dev/
# Next execute the script to download everything in the forest
$ chmod u+x ./
$ sh ./
# this may take some time & bandwidth

# Reading the README would make things more clear. Do open the README-builds.html
$ cat README
# Configure the environment
$ bash ./configure
# Configure may fail when a particular dev library would not be present.
# It would tell you what to install to fix that issue. And run Configure again.
# Below is a list of libraries which were missing from my Ubuntu 14.04
$ sudo apt-get install libX11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev libcups2-dev libfreetype6-dev libasound2-dev

# Begin the compilation
$ make all

Build Statistics:
On my machine Linux 3.13.0-35-generic x86_64 x86_64 GNU/Linux it took around 40 minutes.

## Starting verify-modules
Checking dependencies across JDK modules
Access verification succeeded.
## Finished verify-modules (build time 00:00:59)

----- Build times -------
Start 2014-09-18 00:06:26
End   2014-09-18 00:46:02
00:00:59 verify-modules
00:39:36 TOTAL

Finished building OpenJDK for target ‘all’
Thu Sep 18 00:46:02 IST 2014

How to execute

$ cd 9dev/build/linux-x86_64-normal-server-release/jdk/bin
$ ./java -version
# openjdk version '1.9.0-internal'
# OpenJDK Runtime Environment (build 1.9.0-internal-nikunj_2014_09_18_00_01-b00)
# OpenJDK 64-Bit Server VM (build 1.9.0-internal-nikunj_2014_09_18_00_01-b00, mixed mode)

git: sparsecheckout: Partially pull a repo

So I got this Firefox Device (called Intex Cloud Fx) a couple of weeks back but still couldn’t switch to it (the cold turkey way) as the keyboard application is still in its infancy and I can barely type on QWERTY anymore (long sentence?)!

I decided to dive right into it. I spent my weekend trying to understand the OS better and managed to push some test applications to the device (and they worked! And I could even debug them from my browser! Cool stuff!).

The end game (more like the next goal) is to get/create a keyboard app which has the placement of keys that my mind would understand. (Think: Colemak)

To do that, I started looking around for examples and that’s when I found something and forked it immediately ūüôā¬† test-keyboard-app

To pull that repository on my laptop was truly intimidating (it’s a full blown Operating System after all). That’s when I found out what magic git sparsecheckout could do.

$ git init repo

$ cd repo/

$ git remote add -f origin

# Updating origin
# remote: Counting objects: 356086, done.
# remote: Compressing objects: 100% (105268/105268), done.
# remote: Total 356086 (delta 245156), reused 356086 (delta 245156)
# Receiving objects: 100% (356086/356086), 817.56 MiB | 892.00 KiB/s, done.
# Resolving deltas: 100% (245156/245156), done.

$ git config core.sparsecheckout true
# Specifying the intention now

$ echo "dev_apps/test-keyboard-app/" >> .git/info/sparse-checkout
# list of directories to be included

$ git pull origin master
# From
# * branch master -> FETCH_HEAD

$ ls -a
dev_apps .git

# voila

#NoteToSelf #LetTheFunBegin

Intex Cloud FX: Turn Debugging On

…and the tinkering shall begin!

Well it doesn’t work out-of-the-box and this post will help other developers get their hands dirty quickly.

One can debug either by using the “adb tools” by Google or “app-manager” by Mozilla.

#1: Enable Debugging on the phone

On your phone go to: Settings -> Device Information -> More Information -> Developer

Set: ‘Remote debugging’ to ‘ADB and Devtools’

#2: Find out the USB Vendor ID

$ lsusb
Bus 005 Device 003: ID 1782:5d04 Spreadtrum Communications Inc.

From above we found out that the VendorID=0x1782 (running `lsusb -v` gives a verbose output and prints values in Hexadecimal)

#3: Tell adb to look at this new device of ours


Log in as root and create this file: /etc/udev/rules.d/51-android.rules.

$ sudo cat >> /etc/udev/rules.d/51-android.rules
# Paste:
SUBSYSTEM=="usb", ATTR{idVendor}=="1782", MODE="0666", GROUP="plugdev"
# CTRL+D to save the file

B) Restart UDEV

$ sudo /etc/init.d/udev restart

C) adb_usb.ini

$ cat >> ~/.android/adb_usb.ini
# Paste

(You need to have adb installed before we move ahead:

#4: Tinkering shall begin

$ sudo adb devices

Will show you your device.

if you see something like

List of devices attached
????????????    no permissions


$ sudo adb kill-server
# now try adb devices again
$ adb shell
# enter the device

All well! ūüôā

Intex Cloud FX:
OS Version: Intex_Cloud_FX_V07
Hardware revision: sp8810
Platform version: 28.1
Update Channel: release-spreadtrum
Buy: for INR1999/- on

Using the App Manager:


Getting back to Sony Xperia SL: LT26ii: nozomi: 4.1.2

I spent the previous night getting Xperia SL back to stock 4.1.2 (Build Number 6.2.B.1.96)! That absolutely deserves recognition and some documentation.

After spending countless¬†hours (experimenting with the ROMs) over the past¬†year, I have realized that Stock Jellybean 4.1.2 is adequately¬†stable (=something you would want to¬†use on a daily basis) – and¬†anything else¬†isn’t just good enough! The developers are trying very hard to support it but lets face it – its¬†ancient and now even the¬†developers do not own it.

So that’s what I wanted to do – go back to the pavilion.


  • Xperia SL is supposed to be¬†an improvement over¬†Xperia S. Didn’t quite become a hit.
  • Most ROMs would only be found for “Xperia S” and would require changing¬†the install script to either omit the device check or modify it. Therefore, the hardware capabilities¬†also get limited to that of Xperia S – which feels somewhat¬†frustrating.
  • “Sony PC Companion” wouldn’t touch your device if your bootloader is unlocked.

Noteworthy ROMs:

  1. ParanoidAndroid/SlimBean: Nifty features. But highly experimental. (~Dec, 2013)
  2. Cyanogenmod 9.1.0: The last official stable release for the device.
  3. OpenSemc: (beta) Incredible effort by devs to get Kitkat 4.4.2 on SL (built on top of unofficial Cyanogenmod 11).
  4. MIUI v5: I couldn’t try this one on. #4.4.4 #ClosedSource

Getting Back to Stock

Things we need:

  • flashtool: using Flashtool (available on unix/windows/mac), Stock FTF¬†images can be flashed on the device without much ado. Locking/unlocking bootloader.
  • Xperia SL LT26ii_6.2.B.1.96 Firmware FTF¬†– firmware for India (but I don’t want to not be a cynic; so lets override this later)
  • Sony PC Companion – your device, automatically suggests to install it – once you connect it to the PC (over USB)
  • Emma: Official Flash Tool for Xperia devices.¬†Meant to be used by developers for devices with unlocked bootloader. Doesn’t work with Xperia SL but works with Xperia S.


#1 Install and set Flashtool up

Put the¬†LT26ii_6.2.B.1.96_Generic.ftf inside the firmware directory inside the installation. Run as admin. Click on the Bolt button on the left – “flash” > select “flashmode”

#2 Connect the device is flash mode

After step #1, the tool will request you to¬†turn off the device and insert the USB wire while pressing volume down key – to go to the “flashmode”.

#3 Once the procedure completes, disconnect the USB and turn on the device. Ensure that all is well.

#4 Lock the bootloader now:

Turn off the device and hit BLU button (not blue) on flashtool. Connect the device in flashmode. Relock!

#5 Turn on the device and start Sony PC Companion. 

Now the companion would recognize the device. Click on the device status. In the popup click on repair.

(Steps #3 Р#5 are optional; Blame the security)



Now the big question is that what am I gonna do with the device now that its back to normal.¬†Well I may¬†have thought of something ūüôā


Break something, struggle with it and then get that fixed. That does raise the value of the Object.