Collaboration: At the Extremities of Extreme
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted 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.
Monitor your Production Java App - includes JMX! Low Overhead - Free download
Using Drools? See what you're missing! Get the Power of Drools with the Assurance of Red Hat
Improve Java Garbage Collection, Runtime Execution, and JVM visibility with Zing
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Hi all,
Just for the paranoid, I've confirmed that the follow the FAQ instructions work.
Cheers,
Martijn
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.
Eclipse should just run with the parameter and if it fails just run again without the parameter instead of sniffing the implementation company name.
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!
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.
John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.
4 comments
Watch Thread Reply