Again with the N800 :-)

Well, I'm at it again. I wanted to read mangas on the N800, but the only working application, Comix (a Python application) was somewhat slow. Not the Python code itself, which was actually quite fast, but rather the overall approach. You see, to speed up processing, Comix would always unzip the whole comic archive file (cbz or cbr) in a temporary directory and read from there. It does make page flipping faster.

It also fills the N800's main drive as fast as you can say, "out of disk space" :-)

The approach is acceptable on the desktop, where at worse, we're talking about 50 MB of temp disk space for really large archives. Not an issue, even on my relatively small (by today's standards) 80 GB drive.

On the tablet, though, not only is it problematic (you get 256 MB of drive space and that's it!), but even writing to external memory cards is really, really slow. Expect 2-5 minutes before you see the first page, and meanwhile Comix is hung. And woe to you if it crashes–you'll have to recover all this space at the command line.

The crash thing didn't bother me too much, but the slow boot time did. I read fast, especially manga which tend to have relatively little dialog per image. So I started looking for an alternate solution that ran on GTK+ and that I could potentially port.

After swimming through numerous Java applications (useless on the tablet), there were two candidates: cbrPager and Comical.

Choosing the One

Comical initially looked more interesting. It embeds libunzip, unrar (through a special exception to the GPL in the license) and did all image decoding in memory, which I thought could be faster. cbrPager, in contrast, had a similar approach to Comix (unzip to a temporary directory), except that it unzipped only one image at a time. I worried that this would be slow. Also, cbrPager used the Gnome libraries, some of which are not available on Maemo, and I didn't really expect to have to rewrite parts of the UI layer. But unfortunately, Comical is written on top of wxGTK, which is a bit problematic on Maemo (there's a port, but it's hard to get from a repository). So I decided to take a look at cbrPager and do an initial "straight port" using the Gnome canvas and disabling parts of the interface, just to see whether it was fast enough to be a workable base and not force me to deal with wxGTK.

It was quite fast, thank you very much.

I immediately knew I had a winner.

Modifications: Front end

I Hildonized the toolbar and main window, which was relatively quick. Unfortunately, one of the features that's really useful for tablet-based comic book readers is rotation. Comix had it, together with very high quality antialiasing. A small modification to the cbrPager source gave me antialiasing and rotation, but not both at the same time; rotated images looked really, really bad.

Since I wasn't too happy with using the Gnome canvas anyways, and that it was the last Gnome dependency left (I had had to remove all others), I decided to try to find a nice way to replace it. Initially, I was quite ambitious, thinking I'd do raw updates to the main widget. Looking over in the gdk-pixbuf library, it looked possible, as that library had all the bells and whistles I needed: antialiasing with selectable algorithm, automatic rotation, image scaling, etc.

But then I started to think about how to embed the image render in the main view, and my head started hurting, thinking that I'd have to write a GTK+ widget from scratch (it's not hard, exactly, as I've learned later, but I had never done something like that before...). In the end, I decided to look for a plain image viewer (initially I though gqview, since it has the features I'm looking for) and see if I could scavenge their widget.

In the end, I found GtkImageView, which had a ready-made widget and was only lacking rotation. I added rotation and was a happy camper.

Well, almost :-) I had introduced a memory leak that ate all the RAM of the tablet really, really quickly. Fixing it was really simple, but that didn't happen before I crashed my tablet several times in an effort to figure out what exactly was going on...

From the front-end point of view, I then added a few tidbits: scrolling through direct pen usage, auto-rotate, bookmarks (my wife asked for that one really fast...), persistent zoom settings, fullscreen... All of those were pretty easy to add, which speaks volumes about the initial cbrPager code's organisation (hint: it's pretty nice).

Modifications: back end

I then got annoyed that users were forced to install unzip. One nice feature of Comical is that it embeds the unzip code. So I wanted to do the same. For RAR files, I chose not to do it right away because of licensing problems.

To do that, I needed to extract the archive reading logic. It was embedded in command line use. So I chose to encapsulate it in a gobject. This was probably a bit overkill, but it made sense with respect to the use of the GtkImageView gobject.

I first moved the code of the fork/exec logic into a gobject and got it to work that way. Once that was done, it was really easy to get it to work with direct calls to the unzip library.

I had wanted to extract the image bits in memory and decode completely in memory, thus removing the need for a temporary file. I didn't do it that way right then because there were reports of really slow decoding when doing that through pixbuf loaders. Since image decoding was actually slower than archive reading, I decided to pass for now.

Writing a gobject was kinda cool, but those things are really quite heavy... there's a lot of macros and presumably some overhead. Since the same 3 objects are reused throughout the application (one object per supported archive type), the overhead is negligible, but if I had to do it again I'd just go with a struct and function pointers, although it feels kind of silly to do that given that there's already gobjects in the application.

The result

Well, just go download it at https://garage.maemo.org/frs/?group_id=777&release_id=2075.

You can see the announcement on the Internet Tablet Talk forum. There's screenshots.

Just beware, you need a memory card in the internal slot for this to work... I'll work on a fix tomorrow.

Credits, thanks, etc.

Many thanks to the original author of cbrPager for writing the initial code, and for putting up with me :-)

And thanks to the ITT community, who will be my beta testers, as usual ;-)

N800 Update

Well, after a couple of months with the N800, I must say this was one of the better purchases I've done in electronics since getting my first computer. It's an extremely useful device.

I got a second one for my wife, and it came with an iGo foldable Bluetooth keyboard, which was a pretty good deal. The keyboard is a nice addition, and next time I go to a convention, I'm not bringing the laptop, or at least, not for anything except the tutorials. The tablet is much nicer to carry, its battery can last much longer, and I look like a total geek when I unfold the keyboard and start typing away. Given that I'm now comfortable with my geekiness, this is actually an advantage :-)

Looking at the price I paid for both tablets, it was actually cheaper than many MP3 players, even when factoring in the price of the additional SDHC cards.

So, here's my appreciation of the device after two months of use:

• For e-books, total success. I'm nearly done with the Honorverse stuff, and I'll move on to other books soon.
• For tech books, I haven't used it much so far because I've been commuting by car lately. But my wife is using it to study for the SCWCD, and although in her opinion it's better to look at her desktop LCD, the tablet is good enough for reading in public transit. And much less heavy than the SCWCD book...
• For the Internet, it's really incomparable. No device that size can do it all like this one. I wish they'd upgrade to Firefox 3's final engine instead of an alpha 1 derived version, though. No doubt that's coming soon.
• For videos, it works very well, although sometimes hitting the optimum encoding can be tricky.
• For games, it's better than I thought in the end. iNES has excellent performance, so old NES games play extremely well. At least iNES has a saner on-screen button system than FCEUltra. Star Control II (The Ur-Quan Masters) is also extremely playable, but you need a keyboard. I use a small PlayStation 2 USB keyboard with an adapter for this, and it works kind of like a mini console controller.

Also good news, the latest release of Maemo, Diablo, has been officially released to the public. I can report that it was a pretty painless upgrade. The browser and flash support seems somewhat snappier, and I'd say the overall OS feels more solid overall. Except for the weather desktop applet, everything from Chinook (previous release) worked very well.

So Nokia can count me amongst their satisfied customers.

Behold my new toy!

Much to my wife's chagrin, I've acquired a Nokia N800 Internet Tablet. It's been a long, long time since a piece of hardware interested me, so let me tell you about this one.

First, though, some background on why I got one. I got fed up of the huge boxes of books (mostly mine, and mostly old sci-fi or computer books) that take a lot of space in our closets. Also, I'm getting worried that my main bookshelf will buckle and fall under the load; the tablets have nearly 3/4 of an inch deflection at the center. Doubling up the number of books on them was probably not very smart...

So, I decided I'd get an e-book reader.

After a lot of research on the Kindle, the Sony PRS-500 and 505, the eBookwise 1100 and a few rare and too expensive other options (Cybook, etc), I settled on a previous-generation Sony. Unfortunately, it's not really a common device in Canada, so I went to eBay.

