Java: Out with the Old, In with the New

Java is nearing version 7. It occurs to me that there must be plenty of textbooks and training manuals kicking around that teach methods based on older versions of Java, where the methods taught, would have far better solutions now.

What are some boilerplate code situations, especially ones that you see people implement through force of habit, that you find yourself refactoring to utilize the latest versions of Java?

Enums. Replacing

public static final int CLUBS = 0;
public static final int DIAMONDS = 1;
public static final int HEARTS = 2;
public static final int SPADES = 3;

with

public enum Suit { 
  CLUBS, 
  DIAMONDS, 
  HEARTS, 
  SPADES 
}

Generics and no longer needing to create an iterator to go through all elements in a collection. The new version is much better, easier to use, and easier to understand.

EDIT:

Before:

List l = someList;
Iterator i = l.getIterator();
while (i.hasNext()) {
    MyObject o = (MyObject)i.next();
}

After

List<MyObject> l = someList;
for (MyObject o : l) {
    //do something
}

Using local variables of type StringBuffer to perform string concatenation. Unless synchronization is required, it is now recommended to use StringBuilder instead, because this class offers better performance (presumably because it is unsynchronized).

reading a string from standard input:

Java pre-5:

try {
    BufferedReader reader = new BufferedReader(new InputStreamReader(System.in));
    String str = reader.readLine();
    reader.close();
}
catch (IOException e) {
    System.err.println("error when closing input stream.");
}

Java 5:

Scanner reader = new Scanner(System.in);
String str = reader.nextLine();
reader.close();

Java 6:

Console reader = System.console();
String str = reader.readLine();

Here is one that I see:

String.split() versus StringTokenizer.

StringTokenizer is not recommended for new code, but I still see people use it.

As for compatibility, Sun makes a huge effort to have Java be backwards and forwards compatible. That partially accounts for why generics are so complex. Deprecation is also supposed to help ease transitions from old to new code.

Older code using Thread instead of the many other alternatives to Thread... these days, very little of the code I run across still needs to use a raw thread. They would be better served by a level of abstraction, particular Callable/Futures/Executors.

See:

java.util.Timer

javax.swing.Timer

java.util.concurrent.*

VARARGS can be useful too.

For example, you can use:

public int add(int... numbers){
    int sum = 0 ;
    for (int i : numbers){
        sum+=i;
    }
    return sum ;
}

instead of:

public int add(int n1, int n2, int n3, int n4) ;

or

public int add(List<Integer> numbers) ;

Using local variables of type Vector to hold a list of objects. Unless synchronization is required, it is now recommended to use a List implementation such as ArrayList instead, because this class offers better performance (because it is unsynchronized).

Formatted printing was introduced as late as in JDK 1.5. So instead of using:

String str = "test " + intValue + " test " + doubleValue;

or the equivalent using a StringBuilder,

one can use

String str = String.format("test %d test %lg", intValue, doubleValue);

The latter is much more readable, both from the string concatenation and the string builder versions. Still I find that people adopt this style very slowly. Log4j framework for example, doesn't use this, although I believe it would be greatly benefited to do so.

Explicit conversion between primitive and wrapper types (e.g. Integer to int or vice versa) which is taken care of automatically by autoboxing/unboxing since Java 1.5.

An example is

Integer myInteger = 6;
int myInt = myInteger.intValue();

Can simply be written as

Integer myInteger = 6;
int myInt = myInteger;

But watch out for NullPointerExceptions :)

Q1: Well, the most obvious situations are in the generics / type specific collections. The other one that immediately springs to mind is the improved for loop, which I feel is a lot cleaner looking and easier to understand.

Q2: In general, I have been bundling the JVM along side of my application for customer-facing apps. This allows us to use new language features without having to worry about JVM incompatibility.

If I were not bundling the JRE, I would probably stick to 1.4 for compatibility reasons.

A simple change in since 1.5 but makes a small difference - in the Swing API accessing the contentPane of a JFrame:

myframe.getContentPane().add(mycomponent);

becomes

myframe.add(mycomponent);

And of course the introduction of Enums has changed the way many applications that used constants in the past behave.

String.format() has greatly improved String manipulation and the ternary if statement is quite helpful in making code easier to read.

Generic collections make coding much more bug-resistant. OLD:

Vector stringVector = new Vector();
stringVector.add("hi");
stringVector.add(528); // oops!
stringVector.add(new Whatzit());  // Oh my, could spell trouble later on!

NEW:

ArrayList<String> stringList = new ArrayList<String>();
stringList.add("hello again");
stringList.add(new Whatzit()); // Won't compile!

Using Iterator:

List list = getTheList();
Iterator iter = list.iterator()
while (iter.hasNext()) {
  String s = (String) iter.next();
    // .. do something
}

Or an alternate form sometimes seen:

List list = getTheList();
for (Iterator iter = list.iterator(); iter.hasNext();) {
  String s = (String) iter.next();
  // .. do something
}

Is now all replaced with:

List<String> list = getTheList();
for (String s : list) {
  // .. do something
}

Although I admit that static imports can easily be overused, I like to use

import static Math.* ;

in classes that use a lot of Math functions. It can really decrease the verbosity of your code. I wouldn't recommend it for lesser-known libraries, though, since that can lead to confusion.

