Overview of JDK 7

Version 7 of JDK was a huge release for Java, providing great functionality for a wide group of developers and platforms, and Oracle WebLogic Server has been certified on this version since WebLogic 11g. Even though this isn't a brand new feature, it is an important one, so let's check some of the main features of this release:

• For those who work at the JVM level, InvokeDynamic (JSR 292) is the big name, providing extensions for dynamically-typed languages (such as Ruby, Perl, and Groovy) to perform at almost the same level as a pure Java program.

• The new class loader architecture introduces safe multithreaded class loading, among other related improvements.

• Concurrency and collections updates (JSR 166) create new classes that support the fork/join structure, new synchronization barriers, and a utility class ThreadLocalRandom that generates random numbers in applications invoking it from multiple threads.

• New APIs for filesystem access, part of NIO.2 (JSR 203), with support file metadata, symbolic links, multicast datagrams, and socket-channel binding. Also, there is a new file system provider for zip/jar files and enhancements to the Watch Service API that allows you to register for file change notifications.

• SDP (Socket Direct Protocol) support: An implementation of a high performance network protocol that streams data over InfiniBand connections on Linux and Solaris. To enable SDP you just need to set a JVM system property and a configuration file.

  Tip

  InfiniBand is a communications link used in high-performance computing (HPC) systems and datacenters that delivers low latency, scalable throughput between processor nodes and I/O systems, with transmission speeds up to 300 GBps.

• On the security side, there are many important enhancements, including support for Elliptic Curve Cryptography (ECC), TLS 1.1/1.2, and NLTM (Microsoft's security protocol).

• The JDBC was upgraded to Version 4.1, enabling the developer to use try-catch structures when dealing with the objects of Connection, Statement, and ResultSet—no need to write finally blocks to release these components anymore.

• Enhancements to the current MBeans (Management Beans) available at com.sun.management to access information about CPU usage on the system and the JVM.

• There was a minor update on the XML stack, including JAXP 1.4 (JSR 206), JAXB 2.2a (JSR 222), and JAX-WS 2.2 (JSR 224).

  Tip

  That's a pretty extensive list but it leaves out tons of RFEs (Request for Enhancement) that were addressed in JDK 7; the complete list can be found at http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html#jdk7changes.

The Project Coin

The objective of Project Coin is to define a set of simple changes to the Java language that would make the developer's life easier. Some of these changes make their way to JDK 7, and some are expected to be released with Version 8.

Let's explore some of these enhancements with quick examples.

The diamond operator

Following the DRY (Don't Repeat Yourself) principle, the diamond operator (<>) allows developers to have protection at compile time by inferring types from generic collections without repeating the declared type. Before JDK 7, if we had to declare a map that contains a list of Strings, it would look something like this:

Map<String, List<String>> words = new HashMap<String,List<String>>();

In JDK 7 it can be replaced with the following statement:

Map<String, List<String>> words = new HashMap<>();

The try-with-resources statement

The try-with-resources feature is also known as Automatic Resource Management because it's focused on resources such as connections, files, input/output streams, but in the end a so-called resource can be defined as an object that needs to be closed after being used. Basically, any object that implements the java.lang.AutoClosable interface can benefit from the try-with-resources statement.

The feature allows you to simplify resource management by closing one or more resources that were declared within a try block right after their use, without having to write code to release the resources (usually inside finally blocks), avoiding insertion of potential leaks.

A quick example on how this feature can be applied to execute a query is as follows:

try (Statement st = con.createStatement()) {
   ResultSet rs = st.executeQuery(q);

  // Process the results
} catch (SQLException e) {
    logger.error(e);
}

In the preceding example, a JDBC Statement is created within the try context and then used by a SQL query. After execution, the Statement will be automatically closed by JVM. In previous versions, we had to manually dispose of the Statement resource when it was no longer necessary, confirming that it isn't null and then releasing it.

Tip

The try-with-resources statement can still use finally blocks just like the traditional try statement; the difference is that any catch or finally block is now executed after the resources declared have been closed.

Strings in switch statements

Strings in switch statements is a long-awaited feature that you should have already asked yourself: Why don't we have strings in a Java switch statement? Some might say it is a performance issue or something like that, but there's not much sense discussing an optimization that sometimes even the Java compiler doesn't care about. Besides, even cell phones are multi-core nowadays, so processing power really isn't a factor here.

So, developers can have a good time when crafting their code now; if we need to test against a list of possible Strings, we can use one switch statement and save many if and else blocks:

for (Order order : orderList) {
  switch (order.getStatus()) {
  case "NEW":
    processNewOrder(order);
    break;
  case "PENDING":
    processPendingOrder(order);
    break;
  case "CLOSED":
    processClosedOrder(order);
    break;
  default:
    processErrorOrder(order);
    break;
  }
}

Of course it's a simple example, but remember that you would need to replace the case blocks with several cumbersome if and else statements.

Manipulating binary integral literals

The use of binary number manipulation is common in some programming domains (compression encoding, network protocols, or any other type of bitmapped application), though, Java supported the use of only other numeric representations such as decimal, hexadecimal, and octal.

The idea of adding some methods to let the programmer write the numbers directly in binary format is much more practical, and avoids injection of bugs, because the programmer doesn't need to keep in mind that a special variable with numbers in hexadecimal is in fact a number to be translated to binary.

Exception handling with multicatch statements

Usually it's a common requirement to write code that needs to catch multiple exceptions and deal with error handling using a common approach (the same piece of code replicated a few times). Until JDK 7, the simplest option was to write a common method to reuse the same error treatment (or re-throw the exception) for some common exceptions or even use the finally block (which is pretty nasty—getting your code executed even with no exceptions? Please don't!). With multicatch, it is possible to catch multiple exceptions and avoid this duplicated code in catch clauses.

A common exception handling block from Java 6 would look like this:

try {
  // try-code throwing IOException or SQLException
} catch (IOException ex) {
    logger.severe(ex.getMessage());
    throw ex;
} catch (SQLException ex) {
    logger.severe(ex.getMessage());
    throw ex;
}

After JDK 7 the same code can be written like this:

try {
  // try-code throwing IOException or SQLException
} catch (IOException | SQLException ex) {
    logger.severe(ex.getMessage());
    throw ex;
}