Migrating from Java SE 6 to Java SE 7

Why should I migrate from SE 6 to SE 7?

The most obvious reason is that you will get access to all the new features and improvements that we have made to Java with the introduction of Java 7.

A few of these changes might require some updates to your code, but they are changes that are well worth it from a performance, quality and readability perspective. You can find more information here: http://docs.oracle.com/javase/7/docs/webnotes/adoptionGuide/index.html

Another important reason is the End of Public updates milestone for Oracle JDK 6. After February 2013, future JDK 6 updates will no longer be publicly available and old JDK 6 releases will me moved to the Java Archive. Running on an old version of Java is a bad idea, so now is the time to move to 7. For more information on the End of Public Updates milestone, see Java SE End of Life Policy

If you are unable to migrate some of your applications and need continued access to Oracle JDK 6 updates, Oracle offers long-term support through the Java SE Support program.

What do I need to do?

Option 1 – “Just run”

Java has binary backward compatibility. This means that if you have a program that has been compiled for and is running with Java SE 6, it will also run on a Java SE 7 JVM. Java SE 7 is strongly compatible with previous versions of the Java platform. Almost all existing programs should run on Java SE 7 without modification. However, there are some minor potential incompatibilities in the JRE and JDK that involve rare circumstances and "corner cases" that are documented here for completeness: http://www.oracle.com/technetwork/java/javase/compatibility-417013.html#incompatibilities.

Option 2 – Re-compiling and modifying source code.

Most of the new features introduced with Java SE 7 are improvements on a Java code level. To benefit from these you will have to update your old source code, or use the new features in any new code you write, and recompile your code for Java SE 7.

The Netbeans IDE can help you find locations in the code where you can use some of the new features, see this link for details. Other major IDEs have similar features.

Some APIs have been marked as deprecated, which means we encourage you to use the replacement APIs instead. The deprecated APIs can be found here.

Also, some of the APIs in the sun.* packages have changed. These APIs are, and have always been, intended for internal use only and any use is “at your own risk”. It is strongly recommended to find alternatives to using these packages as soon as possible.


That's fine for server-side applications but for GUI apps it's more problematic. On OS/X. Java 7 doesn't support retina displays and still has enough graphical defects that vendors like JetBrains won't support it. Which means Java 6 is the only option for GUI Java apps on OS/X and leaves those users waiting on Java 8 which supposedly will support retina.

Posted by guest on February 19, 2013 at 07:41 PM PST #

