Caucho's OSGi Pains

Earlier this month, I commented on Atlassian's OSGi experiences, and how it seemed that most of these experiences recount the pain of getting up-close-and-personal with OSGi. I've just noticed that Caucho has a similar tale of woe; they considered using OSGi within their application server and eventually rejected it, at least for the time being.

Now, you could of course argue that this a way for Caucho to explain the lack of OSGi support within their application server. I'm not trying to position their tale in any way. I don't have enough OSGi experience to agree or disagree with the points they raise, I'm just trying to synthesize from the experiences of others, and that seems to come down to this:

If you read detailed adventures of people's experiences with OSGi, it seems to come with a fair amount of pain, so keep that in mind when you're looking at OSGi for your own purposes.

Java for OS X Update 4, Java Preferences and JAVA_HOME

Java for Mac OS X 10.5 Update 4 is out, and if you're on Mac OS X 10.5, you should install it as soon as possible; it patches the serious vulnerabilities that existed in Java for OS X before that.

However, if you're unfortunate, installing this will also mess up your ability to run different versions of Java. On OS X, the version of Java you run by default can be controlled using the Java Preferences panel:

Unfortunately, I quickly discovered that this was no longer true on my system. Although Java 1.6 was heading up the pack, Java 1.5 seemed to be the VM of choice when compiling and running Java code. And since I'm on a project that's using Java 1.6, this was a serious problem.

Changing the value in the Java Preferences application had no effect. Neither did rebooting. I briefly considered reconfiguring the Java setup using softlinks, but it seemed like that was a last resort as it would be further breaking the Java preferences panel. I did some digging and didn't find very much at first.

Eventually I discovered this post on Apple's "java-dev" mailing list talking about changes to the way JAVA_HOME works on OS X, and started experimenting. I discovered:

• The value of JAVA_HOME was pointing to Java 1.5 on my system.
• Altering JAVA_HOME had an immediate and significant impact on what version of Java was used to run 'java' or 'javac' by the executeables that were softlinked by OS X.
• The output of the new 'java_home' command was influenced by whatever went into the Java Preferences panel.

Accordingly, I did as the mailing list suggested, and set JAVA_HOME to `/usr/libexec/java_home` and voila, everything seems to have resolved itself. If any of you run into this, hopefully you'll find success with this solution as well.

. In order to better support JAVA_HOME in OSX there have been some changes. Out of curiosity, I switched the order of the JVMs in Java Preferences and ran the new 'java_home' command and the results would change. I also tried changing the value of the JAVA_HOME environment variable, which immediately affected which version of Java would be run by the 'java' and 'javac' commands.

I'm guessing that I had a JAVA_HOME setting already, pointing to Java 1.5, and it was this value that was overriding whatever was in my Java Preferences. Adjusting JAVA_HOME to be the result of the java_home invocation seems to have solved my problems.

I'm hoping that by posting this I can save some of you the same pain.

PHP Considered Harmful

I noticed this morning (via @PeterBell) that PHP was getting a goto statement in v5.3. Some would argue that the Goto statement has been considered harmful since the late '60s, if not before.

OSGI Case Studies == Pain

Every time I see someone give both sides of their OSGi tale, it reminds me a lot of my EJB 1.x experiences, and I remind myself to stay away unless I absolutely have to.

At QCon (2007?), I saw a presentation on Spring Dynamic Modules. They pointed out some of the issues you might have with OSGi and how Spring DM might help. Mostly, it made me want to avoid OSGi.

I've just quickly skimmed Atlassian's presentation on how they've used OSGi for their plugin architecture, and while I'm sure it has provided them with benefits, and it may be worth it for their needs, my key takeaway is still, "stay away from OSGi unless you have no other choice."

Basically, just looks like it's going to come with a fair amount of pain, so you'd best know in advance that you absolutely need the benefits to offset the cost.