Moving to Java 7 as default

Update: The issue reported in JRE 7 related to JAR file association on certain Windows configurations has been fixed and updated binaries posted to

Back in February, I wrote a post on this blog stating that the End Of Life (EOL) of public support and public releases for JDK 6 was extended to November 2012, to allow for some more time for the transition to JDK 7. As part of the updated EOL policy, EOL for public support and fixes for Java SE will typically occur no earlier than six months after a subsequent major release has been established as the default JRE.

With the release of Java SE 7 Update 4, the Java SE 7 runtime is now available on as the default JRE. We can now slowly begin the process of automatically upgrading Microsoft Windows Java users to the latest version of Java SE 7 through the auto update function. If you don't desire to be automatically upgraded to Java SE 7 just yet, you can learn more about your options in the FAQ.

In terms of major new features, beside Mac OS X support, Java SE 7u4 includes the eagerly anticipated next-generation Garbage First (G1) garbage collection algorithm, as well as numerous performance enhancements to the JVM. It's very mature and stable, has been tested with large parts of our middleware and applications stacks and - as a result - is fully supported and recommended for use with Oracle Fusion Middleware.

This is another Java SE 7 update release that has been developed from beginning to end within the JDK 7 Updates Project in the OpenJDK community. As the vast majority of Oracle’s maintenance contributions in the OpenJDK community is for Java SE 7, users of the previous release, OpenJDK 6, should consider upgrading to OpenJDK 7, or - of course - to Oracle JDK 7, depending on their requirements. In line with no longer posting updates of Java SE 6 after November 2012 to Oracle’s public download sites, we don’t have plans to contribute further changes to the OpenJDK 6 Project after November 2012.


It helps if the JavaSE 7 updates are actually stable.

I tried to move to 7u4 on Windows, and then discovers that all my .jar file can no long run by double-click under Windows Explorer.

I guess accident happens, but you would think that somewhere in the QA process this will get tested...

Posted by alex on May 02, 2012 at 10:25 AM PDT #

Looking forward to trying G1 again: my main app used to be a torture test for it and I kept having to send dumps to Ramki et al, but they were very patient! Though given relatively small heap sizes for most of my instances (1GB at most) maybe I'll be sticking with CMS for now...



Posted by Damon Hart-Davis on May 02, 2012 at 01:30 PM PDT #

Noticed the latest JRockit release is at 1.6.0_31. Will Java7 be available on JRockit sometime soon. Thanks

Posted by bank kus on May 02, 2012 at 01:34 PM PDT #

Alex - looking into it. Damon - G1 has been verified through extensive stress & performance testing, as well as with various Fusion Middleware workloads. Target applications are primarily those with larger heaps (> 6 GB is our current recommendation) but it may be worth trying out regardless. I run Netbeans with it on my Mac laptop and it's a smooth experience. Bank kus - We have no plans to make JRockit available for JDK 7. JRockit and HotSpot are being merged to a single "best of breed" JVM. See previous entries on this blog for detail.

Posted by Henrik on May 02, 2012 at 02:16 PM PDT #

with JRE 7u4 can't execute the application.jar with double click

Posted by benferhat1 on May 03, 2012 at 12:24 AM PDT #

Alex and benferhat1 - Thanks for the reports. There is an installer issue that impacts certain Windows configurations, one symptom of which is the JAR file association being broken. We have switched back to JRE 6 while we investigate and fix/update. Expect to be back with an update shortly.

Posted by Henrik on May 03, 2012 at 07:27 AM PDT #

G1 has been a huge dissapointment for me. For many applications, it works fine but not any better than CMS did. For my larger heap application that is performance critical, the performance is atrocious. Throughput is HALF of CMS (% time in GC jumps from 1% to 50%!). Now, CMS still gets fragmented and every so often has one large painful GC, but G1GC still is a huge problem for me. If 10% of the effort put in G1GC was put in optimizing CMS, CMS might be a whole lot better.

It may be caused by this applications heavy use of WeakReferences, or some other less used characteristic of this mutator, but my conclusion so far is that a young generation that works like CMS combined with a G1-esquel old generation might work much better. Another conclusion is that the CMS's young gen collector is better than the throughput collector's, since you can control the tenuring thresholds much better.

Posted by Scott C. on May 03, 2012 at 06:02 PM PDT #


I got hold of one of the OpenJDK 7 builds for my Mac thanks to previous advice, and I note that it still has trouble with my workload using G1GC (throws OOMEs) and I've had to revert to CMS for now. And indeed on uniprocessor hosts I suspect that I'll need to stick with -Xincgc too.

Like Scott, though I've cut down on Soft/Weak references I still have typically >>100,000 live at any time, and they were a continual source of bugs in CMS in the old days (eg missing barriers around ref handling).

It might be worth ensuring that G1GC tests include some with very heavy use of refs: I'm offering again to donate a chunk of (already public) code to do so if that helps.



Posted by Damon Hart-Davis on May 07, 2012 at 01:06 AM PDT #


As Henrik mentioned, we have done significant testing on G1 over the last couple of years. However, some CMS-tuned application workload may not perform as well out of the box on G1. I suggest you explore the tuning options provided by G1. Also, the OpenJDK GC mailing list is a good place to discuss your experience and get feedback.



Posted by guest on May 07, 2012 at 02:45 PM PDT #


Thanks for your feedback. We will certainly be interested to get help from the community to increase the workload test coverage on G1. Feel free to start a thread on the OpenJDK GC mailing list ( to discuss this.



Posted by guest on May 07, 2012 at 02:51 PM PDT #

Alex and benferhat1 - Jar file association issue has been identified and fixed and new binaries posted ton Thanks for the feedback!

Posted by Henrik on May 07, 2012 at 03:30 PM PDT #

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.


« February 2017