Java 7: New Features

• JVM support for dynamic languages, following the prototyping work currently done on the Multi Language Virtual Machine
• Compressed 64-bit pointers^[87] (available in Java 6 with -XX:+UseCompressedOops)^[88]
• Small language changes (grouped under a project named Coin):^[89]

·         Strings in switch^[90]

·         Automatic resource management in try-statement^[91]

·         Improved type inference for generic instance creation^[92]

·         Simplified varargs method declaration^[93]

·         Binary integer literals^[94]

·         Allowing underscores in numeric literals^[95]

·         Catching multiple exception types and rethrowing exceptions with improved type checking^[96]

• Concurrency utilities under JSR 166^[97]
• New file I/O library to enhance platform independence and add support for metadata and symbolic links. The new packages are java.nio.file and java.nio.file.attribute^[98][99]
• Library-level support for elliptic curve cryptography algorithms
• An XRender pipeline for Java 2D, which improves handling of features specific to modern GPUs
• New platform APIs for the graphics features originally implemented in version 6u10 as unsupported APIs^[100]
• Enhanced library-level support for new network protocols, including SCTP and Sockets Direct Protocol
• Upstream updates to XML and Unicode

Strings in switch

many a times we want to switch based upon string output received from user or other part of program but before JDK7 we can't do it directly instead either we need to map those String to final integer constant or char constant to use them inside switch and case or you need to fallback on if-else statement which gets clumsy once number of cases getting increased. But now with jdk7 you can directly use String inside switch and case statement.
Example:

switch (trading) { 

            case "Stock Trading":    

                        System.out.println("Trader has selected Stock Trading option"); 

                        break; 

            case "Electronic Trading":      

                        System.out.println("Trader has selected Electronic Trading option");      

                        break; 

            case "Algorithmic Trading":      

                        System.out.println("Trader has selected Algorithmic Trading option");      

                        break; 

            case "Foreign exchange trading":      

                        System.out.println("Trader has selected Foreign exchange Trading option");      

                        break; 

            case "commodity trading":      

                        System.out.println("Trader has selected commodity trading option");      

                        break;

            default:      

            throw new IllegalArgumentException();

}

Automatic Resource Management

java.lang.AutoCloseable, interface has been added in API which contains single method close() throws Exception    this interface is a parent of java.io.closeable interface so all the input and output devices inherit this property.

Here is example of automatic resource management with JDK 1.7 source base. Please make sure you run this with java source 1.7 otherwise you will get compilation error.

try (

FileInputStream stockQuoteReader = new FileInputStream("StockQuotes.txt");

FileOutputStream stockQuoteWriter = new FileOutputStream("StockQuotes.txt") )  {

int var;     

while((var= stockQuoteReader.read()) != -1 )   

stockQuoteWriter.write(); 

}

In this code inside try we have declare two file stream one is input file we are reading from one file and writing to another file.

After the whole process both streams will be closed automatically either the code has been executed normally or not that means stockQuoteReader.close() and stockQuoteWriter.close() called automatically which is the best part of ARM.

Whatever resource we are using should be subtypes of AutoCloseable other wise will get compile time error.

§          The resources which we are using are closed in reverse order means stockQuoteWriter.close() will be called first then stockQuoteReader.close().

That’s all on new automatic resource management (ARM) feature on JDK7, some how it address the cluttering of code due to checked exception handling and code duplication on several exception cache block.

Binary integer literals

byte fourTimesThree = 0b1100;

byte data = 0b0000110011;

short number = 0b111111111111111;

int overflow = 0b10101010101010101010101010101011;

long bow = 0b101010101010101010101010101010111L;

 

// 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;

Allowing underscores in numeric literals

In Java SE 7 and later, any number of underscore characters (_) can appear anywhere between digits in a numerical literal.

This feature enables you, for example, to separate groups of digits in numeric literals, which can improve the readability of your code.

long creditCardNumber = 1234_5678_9012_3456L;

long socialSecurityNumber = 999_99_9999L;

float pi =     3.14_15F;

long hexBytes = 0xFF_EC_DE_5E;

long hexWords = 0xCAFE_BABE;

long maxLong = 0x7fff_ffff_ffff_ffffL;

byte nybbles = 0b0010_0101;

long bytes = 0b11010010_01101001_10010100_10010010;

You can place underscores only between digits; you cannot place underscores in the following places:

·         At the beginning or end of a number

·         Adjacent to a decimal point in a floating point literal

·         Prior to an F or L suffix

·         In positions where a string of digits is expected

Catching multiple exception types and rethrowing exceptions with improved type checking

Case 1:

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;

}

Case 2:

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 statement throw 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.

Type Inference for Generic Instance Creation

You can replace the type arguments required to invoke the constructor of a generic class with an empty set of type parameters (<>) as long as the compiler can infer the type arguments from the context. This pair of angle brackets is informally called the diamond.

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<>();//one more way in java 7 to create object for generic class

list.add("A");

  // The following statement should fail since addAll expects

  // Collection<? extends String>

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