Project Coin: language enhancements in Java 7

The goal of Project Coin is to determine what set of small language changes should be added to Java 7. You probably know about it, if not learn it- "http://openjdk.java.net/projects/coin/coin_proposal_form_v1.0.html"

So here today I’m going to share about a collection of small yet effective new features implemented in project coin. The features are –

1. Strings in switch
2. Binary integral literals and underscores in numeric literals
3. Multi-catch and more precise rethrow
4. Improved type inference for generic instance creation (diamond)
5. try-with-resources statement
6. Simplified varargs method invocation

String in switch:

Java’s switch statement allows you to write an efficient multiple-branch statement without lots and lots of ugly nested ifs, like this:

Code:

public void printDay(int day) {
      switch (day) {
      case 1:
         System.out.println("Sunday");
         break;
      case 2:
         System.out.println("Monday");
         break;
      // more cases will be here
      default:
         System.out.println("Error");
         break;
      }
   }

In java 6 and earlier version of Java, the values for the cases can be only byte, char, short, or int or their reference-type equivalents Byte, Character, Short and Integer and enum. But in Java 7 the spec has been extended to allow for Strings to be used as well. Example-

Code:

public void printDay(String day) {
      switch (day) {
      case "Sunday":
         System.out.println("শনিবার");
         break;
      case "Monday":
         System.out.println("রবিবার");
         break;
      // more cases will be here
      default:
         System.out.println("Error");
         break;
      }
   }

Binary Literals:

Before Java 7, if you’d wanted to manipulate a binary value, you would do like-

Code:

int x = Integer.parseInt("1100110", 2);

This is a lot of typing just to ensure that x ends up with that bit pattern (which is 102 in decimal, by the way). There’s worse to come though. It:
• Is really verbose.
• Has a performance hit for that method call.
• Means you’d have to know about the two-argument form of parseInt().
• Requires you to remember the detail of how parseInt() behaves when it has two args.
• Makes life hard for the JIT compiler.
• Is representing a compile-time constant as a runtime expres​sion(so it can’t be used as a value in a switch statement).
• Will give you a runtime exception (but no compile-time exception) if you get a typo in the binary value.

Fortunately, with the advent of Java 7, we can now write:

Code:

int x = ob1100110;

Now we’ll not face the above problems.

Underscores in numbers:
We all know that human mind is quite different from computer’s CPU. Human are not comfortable to handle quite long string of number. That’s why we invented hexadecimal number. That is we find easier ABC420 instead of 101010111100010000100000. So there is a way to deal with long strings of numbers is to break them up. Like our phone number, we break it like-

088-01671-865012

Other long strings of numbers have separators too:

$100,000,000 (Large sums of money)

08-92-96 (UK banking sort codes)

Unfortunately, both ‘,’ and ‘–‘ have too many possible meanings within the realm of handling numbers while programming, so we can’t use either of those as a separator. So here project coin borrow idea from an idea from Ruby and introduced the underscore ‘_’ as a separator. So, you can write 100_000_000. Example –

Code:

long cellNo = 088_01671_865012L;

Note that this is just a bit of easy-on-the-eyes compile time syntax – the compiler just strips out those underscores and stores the usual digits.

Here is some other example:

int x1 = _52; // This is an identifier, not a numeric literal.
int x2 = 5_2; // OK. (Decimal literal)
int x2 = 52_; // Illegal. (Underscores must always be between digits)
int x3 = 5___2; // OK. (Decimal literal.)
int x4 = 0_x52; // Illegal. Can't put underscores in the "0x" radix prefix.
int x5 = 0x_52; // Illegal. (Underscores must always be between digits)
int x6 = 0x5_2; // OK. (Hexadecimal literal)
int x6 = 0x52_; // Illegal. (Underscores must always be between digits)
int x6 = 0x_; // Illegal. (Not valid with the underscore removed)
int x7 = 0_52; // OK. (Octal literal)
int x7 = 05_2; // OK. (Octal literal)
int x8 = 052_; // Illegal. (Underscores must always be between digits)

These examples above is borrowed from: http://stackoverflow.com/questions/6212558/java-7-underscore-in-numeric-literals

Improved exception handling:

There are two parts to this improvement – multi-catch and, effectively, final rethrow.

• Multicatch : You’ll now be able to catch multi exceptions type in one catch block
• Final Rethow : Allows you to catch an exception type and it’s subtype and rethrow it without having to add a throws clause to the method signature.

Let see how we handle exception-

Code:


try {
         //do some code here
         //bla bla bla
      } catch (FileNotFoundException e) {
         // Log or printStackTrace
         throw e;
      } catch (ParseException e) {
         // Log or printStackTrace
         throw e;
      } catch (ConfigurationException e) {
         // Log or printStackTrace
         throw e;
      } catch (IOException iox) {
         // Log or printStackTrace
         throw e;
      }


This code is fine, but really heavy for nothing interesting. In in Java 7, there is an interesting solution.

