WombatNation

After using the built-in self upgrade feature of Eclipse to go from 3.4 to 3.4.1, I was no longer able to launch Eclipse. Instead of the happy Ganymede splash screen, I got a poorly formatted dialog saying “The Eclipse executable launcher was unable to locate its companion shared library.” I discovered that the problem was that eclipse.ini had not been updated to point to the updated launcher library. Here’s how to fix it.

1. Open a Finder Window to the Applications directory, or wherever you installed Eclipse
2. Expand the plugins directory
3. Scroll down to the directory starting with the name “org.eclipse.equinox.launcher.carbon.macosx_”
4. Copy the text of the name following “carbon.”. After the update, mine was 1.0.101.R34x_v20080731.
5. Right click Eclipse.app and select Show Package Contents
6. Expand the Contents and MacOS directories
7. Open eclipse.ini in a text editor
8. Look for two lines that look like

--launcher.library
../../../plugins/org.eclipse.equinox.launcher.carbon.macosx_1.0.100.v20080509-1800

9. Change the part after “_” to the text you copied above
10. Close and save changes to eclipse.ini
11. Restart Eclipse

In case you weren’t aware of this, you can also edit eclipse.ini to change the vmargs Java will use when launching Eclipse. For example, if Eclipse itself is running out of heap, you might want to boost the min and max heap size with something like:

-Xms64m
-Xmx512m

Of course, you should also click “Show heap status” in the General section of the Preferences dialog so you can monitor how much heap is being used and can force a GC before a big compile. You shouldn’t boost the min heap size from the default, though, unless you blow past it pretty quick and experience initial sluggishness as the heap keeps getting expanded.

I went to JavaOne last week and was once again amazed by the number of attendees. I heard someone say 15,000 people had registered. I believe it. Other programming languages like Python and Ruby might be gaining in popularity on Java, but Java is still pretty dominant.

And just like last year, the queues for getting into the sessions were chaos. The people trying to organize the queues were trying hard (well, a few were), but the space where people lined up for the biggest sessions was the least conducive to organization. Someone at Sun needs to go to a major theme park and take lots of notes. Theme parks figured this out long ago.

And then the last thing you want to hear about happening when you were recently in a crowded space with 15,000 of your best friends did happen. On Friday I got an email from Sun that about 70 of those best buddies (actually, almost all of the 70 were workers not included in the registrant head count) caught a highly contagious norovirus.

I shared my pass with some co-workers, so I was there only on Tuesday. Fortunately, none of us got sick. The best sessions I attended were:

• More Effective Java
• Defective Java™ Code: Turning WTF Code into a Learning Experience
• Let’s Resync: What’s New for Concurrency on the Java™ Platform, Standard Edition
• Real World, Not Hello World: GWT Development for Java™ Technology Shops

I was really impressed by the quality of the web apps that had been built with GWT. I co-developed an app at work using GWT, but the part of the UI I developed was not nearly as cool as what these two companies built. It made me want to do some more work with GWT.

While I was impressed with JavaFX Script, the presentation Tuesday morning went at much too slow of a pace. Although 50 minutes had elapsed, I felt like only about 15 minutes of material had been covered.

The EBay presentation was also sort of interesting, but it felt too much like “here’s a little bit of info about a lot of cool technologies we have developed, but it won’t be much use to you since there are a lot of interdependencies and it’s closed source.” In the Q&A session they said they were considering open sourcing some of it, but I would understand if they didn’t. It would probably take a very large amount of work to unwind all the internal dependencies on their other infrastructure.

I’ve been meaning to try out the JPackage repository for a long time to manage the Java installations on my Fedora Linux installs at home. However, the documentation on the JPackage site is incomprehensible. I don’t see how anyone could possibly use it to install the Sun JDK for use with the JPackage repository with the nosrc rpm. It’s almost like they are daring you to use GCJ, which in my opinion, is a total waste of time. Even the instructions for the compat rpms are overly verbose.

Fortunately, I found some documentation for installing Java on CentOS. CentOS is a free-of-charge distribution of Red Hat Enterprise Linux that we use for our production servers at Voxify. Since Fedora is cut from the same cloth as RHEL and CentOS, I was hoping the instructions would work with minimal change, and I was right. A million thanks to the people who wrote that document.

I was able to follow the directions exactly as written, except for the need to first install libXp ($ sudo yum -y install libXp) and to change the 11 to 12 in the file references for the JDK, since the newest Java 5 distribution is now 1.5.0.12.

The Java 6 install is even easier, although it uses the compat rpm instead of the nosrc rpm. From my perspective, though, using the compat rpm is worth it for the time it saves.