Mobile Conference

Recently I attended the Indicthreads Mobile Conference as a Panelist and as a Speaker:

Here are some Photos from the Event:
Day 1 – Panel discussion [Software For The “Mobile Is The New Desktop” Era]


Day 2:  Conference Talk – Mobile Payment Systems

Check out the slides of the Presentation on Slideshare

It was an informative conference and I got to meet a lot of like-minded geeks with lots of interesting mobile gadgets and even more interesting ideas for mobile applications.

A Java old timer reminisces – Oak, 0XCAFEBABE, Green Threads, RuntimeException

I have been working with Java since the mid nineties, and in that time, Java has gone from being a “fad”, the next “big thing”, etc, to becoming a widely accepted and deployed programming language in the business world.  Being involved with Java for a long time has its share of ups and downs. On the plus side, you know and understand the very basic foundations of the language and its evolution, on the negative side you sometimes talk about stuff no one else has a clue about. So many people have given me a strange look whenever I have mentioned any one of the four items in the title that I have decided to write a blog post about it just so that I can declare “go read it up on my blog” :).


Oak is the name that Java was known by internally at Sun before a committee of lawyers gave their approval for it to be called Java. The other potential names were “Silk” and “Lyric”. From Jonathan’s blog that gives an account of James Gosling “…So, who named Java? Marketing organized the meeting, the consultant ran it, and a whole pile of us did a lot of yelling out of random words. I’m honestly not real sure who said “Java” first, but I’m pretty sure it was Mark Opperman.” So what about Oak ? Where did this come from?
Java was created by a secret “Green team” put together at Sun microsystems to prepare for the next big thing in computing. James Gosling one of the key members, basically named  it  after an Oak tree in front of his office. Short answer – Oak is the precursor of Java.


The first four bytes of every Java class file are specified to be 0xCAFEBABE, a magic number that can help tools quickly differentiate likely class files from non class files.  It is surprising how few people, even people who have been working on Java for a long time actually know of this. To check this out, open any .class file generated by the Java Compiler in a binary mode HEX editor, the first four bytes are CA FE BA BE . Sometimes, when I am in the (inevitable) position of interviewing a job applicant with deep knowledge of Java, I toss this question out casually. To my disappointment, not one single person out of the  dozen or so “senior Java people”  that I have asked it to has been able to give me the right answer – (not that this matters, being ignorant of trivia about Java is not a show stopper by any means).

There was much speculation about the origin of word when it was initially introduced. Take a look at this[] discussion for instance. The strange thing is that, it seems to have been decided even before the name “Java” was officially chosen to represent the language. There is also some discussion about Kim Polese and how she might have been the origin of the “babe” term for the original Java team.
The answer as provided by James Gosling himself here “We used to go to lunch at a place called St Michael’s Alley.  According to local legend, in the deep dark past, the Grateful Dead used to perform there …<snip>, we referred to the place as Cafe Dead.  Somewhere along the line it was noticed that this was a HEX number.  I was re-vamping some file format code and needed a couple of magic numbers: one for the persistent object file, and one for classes.  I used CAFEDEAD for the object file format, and in grepping for 4 character hex words that fit after “CAFE” (it seemed to be a good theme) I hit on BABE and decided to use it.  At that time, it didn’t seem terribly important or destined to go anywhere but the trash-can of history.  So CAFEBABE  became the class file format, and CAFEDEAD was the persistent object format.  But the persistent object facility went away, and along with it went the use of CAFEDEAD – it was eventually replaced by RMI.”

Green Threads

Green threads, the threads provided by the JVM, run at the user level, meaning that the JVM creates and schedules the threads itself. Therefore, the operating system kernel doesn’t create or schedule them. Instead, the underlying OS sees the JVM only as one thread. The latest JVMs all use native threads and not green threads but when Java was very young  (JDK 1.1), only green threads were supported.
The reason for this has to do with the original intent of Java’s creators – that it should be an OS that would run “set-top-boxes” for television. These were to be simple low-computing-power devices and hence Java used to abstract out all the thread creation into the user space rather than at the OS space.

Unfortunately as Java become popular in the enterprise, green threads proved inefficient for a number of reasons. Foremost, green threads could not take advantage of a multiprocessor system. Since the JVM runs from within one thread, the threads that the JVM created are not threads at the OS level. Instead, the JVM splits its timeslice among the various threads that it spawns internally. Thus, the JVM threads are bound to run within that single JVM thread that runs inside a single processor. In contrast, native threads were created and scheduled by the underlying operating system. Rather than creating and scheduling threads itself, the JVM created the threads by calling OS-level APIs. As a result, the native threading model can benefit from multiple processors. Performance can improve because an IO-blocked thread will no longer block the entire JVM. The block will only block the thread waiting for the IO resource.
However Green threads (or their equivalents) are still in use in some languages – Smalltalk and Ruby (as of 1.9) for instance. One benefit of using them is that the underlying OS does not have to support a threading implementation. They are also much lighter weight and faster to start.
I actually remember having to debug a Java program that was calling some multi-threaded C++ routine wrapped by JNI calls using a different Java version and encountering a hard-to-reproduce problem. After some very late nights spent going round in circles, I eventually figured out that the root of the problem was one version of Java was using green threads while the other was not.


