"Ease of Development" is one of the main focuses in J2SE 5. Accordingly, J2SE 5 introduces several new features designed to simplify the developer's life. If you use these new constructs, your code will become more compact and expressive, hence easier to understand and debug. This article explains how you can use the new features to prevent some silly mistakes, as well as some that are not so silly.

Generics
The Collections framework was introduced in Java 1.2. It provides a set of interfaces and implementations that encapsulate many common data structures, the most common being the List and Map interfaces.

The main drawback of using this well-thought-out framework is that a significant amount of casting is required when extracting elements from a pre-J2SE 5 collection (because the collection necessarily has no knowledge of what kind of elements are stored in it). Listing 1 provides a simple example. In the listing, the line with the cast is clunky. Yet it seems that nothing could go wrong, since the only way to add elements to fileList is through the addFile method, which takes only a string.

However, problems will inevitably surface sooner or later. For instance, assume that two years later, you or another developer decide that it would be a good idea to store actual File objects (instead of their names) in the FileList class.

The addFile method will be changed to read:

	public void addFile (File file) {
		fileList.add(file);
	}

The code will compile just fine. Yet, when the customer runs the application, it will crash with a ClassCastException as soon as the listExtensions () method is called. One way to guard against this problem is to wrap each casting operation into some defensive code:

while (it.hasNext()) {
	Object name = it.next();
	if (name instanceof String) {
		System.out.println
			(getExtension((String)name));
	}
}

This will solve the immediate problem, but it has several drawbacks:

• The code is now even clunkier (and, consequently, more difficult to maintain).
• There are (potentially) many unnecessary instanceof operations.
• The application will fail silently instead of crashing when a disruptive change in code (such as the one above) occurs. Whether this is a better or worse situation for the customer and the support staff is debatable.

I'm pretty sure that most developers wouldn't make such an obvious mistake, but the problem can manifest itself in much more subtle ways, and it grows into a major issue when libraries are shared across team and company boundaries.

J2SE 5 provides a solution for all of this: collections can now use generics. For instance:

private List <String> fileList = new ArrayList <String> ();

Now, only strings can be added to fileList, and method calls, such as fileList.get(0) and fileList.iterator().next(), will return strings with no casting necessary:

String name = it.next();

If you use generics and try to modify the addFile method, the compiler will flag your attempt to add a File to a List<String>. If you change the declaration of fileList to a List<File>, the compiler will now notice that it.next() returns File and not a string; this will force you to fix the listExtensions method.

Note that this is just one use of generics. One of my other favorites is that since the Comparable interface is now generic, you can write the following code and avoid the boilerplate instanceof/casting code that is common for compareTo method implementations:

public class Comp implements Comparable <Comp> {
    public int compareTo(Comp o) {
        ....
    }
}

Enhanced For Loop
Here is a snippet of buggy code (slightly modified from the J2SE 5 release notes):

List <Suit> suits = ...;
List <Rank> ranks = ...;
List <Card> sortedDeck = new ArrayList <Card> ();

for (Iterator <Suit> i = suits.iterator(); i.hasNext(); )
	for (Iterator <Rank> j = ranks.iterator(); j.hasNext(); )
	sortedDeck.add(new Card(i.next(), j.next()));

If you try to run it, it will throw a NoSuchElementException. Can you spot the bug? The problem is that i.next() is being called every time a new card is created, rather than once per suit. As a result, we run out of suits much faster than expected. This is how to fix the loop:

for (Iterator <Suit> i = suits.iterator(); i.hasNext(); ) {
    Suit suit = i.next();
    		for (Iterator <Rank> j = ranks.iterator(); j.hasNext(); )
        	Rank rank = j.next();
	   			    sortedDeck.add(new Card(suit, rank));
}

J2SE 5's new enhanced for loop construct provides a neat solution for this. The nested loop in the above code can be rewritten as:

for (Suit suit : suits)
for (Rank rank : ranks)
	sortedDeck.add(new Card(suit, rank));

What appears to be happening is that the variables suit and rank point (in turn) to the elements of the Lists suits and ranks. Under the hood, the same code as in the fixed loop is being run.

Enhanced for loops can also be used while iterating through arrays. This time, instead of not having to explicitly iterate in your code, you can skip any references to the array indices:

String [] vowels = new String [] {"a", "e", "i", "o", "u"};

for (vowel : vowels) {
	System.out.println(vowel.toUpperCase());
}

As well as being more compact and easy to understand, the enhanced for construct for arrays prevents common bugs, such as referring to the wrong index in nested loops:

boolean isVowel (char c) {
}
int vowel_count = 0;
for (int i = 0; i < words.length; i++) {
	String word = words[i];
	for (int j = 0; j < word.length(); j++) {
		if (isVowel(word.charAt(i)) {
			vowel_count++;
		}
	}
}

Enums
C has an enum construct, which in theory allows the developer to define an enumerated type, but in practice does little more than define a bunch of integer constants. In the pre-J2SE 5 world, the most common way to accomplish the same task was to mimic the way C works and write code like this:

public class Card {
	// suits
	public static final int CLUBS = 0;
	public static final int DIAMONDS = 1;
	public static final int HEARTS = 2;
	public static final int SPADES = 3;
	// ranks
	public static final int ACE = 1;
	public static final int DEUCE = 2;
	...
	public static final int KING = 13;	}