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.
/filters:no_upscale()/sponsorship/topic/25afca57-6bcb-4c42-9a70-fbea10ce4fc7/MicrosoftLogoRSB-1678874949003.png)
/articles/open-source-java-profilers/en/smallimage/unleash-power-of-open-source-java-profilers-small-1681206807197.jpg)
/articles/rapid-startup-of-your-cloud-native-java/en/smallimage/logo-1680293937095.jpg){kind=logo}
/presentations/java-compiler-intermediate-representation/en/smallimage/chris_seaton-s-1679038354209.jpg)
/presentations/jfr-observability/en/smallimage/Ben Evans-s-1675024642432.jpg)
/articles/graalvm-java-compilers-openjdk/en/smallimage/small-image-jdk-2023-1671096273181.jpg)
/articles/java-jvm-trends-2022/en/smallimage/InfoQ-Trends-Report-small-1670863712433.jpeg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/rmi-to-websocket/en/smallimage/migrate-a-RMI-based-legacy-application-to-WebSocket-small-1680106723513.jpg)
/minibooks/jhipster-mini-book-7/en/smallimage/logo-1677849630224.jpg){kind=logo}
/articles/billions-messages-minute/en/smallimage/LOGO-1679471830613.jpg){kind=logo}
/articles/series-apache-kafka-streams/en/smallimage/apache-kafka-article-series-logo-small-1673455781546.jpg){kind=logo}
/articles/secure-kafka-cluster-strimzi/en/smallimage/securing-a-kafka-cluster-in-kubernetes-using-strimzi-small-1671647644310.jpg)
/minibooks/2022-infoq-trends-reports/en/smallimage/LOGO-1672051527011.jpg){kind=logo}
/articles/infoq-software-trends-report-2022/en/smallimage/InfoQ-Trend-Report-logo-small-1672911593669.jpg){kind=logo}
/presentations/refactoring-cleaning-code/en/smallimage/kent-beck-small-1684908700538.jpg)
/presentations/devsusops/en/smallimage/adrian-cockcroft-small-1684908390875.jpg)
Community comments
Confirmed
by Martijn Verburg,
Yet another Sun-to-Oracle rebranding issue
by Vitaly Mikheev,
That is way Feature Detection is preferred to Implementation Sniffing
by Eduardo Pérez Ureta,
Oracle
by Andrew Smith,
Confirmed
by Martijn Verburg,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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,
Your message is awaiting moderation. Thank you for participating in the discussion.
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!