More UTF-8 head-thumping with Hibernate 3

I’ve just finished upgrading an application component so that it uses Hibernate 3 instead of Hibernate 2. The last time I tried to do this, I spend half a day on it, realised that all of my UTF-8 encoded data wasn’t working and simply abandoned the effort. But I was feeling brave, so I tried again.

First off, since I’m running on OS X, the first thing that I had to learn is that Firefox on OS X doesn’t handle a lot of Indic text properly (notice that this bug is just over three years old!). That makes it really hard to test when you are looking at question marks instead of Tamil! Solution: use Safari. It works fine. A good test page is the OpenOffice Tamil intro.

But it still wasn’t working for me. I resorted back to the techniques that I used in an earlier blog post, specifically md5 checksums of the text in question. And, yes, there was definitely a problem.

The solution: you need extra parameters for your connection string when using Hibernate 3:

jdbc:mysql://localhost:3306/mydb?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8

… and now things work again (well, in Safari, anyway).

A microbenchmark for Whirlycache

I was browsing around tonight and noticed a reference that Greg Luck (started the EHCache project) made on his blog to a cache benchmarking tool. Of course, my first thought was, “Gee, I wonder how Whirlycache does using their benchmark.”

A few minutes later… yes, it wins on all counts:

---------------------------------------------------------------
java.version=1.5.0_04
java.vm.name=Java HotSpot(TM) Client VM
java.vm.version=1.5.0_04-b05
java.vm.info=mixed mode, sharing
java.vm.vendor=Sun Microsystems Inc.
os.name=Windows XP
os.version=5.1
os.arch=x86
---------------------------------------------------------------
This test can take about 5-10 minutes. Please wait ...
---------------------------------------------------------------
|GetPutRemoveT  |GetPutRemove   |Get            |
---------------------------------------------------------------
cache4j 0.4       |7441           |5108           |3414           |
oscache 2.2       |14000          |16784          |4526           |
whirlycache 1.0.1 |4206           |1643           |891            |


ehcache 1.1       |7261           |2603           |1092           |
jcs 1.2.7.0       |5238           |3535           |1251           |
---------------------------------------------------------------

Disclaimer: Like all benchmarks, take these numbers with a grain of salt.

By the way, Whirlycache was mentioned on TheServerSide today.

Whirlycache 1.0 Released

Whirlycache 1.0 is released.  This release fixes a harmless exception that can sometimes occur during cache shutdown.  And it also removes the JDOM dependency so there’s one less jar file required to deploy. The 1.0 release is a dropin replacement for earlier versions.



We’re now starting work on the 2.x branch, which will explicitly require JRE 1.5 or higher.

The 1.0 branch will be supported in the future for those users who need to continue using JRE 1.4.

Thanks again to Peter Royal and Seth Fitzsimmons for working on this with me over the years.

Skewering Bloglines (again)

David Berlind at ZDNet apparently noticed the games that Sam Ruby has been playing with Bloglines. Bloglines is hopelessly silly in so many areas and Sam likes to point this out by putting little HTML tags in his posts that break Bloglines. I laugh every time he does this.

In addition to Bloglines’ inability to make a sane feed reader, there are also very serious unresolved privacy problems, security problems and specification compliance problems.

You must wonder why we continue to use Bloglines in spite of all this. It’s because all of the other web-based feed reader applications are so hopelessly, unbelieveably bad that we all keep coming back to this junkheap of a web service and wait for it to get better.

Maybe one of Paul Graham‘s startup school fundees can rewrite the damn thing in a weekend… (in Lisp, just to make us all smile).

A Day Without Immigrants

I have to wonder if this “A day without immigrants” campaign is going to have any meaningful outcome. It makes me think of a claim in John Gall’s Systemantics that says:

Systems in general work poorly or not at all

The thought is that complex systems must be resilient in the face of failure. If a system is large and composed of many pieces operating together, then larger systems have a much higher chance of experiencing a failing component at any given time. If the system cannot continue operating in the face of such a failure, then the system fails.

In Systemantics, I believe that Gall uses the example of garbage collection in a big city. At any given time, you have strikes, broken trucks, traffic jams, shifting regulations, unplanned sickness and injury among garbage workers and other unforseen problems. But it all still happens. Garbage collection is performed in the face of all of this.

And if I cut my toe, it doesn’t inhibit me from moving about. I adapt.

I’m wondering what the day without immigrants tactic will produce when the system containing these immigrants doesn’t completely fail.

That being said, it is an interesting time watching people trying to figure out what “American” means these days.  This country has a foundational reliance on under-represented people inside the US and in other countries.  Calls for undocumented workers to leave

the US doesn’t reflect the reality of the situations that many of these people are running from.

A strange IBM decision

From my friend BenBen:

This is the IBM 32-bit Runtime Environment for Java 2 (JRE), Windows Edition.

To be able to install this JRE your computer must

be an IBM system, as shown by a BIOS check. It must also be running Microsoft Windows Me, 2000, or XP. Or it must be updated with the latest WMI classes if running an older Microsoft operating system. And, finally, you must have Administrator level access.

This artificial restriction prohibits the IBM JDK for Windows from running on non-IBM systems.  The logic for this escapes me right now, but removing the restriction would allow people to run the IBM JDK for Windows on Dell, HP and other systems.  I don’t see how this hurts IBM.

And it’s not as if the users of these other systems don’t have the option of using a JDK from Sun, BEA, Apache (well, almost) or elsewhere.

More here.