Firefox/CruiseControl Extension

I’ve been having some issues with my installation of Firefox for a while now (notably Javascript-based hyperlinks not working properly), so I decided to download the latest trunk version of Deer Park (Firefox 1.1), which is in alpha at the moment.

It’s early days for Deer Park, but from what I’ve seen so far, it will be excellent. It’s noticeably faster at starting up than Firefox is, for starters. And it now has built-in SVG support, which is a very useful addition – hopefully we can start publishing UML diagrams directly from our modeling tools as SVG straight onto a Wiki someday soon. For now, though, the SVG support still has a few flaws – it can’t seem to handle compressed SVG files, and it still only supports a subset of SVG 1.1. The JavaScript engine looks like it has been beefed up considerably as well. One of the most noticeable enhancements is the addition of native XML handling, via ECMAScript for XML. Oh, and I’ve also been using the Outlook 2003 Silver theme, which is very cool.

One small plugin I found recently (and which I had been idly wondering if one existed a couple of days beforehand) is the CruiseControl Firefox extension. This is a nifty little extension that queries a CruiseControl installation and displays the build status of your projects in the Firefox status bar. Quite neat – and a very small plugin (only about 5K, including images). The only problem is that it (like most other CC-related applications that I have seen) is just a simple screen-scraper that retrieves the build results page and parses the HTML, extracting the status and last build time of each project in the status list. We have customized our CruiseControl installation so much that it can’t find what it is looking for in the returned page anymore. So I decided to take a quick look at the plugin itself and try to fix it. It turned out to be much easier than I thought.

Writing a Firefox extension is actually very simple, and the CruiseControl extension is the perfect starting point if you want to learn how an extension is put together. I just downloaded the extension, unzipped the .XPI (which is just a zip file), and created a 10-line Ant build script to build the extension. The extension’s logic is contained in one single JavaScript file, and the quirky Mozilla XPCOM model is easy enough once you get used to it. For instance, here is how to log to the JavaScript console:

function ccLog(aMessage) {
if (isCcDebug()) {
var consoleService = Components.classes[';1'].getService(Components.interfaces.nsIConsoleService);
consoleService.logStringMessage("ccMonitor: "+aMessage);

Notice the naming syntax for the Mozilla interfaces.

This begs the obvious question – why doesnt CC have a Web Services API where you can query this kind of information programmatically? Firefox itself has a stable and mature Web Services API, and it would make writing these kind of applications a piece of cake.


Javadoc bug in JDK 5.0

Came across a surprising bug in JDK 5.0. today. “Surprising” because it’s so easy to reproduce, and the use case would seem to be pretty common. If you run javadoc over a codebase that uses custom annotations, and the annotation classes themselves are not in the runtime classpath, javadoc will throw ClassCastExceptions and consequently fail to generate the indexed contents correctly. In my case, the annotation classes are the Hibernate annotations, and javadoc complains about not being able to find the EJB3 javax.persistence classes in the classpath, along with the Hibernate classes. This is normally no problem, but if your annotation classes themselves are unavailable in the classpath, then javadoc will throw lots of exceptions.

The actual output looks like:

[javadoc] Standard Doclet version 1.5.0_03
[javadoc] Building tree for all the packages and classes…
[javadoc] java.lang.ClassCastException:
[javadoc] at
[javadoc] at

The culprit seems to be the annotationType() method from AnnotationDescImpl. If we look at that, we get:

* Returns the annotation type of this annotation.
public AnnotationTypeDoc annotationType() {
ClassSymbol atsym = (ClassSymbol)annotation.type.tsym;
return (AnnotationTypeDoc)env.getClassDoc(atsym);

The offending line is (AnnotationTypeDoc)env.getClassDoc(atsym). The getClassDoc() method looks like:

* Return the ClassDoc (or a subtype) of this class symbol.
ClassDocImpl getClassDoc(ClassSymbol clazz) {
ClassDocImpl result = classMap.get(clazz);
if (result != null) return result;
if (isAnnotationType(clazz)) {
result = new AnnotationTypeDocImpl(this, clazz);
} else {
result = new ClassDocImpl(this, clazz);
classMap.put(clazz, result);
return result;

I have a feeling that the error may be due to Annotation types not being processed correctly when they are not in the classpath, and consequently not being initialized as ClassDoc instances. The easy fix/workaround is to pass the runtime classpath to the javadoc task.

Strangely enough, a very similar bug was posted and fixed for 1.4.


Visual C# Very Slick

I must confess, I’ve always been a fan of Microsoft’s IDEs for developers. One thing you have to give the Redmondians credit for is that they realized at a very early stage that healthy developer support was the key to maintaining interest and support of their products in the marketplace. To that end, they released more APIs, SDKs, and IDEs than you could shake a large stick at, and some of them were even quite good. The Visual Studio family of tools, for instance, was a mixed bag, but it had a couple of gems. Alongside the tragic Visual Interdev, the utterly terrible Visual SourceSafe, and the vomit-inducing Visual Basic, there were some slick and useful applications. One of these was ( and is ) Visual C++, which easily wiped the floor with any other C++ IDE, even in Borland’s heyday. This product has matured and improved with age – I recently gave a quick test drive to the Visual C++ 2005 beta whilst fixing a bug in some legacy code, and I was impressed.

Another very nice addition to the Visual Studio family was unfortunately short-lived. Way back when, MS introduced a product called Visual J++. This was their first (and last) step into the Java IDE market. The language was Java, but being Microsoft, it wasn’t 100% “pure” Java – it had some custom extensions that made it very useful in a Windows-only environment. Chief among these was J/Direct, which basically was a mechanism that inserted proprietary bytecode into generated .class files, relying on the extensible bytecode mechanism written into the JVM specification by Sun. This turned out to be really powerful, and a godsend for us (at the time) Windows programmers. It allowed you to declare and invoke native function calls in a similar manner to how VB did, and all the parameter and datatype marshalling was done under the hood. The entire Windows API was at your beck and call, and all for very little effort. A set of wrapper classes for common chunks of the Win32 API was supplied, and was called WFC (Windows Foundation Classes). I remember giving a presentation at a Java conference in San Jose back in 1998 on this stuff, and the Java guys who managed to get over their disgust at me presenting on a MS-specific topic were amazed at what it could do. There were two other great attributes to this package as well – it had a very nice event model (called delegation, which you can find in Visual C#), and a drag-and-drop visual form editor, good examples of which were relatively rare in the Java world at the time. So you got the elegance of the Java syntax, with the ease of GUI construction that at the time only existed in VB.

Unfortunately, it couldn’t last. MS and Sun fell out, and took their mutual dislike to the courts. Visual J++ gradually become sidelined, and then an MS technology evangelist told me at a conference that J++ was quietly being dropped, and a replacement was being mooted (at the time, it was codenamed “Cool”).

Which brings us back to 2005, and Visual C#. What you get when you work with Visual C# is the direct descendent of Visual J++. The same guy (Anders Hejlsberg) has lead the development stream for both J++ and C#, and he has fused a lot of the original ideas of J++ with many (many) more directly from Java. And it’s really, really good. I’m actually going to try and earmark a piece of work that I know will be Win desktop-specific and I’m going to do it using Visual C# 2005. It took me no time at all to knock up a desktop client for CruiseControl, and I was rather pleased with the result.

Of course, there are limitations – portability being the obvious one. But I do think it’s wise to have as many tools at your disposal as you have individual problem areas to attack (also a famous theory in economics). And I think Visual C# will be able to solve quite a few problems for me in the future.