BT

Eclipse and Java 6u21 problems

by Alex Blewitt on Jul 21, 2010 |

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.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Confirmed by Martijn Verburg

Hi all,

Just for the paranoid, I've confirmed that the follow the FAQ instructions work.

Cheers,
Martijn

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.

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.

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!

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT