Java 6 now end of life: time to move to 7

Oracle Java 6, first released over 6 years ago, has now received its final public update. Update 41 addresses several security concerns, mostly regarding the web browser applets part of Java.
There will still be updates available for Java 6 if you pay Oracle for support, or if you are using a different JVM vendor, like IBM. In my experience, the majority of the Java user base relies on free public updates to keep Java current and secure. Paying for support also does not address all issues of staying on  an old version.

If you are still developing/maintaining software using Java 6, you are in trouble:

• You don’t get any more fixes, improvements or support. For instance, Java 7 is the only Java version that officially supports Windows 8. Your IT services group may have policies that prohibit running unsupported software.
• The public EOL for a Java version is traditionally a sign for (open source) frameworks and tools that it is OK to stop supporting it in next versions of their products. For instance, version 9 of the Jetty web application server, due in July, will only run on Java 7.
• If you are targeting desktops, be prepared that Java 6 may be automatically removed by Java 7 updates, and that client code will be more likely to run on Java 7.
• Developers may start to hate working on the system, because better solutions are available that they cannot use because of staying on an old version, and they like to stay current on their technical skills.

Migrating to Java 7 is not a trivial thing to do, but it very much possible. Most of the popular tools, middle ware and frameworks support Java 7 for a while now, the main factor that determines how difficult it will be to migrate is how much you were already behind. At my company, we already migrated several projects last year, in various teams and scenarios, with code bases that are up to 10 years old and a million lines in size. Tim Prijn and myself talked about our own experiences at last years JavaOne 2012 (slides and video here), and I did a BOF at Devoxx 2012 on the same topic.

The first thing you probably want to consider is to migrate your entire ALM stack to products that supports Java 7. This means developer IDE, build environment, test tools, profilers, code coverage, code analysis, etc. Virtually all tools available still support Java 6, so this is a safe first step to take. At our company, we took this step in December 2011 with our own Java ALM stack “Endeavour“, based on popular tools like Eclipse, Maven and Sonar.

The next step is considering what middleware and frameworks you need to upgrade or replace to start running on Java 7. In a larger codebase, you should be able to slice this up in smaller components that you can migrate one at a time.

Next it’s time to start testing. Java 7 has a small number of potentially breaking changes in its API. In our experience, the most common pitfalls are subtle changes in the reflection- and collections API. When methods are looked up using reflection, Java 7 will no longer guarantee that they are returned in order of declaration. This means JUnit tests will run in a different order for instance. The collections API is more strict now. That means programming errors that used to lead to subtle problems now throw explicit exceptions.

Finally, you should start migrate to new features in order to take advantage of new stuff in Java 7. A quick first step is using automated tools to migrate code to new language syntax. In our experience, IntelliJ IDEA (even the free version) has some great wizards for doing this quickly and safely.

If you like to brainstorm a bit about you situation, feel free to send me a message. With Java EE 7 around the corner and Java 8 shipping at the end of the year, it is time to start migrating!

Share this