Converting a number to a String:

String s = n + "";

In this case I think there has always been a better way of doing this:

String s = String.valueOf(n);

copying an existing array to a new array:

pre-Java 5:

int[] src = new int[] {1, 2, 3, 4, 5};
int[] dest = new int[src.length];
System.arraycopy(src, 0, dest, 0, src.length);

Java 6:

int[] src = new int[] {1, 2, 3, 4, 5};
int[] dest = Arrays.copyOf(src, src.length);

formerly, I had to explicitly create a new array and then copy the source elements to the new array (calling a method with a lot of parameters). now, the syntax is cleaner and the new array is returned from a method, I don't have to create it. by the way, the method Arrays.copyOf has a variation called Arrays.copyOfRange, which copies a specific region of the source array (pretty much like System.arraycopy).

The new for-each construct to iterate over arrays and collection are the biggest for me.

These days, when ever I see the boilerplate for loop to iterate over an array one-by-one using an index variable, it makes me want to scream:

// AGGHHH!!!
int[] array = new int[] {0, 1, 2, 3, 4};
for (int i = 0; i < array.length; i++)
{
    // Do something...
}

Replacing the above with the for construct introduced in Java 5:

// Nice and clean.    
int[] array = new int[] {0, 1, 2, 3, 4};
for (int n : array)
{
    // Do something...
}

Clean, concise, and best of all, it gives meaning to the code rather than showing how to do something.

Clearly, the code has meaning to iterate over the collection, rather than the old for loop saying how to iterate over an array.

Furthermore, as each element is processed independent of other elements, it may allow for future optimizations for parallel processing without having to make changes to the code. (Just speculation, of course.)

Related to varargs; the utility method Arrays.asList() which, starting from Java 5, takes varargs parameters is immensely useful.

I often find myself simplifying something like

List<String> items = new ArrayList<String>();
items.add("one");
items.add("two");
items.add("three");
handleItems(items);

by using

handleItems(Arrays.asList("one", "two", "three"));

Annotations

I wonder no one mentioned it so far, but many frameworks rely on annotations, for example Spring and Hibernate. It is common today to deprecate xml configuration files are in favor of annotations in code (though this means losing flexibility in moving from configuration to meta-code, but is often the right choice).The best example is EJB 2 (and older) compared to EJB 3.0 and how programming EJB has been simplified thanks to annotations.

I find annotations also very useful in combination with some AOP tools like AspectJ or Spring AOP. Such combination can be very powerful.

Changing JUnit 3-style tests:

class Test extends TestCase {
    public void testYadaYada() { ... }
}

to JUnit 4-style tests:

class Test {
   @Test public void yadaYada() { ... }
}

Improved singleton patterns. Technically these are covered under the popular answer enums, but it's a significant subcategory.

public enum Singleton {
    INSTANCE;

    public void someMethod() {
        ...
    }
}

is cleaner and safer than

public class Singleton {
    public static final Singleton INSTANCE = new Singleton();

    private Singleton() {
        ...
    }

    public void someMethod() {
        ...
    }
}

Converting classes to use generics, thereby avoiding situations with unnecessary casts.

I'm a little wary to refactor along these lines if that is all you are doing to your source tree. The examples so far do not seem like reasons alone to change any working code base, but maybe if you are adding new functionality you should take advantage of all the new stuff.

At the end of the day, these example are not really removing boiler plate code, they are just using the more manageable constructs of newer JDKs to make nice looking boiler plate code.

Most ways to make your code elegant are not in the JDK.

Okay, now it's my turn to get yelled at.

I don't recommend 90% of these changes.

It's not that it's not a good idea to use them with new code, but breaking into existing code to change a for loop to a for(:) loop is simply a waste of time and a chance to break something. (IIWDFWI) If it works, don't fix it!

If you are at a real development company, that change now becomes something to code-review, test and possibly debug.

If someone doing this kind of a refactor for no reason caused a problem of ANY sort, I'd give them no end of shit.

On the other hand, if you're in the code and changing stuff on that line anyway, feel free to clean it up.

Also, all the suggestions in the name of "Performance" really need to learn about the laws of optimization. In two words, Don't! Ever! (Google the "Rules of optimization if you don't believe me).

Using Swing's new DefaultRowSorter to sort tables versus rolling your own from scratch.

New version of Java rarely break existing code, so just leave old code alone and focus on how the new feature makes your life easier.

If you just leave old code alone, then writing new code using new features isn't as scary.

String comparisons, really old school Java programmers I've met would do:

String s1 = "...", s2 = "...";

if (s1.intern() == s2.intern()) {
    ....
}

(Supposedly for performance reasons)

Whereas these days most people just do:

String s1 = "...", s2 = "...";

if (s1.equals(s2)) {
    ....
}

Using Vector instead of the new Collections.

Using classes instead of enums

 public class Enum
  {
      public static final Enum FOO = new Enum();
      public static final Enum BAR = new Enum();
  }

Using Thread instead of the new java.util.concurrency package.

Using marker interfaces instead of annotations

It is worth noting that Java 5.0 has been out for five years now and there have only been minor changes since then. You would have to be working on very old code to be still refactoring it.