New features in Java 7

New features in Java 7

1. Binary Literals
2. Strings in switch Statements
3. The try-with-resources Statement
4. Handling Multiple Exception Types
5. Rethrowing Exceptions with Improved Type Checking  
6. Type Inference for Generic Instance Creation 
7. New object utils class 

1. Binary Literals

In Java SE 7, the integral types (byte, short, int, and long) can also be expressed using the binary number system. To specify a binary literal, add the prefix 0b or 0B to the number. The following examples show binary literals:

// An 8-bit 'byte' value:
byte aByte = (byte)0b00100001;

// A 16-bit 'short' value:
short aShort = (short)0b1010000101000101;

// Some 32-bit 'int' values:
int anInt1 = 0b10100001010001011010000101000101;
int anInt2 = 0b101;
int anInt3 = 0B101; // The B can be upper or lower case.

// A 64-bit 'long' value. Note the "L" suffix:
long aLong = 0b1010000101000101101000010100010110100001010001011010000101000101L;

2. Strings in switch stamements 

Currently you can only use char, byte, short, int,Character, Byte, Short, Integer, or 

an enum type (spec).Now Java 7 adds Strings making the switch instruction much 

friendlier to String inputs.



public String getTypeOfDayWithSwitchStatement(String dayOfWeekArg) {

     String typeOfDay;

     switch (dayOfWeekArg) {

         case "Monday":

             typeOfDay = "Start of work week";

             break;

         case "Tuesday":

         case "Wednesday":

         case "Thursday":

             typeOfDay = "Midweek";

             break;

         case "Friday":

             typeOfDay = "End of work week";

             break;

         case "Saturday":

         case "Sunday":

             typeOfDay = "Weekend";

             break;

         default:

             throw new IllegalArgumentException("Invalid day of the week: " + dayOfWeekArg);

     }

     return typeOfDay;

}



The switch statement compares the String object in its expression with 
the expressions associated with each case label as if it were using the 
String.equals method; consequently, the comparison of String objects in 
switch statements is case sensitive. The Java compiler generates 
generally more efficient bytecode from switch statements that use String
 objects than from chained if-then-else statements.

 3. The try-with-resources Statement

A *resource* is as an object that must be closed manually,
such as a java.io.InputStream, OutputStream, Reader, Writer, Formatter;
java.nio.Channel;java.net.socket; java.sql.Connection, Statement, ResultSet,
or java.awt.Graphics.
The *automatic resource management statement* is a form of the try statement
that declares one or more resources. The scope of these resource
declarations is limited to the statement. When the statement completes,
whether normally or abruptly, all of its resources are closed automatically.
*EXAMPLES*
SIMPLE EXAMPLE: Here is a static method to read the first line of a file,
demonstrating the minimal (nearly) correct code to release a single resource
today.
    static String readFirstLineFromFile(String path) throws IOException {
        BufferedReader br = new BufferedReader(new FileReader(path));
        try {
            return br.readLine();
        } finally {
            br.close();
        }
    }
