The 8 Nights of Java – Night 7

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.

The 8 Nights of Java – Night 5

Java 5.0 was the biggest change to the language syntax since it came out. The designers of Java managed to complete this impressive feat without removing any existing syntax and by keeping everything backward compatible. They accomplished this by leveraging compile-time enhancements. A compile-time enhancement is a language rule that a developer can use to write and build software with, but that gets stripped out of the compiled file. For example, Generic notations like List<String> are actually removed from a class when it is compiled, resulting in just a List of Objects. This technique allowed the authors of Java to thrust it into the future, with minimal impact on existing implementations.

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

Java 5.0 Notable Features
Sun release Java 5.0 (codename Tiger) on September 30, 2004.  Notice we went from 1.4 to 5.0? That’s right. Java finally dropped the “1.X” from the name with Java 5.0! Sun realized that they were far out of beta testing of Java (with millions of businesses around the world using their software) and rather than go from 1.4 to 2.0, they decided to just drop the 1. prefix. Key new functionality included:

  • Generics
  • For each loop
  • Autoboxing and unboxing
  • Varargs
  • Enums
  • Static imports

From Scott:

In my opinion, Java 5.0 helped saved Java as a modern development platform. Other languages with more advanced features were coming out, many that were far easier to write with. As I said on Night 2, Collections were powerful, but not particularly easy to use. Dynamic Lists with primitives were such a pain… I mean take a look at this before and after code:

Before Java 5.0:

List data = new ArrayList();
data.add(new Integer(1));
data.add(new Integer(2));
data.add(new Integer(3));
Integer sum = new Integer(0);
for(int i=0; i<data.size(); i++) {
	sum = new Integer(sum.intValue() 
			+ ((Integer)data.get(i)).intValue());
}
System.out.println(sum);

With Java 5.0:

List<Integer> data = new ArrayList<Integer>();
data.add(1);
data.add(2);
data.add(3);
Integer sum = 0;
for(int value: data) {
	sum += value;
}
System.out.println(sum);

It might not seem like a lot, but when you have to write thousands of lines of code that use Collections and other generics, it makes a big difference! The syntax got even shorter in Java 7 with the Diamond (<>) operator!

At the time of it’s release, these changes were quite controversial. Some felt they shouldn’t be stripped out during compilation and should be made part of the JRE. After all, the two code samples above compile to nearly the same thing (except possibly with an iterator), but Java has always been big about backwards compatibility. I think part of what helped to settle the issue is that the drastic improvement and availability of multi-core processors, which made any theorized performance hit negligible compared to the huge benefit of writing simpler, more maintainable, and easier-to-read code. Being the “old man” that I am, I still sometimes call intValue() on an Integer. If you were writing in Java before 5.0, the variable can feel naked without it!

From Jeanne:

I still have my copy of “Java 1.5 Tiger: A Developer’s Notebook” and the stuffed tiger Sun gave out is on my desk at work. This was a great change to the language. Generics made the code so much cleaner and safer. Autoboxing made the code cleaner as well. Enums are awesome too. While I use static imports a lot, I have mixed feelings about them. It’s a bit like the debate on whether to use a wildcard in regular imports. Are static imports clearer than typing the class name in each place. Well, like many things in programming, it depends.

I was looking forward to varargs so much that I designed a class to use them before they were written. I remember writing a class in Java 1.4 with methods taking 1, 2, 3, 4, 5 and 6 String parameters (along with an array version) and a comment to refactor it in Java 5.0 to use varargs. I also remember the feeling when I could get rid of all that crud when we upgraded!

Looking back, I have trouble deciding which is my favorite new feature. I’m torn between generics and autoboxing. Generics makes the code safer, but autoboxing makes the code easier to read. Decisions. Decisions.

The 8 Nights of Java – Night 3

Continuing The 8 Nights of Java series, tonight we focus on one of the most monumental, enormous, earth-shattering… no wait, we’re talking about Java 1.3 aren’t we? Java 1.3 has a number of important implementation and JRE changes but from a developer standpoint, very few new features. In retrospect, Java 1.3 was important as helping to make Java more stable and set up some of the hooks that later versions of Java would tie into, but in and of itself, was kind of a minor release.

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

Java 1.3 Notable Features
Sun brought in the new millennium with Java 1.3 (codename Kestrel), released on May 8, 2000. Key new functionality included:

  • JNDI
  • Hotspot JVM

From Scott:

I’ll be honest, there’s not much in Java 1.3 that find particularly interesting. Yes, JNDI is important but it’s not very exciting and wasn’t really relevant until J2EE servers started becoming commonplace years later. The Hotspot JVM was also important for production and deployment, but did not change how developers wrote code since the change was on the JRE side of things. In other words, Java 1.3 was a bit of a bore. Luckily the next few “nights” of Java more than make up for it!

My personal experience with Java 1.3 wasn’t completely uneventful, though. I took my first database applications course, CS433, back in college around this time. Our task was to design a database-driven web-based system. Because my school had been extremely heavy on theory, it was the first time we could really ‘cut loose’ and build something fun that people could use. We chose to build an toy auction website powered by Java 1.3, JSPs served by Tomcat, and an IBM DB2 SQL database. My two other teammates and I had so much fun in the course! For extra credit, we decided to integrate our search functionality into eBay, parsing their results and transforming them with XSLT so that our results and their results appeared side-by-side. It was a wonderful time and in hindsight, probably set the foundation for the rest of my Java career!

From Jeanne:

I was still in college when this was released. In fact, I had just started learning Java in 1999.. In summer 2001, I had my first paid job (internship) that used Java. (It was my second internship, but the first used C++.) My main task was using XSLT to generate webpages. I got a fast appreciation for JSPs from that job. Using XSLT added another level of abstraction and another way of thinking while trying to make web pages.

While there wasn’t anything new I cared about at the time, that was because I didn’t know enough. I’m thankful for it though. JNDI is really useful when writing code that runs on a server. I can’t imagine not being able to register a DataSource or JMS queue through JNDI. I imagine some other standard would have arisen to fill the gap if JNDI wasn’t invented.