My hellish journey with axiondb
I’ve been finding mckoi more and more frustrating to use in unit tests. It tends to get a bit upset if you try to recreate an in-memory database, and leaves itself in some indeterminate state that makes everyone sad and irritable.
So, I remembered a claim made by some of the Jakarta primitives fuckwits of how axiondb was made so much faster by it. I thought a good test would be to see how easily it’d be to switch from mckoi to axion, and hopefully pick up some performance and functionality on the way. After all, axion is designed to be unit-testing friendly.
You know, I really, really should have paid attention to all those alarm bells firing off. First, it’s a tigris project. Tigris projects are always astoundingly awkward and ugly. They make Jakarta look like a beautiful shiny house of intellectual advancement. The stench of the commons-primitives dependency alone should have been sufficient; someone that retarded is likely to be a repeat offender.
I wasn’t disappointed, needless to say. My quest to just get the fucking thing running was a dark dismal journey down a rabbithole. First, the current latest release ships with just the db jar file. My heart beat faster at the thought of a beautiful all-in-one jar file that can be used out of the box. What a fool. It turns out it requires most of Jakarta-commons. The wankers didn’t even bother use their own base64 encoders; instead you have to plop in commons-codecs.
Oh well, I thought to myself. I’ll just grab these zillion jars like I’m told, stuff them all in one dir and spend the rest of the day drowning my sorrows, in the vain hope of killing all braincells that witnessed this horror.
So so naive! Of course, like all projects that do not manage their own deps and use explicit versions, that attempt blew up horribly. The current latest milestone, it turns out, was compiled against some bizarre version of commons-collections, and a method signature had changed in the actual release they say they require.
I briefly considered building the damn thing from source. That in turn brought to light another idiocy. You need to explicitly download and plop in various commons-shite.jars, as well as create your own build.properties file (they do provide the oh-so-generous build.properties.sample though). So really, fuck that. In the end, all they accomplished with their bungling and user-unfriendliness is a lost potential user, and gained much bad karma.
Now, you might think this is no big deal. However, you can barely imagine my glee when a friend of mine recently regaled me with the story of an interview he conducted with a potential employee. Said potential employee was too enthusiastic about commons-primitives, and was so eager to use it, that it cost him the job. The emperor has no clothes, after all.
There are many morals to this story. First, do not brag of your Jakarta love. It’ll cost you your job, hopefully. The more important moral is though that the axiondb developers are a bunch of shit-eating twats who insist on abusing ant and shipping broken crap and expecting their users to bend over backwards just for the privilege of using their filthy useless little database. Assholes.
December 30th, 2003 at 12:03 pm
What’s wrong with bending over backwards?
December 30th, 2003 at 1:44 pm
Who uses jakarta for base64? Everyone knows about the undocumented one in sun.misc. Asshats times three.
December 30th, 2003 at 1:49 pm
how about hypersonic (http://hsqldb.sf.net)? it’s designed to be used as an in-memory database, there’s only one jar, it’s well documented and 1.7.1 is pretty stable.
regarding axion, no doubt you’ll be pleased to know that it has been accepted into incubation by apache db. that said, i think you’re being a little harsh to a project that hasn’t done a full release yet.
December 30th, 2003 at 1:56 pm
Got building troubles & issues downloading the right versions of jars? Just install Maven and type ‘maven’ and hey presto it builds :)
Whoops, I’ll just get my coat…
December 30th, 2003 at 2:25 pm
Why do so many people make it so freakin’ hard to download and use their pitiful projects? I mainly blame Maven for promoting this idea of not shipping dependencies. A zip file or a fancy tar with all dependencies - is that too much to ask? If you use one of those damn install wizard tools, please provide a compressed archive option too.
I had the same problem with Axion, too. I had to compile from source using the most heinous Maven. Once I got Axion running, it worked well though. It has real potential.
Hani, when are you going to bile Merlin?
December 30th, 2003 at 3:18 pm
Have you tried DaffodilDB?
December 30th, 2003 at 4:58 pm
Lame.
This way my contribution level is equal to Hani’s.
December 31st, 2003 at 8:25 am
Nowadays tons of projects act like this.
1. it cant be that we should wait for a 1.x release to be able to get a tool running under 4 hours. (at least not for such a primitive one)
2. if a project relies on seventy four other project jars, be so nice to provide also a tar with all deps. If you worry about the size, rethink your complete usage of other jars.
Lately i saw a project using a third party jar (>50k) only because of MD5 hashing. Allways thought that this is allready in the J2SDK ;-)
But hey, this way, this blog allways has plenty to bile..
marc
December 31st, 2003 at 9:30 am
maybe you should go for other databases, Hsqldb is a good choice. also Berkeley is pretty damn fast and complete. There are some nice OODB’s are also available, i am using a small DB called Perst from
http://www.garret.ru/~knizhnik/perst.html
which can be used for embedded systems and single client db’s (complete java, single jar).
Also thhere is goods , a high performance multithreaded serve OODB (base is C++ i assume, with java api).
http://www.garret.ru/~knizhnik/goods.html
all are open source.
December 31st, 2003 at 10:36 am
If it looks like shit, and smells like shit, then it probably is shit.
-PooMonkey
December 31st, 2003 at 12:10 pm
Bile wishlist:
Hibernate: Come on. This thing has gotten way too opaque and complicated with its caching and other weird stuff.
JUnit: What an incredible lame framework. Great idea, pathetic implementation. What’s with all the assert methods? Do I really need assertEquals when I’ve got assertTrue?
JDOM: Can we have more convienience methods please? The learning curve is not quite steep enough.
Javaspaces RI: Is anyone able to get this up and running without googling the web for decades old, outdated documentation? Why does it have to be this complicated? Gigaspaces took me 10 minutes with a HelloWorld example running.
January 1st, 2004 at 2:50 pm
Hi Mr. Anonymous Bastard, is “eatme.com” really your blog? I’m only asking because it looks more like a porn site re-direct to me.
January 1st, 2004 at 3:59 pm
AB: As proof that one man’s poison is another man’s lunch, one of my pet peeves is people who use assertTrue() when they should be using assertEquals().
assertEquals(), when it fails, prints out the two values being compared, so you can see pretty quickly where they differ. (IDEA pops up a diff browser if the output is too long). assertTrue just says “assertion failed”, and you have to hunt down the difference yourself.
Sure you could put the two values into the message argument of the assertion. But then you’ve just rewritten assertEquals() yourself. Badly. In a hundred different places.
The only really bad things about assertEquals() are its woeful handling of arrays, and the fact that it has to have so damn many different methods to do the one thing. But both of those are more Java’s fault than JUnit’s.
January 2nd, 2004 at 8:04 am
The problem is not assertEquals’ handling of arrays, its that its impossible to add an assertArrayEquals to the framework in an easy fashion (Java’s fault) and that JUnit is no longer being maintained as far as anyone can tell so it will never be added to the core framework and nor will any other useful new features.