Dependency Trap - Hessian, Spring, Tapestry

A project I'm doing some work with is using Hessian, Spring and Tapestry, and we've just discovered that we're deep in a dependency trap, as follows:

1. Hessian, a binary remote-invocation protocol written by Caucho, avoids cycles and reduces bandwidth by only serializing objects once per request by using object references. Unfortunately, hessian-flex 3.2.0 and below have a problem with references such that they have a tendency to point to the wrong object. (See: my initial report of a bug in references, confirmation of references bug).
2. There's a new version of hessian-flex, hessian-flex-4.0.0, which solves this reference problem, but it's only compatible with hessian-3.2.1 and above. (See: hessian-flex-4.0 posted)
   
3. Hessian-3.2.1 and above do not work with the Spring Framework's remoting framework in Spring 2.5.6; there's been some motion to resolve this in Spring 3.X, but that may not be complete. Further, hessian-3.2.1 itself has a bug. (See: summary of the current state, spring-framework bug for supporting later hessian versions, hessian null-pointer bug)
4. Tapestry-spring, which integrates the spring framework's context into Tapestry's IoC, apparently doesn't play well with Spring 3.x. (See: T5.1/Spring/Antlr issue, another issue I posted myself, but which isn't yet in the list archives).

So, we can:

1. Continue with the dependencies we have, which leave us with broken hessian references.
2. Upgrade to a newer hessian-flex, which requires a newer spring framework, possibly one that isn't even made yet, and which isn't compatible with Tapestry.
3. Fix hessian-flex-3.2.0 ourselves to avoid the reference issue.
4. Write our own hessian remoting (or patch existing) for springframework 2.5.6 to export services using hessian-3.2.1.
5. Fix tapestry-spring to work with Spring 3.x.
6. Abandon hessian in favor of Spring-BlazeDS.
7. Other equally painful choices, probably.

It's always nice to have choices.

Flex Builder 3 on Eclipse 3.5 (Gallileo) on OS X?

I spent a little time this morning trying to get FlexBuilder 3 up and running in Eclipse 3.5 (Gallileo). A little experimentation and reading implied that getting it up in the Cocoa version of Eclipse wasn't going to happen.

I then tried a few more times with Eclipse 3.5 carbon, and still wasn't able to get it working. So if you've managed to get FlexBuilder 3.X up and running on Eclipse 3.5 on OS X, I'd be happy to hear more.

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.

Lift Book Outsells All Other Web Frameworks at JavaOne

It's interesting to review the top sellers at the JavaOne bookstore. Seems to break down like this:

• Two JavaFX books, at #1 and #2. Considering how few people I know who are interested in JavaFX, this feels like a stuffed ballot box to me, but, what the hell, I'll give it the benefit of the doubt. Maybe people were impressed with JavaFX at the conference.
• Three scala books, at #5, #8, #9. Interesting that 'lift' was the only web framework whose book made the top ten, unless you want to count the Java EE book (I don't).
  
• Four core Java and Java EE books at #3, #4, #6, #7. Not really shocking for a Java conference.
• One solaris book.