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:
Germany
Slovakia
Canada
Brazil
Singapore
Hungary
Philippines
Mexico
Thailand
Ukraine
Luxembourg
Estonia
Lithuania
Norway
Chile
United States
Great Britain
India
Spain
South Korea
Ecuador
Colombia
Taiwan
Switzerland
Indonesia
Cyprus
Denmark
Finland
Poland
Malta
Czechia
New Zealand
Austria
Turkey
France
Sweden
Italy
Egypt
Belgium
Portugal
Slovenia
Ireland
Romania
Greece
Argentina
Malaysia
South Africa
Netherlands
Bulgaria
Latvia
Australia
Japan
Russia