Code:


      try {
         //do some code here
         //bla bla bla
} catch (FileNotFoundException | ParseException | ConfigurationException  | IOException e) {
         // Log or printStackTrace
         //or do whatever you want
         throw e;
      }


It is something interesting a bit.

And the second improvement is a little more complicated. Imagine that you want to catch all exceptions, make several operations and then rethrow it. The code isn’t hard to make, but the big problem is that you must add a throws clause to your method signature to manage the new exception launched by your code and this is not the objective. Now, you can do that without adding an exception throws clause:

Code:

 
try {
         //do some code here
         //bla bla bla
      } catch (final Throwable ex) {
          // some more code         
         throw ex;
      }


Using the final keyword it allows you to throw an exception of the exact dynamic type that will be throwed. So if an IOException occurs, an IOException will be throwed.

Diamond syntax:

We probably very much familiar with this type of code:

Code:

Map<String,Map<String, String>> userList = new HashMap<String,Map<String,String>>();

That’s quite a mouthful, and almost half of it is just duplicated characters. Wouldn’t it be better if we could just write something like the code below, and have the compiler just infer the type information on the right hand side?

Code:

Map<String, Map<String, String>> userList = new HashMap<>();

And this is the magic of project coin. In java 7, the shortened form for declarations like that is entirely legal.

Try-with-resources:

For example we want to read from a URL-based stream URL and write and write to a file.

Code:


      InputStream is = null;
      try {
         File file = new File("output.txt");
         URL url = new URL("http://blog.codexplo.org/2011/08/10/functional-language-rule-future-programming-world/");
         is = url.openStream();
         OutputStream out = new FileOutputStream(file);
         try {
            byte[] buf = new byte[4096];
            int n;
            while ((n = is.read(buf)) >= 0)
               out.write(buf, 0, n);
         } catch (IOException iox) {
            // Handles exception (could be read or write)
         } finally {
            try {
               out.close();
            } catch (IOException closeOutx) {
               // Can’t do much with exception
            }
         }
      } catch (FileNotFoundException fnfx) {
         // Handles exception
      } catch (IOException openx) {
         // Handles exception
      } finally {
         try {
            if (is != null)
               is.close();
         } catch (IOException closeInx) {
            // Can’t do much with exception
         }
      }


The key point here is that, when handling external resources, Murphy’s Law applies – anything can go wrong at any time:
1. The InputStream can fail:
a. To open from the URL.
b. To read from it.
c. To close properly.
2. The file corresponding to the 2 OutputStream can fail:
a. To open.
b. To write to it.
c. To close properly.
3. Or have some combination of more than one of the 3 above.

This last possibility is actually where a lot of the headaches come from – the possibility of some combination of exceptions is very difficult to deal with well.
Let see how we could write it in Java 7,

Code:

try ( OutputStream fos = new FileOutputStream(file);
        
         InputStream is = url.openStream() ) {
           byte[] buf = new byte[4096];
            int len;
            while ((len = is.read(buf)) > 0) {
            fos.write(buf, 0, len);
        }
      } catch (IOException | FileNotFoundException e) {
      // If file is not fo
       }


Much cleaner, right! With that code, the resources are automatically closed after the try. You need not do it manually.

Simplified varargs method invocation:

This is one of the simplest changes of all – it just moves a warning about type information for quite a specific case where varargs (variable arity) combines with generics in a method signature.
When a programmer tries to invoke a *varargs* (variable arity) method with a non-verifiable varargs type, the compiler currently generates an “unsafe operation” warning. JDK 7 moves the warning from the call site to the method declaration. This will enable API designers to use varargs due to the reduction of warnings reported
Read more about it from here: http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000217.html

References:

1. http://www.baptiste-wicht.com/2010/05/better-exception-handling-in-java-7-multicatch-and-final-rethrow/
2. http://thecoderlounge.blogspot.com/2011/07/java-7-support-in-eclipse-jdt-beta-part_14.html
3. http://blogs.oracle.com/darcy/entry/project_coin_literal_grammar_hackery
4. http://code.joejag.com/2009/new-language-features-in-java-7/
5. http://blogs.oracle.com/darcy/entry/project_coin_multi_catch_rethrow
6. JavaTech Journal, Issue June 2011
7. http://mail.openjdk.java.net/pipermail/coin-dev/2009-March/000217.html
8. http://openjdk.java.net/projects/coin/

Note that most of the content is here copy paste version and from the JavaTech Journal, Issue June 2011. I just tuned up a bit.

I know one more and I liked it. JComboBox is now generic. That means:

Code:

JComboBox<String> jcb = new JComboBox<>();

yup Mohaimin, That is probably under the Diamond Syntax. I just showed one example. Anyway thanks.

BIT0112-Rokon wrote:yup Mohaimin, That is probably under the Diamond Syntax. I just showed one example. Anyway thanks.

Yes it falls under Diamond Operator. But thats not the point. Swing's JComboBox was not generic before. It used to deal with Object types in earlier versions of Java.

I understand that this is not a Language enhancement. This is just an API update.