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.
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:
In JDK 7 it can be replaced with the following statement:
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:
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:
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:
After JDK 7 the same code can be written like this: