Hrishikesh Barua | code@deepinspace

When I was studying for my CS degree, the programming language we were taught was C. To be honest, I didn’t code much C in college – just what was necessary to scrape through the lab assignments. I did stay up one night writing Tetris in C with 2 close friends for an internal contest, but such occasions were rare. Pointers? Grokked them, but I suspect it was a very shaky understanding. For the rest of my years there, it was C for all lab projects. I didn’t dislike C, but I did find it tough for a first language. So as soon as I got a chance, I set out to do some side projects in Java (atleast I thought was writing Java). That was the end of my relationship with C, because my first (and current) job post-college was and still is in a Java shop.

Fast forward 8 years. The products I’ve worked on till now have been in Java. Serverside Java, Infrastructure Java, Applications Java. An appserver, a desktop app, a SaaS app. Abstractions, APIs, SPIs, Specifications, Javadocs, Objects talking to each other – it’s a satisfying, pleasant world if you like high level order.

I made occasional forays into Python and Ruby for some side projects and scripting.

But lately, I’ve been wanting to code in a really low level language. Yes, like C. Let me rephrase that. I’ve been wanting to write code where I can be as close to the OS as possible, learn bit twiddling hacks, make low level system calls. I’m not sure what this desire was born out of. Maybe 8 years of Java. Maybe wanting low level control over what I was doing.

So I’ve ploughed through K&R the last couple of months. Bought Deep C Secrets. Regrokked pointers – properly, this time. Had a brief period of not knowing where to go after this, which resolved itself in the form of Unix Network Programming (Richard Stevens). I’m working through Vol 1 right now. It’s slow going at times, but I’m loving every moment. I’ve fallen through – the abstractions, the bytecode, the layers of objects – and reached the ocean floor.

<In the background, the Toccata ends, and the Fugue begins.>

Take a look at this simple code

Code Snippet 1

public class Init {
    {
        System.out.println("In the beginning was the command line");
    }

    public Init()
    {
        System.out.println("Created an instance");
    }

    public static void main(String[] args)
    {
        Init init = new Init();
    }
}

What do you think the output is? It’s this -

    In the beginning was the command line
    Created an instance

The ‘hanging’ braces at the start of the class definition are instance initializers. Most of us are more familiar with static initializers -

Code Snippet 2

static
{
    //Do stuff
}

Instance initializers (II) are not seen often in everyday Java code – so they might seem odd at first. They are executed every time an instance of that class is created, before the statements in the constructor are executed. (See The Java Language Specification 3 section 8.6).

One use of IIs can be to execute something whenever an instance is created, and the class has multiple constructors, without calling it in every single constructor.
Another one which has become popular is populating collections during declaration, in the style of Ruby or Python single-line initializers -

Code Snippet 3

private Set<String> names = new HashSet<String>() {
    {
        add("Rigel");
        add("Vega");
        add("Antares");
    }
};

This idiom was how I encountered IIs first while reading somebody’s blog.
What is actually happening here?

1. An anonymous inner class is created.
2. An instance initializer block is added to the anon inner class.
3. Objects are added to the instance of that class when the names variable is initialized.

Now take this scenario
Code Snippet 4

public class WrongUsage {

    private Set<String> names;

    {
        add("pleiades");
    }

    public void WrongUsage()
    {
        names = new HashSet<String>();
    }

    public void add(String name)
    {
        names.add(name);
    }
}

Based on what we have seen above, the names set is used before it’s initialized. So this throws a NullPointerException.
Let’s take another case – similar to the above but involving inheritance.

Code Snippet 5

public class MyHashSet extends HashSet {
    {
        add("pleiades");
        System.out.println("Added");
    }

    public MyHashSet()
    {
        super();
        System.out.println("After calling super");
    }

    public static void main(String[] args)
    {
        Set set = new MyHashSet();
    }
}

This runs, with the output being

    Added
    After calling super

In this case, add() internally uses the inner HashMap inside HashSet which is initialized in the HashSet constructor. This implies that the instance initializer is invoked before the class constructor, but after the superclass constructor (The super call is redundant here. It will be called anyway).

So the sequence is

1. Superclass initialization (this includes superclass instance initializers and constructor)
2. Current class’s Instance initializers
3. Current class’s Constructor

This is why the code in Code Snippet 3 does not throw an NPE – because it’s a case of inheritance (the anon inner class is a subclass of HashSet)

A friend of mine forwarded this article by Yakov Fain on sys-con.com -

http://in.sys-con.com/node/1040135

The essence of the article is this

The author interviewed a lot of people for developer positions, and most of them who call themselves Java developers and cite extensive experience in J2EE lack basic knowledge of core Java.

This might sound suspiciously like a gross generalization, but I believe that’s not the case. I had a similar experience when I interviewed people for developer positions on my team last month. The position called for both Java and Javascript experience. These are the things I encountered -

• Most people who have worked solely on services (read outsourced) projects list all J* technologies on their resume, but know very little in depth of Java programming.
• There are people who lack any kind of programmer mentality or skills at all and put their current role as something like Programmer Analyst, and this fact cannot be ascertained from their resume alone. They often try to highlight other (non-software development) achievements.
• SCJP certification is no guarantee that a person can code in Java (Surprise? Not at all)
• There are people who have 3.5 years of experience, with multiple services projects under their belts, and familiarity with a host of technologies, who cannot write a Java class which will print out the prime numbers between 0 and 100.
• Most core CS concepts are forgotten after 2-3 years of working in services projects.

Please note that I am not generalizing, but these facts do indicate a problem somewhere. These developers actually a represent a very small distinct sample of the worldwide developer community, since all my interviews were done in India (both face to face in my Hyderabad office and over the phone).

Another interesting point I noted was that most non-Javascript developers think that Javascript is used only for form validation. Such usage also qualifies as ‘extensive Javascript knowledge’ in their resumes.

What should I conclude from this? Is this malaise widespread in other parts of the world as well? Is it specific to developers in India working on outsourced projects? (No, as the link by Yakov Fain shows) Is it a result of outsourcing, leading to a lack of innovation? Or is the innovation there, but the signal to noise ratio too low?