New features coming to Java 7

Joseph Darcy, the lead of Project Coin, formally announced the approved changes to the Java language to be included in JDK 7.  Although there was no major change announced, the announced enhancements will improve program readability. Following are few changes that I am glad they are going to incorporate in JDK7.

Automatic Resource Management:

The change I liked the most is the proposal for automatic resource management. Currently whenever you open and use a java resource, e.g, IO Stream or database connection, you need to release that resource after you are done using it. But most of the time this is not done properly or even not done at all. This leads to costly memory leaks and sometime application failures. I have seen many examples of this where programmers failed to close database connections and that ultimately crashed the database. The proposed automatic resource management will take care of releasing the resources after the statement is completed. It will even close the resource if the statement ends abruptly. It has another advantage. It will make Java code cleaner by eliminating the boiler-plate exception handling code that is required in current version during creation and disposal of resources. All classes that represent various resources in Java will implement a new interface, Disposable. These resources are then automatically disposed upon completion. Here’s how it would look with an automatic resource management statement: (taken from the proposal):

static String readFirstLineFromFile2(String path) throws IOException
{
    try (BufferedReader reader = new BufferedReader(new FileReader(path))
   {
       return reader.readLine();
    }
}

Diamond Notation:

One of the significant additions to Java language was the introduction of generics in Java5. Most programmers welcomed the change. Generics and paramaterized type ensure type safety, thus eliminating the possibility of run-time type mismatch exception. But they unnecessarily made the declarations quite lengthy and verbose. For e.g;

Map> accounts = new HashMap>(); 

with diamond notation in JDK7 the programmers can replace the generic parameters on the right-hand side of the statement with empty <>, if the full parametrized type is obvious from the context.

Map> accounts = new HashMap<>();

This will also apply to parameter passing. For e.g; (taken from proposal)

class TreeNode {
  T value;
  TreeNode left, right;
  private List> buildPathsInternal(
    List> list, List currPath, TreeNode node) {
    if (node == null) {
      // type inference does not save typing here; see section on Wildcards.
      list.add(new ArrayList(currPath));
      return list;
    }
    currPath.add(node);
    buildPathsInternal(list, currPath, node.left);
    buildPathsInternal(list, currPath, node.right);
    currPath.remove(node);
    return list;
  }
  public List> getAllPaths(TreeNode head) {
    // Type inference saves typing here:
    return buildPathsInternal(new ArrayList<>(), new LinkedList<>(), head);
  }
}

Switch using String literals:

Another welcome change is including the String literals in switch statement. I have seen many applications with a lot of if/else conditions where programmers need to decide the course of action based on a string value. For e.g;

if(clientID.equals("eStore"){
  callEStore(clientID);
 }else if(clientID.equals("Retail")){
	callRetail();
 }else if(clientID.equals("CSR")){
	callCSR();
 }else{
	invalidClient();
 }

With the proposed change in JDK7, this code can be written using the switch statement.

swith(clientID){
  case "eStore":
    callEStore();
    break;
 case "Retail":
   calRetail();
   break;
 case "CSR":
   callCSR();
   break;
   default:
   invalidClient();
 }

I am looking forward to using these and other proposed changes in coming months.