The 8 Nights of Java – Night 6

Continuing on our 8 Nights of Java series, we move on to Java 6. Java 6 was about making Java “more”. As a result, a lot of the changes were important, but didn’t affect a developers day-to-day tasks. For example, annotations affected tool and library developers but were mostly unused for regular developers. Java 6 was initially released by Sun Microsystems, and later taken over by Oracle as part of the acquisition. This was also the last version of Java in which the Professional certification (SCJP renamed to OCP) could be completed with a single exam. Starting with Java 7 and continuing in Java 8, two exams are required to obtain an OCP certification.

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

Java 6 Notable Features
Sun released Java 6 (codename Mustang) on December 11, 2006. Notice they dropped “.0” from the version number, going from Java 5.0 to 6? This would be the last version of Java released by Sun, with Oracle taking over the Java 6 updates in 2010. Of all the versions of Java, version 6 was out there the longest, with 5 years (and 131 updates) before the release of Java 7.  Key new functionality included:

  • Renaming J2SE to Java SE
  • Common annotations support
  • JavaScript Rhino support
  • Performance improvements
  • JDBC 4.0

From Jeanne:

I have no memories of Java 6. I remember using it. While it was nice to finally ditch the “2” from the name of J2SE, I can’t think of a single thing that was new in it that I cared about. That said, the commons annotations support was a big deal. It let libraries like JUnit and Spring use custom annotations to be more expressive and easy to use. I do appreciate the feature and know it came from language updates. But since I used it when the libraries came out rather than when Java 6 came out, I don’t intuitively think of it as a Java 6 feature.

This does seem like a good place to reflect on the change in stewardship. We’ve been hearing about Oracle’s takeover spelling the death of Java since at least 2009. That’s right. The worries started even before Oracle acquired Sun. The rumors are still with us and stronger. They’ve moved more to the Java EE space more than in the core Java space. Oracle did rename the certifications from things like SCEA (Sun Certified Enterprise Architect) to OCEA (Oracle Certified Enterprise Architect). No surprise there. They also controversially added a requirement to take a class to a few certs to be more consistent with the database cert. Luckily, this requirement does not exist for the certifications Scott and I have written books about!

From Scott:

I have to agree with Jeanne on this. While Java 6 was a maturing release, with lots of new methods and features built on top of existing APIs, it paled in comparison to the Java 5.0 release in terms of scope. In other words, there wasn’t a compelling reason to go out and install Java 6 on all of your servers and desktops. As Jeanne started, the biggest change was really about Oracle’s acquisition of Java and handover of the platform and staff (remember Sun employees overnight became Oracle employees!). Java 7 was delayed almost 5 years because of this transition. As I said on Night 1, people have been predicting the death of Java since the first year it existed and the acquisition by Oracle was no different. While Oracle did make changes to Java, especially to the certifications, it’s fair to say they kept most things intact, helping Java to continue to thrive today.

One other important note. Java 6 had the most number of updates and patches, in part because so many “zero day” bugs were discovered. I’m not sure this was a deficit in Java, so much as this was Java spreading as a server platform across the web. Any server technology must be constantly kept up-to-date, as exploits are discovered all the time in the wild. As of April 2015, Oracle no longer publicly supports Java 6. Any servers running Java 6 must be updated and any that are not are prime targets for hackers.

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());

With Java 5.0:

List<Integer> data = new ArrayList<Integer>();
Integer sum = 0;
for(int value: data) {
	sum += value;

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 4

Continuing The 8 Nights of Java series, tonight we focus on one of the single most important releases of Java. Java 1.4 was released a time when many businesses were starting to look to Java as a foundation for their software systems. After years of licensing proprietary or difficult to use software, Java was seen as a breadth of fresh air for many software engineers. It was helped, in part, by the decline of Windows-based computers and explosive growth of Mac and open-source Linux systems in the workplace and in homes. After all, if all of your developers are using different operating systems, then you need a software development platform that works on all of them and in that, Java was a success. So many business adopted Java 1.4 during this time and stayed on Java 1.4 for over a decade. In fact, many large enterprise systems still rely on Java 1.4 to this day. Hopefully, someone will be hired to update them soon!

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

Java 1.4 Notable Features
Sun released Java 1.4 (codename Merlin) on February 6th, 2002. Key new functionality included:

  • Regular expressions
  • Assertions
  • NIO Version 1
  • XML/XSLT support

From Jeanne:

I love regular expressions. They are one of my favorite language features because they are concise and expressive when written well. I was excited when they came out. While I started programming as a full time job after Java 1.4 was released, we were still using 1.3 as we waited for the application servers to support Java 1.4. This meant I was already employed and got to teach my teammates about regular expressions. I’ve actually given that presentation a number of times since.

I don’t use assertions because I write a lot of unit tests and the unit tests tell me about the type of problem that an assertion would. Tests help me design my code in a way that I don’t need assertions to tell me about the state of affairs. And then there is poor New I/O. I really like Java 7 NIO.2. New I/O “1”, not so much. It served it’s purpose in getting us to NIO.2 though.

From Scott:

I started programming professionally around the time that XML/XSLT were seen as the “new hot technology” to use on build enterprise systems. Having built-in support for XML transformations made Java look cutting edge at the time. While a lot of what is now done with XML is instead done by JSON, XML is still the core of many data-based systems. In fact, numerous web and mobile frond-end languages still use XML for their layouts, even if the developers using them rely solely on a GUI-based editor. Either way, Java 1.4 demonstrated that new technologies could be integrated into the JVM quite rapidly. That said, I’m still waiting for a JSON parser to become part of the standard Java runtime environment!

Java 1.4 also introduced NIO version 1, or NIO.1 for short. While NIO.2 is a quite powerful, if not commonly used framework, NIO.1 is basically dead weight at this point. The NIO.1 API never really caught on and today, very few people rely on file channels and the like. Since a key part of Java is keeping backwards compatibility, it remains part of the JRE, albeit rarely used.