CertPal

I have taken many java interviews over the last few years. As time passed by, I learned from mistakes I have made. One of them being to ask candidates trick questions or questions that do not necessarily have an obvious answer.

I read a blog post recently that detailed such a question. I will highlight the question here along with the answer

public class JavaPuzzler{
    public static void main(String[] args) {
        HashSet<Short> s = new HashSet<Short>();//1
        for(short i = 0; i<100;i++){//2
            s.add(i);//3
            s.remove(i-1);//4
        }
        System.out.println(s.size());//5
    }
}

Can you guess the answer to this question ? Simply drag and select the text near the spoiler to see the answer.

Spoiler: The answer to the question is 100. The gotcha is that the statement s.remove(i-1); at //4 will autobox to an Integer and not a Short. Equals comparison between an Integer and Short fails.

I came across a post on the Adam Bien blog recently about using the prefix ‘Abstract‘ to define Abstract classes. The argument was that using the ‘Abstract‘ prefix is superfluous. I do not fully agree with the post. As I read the points he had mentioned on the post, here are some that came to mind

Abstract classes are already distinguishable by the keyword abstract. There is no need to further emphasize it.

A prefix “Abstract” doesn’t provide any additional value to the user – in contrary it blurs the actual intention

The Abstract in the class name helps a developer know that a class is Abstract even before they open it. Of course if some one bucks the convention and names a Concrete class abstract, it creates confusion but that scenario is rare.

Modern IDEs don’t let you instantiate an abstract class, even before saving / compiling.