Eclipse and Java 6u21 problems

Posted by Alex Blewitt on Jul 21, 2010

Sections

Process & Practices,

Development

Topics

Community ,

IDE ,

Java

Tags

Oracle ,

Eclipse ,

JDK ,

Java SE

Oracle recently released Java 6 update 21 which had a small but innocuous change in the way that the java.dll was created. Unfortunately, this change impacted Eclipse's startup, causing more problems for Eclipse than NetBeans ever had under Sun.

The change was to replace COMPANY_NAME=Sun Microsystems, Inc. to COMPANY_NAME=Oracle Corporation in the way that the dll was generated. Unfortunately, Eclipse uses the name on the DLL to know whether it's safe to append the non-standard -XX:MaxPermSize or not. Since some JVMs will fail to start when the flag is present but not supported, rather than putting the -XX:MaxPermSize in Eclipse's startup file (eclipse.ini), a new argument, --launcher.XXMaxPermSize 256m is permitted, and if the launcher executable on Windows detects that it is a Sun VM, it appends the -XX:MaxPermSize=256m automatically.

This auto-detection happens in the C launcher shim (eclipse.exe) rather than from the VM – because once the VM is running, you can't change the properties. In order to do this in a quick (and let's face it, dirty) way, the eclipse.exe launcher looks for the string Sun Microsystems to determine if the flag should be added.

Thus it was that the change broke Eclipse's launcher process; and causing OutOfMemoryError at launch. This was quickly reported to Eclipse, who then escalated to Oracle and was quickly fixed.

Even though this rebranding change was Oracle's right (and wouldn't even merit an entry in the release notes), it impacted Eclipse – not only the current 3.6 version, but also any IDEs or RCPs based on 3.5, 3.4 or 3.3. A co-ordinated sequence of fixes is needed in order to fix this (on the Eclipse side); there's a patch for the Eclipse launcher waiting to be applied to the latest, but it may be necessary to respin at least Eclipse 3.5 and maybe 3.4 as well in order to ensure compatibility.

Oracle are to be commended for their quick handling of the situation. Even though they didn't need to resolve the problem, they fixed it in a matter of days and subsequently the next Java build will have the fix in place. (Whether that's a rebuilt 6u21 or 6u22 remains to be seen.) In the meantime, if you're experiencing problems with Eclipse and have recently installed (or had automatically updated) Java 6u21, you can downgrade to Java 6u20 or follow the FAQ to re-enable the permgen size.

1. Back to top

   Confirmed

   by Martijn Verburg

   Hi all,
   
   Just for the paranoid, I've confirmed that the follow the FAQ instructions work.
   
   Cheers,
   Martijn

   Reply

2. Back to top

   Yet another Sun-to-Oracle rebranding issue

   by Vitaly Mikheev

   Much more apps will stop working when and if the value of the java.vm.vendor property turns to "Oracle Corporation"
   
   Here goes yet another example of this issue.

   Reply

3. Back to top

   That is way Feature Detection is preferred to Implementation Sniffing

   by Eduardo Pérez Ureta

   Eclipse should just run with the parameter and if it fails just run again without the parameter instead of sniffing the implementation company name.

   Reply

4. Back to top

   Oracle

   by Andrew Smith

   I really admire Oracle in their contribution of trying to handle the situation and effort to help fix Java problems. The quick response and actions on the matter was pretty impressive. Great job!

   Reply

• Older >