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...

Odds and ends

I saw a couple of interesting things on TV today. First, there was this report of protest over the Gentilly 2 nuclear reactor renovations¹. As you may already have guessed from my not-entirely-green opinions, I think those protests make no sense. Building a new nuclear reactor may be questionable (and then again, maybe not--nuclear waste is a huge problem, but so is the greenhouse effect, and at least the former can be found and contained with relatively primitive facilities). But Gentilly 2 has been built, and we can either get rid of it now (and thus make this costly endeavour more costly), or fix it, run it for 20 more years, and amortize the cost of getting rid of it over a longer period. Yes, Hydro Quebec is building a wind power park; that's not nearly done, and in the meantime, we're stuck importing electricity from coal-fired US electric plants. Turning off Gentilly 2 would make it worse.

On a related note, if the protesters are also those against new hydro dams, I have to wonder how they thing we'll build the windmills they are so in love with. Answer: lots of petroleum, and a bit of hydro to power the facilities while they're assembling the stuff. We'll be lucky if we can maximize the use of hydro power. The fact is, as things stand right now, it's extremely inconvenient to carry electrical power, so we're very much slave to oil when it comes to building stuff using heavy equipment. The energy density of windmills is much lower than a dam's, so I wouldn't be surprised at all if the amount of oil used to up the wind power capacity is larger than that used to build one of the humongous hydro dams that make our pride in this province. The main reason for building windmills is when hydro dams have all been built and the demand still rises.

Yeah, demand could go down too, but it's a bit late to think about this--too many buildings built with poor insulation, too many joules wasted for no good reason except to save a few pennies in construction cost, etc. We'll just have to regulate for better energy efficiency and hope we'll stamp out those obsolete energy wasters sooner rather than later. By the way, I agree with ecologists that both the provincial and federal government are really being idiots about this. I'll excuse the provincial government somewhat because it has no money, but for the federal government, this is unacceptable. They're sitting on a multi-billion dollar surplus, and instead of lowering taxes or attempting to conform to the Kyoto protocol they're so proud of having ratified, they're just pissing off the provinces trying for a political land grab. The tragedy is really the lack of alternatives; the Liberal Party really needs a kick in the <somewhere> to wake them out of their arrogance. If they don't want to lower taxes, the least they could do is gain political favor by showing leadership on the energy front, instead of duplicating provincial programs.

But I guess that while Canada still makes a lot of money off tar sands, there's little incentive to do anything like that. Why not do both, export all the tar sands, let other countries foot the Kyoto fine, and laugh all the way to the bank? Oh, wait, the US is our main buyer and haven't ratified the protocol. Damn it.

---

And before your friendly neighborhood defender of the A-25 bridge (which, by the way, does not look like it's going to happen--we'll get a "urban boulevard" on Notre-Dame street instead, and I'd rant about this, too, except I'm so disgusted I can't find the energy) is written off as a quack because he's inconsistent, I'll let you all know that I've been biking up a storm lately. I've also been buying local fruit and vegetable as much as I could, which is less than I'd like because growing season is too short here. I'll also let you know that my CO₂ emmissions are 1.64 tonnes per year, according to the Climate Change site (which, I guess, is the only tangible thing the federal government has done about Kyoto...). Provincial average is 3.7. I can't go much lower than that if I want to survive winter, either; taking all their suggestions would lower only to 1.4 tonnes per year, mostly by recycling. There is no recycling in this building, because of some lame-ass municipal bylaw, and that's the part that hurts the most.

I find it ironic that the calculator admonishes me for not lowering my emissions by a whole ton, when one ton is 66% of my CO₂ emissions. There's not an awful lot more I can do, either; I barely use the car anymore, not using the A/C and dishwasher would save something like 75 kg of CO₂ per year, and I can't compost because I have no yard (condo life, you know--I'm sure I'm saving more emissions by having to heat less).

---

On the biking subject, I'm starting to get serious about it. I bought some new bags for the rear rack (the old one was cheap crap and its zippers broke; the new one uses a pull rope, which is a much smarter system, and it's made in Quebec to boot), a small rear-view mirror for my helmet (looks silly, but still a good idea), and biking shorts. The latter were expensive, but well worth it. I feel like maybe I'll have children someday after a long ride, which is something I wasn't too sure about when I rode with regular shorts. My perineum would feel numb after 25 K or so, 30 K if I was riding on nice, well-maintained pavement (which doesn't really exist in Montreal, I'm sad to say).

Let me tell you about my latest bouts of crazyness.

Two weeks ago, a very good friend (who is now my official biking partner) and I took the south trail. I joined her around St-Michel and Jarry East, we went to Christophe Colomb, all the way down to the Old Port, right to Pont de la Concorde, down to Jean Drapeau park, got lost (laughing most of the time) in Jean Drapeau park, decided not to go to the south shore given we had done the Ile Notre-Dame trail twice, went back up the Champlain Bridge Estacade, through the Lachine Canal trail, then back home after nearly dying on the Berri climb. The Berri climb, by the way, is much worse than I had expected. Halfway up, you feel great. Then the wind blows you nearly back down the hill, and the second part, while shorter, is steeper. You do the whole think in first gear, believe me, especially if you've just done 35 K. Total, about 45-50 K.

