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

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.

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.

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