Unfortunately, if the readLine and close invocations both throw exceptions,
the latter exception supplants the former.  The only practical way around
this today would to be to ignore any exception thrown by the close invocation.
While this might be reasonable in the case of a Reader or InputStream, it
would be disastrous for a Writer or OutputStream.
Here’s how it would look with an automatic resource management statement:
    static String readFirstLineFromFile2(String path) throws IOException {
      try (BufferedReader br = new BufferedReader(new FileReader(path)) {
            return br.readLine();
         }
      }
You may declare one or more resources in a try-with-resources statement.
like
    try (
       java.util.zip.ZipFile zf = new java.util.zip.ZipFile(zipFileName);
       java.io.BufferedWriter writer = java.nio.file.Files.newBufferedWriter(outputFilePath, charset)
      )
The following example uses a try-with-resources statement to automatically close a java.sql.Statement object:
  public static void viewTable(Connection con) throws SQLException {
    String query = "select COF_NAME, SUP_ID, PRICE, SALES, TOTAL from COFFEES";
  try (Statement stmt = con.createStatement()){
      ResultSet rs = stmt.executeQuery(query);
      while (rs.next()) {
        String coffeeName = rs.getString("COF_NAME");
        int supplierID = rs.getInt("SUP_ID");
        float price = rs.getFloat("PRICE");
        int sales = rs.getInt("SALES");
        int total = rs.getInt("TOTAL");
        System.out.println(coffeeName + ", " + supplierID + ", " + price +
                           ", " + sales + ", " + total);
      }
    } catch (SQLException e) {
      JDBCTutorialUtilities.printSQLException(e);
    }
  }
The resource java.sql.Statement used in this example is part of the JDBC 4.1 and later API.
Note: A try-with-resources statement can have catch and finally blocks just like an ordinary try statement. In a try-with-resources statement, any catch or finally block is run after the resources declared have been closed.
Advantage : The automatic resource management statement obviates the need for manual resource termination, which has proven ugly and error prone.
It could emit the code to suppress the uninteresting(second) exception in favor of the interesting(first) one with no effort on the part of the programmer, and no loss to the clarity of the program.
Like the for-each statement(introduced in java 1.5), the automatic resource management statement is a small piece of syntactic sugar with a very high power-to-weight ratio.
Disadvantage: Like all syntactic sugar, this construct removes a bit of java's "what you see is what you get" character ("transparency").

4. Handling Multiple Exception Types

 

A single catch block can handle more than one type of exception. This feature can reduce code duplication and lessen the temptation to catch an overly broad exception.

Consider the following example, which contains duplicate code in each of the catch blocks:

catch (IOException ex) {
     logger.log(ex);
     throw ex;
catch (SQLException ex) {
     logger.log(ex);
     throw ex;
}

In releases prior to Java SE 7, it is difficult to create a common method to eliminate the duplicated code because the variable ex has different types.

The following example, which is valid in Java SE 7 and later, eliminates the duplicated code:

catch (IOException|SQLException ex) {
    logger.log(ex);
    throw ex;
}

The catch clause specifies the types of exceptions that the block can handle, and each exception type is separated with a vertical bar (|).

Note: If a catch block handles more than one exception type, then the catch parameter is implicitly final. In this example, the catch parameter ex is final and therefore you cannot assign any values to it within the catch block.

 

5. Rethrowing Exceptions with More Inclusive Type Checking

The Java SE 7 compiler performs more precise analysis of rethrown exceptions than earlier releases of Java SE. This enables you to specify more specific exception types in the throws clause of a method declaration.

Consider the following example:

  static class FirstException extends Exception { }
  static class SecondException extends Exception { }

  public void rethrowException(String exceptionName) throws Exception {
    try {
      if (exceptionName.equals("First")) {
        throw new FirstException();
      } else {
        throw new SecondException();
      }
    } catch (Exception e) {
      throw e;
    }
  }

This examples's try block could throw either FirstException or SecondException. Suppose you want to specify these exception types in the throws clause of the rethrowException method declaration. In releases prior to Java SE 7, you cannot do so. Because the exception parameter of the catch clause, e, is type Exception, and the catch block rethrows the exception parameter e, you can only specify the exception type Exception in the throws clause of the rethrowException method declaration.

However, in Java SE 7, you can specify the exception types FirstException and SecondException in the throws clause in the rethrowException method declaration. The Java SE 7 compiler can determine that the exception thrown by the statementthrow e must have come from the try block, and the only exceptions thrown by the try block can be FirstException and SecondException. Even though the exception parameter of the catch clause, e, is type Exception, the compiler can determine that it is an instance of either FirstException or SecondException:

  public void rethrowException(String exceptionName)
  throws FirstException, SecondException {
    try {
      // ...
    }
    catch (Exception e) {
      throw e;
    }
  }

This analysis is disabled if the catch parameter is assigned to another value in the catch block. However, if the catch parameter is assigned to another value, you must specify the exception type Exception in the throws clause of the method declaration.

In detail, in Java SE 7 and later, when you declare one or more exception types in a catch clause, and rethrow the exception handled by this catch block, the compiler verifies that the type of the rethrown exception meets the following conditions:

• The try block is able to throw it.
• There are no other preceding catch blocks that can handle it.
• It is a subtype or supertype of one of the catch clause's exception parameters.

The Java SE 7 compiler allows you to specify the exception types FirstException and SecondException in the throws clause in the rethrowException method declaration because you can rethrow an exception that is a supertype of any of the types declared in the throws.

In releases prior to Java SE 7, you cannot throw an exception that is a supertype of one of the catch clause's exception parameters. A compiler from a release prior to Java SE 7 generates the error, "unreported exception Exception; must be caught or declared to be thrown" at the statement throw e. The compiler checks if the type of the exception thrown is assignable to any of the types declared in the throws clause of the rethrowException method declaration. However, the type of the catch parametere is Exception, which is a supertype, not a subtype, of FirstException andSecondException.

6. Type Inference for Generic Instance Creation

Previously when using generics you had to specify the type twice, in the declaration and the constructor; List<String> strings = new ArrayList<String>();
In Java 7, you just use the diamond operator without the type; List<String> strings = new ArrayList<>();  

If the compiler can infer the type arguments from the context, it does all the work for you. Note that you have always been able do a “new ArrayList()” without the type, but this results in an unchecked conversion warning.

Type inference becomes even more useful for more complex cases;

Before Java 7

Map<String, Map<String,int>> mS = new HashMap<String, Map<String,int>>();

Java 7

Map<String, Map<String, int> mS = new HashMap();

Java SE 7 supports limited type inference for generic instance creation; you can only use type inference if the parameterized type of the constructor is obvious from the context. For example, the following example does not compile:

List<String> list = new ArrayList<>();
list.add("A");

  // The following statement should fail since addAll expects
  // Collection<? extends String>

list.addAll(new ArrayList<>());

Note that the diamond often works in method calls; however, it is suggested that you use the diamond primarily for variable declarations.

In comparison, the following example compiles:

// The following statements compile:

List<? extends String> list2 = new ArrayList<>();
list.addAll(list2);

7. New useful class (java.util.Objects) in java 7

In JAVA 7 API, we'll find a new class: java.util.Objects. This class consists of static utility 9 methods for operating on objects. These methods provide null-safe or null-tolerant operations on objects.
Methods in Objects class :
static <T> int compare(T a, T b, Comparator<? super T> c)
Returns 0 if the arguments are identical and c.compare(a, b) otherwise
static boolean deepEquals(Object a, Object b)
Returns true if the arguments are deeply equal to each other and false otherwise
static boolean equals(Object a, Object b)
Returns true if the arguments are equal to each other and false otherwise
static int hash(Object... values)
Generates a hash code for a sequence of input values.
static int hashCode(Object o)
Returns the hash code of a non-null argument and 0 for a null argument
static <T> T requireNonNull(T obj)
Checks that the specified object reference is not null
static <T> T requireNonNull(T obj, String message)
Checks that the specified object reference is not null and throws a customized NullPointerException if it is
static String toString(Object o)
Returns the result of calling toString for a non-null argument and "null" for a null argument
static String toString(Object o, String nullDefault)
Returns the result of calling toString on the first argument if the first argument is not null and returns the second

The following Examples demonstrates how to use some of these methods.

import java.util.Objects;

class Employee {

public String empName, empNo;

public Employee(String empName, String empNo){
this.empName = Objects.requireNonNull(empName, "Empolyee Name not be null"); // if first argument null, will throw null pointer exception with customized message
this.empNo = empNo;
}

@Override
public boolean equals(Object obj) {
final Employee employee = (Employee)obj;
return this.empName.equals(employee.empName) && this.empNo.equals(employee.empNo);
}

@Override
public int hashCode() {
return super.hashCode();
}

public void empDetails(){
System.out.println(empName);
System.out.println(Objects.toString(empNo, "Default value")); // if first argument null, will return the default value
}
}


public class ObjectsDemo{

public static void main(String[] args) {

System.out.println(Objects.hashCode(null)); // display 0

//Case1
Employee emp1 = new Employee("Employee1","1");
emp1.empDetails();

//Case2
Employee emp2 = new Employee("Employee2", null);
emp2.empDetails();

//Case3
System.out.println(Objects.equals(emp2, null));

//Case4
Employee emp3 = new Employee (null, "4");
emp3.empDetails();


}
}

output will be

0
Employee1
1
Employee2
Default value
Exception in thread "main" java.lang.NullPointerException
at test.Employee.equals(ObjectsDemo.java:18)
at java.util.Objects.equals(Objects.java:57)
at test.ObjectsDemo.main(ObjectsDemo.java:48)