Hi guest - JetBrains provides Java SE 7 support as of their 10.5 release (http://www.jetbrains.com/idea/whatsnew/whatsnew_105.html). Support for the Retina display is in the works both for Swing/AWT and JavaFX. If you want to help accelerate this work (or encourage JetBrains to help out) you can help out in OpenJDK or OpenJFX. Until then, you can continue to have Apple JDK 6 and Oracle JDK 7 installed side-by-side on your Mac, though it is recommended that you use JDK 7 for the browser plugin (if you need to have it enabled).

Posted by Henrik on February 19, 2013 at 08:49 PM PST #

The main question is not "Why should I migrate from SE 6 to SE 7?". That's perfectly clear. The main question is "How can I migrate from SE 6 to SE 7?". In particular, how can I have SE 7 on 32-bit Mac computers. They are still widely used in the wild and cannot be upgraded to a newer Mac OS version, because those newer versions of Mac OS come only in 64-bits.

Posted by Roman Elizarov on February 19, 2013 at 11:45 PM PST #

Roman - A bit of history. Apple provided Java for PPC and 32-bit Intel Macs. Their implementation was tightly integrated in the OS, relying on internal and undocumented APIs. Oracle and Applet then agreed to work together on Java for Mac in OpenJDK, and for Oracle to provide Oracle JDK 7 for Mac based on that cooperation. As part of this effort, Apple added public APIs to OS X needed to get Oracle JDK 7 and OpenJDK to run. These APIs are only available in newer releases of Mac OS X, so we are unable to properly support older versions. Furthermore, given the minimum OS version we really only support 64-bit Intel Macs and therefore only provide a 64-bit JDK. It is possible to get OpenJDK run on older Mac OS X versions and PPC/32-bit Intel Macs but it will have glitches due to missing APIs in the OS and not provide a great user experience. And of course, every platform we add comes at a cost and we don't have unlimited resources so that would be an issue even if there were no technical blockers.

I realize this is not any help to you, but there isn't much we can do about it.

Posted by Henrik on February 20, 2013 at 02:08 PM PST #


One performance regression that will stop me from migrating to Java SE 7 is the shortsighted "fix" to the hashmap that forces synchronization across threads:


A seemingly innocuous upgrade to 7 would result in a drastic drop in response time and throughput for most multithreaded web applications that employ a large number of threads and have throw-away hashmaps created on the fly. (And contrary to what the author believes, there are real world web apps out there that need to work that way.) Worst, there isn't even a workaround to this issue.

Posted by Bharath on February 21, 2013 at 11:23 PM PST #


I understand your position.

I'm a keen long-time Java user. I'm not going to throw away my perfectly good Intel MacBook dev machine (or maybe just go through all the OS upgrade hassle) for this, so I'm forced to work on a mess of Apple JDK 6, a random community JDK 7 that took a fair amount of pain to install, and foreswear JDK 8 entirely for now, much as I'm otherwise a serious Java fanboi (there, I said it, I'm out of the closet).

Maybe if Oracle could spare some cycles to point to, ON THE SAME PAGE AS the officially-supported binaries, slightly vetted decent community versions of the JDKs for other/older/rarer OSes. Put up all the DON'T SUE US disclaimers you like.

Maybe that page already exists and I've missed it.

Bizarrely, it's easier for me to run JDK 7 on my SheevaPlug (ARM v5!) than on my MacBook. And don't make me use my Windows laptop! %^>



Posted by guest on February 22, 2013 at 03:12 AM PST #

Bharat - This has been reported as a bug and is currently targeted for our next limited update, see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006593. Note that the 7u14 target is incorrect since that release number was skipped due to two consecutive Critical Patch Updates (security releases). It shouldn't be more than a few months out. In the meantime, you can get a patch from Oracle if you have a support contract or you can patch it yourself if you use OpenJDK.

Damon - Thanks for the response. I like the idea of a repository of "known good" community-supplied ports. Have sent out a few feelers to see if anyone would be interested in stepping up to do this work. If you read this and want to volunteer your time, let me know. In order for us to recommend it, it has to be actively maintained.

Posted by Henrik on February 24, 2013 at 06:17 PM PST #

Hi Henrik,

Seems the Java 7 is under active development and it is update 15 now. Do you have a way to find out the list of bugs fixed by an update like update 15?


Posted by guest on February 25, 2013 at 01:03 PM PST #

Hi Bo - Check the release notes. For JDK 7 Updates, they can be found here: http://www.oracle.com/technetwork/java/javase/7u-relnotes-515228.html.

Posted by Henrik on February 25, 2013 at 01:20 PM PST #

Thanks for the reply, Henrik.

For the example of update 13 and update 15, the only bug fixes listed are security vulnerabilities. Is there a full list of bug fixes somewhere that we can check? Or the release note actually is the list.


Posted by Bo on February 25, 2013 at 01:34 PM PST #

Bo - 7u13 and 7u15 were security updates and did not include issues to non-security issues. The release notes are complete.

Damon - It turns out we have looked into the idea of community ports before, and it never took off. The biggest issue is that maintaining a port is a lot of work, and is unlikely to succeed unless there is a big backer behind it. Furthermore, we cannot host (and probably not officially link to or recommend) binaries that we have no control over due to liability concerns: What if there is a trojan embedded, for example? To be clear; we would have no issues with an initiative in this direction, we just don't think it's very likely that it will happen.

Posted by Henrik on February 25, 2013 at 03:28 PM PST #

Post a Comment:
Comments are closed for this entry.

Henrik Stahl is VP of Product Management in the Java Platform Group at Oracle, and is responsible for product strategy for Java ME and SE.


« July 2016