Aehso’s Output

Nokia have released the slightly overdue GPS Navigation Kit for the N800 (Internet Tablet).

A new toy for my new-ish toy, or high tech wireless Lego bricks as I like to think of them. Soon I’ll be blindly driving into rivers with the best of them…

A great clip for all the hardcore gamers out there (from Look Around You series two)

When you are done, you can even play Diarrhea Dan yourself.

Superb.

Dare Obasanjo has a Top Ten Signs Your Software Project is Doomed post in which he references some other great posts about The Schedule Chicken Game, Second System Syndrome and others pertinent issues.

Curiously, the word requirements doesn’t appear once in his list yet poorly defined requirements must be the most common reason why software projects fail. If you don’t have good requirements you can’t even get as far as most of these issues, or even use simple techniques like MoSCoW to avoid them.

On a related note, good to see How Projects Really Work continues to evolve, now at v2.0.

Frank Kieviet has two excellent posts that explain the dreaded “java.lang.OutOfMemoryError: PermGen space” error and more importantly how to use some new Java 6 tools to diagnose the source of the problem. The first post in particular highlights a very subtle issue with classloader/reference handling that anyone developing code for multiple-classloader environments needs to be aware of.

Alessandro Ribeiro also has an interesting three post piece where he shows how to use the JDK 1.5 ‘jps’ and ‘jstat’ tools to help diagnose the same problem (hint: “jstat -gcpermcapacity ” will give you a nice summary of the status of the VM with the target PID).

Users have been running into this when running Eclipse-based products on Sun’s JDK 1.5 for some time and Eclipse Bug 92250 has been quietly collating lots of feedback and suggestions from the Eclipse community along the way. A lot of people have been lurking/waiting/hoping that someone would identify the source(s) of the issue and produce a fix so it is good to see increased activity there. However, the recent debate about whether this is a Sun or Eclipse (where I found links to the above blog posts - thanks Karsten!) issue might be a little discouraging but it appears there is acknowledgement that some responsibility lies within the Eclipse community to help diagnose the problem.

I’d imagine many adapters would be willing to lend a hand in diagnosing this since it is a potential stability issue for all Eclipse based products when run on what is the de-facto Java VM. However, I suspect any such analysis effort would need to be done in coordination with some platform/WTP folks since they would need a good insight into the expected behaviour of all of the active bundles to be able to determine which are at fault (or if indeed the fault lies with the VM)

What intrigues me about this issue is that Eclipse/Equinox doesn’t normally destroy classloaders so classloaders not getting garbage collected can’t be the source of the problem. But with that assertion, how can any application be hitting a 512Mb permGen limit? It does smell of a VM bug but then why doesn’t it happen with other Java based applications? Clearly some feature common to many Eclipse applications is rubbing the Sun VM up the wrong way.

I guess the only way to find out is to do a very deep analysis but a pre-requisite for that is to find a simple use case that can reliably and repeatedly reproduce the problem. We don’t seem to have one with our product but perhaps someone else out there does.