The 8 Nights of Java – Night 7

Main menu:

Topics

Recent Posts

Feeds

RSS Feed RSS - Posts

December 2016
M T W T F S S
« Nov   Jan »
 1234
567891011
12131415161718
19202122232425
262728293031  

Past Posts

Java/Java EE

JDBC

Other

The 8 Nights of Java – Night 7

December 30th, 2016 by Scott Selikoff

Our 8 Nights of Java series is nearly at an end! Tonight we look at Java 7, the first version of Java released entirely by Oracle. Java 7 included many goodies for developers, in the form of Project Coin. In a lot of ways, Project Coin was straight off of most developers Top 10 Wish List. Like Java 5, many of the futures were compile-time enhancements and helped to simplify numerous lines of code down to just one, allowing developers to focus on the important logic in their classes rather than syntax.

Jump to: [Night 1 | Night 2 | Night 3 | Night 4 | Night 5 | Night 6 | Night 7 | Night 8]

Java 7 Notable Features
Oracle released Java 7 (codename Dolphin) on July 7, 2011. After 5 years of Java 6 (including 131 updates) and the acquisition of Sun by Oracle, it was finally time to add some new features to Java. Key new functionality included:

  • Project Coin:
    • Strings in switch statements
    • Underscores (_) in numbers
    • Diamond (<>) operator
    • try-with-resources statement
    • Multi-catch blocks
    • Binary literals
  • NIO.2
  • Expanded Concurrency API

From Scott:

I love Java 7. While Java 5 “fixed” Collections by adding generics/autoboxing/foreach loops, Java 7 greatly improved the language by adding things that I didn’t even realize I was missing. The greatest of those (for a database-driven developer such as myself) was the try-with-resources statement. We’ve spoken in the past about finally closing JDBC resources, and to be honest, even we forget to do them sometimes. Could you blame us? The syntax was horrible. Especially because close() throws a checked exception which often must be caught inside another catch block! The try-with-resources statement fixed this not only by designing a syntax that was simple and easy to use, but finally providing a “standard” for all developers to work off of. After Java 7 was released, if I came across another developer opening/closing a connection without a try-with-resources statement, I could instruct them to replace it with one that does, thereby ensuring any possible resource leak is closed.

Project Coin had many other, very useful features. Strings in switch statements had been requested by numerous developers, especially beginners learning Java, for the better part of a decade. The diamond operator, while seemingly simply, greatly reduces assignments involving embedded Collections… such as “new HashMap<String,List<Integer>>” to just “new HashMap<>”. It was a pain to write out the full generic expression on both sides of an assignment! I don’t tend to use binary literatals or underscores in numbers, but I’m thrilled they were added to Java 7 since it makes reading other developers code a lot easier.

So many awesome features for developers in Java, I haven’t even gotten to the improved Concurrency API and new NIO.2. Both are extremely powerful, fully developed libraries that you can use to developer complex applications in minutes. And both got even better in Java 8 with the inclusion of… oops! Guess we’ll have to wait till tomorrow night to finish that sentence!

From Jeanne:

When I was young, the local college built a science building and named it the “New Science Building.” It’s still called that.The problem is what you call the one after that. NIO.2 had the same problem. “New I/O” didn’t take so well and now the name is taken. Luckily NIO.2 is nice! I use it a lot in my coding because I do a lot of file system work. I find myself using Apache Commons for I/O operations very rarely now.

Then there is Project Coin. While some is just semantic sugar like the diamond operator, it still makes the code cleaner and less redundant. The try with resources is great for not having to deal with boilerplate code! I also appreciate multi-catch. Before it existed, I’d often revert to “throws Exception” rather than independently catch two or three exceptions and handle them the same way. This happened a lot with a framework we used that declared two checked exceptions. It also happened a lot with XML parsing and reflection. With multi-catch, I’m more inclined to do the right thing and handle them all in one line.

Write a comment