Project Coin: “Small” Java 7 Tweaks, Big Dev Gains

Project Coin: “Small” Java 7 Tweaks, Big Dev Gains

There are several new features being introduced with the new release of JDK 7. Some of the important changes that will be introduced in Java 7 include:

  1. Project Coin
  2. Join/Fork Framework
  3. File System NIO2
  4. Changes to the JVM

We will cover all these features in our series on New Java 7 Features. In this first installment, we explore the features of Project Coin.

What Is Project Coin?

Project Coin (JSR 334) features some of the smaller enhancements made to JDK 7. The objective of this project is to make programs more readable and reliable, as well as to make them integrate well with existing and future versions of Java. Project Coin features have been introduced primarily at the language level.

The following features are supported as part of Project Coin:

  1. Using strings in switch statements
  2. Improved generic instance creation
  3. Binary integral literals and usage of underscores in numeric literals
  4. Enhancements in exception handling mechanisms:
    • Optimized rethrow
    • Multi-catch
    • Try-with-resources
  5. Simplified varargs method invocation

In this article, we drill down on all these enhancements and provide some code snippets.

Project Coin: Using Strings in Switch Statements

Switch statements are one of the primary constructs of any programming language. In all the earlier versions of Java, the valid data type for case could be one of int, short, char or byte constants. Earlier versions of Java also supported enum as one of the types for case. With the release of Java 7, the much needed string constant can be used as a value for case. The strings are matched with the appropriate cases using the equals method of the String class.

The following code snippet demonstrates the use of strings in a switch statement:

String role = "Programmer";Double bonus;switch (role) {case "Manager":         bonus = 10000.0;            break;     case "Architect":         bonus = 80000.0;            break;      case "Programmer":         bonus = 5000.0;          break;      default:           bonus = 0.0;          break;}

Project Coin: Improved Generic Instance Creation

Generics was one of the major concepts/new features introduced in Java 5 for achieving compile time safety. While creating an object of generic type, the language mandated both the reference type and actual type to define the generic syntax.

Until Java 7, generic instances were created like this:

Map myNewMap = new HashMap();

Java 7 allows the freedom to use only the generic syntax for the reference. In this revised version of the above code snippet, the myNewMap reference type is created without specifying the type information for the actual type.

Map myNewMap = new HashMap<>();

Project Coin: Binary Integral Literals, Underscores in Numeric Literals

In Java 7, a numeric constant can store a binary value. The binary value helps developers who are working on low-level APIs to deal with byte code to manipulate the numeric values. In this example, the binary equivalent value of 102 is stored for the int variable number.

int number = 0b1100110;

The other change being made to the numeric literal is the addition of underscores. Lengthy numeric values can be separated using underscores and they remain valid as long as the underscore is used between valid numerical values. The idea behind this addition is to make the numbers easier for users to read and interpret.

Here is an example:

long longNum = 27_04_86L;long ccnumber = 3434_5656_3903_3444L;

The ccnumber in the snippet above is more readable and it is represented as 3434565639033444L in the system.

Project Coin: Exception Handling Enhancements

Several enhancements have been made to the exception handling mechanism in Java 7, most notably:

  • Optimized rethrow
  • Multiple exceptions caught in the same catch block
  • Automatic resource management (try block with resources)

Optimized Re-throw

A developer may want to handle all the exceptions thrown by a try block in a similar fashion and hence chooses to define a single catch of the base type that is generally Throwable or Exception type. If the catch block throws an exception then the exception signature would have a Throwable type, as the actual exception type is not decided by the compiler. To overcome this, the developer can add a final keyword to the argument in the catch block. This basically means that the type of the thrown exception type is the type that the runtime actually got.

Consider the following example:

public class MyExceptionClass {public static void throwMe() throws FileNotFoundException, ArithmeticException {        try {                      throw new ArithmeticException("Error");      } catch (Exception exception) {           throw exception;         }       }public static void main(String[] args) {       try {               throwMe();     } catch (ArithmeticException exception) {                // Handler Code      } catch (FileNotFoundException exception) {               // Handler Code          }      }}

The above code would not compile because the throwMe method throws an Exception type, which is not defined in the throws clause of the method. One simple substitute would be to catch the appropriate exceptions in different catch blocks and rethrow the exception if required. However, if the developer wants to handle the exception in a single catch block, Java 7 provides a feature to handle this by using the following snippet in the throwMe method.

public static void throwMe() throws FileNotFoundException, ArithmeticException {try {       // throw new ArithmeticException("ArithmeticException");throw new FileNotFoundException("FileNotFoundException");     } catch (final Exception exception) {         throw exception;       }}

The exception type that is thrown by the throwMe method throws one of the actual exceptions that the catch block catches at run time. This is ensured by the final keyword, which is prefixed before the exception argument. The catch block can handle the exception and throw the appropriate exception back to the caller method in the call stack.

Multiple Exceptions Caught in the Same Catch Block

If a try block threw multiple exceptions in previous versions of Java, it was the developer’s responsibility to declare a catch block for each exception type. Java 7 provides a new feature: defining multiple exception types in the catch block definition. A single catch block can catch exceptions of multiple types. Here is an example:

try {   Class string = Class.forName("java.lang.String");   string.getMethod("equals");} catch (ClassNotFoundException | NumberFormatException | IOException ex) {      // Handler Code   }

In the above example, the try block can throw an exception of type ClassNotFoundException or NumberFormatException or IOException, and these exceptions can be caught in a single catch block.

An exception to this feature is that the multi-catch does not support the exception in a hierarchy; that is, one exception class in the list cannot be a subclass of another in the list. For instance, IOException and FileNotFoundException cannot be used in the catch block clause as FileNotFoundException is a subclass of IOException.

Automatic Resource Management

This new try block syntax helps with the automatic closing of resources. The resources that are declared while defining the try block will get automatically closed when the control comes out of the try block. In the earlier versions of Java, the finally block was used to close the resources.

try (BufferedReader reader = new BufferedReader(new FileReader(fileName))) {while ((line = reader.readLine()) != null) {          myFileContents.append(line);            myFileContents.append("
");       }       Integer empId = Integer.parseInt(employeeId);  } catch (IOException ex) {             }

In the above code snippet, the reader object will get automatically closed when the control comes out of the try block.

Project Coin: Simplified Varargs Method Invocation

Generics, while a major advancement for the Java platform, has a major limitation: generic arrays cannot be created. The below code snippet throws a compile time error.

List myList = new ArrayList<>[];

Consider a situation where a method accepts varargs arguments. The compiler gives a warning if the arguments passed to it are non-reifiable, and it can lose its type information after type-erasure. The compiler issues a warning “warning: [unchecked] unchecked generic array creation“. The programmer can also suppress this warning by using the @SafeVarArgs annotation on the method, which would ensure that the method wouldn’t perform any unsafe operation.

public class MyVarArgsDemoClass {public static void main(String[] args) {        compute(new HashMap(), new TreeMap());       }@SafeVarargs    static void compute(Map... args) {         //Some code       }}


Hopefully, it has become clear that even the smaller Java 7 enhancements, which are at the heart of Project Coin, make the Java language much simpler for developers.


The author would like to sincerely thank Mr. Subrahmanya (SV, VP, ECOM Research Group, E&R) for his ideas, guidance, support and constant encouragement, and Mr. Piram for kindly reviewing the article.


About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist