A Thought a Day ...: Kedar Mhaswade's Weblog

This tip deals with using Javadoc to document the use of custom annotation types.[Read More]

Use of bad code as utility code is more commonplace. Is there any place for good practices? Or should you just churn out as much code as you can? [Read More]

Use IDE for Java Development. Here is why ...[Read More]

mvn + svn = mess?[Read More]

A subtle observation about usability as an inverse function of capability of a software.[Read More]

Disclaimer: I don't think this is not obvious (at least to some) and it (this observation) might have been made by many. I just reached it independently.

Javadoc is a great tool. It helps understand the basic hierarchy of an API and its public implementation. It's no replacement for looking into the source code, however. Sometimes, it might be misleading to draw conclusions based on what normal Javadoc shows, without looking into the code. Here is an example:

The java.util.LinkedList  inherits iterator() from java.util.AbstractSequentialList, which has a concrete implementation for iterator(). This method calls listIterator() which is inherited from java.util.AbstractList.  This method in turn calls listIterator(int index) which has concrete implementation in java.util.LinkedList  itself.

Thus, calling java.util.LinkedList.iterator()  will result in calling listIterator(int) on the same instance of LinkedList.

Did LinkedList really inherit iterator() from AbstractSequentialList in that case?

It of couse inherited the Java method named iterator(), but it does not inherit (and does override) the behavior for iterator().

Conclusion: Read source code, and open source software is beneficial.

While I was getting used to IDEA IntelliJ IDE, one "feature" caught my attention. They have a way to create a "Singleton" by way of a pop-up menu. Here is the code that generates the class for this controversial and damned pattern (now that Google has a Singleton Detector ).

public class Single {
    private static Single ourInstance = new Single();

    public static Single getInstance() {
        return ourInstance;
    }

    private Single() {
    }
}

I see at least two problems with this "default" code:

1. The class should have been declared final.
2. The variable ourInstance should have been declared final.

Motivation:

Quality criterion for boilerplate code is same as that for real code (in these days of fast search engines ). Also, I am mildly surprised that it takes a lot of time for me to:
• Create a Java Interface
• Create a Class that implements that Interface with stubbed implementation for interface methods .
This is true with both NetBeans 6.0 (which means it is true with any other IDE because NetBeans is the only IDE you need, these days ) and IDEA 7.0.

Java 6 is what Leopard misses ...

13949712720901ForOSX