Atif Khan’s Blog

A lot of Java applications run on Sun’s JDK due to various reasons. In fact till recently Sun had a very restrictive license policy for Java. So, effectively Sun’s JDK has been a de facto standard. That’s the reason Sun’s JDK code is supposed and expected to be of high quality and following at least the coding conventions recommended by Sun in a 1999 article that is widely used.

If you look under the hood of JDK, you will find a completely different picture. Here is an example from the Java 6 source code of StringBuilder class. (I have noticed similar stuff in 1.4 and 1.5 releases.)

• Indentation - not sure if it was edited in notepad (even vi does indentation) or a result of source control merge?.
• If clause doesn’t use brackets- Here is an excerpt from Sun’s Java coding conventions. The if-else class of statements should have the following form: if (condition) { statements; } if (condition) { statements; } else { statements; } if (condition) { statements; } else if (condition) { statements; } else { statements; } Note: if statements always use braces {}. Avoid the following error-prone form: if (condition) //AVOID! THIS OMITS THE BRACES {}! statement;

  Need I say more?

• Creating “null” string instance- Why can’t it be represented by a static final constant and reused? All the string literals are stored in JVM in a String pool, even the ones defined as constants. Isn’t it more optimized if you have a direct reference to it rather than JVM doing a lookup in the pool every time you call the method?
  Note: After looking at the bytecode generated by the compiler, it looks like a direct reference is pushed on the stack for the string literal. So, it effectively doesn’t matter if you use a literal or a constant. Still, if you are using a string literal over and over again, it may be a better idea to create a constant. This way if you need to change the string literal, there is only one place where you need to make change. So, you protect yourself against future changes. Thanks to Messi for pointing this out in the comments :).
• Variables can be made final-The method parameter sb and local variables len and newcount can all be declared final for optimization. This article has good explanation for it.
  Note: Again after analyzing the bytecode it seems like compiler really doesn’t care about the final declaration for the local variables. The method parameter are a different case as by declaring them final you make sure that they are not modified by mistake. Also, the local variables can be declared as final as a coding practice to mark them as immutable even though it doesn’t affect the byte code. But it makes it clear for a person looking at your code that the variable can not be modified. Thanks to Messi and Kevin Riff for pointing this out in the comments

This is just an example. There are instances like this all over the JDK code base. I want to make it clear that I am not commenting on the performance aspect of JDK, just the code conventions and formatting (for the obvious reasons that the code should be properly formatted). Now, since Sun has released the JDK source code under GPL license, do we expect to see things like this continue? Do you think people will take more responsibility and clean up the JDK code? I hope so. I also hope that Sun does not blacklist me after this post

One of the biggest feature added with JDK 1.5 is enum support. At last you can use a language construct to define constants in the system rather than using the static final to define the constants. The obvious benefits of enums are type safety and type checking.

Also enums let you define meaningful values for the constants. e.g.

As you can see in the above example, you can use the enum constant PI across your code, but if you wanted to get the value of PI, you can do that by using PI.getValue().

This is where things get a little fuzzy. What if you have a double value representing either PI or LOG_E and you want to find out which constant in MathEnum represents that value? This is the reverse lookup of enum. The Java implementation of enum does not allow reverse lookup by value. It is a very useful feature if you are working with an existing code base and an external system returns values for the constants that need to be translated into Java Enums.

Here is how this problem can be solved by using the Reversible Enum Pattern. First we need to create a ReversibleEnum interface that will mark the Enums as reversible and define the required method.

Next, we need to define a Map that will be used to store the enum constant values and for reverse lookup.

You will notice that in both the ReversibleEnum interface and the ReverseEnumMap class the Generics template is used. This is done to customize these based on the type of the enum that will use them and the type of the value of enum constants. If this sounds confusing, it will become more clear after we see the modified version of the MathEnum class from earlier.

The changes you will notice here are:

• MathEnum implements the ReversibleEnum interface.
• New variable for ReversibleEnumMap
• New method reverse(final Double value) to do the reverse lookup. This is from the ReversibleEnum interface.
• New static method getInstance() that just returns the first constant of the enum. This is kind of a hack to get a reference to an instant of the enum, so that the reverse(..) method could be called on it.

Now to do a reverse lookup on the MathEnum, all you need to do is:

Lets recap all the steps needed to be done to create a reversible enum:

1. Define an interface ReversibleEnum. — One time job.
2. Define a new class ReverseEnumMap. — One time job.
3. Implement the ReversibleEnum interface and define a member variable of type ReverseEnumMap in the enum that you want to be reversible. If you do not need the reverse functionality, you don’t need to do any of this.

So, effectively once you have the interface and map class created, it’s minimal effort to create a reversible enum. I wish this was a built-in functionality in the JDK enum implementation.