The price was rather high in my view, for a previous generation device, and all sellers were shipping by UPS (I really don't like getting packages by UPS, the distribution office is at the other end of the city and they never deliver the package at a decent hour). So, I started looking for other options, such as PDAs, with the philosophy that if I paid more than 200$ for something, it better do more than one thing.

Research on this took a lot of time. Did you guys know that PDAs are a disappearing species? Which is bizarre, in my view, because they are useful beasts, especially with WiFi. But smart phones are killing them. Unfortunately, for e-book reading, a smart phone is not an option... especially since I already have a cell phone (the cheapest I could find) and have no desire to change providers/pay a lot just for getting extra PDA functions.

But after a while, I found a site that mentioned the Nokia 770 Internet Tablet. Being curious (what's an Internet Tablet? Since when did Nokia do something other than a phone?), I researched a bit, and here's a capsule version of what I found:

• The Internet Tablet series of devices are 4-inch, 800x480 screen devices with WiFi and Bluetooth included;
• The screen size/resolution yields a totally crazy 220 DPI screen;
• The screen size means that you can browse web sites from the tablet with a minimum of scrolling;
• The screen size also means you can read PDFs in landscape mode without too much trouble, which is a HUGE advantage compared to the Sony PRS 505, which doesn't render PDF too well. As much of what I intended to read on it were technical books that tend to be distributed in PDF, this was an excellent advantage;
• And, the clincher: this thing runs a variant of GNU/Linux known as maemo, and hundreds of programs have been ported to it!

I originally thought of getting a 770, but in the end, I settled for an N800, which looked better, had a faster CPU, more RAM, and as an added bonus, is somewhat lighter.

So, what am I doing with this thing?

• Reading e-books, of course, mainly David Weber stuff I got on the CD that came with the War of Honor hardcover I bought some time back;
• Reading tech books, especially since I hacked evince to be a bit closer to my preferences (I wanted the paging buttons to scroll by screen size rather than go directly to the next page);
• Browsing the internet. Instead of staying in our home office to browse 'til the wee hours of the morning, I can finish reading my favorite blogs elsewhere, the idea being that I don't need to stay in front of the PC 'til the wee hours. It's kinda hard putting this in practice, though;
• Watching video. This was a surprise, since the tablet is not meant for that and apparently, Nokia sort of goofed the video hardware on that count. But when properly re-encoded, the screen is gorgeous enough and the speaker good enough quality that it's quite a pleasant experience, and doesn't tie up the TV screen. Great for watching smaller clips. My wife and I have been listening to a couple of episodes of La Linea every day when we feel like it;
• Games. This was somewhat disappointing so far, because the d-pad isn't the best thing in the world, emulators run slow, and button placement is awkward. ScummVM was the best success so far, probably because it's already mouse-based.

But the most unexpected development of all: lately, I've stopped having much fun with my Xubuntu box, because, besides small, occasional sound card glitches I had when following Hardy, I've been having no problems at all... and no incentive to do a re-install. In fewer words, I was getting bored. But the N800 is a new environment. Even though it's GTK+ based, there's lots to do--it's still somewhat rough, and there's a lot of stuff to port to it.

I got the urge to hack on it just for fun.

The first thing I did was recompile evince (a PDF viewer, slightly more flexible than the one that's included by Nokia) to give it key assignments I like better. If anybody wants the patch, I'll be glad to provide it (it's quite trivial). Setting up the cross-compiling environment (known as scratchbox) wasn't the simplest environment setup I've ever done, but after a couple of tries, I got it to work right. I had to try a second time because somehow, I hosed the first version when switching targets.

The second is far more interesting. As I was complaining about the hand writing recognition on the tablet, somebody at the office pointed me to the QuikWriting system by Ken Perlin. That system lets you write without lifting your pen, and the overall mechanism is much less error-prone than hand-writing recognition. I looked and looked for an implementation and could only find an old one for Qtopia. I really wanted to try it out on the tablet to see if it was a viable option.

Finding no port, I ported it myself. The result is available in the maemo Garage. It's not quite finished--namely, I'm a bit annoyed at the current letter display, and international support would be nice. I'd also like to refactor the code and render the input areas using vector graphics instead of a stupid bitmap.

Still, it works right now, and I'm using it in production.

Doing this was the most fun I had in a long time.

As for my wife, she asked me to buy her her own N800.

A nice new toy, indeed! I'd recommend it to any GNU/Linux-head out there. It's pretty capable, the build quality feels solid, the battery life is good, and the screen is fantastic. I give this device 9/10, and I'll be sure to look out for the next version.

(Addendum: yes, I know of the N810, but the hardware is very similar, so I'll probably skip it. My dad got one, though, and he's also having fun with it.)

Musings from EclipseCon 2008, part 1

I totally forgot to mention it for the longest time, but having a fruit hat picture on my blog landed me a free entry to EclipseCon in Santa Clara, CA, USA. Alogient was kind enough to pay for my transportation and hotel room.

I'm writing this from there; the connectivity is really good overall, I wish I'd been wired like this last time I went to a conference...

I'll have more things to say about the overall experience later, but right now, there's an interesting thought I want to write down.

Today's keynote was given by the guy behind Fake Steve Jobs, who, at one point, made an interesting (if not very original) parallel between Apple and a cult. It's mostly interesting because during lunch, I sat at the "Maven" table (and unfortunately, none of the m2eclipse or q4e guys were there--guys, you suck! :-) and one of my lunch colleagues made the reflection that people get on the Maven train because they've invested so much time learning it that they want it to be worth something.

Note that the guy saying that being wry, and we all had a good laugh. But it got me to think that Maven could be seen as a cult as much as Apple, but for totally opposite reasons:

• Apple is a cult because they do products that are designed and work really really well the first time you pick them up;
• Maven is a cult because it does not work at all the first time you pick it up, and probably the converted really just want other people to suffer as much as them :-)

So, now you can decide whether that's the reason I'm a Maven fan...

Maven (non)-bashing

Looks like the popular sport of bashing Maven continues. Just thought I'd add my own opinion to the mix.

Background

At work, I've instated Maven use for new projects as well as some active projects (those I could get people to migrate, anyhow) about nine months ago. My reasons were the following:

1. We had a crufty Ant-based build system (which I built myself, I'm ashamed to say--I think my only excuse is that it replaced another, cruftier Ant-based build system with really wonked dependency management), and some of its persistent bugs (wonked version number handling and unversioned third party libraries) were really starting to get on my nerve and other developers';
2. I'd tried out Ivy, and I had problems getting it to just work (this was way before the current version, at a time the documentation was rather sparse);
3. A co-worker started bugging me about "why not Maven," so I got curious;
4. I finally found out how to adapt the pom.xml file to a non-standard directory structure, from the Wicket project's pom files. This was the clincher, because I really hated the standard Maven layout (especially separated code and resources directories--ugh) and I wanted to be able to retrofit our old projects that had a more widespread layout (source in src/, tests in test/ and webapp in www/).

Initially, I was the only Maven user in the whole place. I introduced my team mate who worked on the same project I was doing, and more recently, I ported a whole bunch of legacy stuff to use Maven instead of the old script, declaring that if that stuff could be ported, anything could. Two other co-workers started using the Maven build at that time, and so far, they feel it's been positive.

Maven bashing

OK, fasten your seat belts, folks, because that's going to hurt.

I had two huge problems with Maven:

• Bugs
• Very, very generic documentation for many non-generic tasks, like sofware release (mvn release:prepare and mvn release:perform)

The main bugs I hit were huge bugs with the CVS SCM provider that made the release plugin basically unusable. I tried fixing it myself, but I nearly burned my eyes out navigating the SCM module source code. This is another sub-complaint: the code quality is, frankly, not that amazing. It's a bunch of too-small modules strewn together, and sometimes the modularization is pushed a bit too far for my tastes: you get a package with interfaces only, a package with the implementation, a package with just the model created automatically from modello files, and then a package for each different plug-in. That's two extra packages, in my view, and it means a very high cognitive load.

The main problem with the documentation was that it was highly variable. Sometimes, you get amazing details, lots of examples. Sometimes, you get a glib description and the goal documentation (note to plug-in developers: the goal documentation would be much better if the configuration parameters were actually explained; sometimes, it's not clear exactly what a term means in a given context, and being told "localRepository: local repository path" does not help much). Sometimes, you only get autogenerated stuff with no description whatsoever.

Also, I wish more attention were paid to error messages. This is a common problem in software, however; Maven is not the only (nor necessarily the worse) culprit. Exception: the archetype plugin is one of the stupidest thing I've seen from an error-reporting point of view. When it's missing files, it just throws "unable to copy file" without having the decency to tell you which one... even the stack trace is mum about this.

Maven praises

However, I'm not convinced that this is an excuse to ditch the whole system. The main concepts, if not necessarily the code, are quite solid. I wish there was a way to specify ordering when binding many plug-ins to a single phase, but that's the kind of stuff that's not needed that often.

Maven works mostly as documented, and when it works, it works really, really well. In my experience, it's relatively speedy (at least, compared to my hokey ant script). The release plugin, now that they fixed many, many bugs with CVS interaction (actually, the CVS plugin may have been the culprit, I was never able to ascertain this because the code was really "indirect" about it), works beautifully.

Writing a plug-in is really easy. Even compared with Ant tasks. Yes, it's that easy. It's a shame some Plexus or Maven core stuff is so poorly documented, but you can usually figure it out by looking at a similar plug-in.

Despite what a lot of people say, it is very much possible to have Maven work outside its standards. You'll have to be more verbose in your pom.xml, or use a parent pom. Wicket, as well as our own projects, are testaments to this flexibility. You have to hunt around for information on how to do this, but it is available on the Maven site.

Conclusion

Despite some shortcomings, I truly believe Maven is a very good build system. It was maybe a bit too ambitious at first, but since 2.0.5, it started being able to deliver on those ambitions. It is also much more flexible than people give it credit for.

For those banging their heads with it, I advise that you look at the Wicket and AppFuse pom.xml files. Likely they've solved your problems already, so you can just stealborrow their solution. :-)

Assertions in Eclipse

A small trick I found. While running unit tests, I realized that the Maven Surefire plug-in enables assertions during the test run, while Eclipse does not do so (at least, not by default). Looking for a way to enable assertions at unit test time, I found that you can go to Windows | Preferences... > Java | JUnit and select the "Enable assertions for new JUnit launch configurations" checkbox. Hope this helps somebody somehow.

3 things I learned about software in and out of school

Following the lead of Carnage4Life and Scott Hanselman, here are my own items:

Three things I learned while in school

1. Some people can program, others can't. Those who can't will never be good at programming, even if they work really, really hard. I learned this when I saw somebody stare at a compiler error message for 30 minutes (until I helped them with it) for a simple missing parenthesis! Staring at the error message for more than a minute is not going to help you figure it out when all it says is "Parse error..."
2. It's hard to know when to stop generalizing. I learned that in Software Engineering when we had heated discussions about whether we should bring generalizations to the next level, something I was very much against.
3. Working in a group is more fun, but can be disturbing to by-standers.

Three things I learned while not in school

1. Business people tend to ignore technology under the pretense that business concerns are more important, but it's not a good idea. Technology problems don't really go away by themselves, even if CPUs become vastly faster every year.
2. Software is a highly volatile industry. When I left school, it was the .com boom, 99.99% employment, etc. etc. Since then, I've seen ups and downs, but always in a very protracted time period.
3. As you grow older, your experience will tend to grow stale. The reason for this is that as you gain experience, you are more and more likely to become the team lead or senior programmer of your team. As such, you won't have anybody to "pull" you forward as you did when you team lead or senior guy was there and you tried to show off that you were a better coder/designer. The only fix is to always remain open to ideas, regardless of how junior the person who expresses the idea may be most of the time.

Lesser known IoC containers

The point of this article is to talk about my experience with IoC containers other than the 1000-pound gorilla in the IoC container space.

Through some interesting circumstances (mostly, my hard-headedness about not including 15 megabytes of stuff just to get an IoC container; note that I do know Spring is modular, but it wasn't at the time), I'm one of the few people who hasn't been using Spring. At work, we've mostly used PicoContainer as our middleware "glue" layer. I've also dabbled with Guice, and Plexus (a bit) when messing around with Maven Mojos. This is a summary of my experience with each.

PicoContainer

Let's cover the IoC container I feel I know best first--PicoContainer. PicoContainer is a small (the JAR is 100 KB or so), type 3 (constructor injection) IoC library.

And that's pretty much the only thing it will ever be, if you don't customize the library. It does constructor injection. It supports hierarchical containers to resolve dependency conflicts. And that's it.

However, the real power of PicoContainer is its open architecture. You can implement your own component management strategy by implementing ComponentAdapter and ComponentAdapterFactory. There are a few example adapters. But overall, this lets you futz around with the component instantiation without having to resort to aspect-oriented programming or exotic annotations. Also, since you are in full control of which ComponentAdapter is used for which component, you can completely customize the instantiation on a per-component basis.

As an example of how useful this can be, it was very simple to implement a specialized adapter that can inject some dependencies through construction injection, and then looks for more dependencies to inject using setter injection. When my experiences with Guice left me somewhat lukewarm, I was able to quickly whip up an @Inject annotation for PicoContainer.

Finally, the hierarchical container facility is extremely useful for one-off dependency injections, such as injecting dependencies in objects retrieved from the persistent store by Hibernate.

So, in conclusion:

Pros

1. Very small
2. Reasonably fast, to the point that it can be used with throwaway containers
3. Works even with old JDKs such as 1.4
4. Component adapters are extremely flexible
5. Containers are very lightweight, can create and throw away child containers at will

Cons

1. The authors believe constructor injection is the only viable option. However, although constructor injection enforces integrity, it's also very awkward, especially when you get more than 5 dependencies. OK, you probably shouldn't have that many, but sometimes, especially in Struts actions or some other equally centralized point of logic, you will get that many, and it's still less awkward than having a façade just to cut down the dependencies.
2. Although the adapters are very flexible, there are very few useful implementations that come with PicoContainer. One that supports Guice-like semantics would be welcome.
3. The hierarchical system for resolving dependencies works well in some situations, but is extremely awkward in others. Granted, it's possible to write a component adapter that uses an alternative resolution mechanism, but in the IoC realm, PicoContainer is a bit like assembly language, or Forth; even relatively common cases have to be implemented by hand.
4. There is relatively little integration from 3rd-party frameworks (such as Struts, Wicket, and so on). On the other hand, such integration is always very simple to write with PicoContainer, which is not necessarily the case with every IoC container.
5. Error stack traces are OK, but sometimes very confusing; specifically, it's not always clear which dependency was missing when trying to instantiate a component.

Summary

If you want a small container and don't need many fancy features, or if you prefer to write such features yourself to gain maximum flexibility, PicoContainer fits the deal. In my mind, it's more of an IoC library than an IoC framework.

Guice

Guice is a relative newcomer in the IoC container arena. Its main claim of fame, despite what its adopters will tell you, is that it comes from Google. Also, unlike PicoContainer, it came out at a time where people started being annoyed at massive XML files, such as those that show up in many industrial Spring-based code bases.

It immediately grabbed the interest of many a-bloggers, showed up on dzone, yadda yadda. The question is, can you believe the hype?

Well, underneath the hype is actually a very nice IoC container that goes the extra mile to provide you with near-perfect error reporting, and that is not afraid to sacrifice purity to the altar of practicality. Guice supports, out of the box, all sorts of dependency injection scenarios, provided that you mark your dependencies with the @Inject annotation. From the theoretical point of view, this is more invasive than a run-of-the-mill IoC container, since classic IoC containers should, in theory, let you use plain objects without any special annotations. This, many argue, makes Guice much less flexible than Spring or PicoContainer.

In practice, I found that adding annotations makes sense in most cases. Externalizing all dependency-related informations sounds great in theory, but in practice, you'll end up with 80% of your services having only one sensible implementation. The services with more implementations have different-enough implementations in many cases that the POJO that receives it works well only with one of them (I estimate that about 10% of application services are like this). Guice's use of annotations to mark injectable resources and to let the target object control what resource gets injected to some degree is very practical.

The IoC container is pretty fast, and does some wicked ASM and cglib-fu to provide precise error reporting and the best possible speed regardless of the situation. Overall, it has an "advanced technology" feel to it. It shows a lot of polish in its package structure and in name selection.

However, Guice is a very "closed" system. Being advanced technology is nice, but it does make certain kinds of things a bit more difficult. Here is an example of such difficult things, and incidentally the reason we went with PicoContainer at work. Guice comes in a "uber jar" format; it bundles two versions of ASM (one for cglib, and a more recent version for itself; ASM is noted for major incompatibilities between minor versions, much to the annoyance of projects using it, and cglib appears to be evolving very slowly these days). Hibernate also uses a version of ASM, albeit an older one, as well as the same version of cglib as Guice. So, in an effort to trim the 550 KB or so JAR file to its bare minimum (remember, PicoContainer takes 110 KB...), I tried to get it to work with the older ASM version. The only part that didn't compile was some code used for error reporting, so I figured I could live without it. Well, I was wrong; the previous version of ASM crashes and burns during unit tests. I'm wary of dismissing obscure crashes to situations that will not happen in production code (even though the failing unit test looked like it was doing something exotic), so I left it at that, figuring I was better sticking with PicoContainer and bloating our applications as little as possible.

Some may dismiss this as a trivial reason to not use Guice, and in some ways it is. But it is something to be aware of. I know Hibernate, for one, has had all kinds of problems with use inside environments that come with a different version of ASM. So I'm a bit wary of such annoying dependencies, especially on ASM and cglib which are known troublemakers. Granted, the problem is a bug in ASM, but it does mean that Guice's use of ASM is exotic enough to trigger that bug.

Another problem with such a closed code base is that it's hard to extend it without releasing your own build of it. I'm not that keen with depending on an annotation that's inside the IoC container's package; I'd prefer depending on, say, the @Resource annotation that's standardized in a JSR (granted, it's not supposed to have exactly the same semantics, but my point is that I dislike putting hard dependencies at the POJO level). I understand the necessity of the annotation, and it's no worse, in my mind, than the transient or volatile keyword. Except in one way: it binds the code specifically to Guice, not just any IoC container. It would be nice if you could ask Guice to use another annotation type (this is noted as issue 70 in their issue database), but right now, you can't.

Pros

1. Still reasonably small
2. Very advanced, gives a peek of what libraries can look like if people would start to target Java 5 (see also Stripes)
3. High-tech, uses all kinds of tricks to maximize performance and give the best error reporting possible
4. More popular than PicoContainer at this point, is getting all sorts of frameworks integrated with it
5. The only IoC container I know of that allows post-instantiation injection of dependencies for non-constructor injected services. This is actually a great idea in some cases (such as deserialization)
6. Used in Struts 2. So it's going to end up being used by somebody visible, unlike PicoContainer :-)

Cons

1. Sometimes too advanced; that kind of trickery can hurt if you get bit by a bug (admittedly, there doesn't appear to be many of them)
2. Binding on a specific in-package annotation is annoying, I'm curious as to why there isn't a way to configure it?
3. Not an open architecture the way PicoContainer is. It's very easy to futz around with PicoContainer internals. Guice is much more selective with respect to what it lets you do or not do.
4. Java 5 only. Not that I care, but somebody might. Though, they did manage to make it work with Retrotranslator.

Summary

If you want a rich IoC container without the huge XML file tradition (yes, Spring folks, I know about JavaConfig, but it's still not what most people use), with sensible defaults and excellent error reporting, Guice fits the bill. However, if you want something with a hood that you can pop open at will, you may prefer another IoC container.

Plexus

I haven't played with Plexus a lot, so I can't really give too many details. My only experience was inside the Maven 2 codebase.

As far as IoC containers go, it looks OK (although it does suffer from the XML configuration file syndrome, the XML files are lighter than Spring 1.2 configurations [though not Spring 2.0 configurations], and you can use JavaDoc tags to autogenerate the XML file). However, I felt a bit annoyed at it overall. Error reporting, at least within the Maven environment, is not that great, even for simple mistakes like forgetting the appropriate JavaDoc tag or misspelling something. Plus, I can't really figure out where this project fits. It doesn't look like a project that's used by anybody except the Maven guys; why didn't they use PicoContainer to start with instead?

There are a lot of plexus components, but they don't tend to be that reliable, or their use within the Plexus infrastructure is not consistent. A good example is the password input component. Some Maven components use it, some use a plain text input component instead. It's not quite clear, when developing Plexus aware components or Mojos, which you're supposed to use for what.

A pet annoyance of mine: the Plexus guys want you to obtain the logging service through dependency injection. Although that sounds great in theory, I think it's nuts. Logging (at least, programmer logging) is purely a developer service. I'd even prefer not having to create a special object to start logging--if it could figure it out from the current stack with reasonable performance, it would be much better. So, if, to get logging, I need to create a field, a setter, and configure something in an XML file... I'm not going to use logging, or at least, I'll use Jakarta Commons Logging or SLF4J and just forget about Plexus logging.

So, all in all, it looks like an interesting project, but I don't really know why anybody would use it over Spring, or Guice, or even PicoContainer. I guess every developer likes to write an IoC container, because although it's not too hard, there are enough challenges and futzing around with reflection or byte code engineering to make it an interesting task.

Closing thoughts

So, there you have it, a quick round trip of some lesser-known containers. I also know of a few others:

• HiveMind/Tapestry-ioc, the container behind Tapestry. Well, this one looks powerful, but like Tapestry, it changes wildly between releases, and releases happen relatively frequently. From a pure technology point of view, it looks very powerful, as HLS does not mind looking for good ideas in other projects.
• Yan, a relatively unknown container that appears to allow injecting almost everything in almost anything. The author is one of the few who documented how to use his container in rich domain model. The Spring guys have allowed this only very recently, and it requires the use of the AOP sledgehammer to get it to work.
• And, of course, Spring, whose basic container is becoming more powerful with every release thanks to ideas from all those lesser-known projects, but which remains a huge project. Granted, you can use only parts of it, but it's not the standard usage.

I hope this (longish) post will be of some use to somebody.

Eclipse Europa Review

About this review

OK, so it looks like I can win a t-shirt doing an Eclipse Europa review, and it happens that I've been using it since M7 (the last release before RC0). So, even if I don't get a t-shirt, I'll post this, because I'm a nice guy and I want people to benefit from my living on the bleeding edge.

Before going on with the review, it would probably help readers to know what my Eclipse usage profile is. I use Eclipse mostly at work (http://www.alogient.com), where we build web applications and web sites. I'm currently doing a lot of work on a transactional Java application, using Maven 2 as the build system, Struts 1.2.9 (yes, I know, it's old... it's also stable and well-known), Hibernate 3.3.2 + patches, PicoContainer 1.2, Jakarta Commons Lang and Collections, and other miscellaneous libraries.

Given that, I won't use a lot of the new features touted by Europa (and specifically WTP 2.0), such as JPA and JSF support. JPA may get some use someday. JSF... nah. My only experience with JSF was extremely painful, so I don't really want to use it.

So, let's see the new features I'm likely to use in WTP:

1. Support for JSP tag files. We've started to use JSP tag files quite a bit, and I'm looking forward to better support for them.
2. Better HTML and JSP formatting when requesting a "format everything" (CTRL-SHIFT-F)
3. Better publishing performance.
4. Improved "maximize editor" behaviour.
5. Improved generics warnings.
6. Rename refactoring changes.
7. Ability to refactor without saving.
8. Class editor showing disassembled code.
9. Improved presentation of libraries in project explorer.

(In case you're wondering, I've had to recall this from the new and noteworth pages, because I've been working with Europa for long enough that I don't recall many specific enhancements)

First impressions

My first impressions once I boot the new Eclipse is that they've made it a bit faster, again. I can't really quantify this, but overall, the IDE feels snappier, especially when dealing with the WTP features. This is a great time saver in the regular look at web page/fix bug/publish/restart server cycle. More speed is always a good thing, especially since I run Eclipse on Linux/GTK+, which is usually slower than under Windows.

The workspace switching improvements are welcome, letting you switch between recently used workspaces without having to open the "Switch Workspace" dialog.

I initially imported my settings from a settings export of 3.2.2. This worked mostly OK, except for the XML syntax highlighting which, somehow, always loses my colors. This is very annoying, given that I like to use a dark background for code (OK, XML isn't really code, but it still gets a dark background). Even after importing my settings, the XML editor ends up having all content and CDATA sections in black-on-black. This kind of thing is commonplace in Eclipse and is generally annoying.

I took our main project (with its project files generated by Maven) and published it to Tomcat 5.5. It worked like a charm, and publish was significantly faster, especially the initial publishing operation.

From a stability point of view, M7 was so-so, but RC0 was pretty solid. I've yet to see it behave badly. It looks more stable than 3.2, especially the WTP features.

Refactor changes

One of the "big deals" with this release is the "inline" rename refactor. Essentially, you select the "rename" refactor (CTRL-ALT-R) and instead of getting the old rename dialog, you get to retype the new name and press enter; the rename is then applied. I've seen this feature in IntelliJ IDEA as well.

My experience with this feature is summarized as follows: I turned it off. There were two annoying things with it:

1. I often fire the refactor with the cursor in the middle of the identifier to rename. Eclipse doesn't pre-select the identifier, so typing the new name immediately doesn't overwrite the old name; instead, it inserts the new character at the position you were in. I assume some people like it that way, but I'm used to the old way of working, and to me, positioning the cursor prior to invoking the refactor interrupts my flow more than typing the new name. Note that I'm a fast typist, so this may make a difference.
2. After running the refactor, all editors "flicker" briefly, and I'm always worried that the refactor wasn't applied properly or something. I agree that this is largely psychological. But it's another reason for which I turned off the new feature.

So, your mileage may vary, but I think it this feature could get a little bit of polish. Maybe having an option to auto-select the renamed symbol so retyping would overwrite the old name. At least, from a "key feel" point of view, it would be more similar to the dialog, without having to lose the advantages of the in-editor rename (you see more context, it's less obstrusive, etc. etc. etc.)

The other big change I noticed in the refactoring support was the ability to refactor without saving files. This appeared to work well, and it's seamless enough that I'm not nervous about enabling it. The only thing that's slightly annoying is that when you build automatically and you do certain refactors with global impacts, Eclipse may flag a bunch of errors until you save your refactored file(s). This is probably due to the way the compiler works. But it's really not a big deal at all.

HTML and JSP improvements

The new HTML and JSP formatters are very much welcome. They do a much, much better job than the old ones, and I can actually (gasp!) use them to format blocks of JSP or HTML without fear. The old ones really mucked up our JSPs. The ones I've tried the formatter with use JSTL; I haven't tried it with scriptlet-heavy files, but hopefully, I don't have to work with those for some time. :-)

The JSP tag file support appears to work well. However, thanks to the use of an Appfuse-like taglib include at the beginning of every JSP file, it doesn't work in my everyday job, because the taglib declarations are stowed away in another JSP fragment. It looks like Eclipse doesn't see them in this case. I've resorted to copy-pasting the declarations temporarily while I work with the file so I can benefit from autocompletion. In that case, it works well.

Unfortunately, it doesn't work that well with custom tags sitting in custom JAR files that come from internal projects. I have that small library with JSP tags, which is included through a project dependency. I could never get autocomplete to work with those tags their TLD file is in the META-INF directory of the source tree). Oh, well.

The tag file support also works for editing the tag files themselves. This is not a big deal, but it does avoid a bunch of spurious warnings about unknown tags when working with those. If you use a lot of tag files, you'll be much happier with WTP 2.0 than with 1.5.

Additional polish

The new look when maximizing editors (with the package explorer, etc. minimized to the side) and the fact that minimizing the docked windows actually minimizes them (instead of turning them into a space-wasting horizontal bar) is a much overdue enhancement, and I'm very happy it's done. Also, the fact that maximizing the editor window does not close the secondary tab group is very welcome, since I tend to work with two tab groups, a habit I've kept from my old Emacs days.

The additonal diagnostics for generics are somewhat useful. They do catch a lot of strange corner cases in the generics specifications. Since we use generics rather heavily (and sometimes in exotic ways), I'm happy with this addition, but I think most developers won't notice.

The improved library presentation also fixes a small annoyance. I used to have to filter out all libraries from the project view to avoid having a huge set of crap in there. Especially for Maven-driven projects, which include every JAR in the world, this is an important feature.

Finally, the class disassembly is very nice, but unfortunately, with Maven's automatic source download feature, I don't use it anymore. Wish I'd had that a year ago...

The less good

This is supposed to be a balanced review, so I have to say something bad... bear with me.

The main annoyance with this release is that a lot of those new features have additional preferences, but those only overload the already busy preference panes. One more checkbox here, one more checkbox there, and you end up with a huge amount of checkboxes. The Eclipse preferences are comparatively messy compared to, say, Netbeans'. In all fairness, Netbeans' doesn't let you configure all that much unless you go to advanced mode, but maybe an advanced mode is what Eclipse needs. All I know is that it's starting to get really, really busy in there, despite the fact that some preference pages have very little on them (see General | Search, for instance). To me, it looks like the nature of the project (it's a plugin-driven platform) has unfortunate side effects when it comes to preference management.

The only other annoyance for me is that I was becoming spoiled rotten with the new features every minor release of Eclipse was bringing. This release does not bring much new stuff, especially from the basic IDE front. This is somewhat less true of WTP, but I'd still like to see more advanced IntelliJ features in WTP, like advanced refactoring support for CSS files. As such, Europa is a bit underwhelming. It seems like many of the features are "gadgets", and there isn't much new stuff. I'd like to see implementation of more refactorings, for instance.

Final throughts

Still, despite all this, it looks like a worthy release. The additional features in WTP are nice, and it's probable that the JSF developers out there will be even happier. And, despite my whining about the lack of "big" changes, the small things count quite a bit as well, such as the new maximized look and the increased performance.

Is it worth upgrading from Eclipse 3.2/WTP 1.5? Well, maybe. I guess it depends what features you're using. For me, it was worth it, if only for the increased performance. It will be worth it eventually anyhow. But for the average Java/JSP developer, I'm not sure there's a compelling reason to upgrade as soon as it's hot the press. For EJB or JSF developers, the picture is likely to be very different, but I admit that I don't use those technologies much anymore.

Still, Eclipse will remain my main IDE. As an aside, yes, I've tried Netbeans 6, but there's always something in the way it wants to work (usually with web projects) that don't match my way of working. Eclipse is very complex, but it's also very flexible, and I always manage to make it do what I want. That is why it remains my main IDE, and why I'll upgrade to Europa. Hey, what am I talking about! I'm already running it! :-)

Technical difficulties

It seems the old domain (bge.kernel-panic.net) does not work anymore, for reasons unknown (I don't host stuff there myself). I need to blog somewhere, so I moved the stuff to a generic blogspot address. Annoying, but sometimes, stuff like this happens. The new address (at least, temporarily) is http://bge-kernel-panic.blogspot.com. Sorry for the inconveniences. Have a nice day anyhow...