Perhaps the most hotly debated aspect of Java when it was initially released was its Exception handling mechanism. Java has what are called as “checked exceptions” and “unchecked exceptions” – checked exceptions need to be declared as a part of the method signature (or caught). This results in fewer unpleasant surprises at run time but causes syntactic clutter and implementation leaks to seep into Interfaces. The class “RuntimeException” in the Java API and its children are examples of unchecked exceptions. Now comes the subtle and interesting part.

What is the meaning of the name “RuntimeException” ?  Why is the class so named? Think about this for a minute.

Whenever I ask this question of a Java professional, the inevitable answer I get is “It is so named because these are exceptions thrown at runtime”.  However ALL exceptions are thrown at runtime right? The real answer is so much simpler.
Recall that Java has a class called as the “Runtime” class – an abstracted representation of the underlying Java Virtual Machine that allows us to add hooks and get information. So the simple answer to “What is the meaning of the name RuntimeException” is
“It is an exception thrown by the Runtime itself” rather than any particular piece of code.

Top 10 Design Guidelines for building good software solutions

I have been building software solutions and systems for a while now. The following rules should be obvious to any programmer but more so for programmers who build typical enterprise systems.
These are sort of high-level guidelines more than hard-and-fast recommendations. As always experience will be the best teacher.
Here are the guidelines in no particular order:

0) Accept the fact that you will have to change or modify your design a few times and keep it Flexible. Design does not end when coding begins. Use an iterative approach.
If your final product after coding matches your very initial design exactly – either you are working on some fairly small product OR you have not found the issues yet.

1) Always document key assumptions that you make while designing any component. Implicit and out-of-date assumptions cause a lot of troubles down the road.

2) Keep it simple – do not devise complicated or fancy solutions unless there is no other way to meet requirements –
Good code IS NOT Fancy code; Good code IS Simple to Maintain Code; Good Code IS Easy to Understand Code;
This is the so called KISS principle. Over-engineered design is almost impossible to remedy and can add a great deal of dead weight that can sink any effort.

3a) You will almost never have to think up a solution from scratch. A little bit of research can save you a lot of trial and error. Google is your friend.
3b) If you use any code or libraries you find online make sure you consider the licensing aspects first.

4) Java specific – Favor Object Composition over Inheritance – Deep nested hierarchies are often a sign of design gone haywire (sometimes necessary but often avoidable).

5) Think about Program structure at Run-time and not just Compile time. How do the objects interact with each other at run-time? Do you understand it well?

6) Non-functional requirements can make or break a project – ALWAYS keep things like Performance, Memory utilization, Database impact, Threading Issues, etc in mind while going thru the design process.

7) Make sure you are aware of common Design Patterns and understand the context that they can be used in.
Gang-Of-Four design patterns such as Factory Methods, Mediators, Facades, Iterators and Singletons often will be the solution that you are looking for, they appear all over the place pretty frequently.
Many Java/J2EE patterns will also make your design process less prone to error by giving you pre-tested solutions. At the same time avoid pattern overuse.

8 ) Think of ways to test your components at design time. Very often, thinking about how some feature will be tested, will actually help you design it.
There are full-blown methodologies such as Test Driven Design/development that depend on this principle. A strong test suite saves you lots of grief while debugging.

9) Design to an Interface never to an Implementation. Try to minimize dependencies on specific implementation details of Objects in your code. Remember that internal implementation details of Objects are subject to change without notice.

10) Collaborate with others on the team and Have fun while doing it :).
Design by mandate is recipe for failure. Design by committee is the other extreme and equally bad but Design by collaboration produces great results.

What your computer does while you wait

Gustavo has a great post on his blog What your computer does while you wait. It has a couple of very excellent diagrams detailing the state of affairs and some nifty work converting computer clock-cycle timings to commonly referred ones.
The comparative in question:
Going to the L1 Cache (On Chip integrated): 3 Seconds
Going to the L2 Cache(On Chip, further away): 14 Seconds
Going to System memory (Computer RAM): 4 Minutes
Going to Persistent Memory (Hard Disk): 1 year, 3 months!

So in summary, most of the time is spent fetching data from disk.
The diagrams – Most Excellent

Go read the entire post…

Suprgeek Tweeting