Last week, we took the north trail, joined by her brother and sister-in-law. Christophe Colomb to Gouin, west all the way to the Bois-de-Liesse park, then on Pierrefond Boulevard all the way past St-Charles to the next park. Then back the way we came. Much less strenuous, but much longer. The trails that way are extremely nice (though with a not-too-nice view on the Hydro Québec high-voltage power lines), and except for a rather disagreeable stint on Boulevard Pierrefond where there's a one-block stretch without a trail (I swear! This is the silliest thing I've seen in bicycle trails, but it's true!), very enjoyable. Total, 80 K for me. Odd thing was, I felt tired, but I didn't feel cramped up the following day. Admittedly, we took it easy. It's still 80 K, and still impressive. I dislike doing that much distance in a car!

Today, went solo to the east, my friend being out of province on vacation. They have this new trail next to the De Montigny stream, going through the Marie-Victorin college grounds and the Rivière des Prairies hospital. Going to the trail is a pain, though. Up an industrial street, hoping to see it connect. Didn't. Had to cross Henri-Bourassa, a rather busy and wide boulevard. Luckily, this was labour day, so it was rather calm. But you can picture me running like an idiot next to my bike because there was no ramp to go on the sidewalk on the other side of the street. Next time I'll cross elsewhere (Renaude-Lapointe, maybe), but it's still likely to be not much fun. Anyhow, I then lost the trail on Maurice Duplessis, I think I turned left instead of right because I found its end on Boulevard Léger. Traffic is light despite the very wide roads there, though, so not a problem. Then on the East Gouin trail, which was overall nice. Then the Pointe-de-l'Île park, which was a bit swampish, but overall OK and mostly free of pesky insects anyhow. Then down to Pointe-aux-Trembles, which alternated between nice trails and so-so trails next to the railroad (lots of brush in the way there; it seems like they're not really maintained). Then a disgusting segment on the sidewalk in Montréal Est. This part alone makes me wary of doing that trail again; the air was full of petrochemical and solvent smells, and I wonder whether it cancelled any health benefit I got from the ride. Then a surprisingly nice part in Promenade Bellerive, which made me forget about the ugly part from before. Then another disgusiting part in Hochelaga, where I stopped at the local Tim Horton's to get a sandwich. Then a part not worthy of being called a trail on Notre-Dame street; it's so incredibly bumpy and badly maintained that I would've been better off going up l'Assomption to Hochelaga and brave the annoying traffic. Then got lost and missed Viau, ended up on Pie-IX, turned on Ontario to join Pie-IX, up the hill (walking) of the Olympic park (it's short, but it felt like 30% grade), one lap of the Maisonneuve park, then back home through Boulevard Rosemont and Beaubien.

I have no idea of the total mileage; probably around 50 K. But I rode at maximum speed for much of it and stopped only three times (once at the park, once at the Tim Horton's at Notre-Dame/Dickson, once before entering the Maisonneuve park because the hills had taken a lot out of me). I expect to be somewhat stiff tomorrow. Overall, I liked the trip, but the part through Montréal-Est really sucked. I'm likely to go to the Promenade Bellerive in the future to kill a few hours, though; it was a really, really nice place, and not nearly as busy as Parc Maisonneuve; also, going over the A-40 east is less stressful than going over it at Viau, because there's less traffic and the lanes are wider. But I'm not sure I'll do the whole east-end-of-the-island trip again, mostly because of the poor state of the Notre-Dame trail. From a pollution point of view, though, the Champlain Bridge part is probably similar, because you're travelling under the busiest highways of the area. Though, I guess being under means a lot of lighter particulates don't enter your lungs. Still, the west Gouin trail was much nicer, though it is less interesting, in the sense that the east part fools you into thinking you're in the middle of the countryside, then throws you in dense residential areas intermixed with industrial complexes.

So, remember that heading "I must be crazy?" Well, my sanity isn't improving. I suppose my health must be, though. I hope I can do some cross-country skiing this winter, otherwise it's going to be really boring waiting for next spring.

---

If you want a decent bike shop in the East End, I'd recommend André Lalonde Sport, on Métropolitain East, a bit east of Langelier (though you have to do some creative acrobatics to get there if you're eastbound on A-40). It's pretty close to my home, and they were having a summer sale, with many things 50% off. That's where I got the shorts and stuff. The bikes there look like they're good quality; maybe I'll get one of the hybrids there at the end of next summer. The Schwinn is somewhat capricious (the rear brakes tend to become loose) and heavy; it's perfect to ride to the metro and for the trip to the grocery store because it's unlikely to be stolen, but for long distances, the gear ratios are far from ideal and the fat tires and weight are really dragging me down. But maybe I'll decide it's good enough by next year. Let's say the improved comfort of the biking short have really improved my appreciation of the Schwinn, now that I don't feel like my bee-hind will fall off every time I'm unable to avoid a pothole.

In any case, it's good to have a decent bike shop close by, given that Canadian Tire is a really poor bike shop, Sport Expert is expensive, and smaller bike shops are somewhat far from my place.

---

1. Gentilly 2 is the only nuclear reactor in the province of Québec. It's largely criticized, but IIRC, it has had a trouble-free life.