The BileBlog

JGraph, for those of you who don’t know, is an opensource swing component to handle all things graphy. It’s a component you can slap in as you would any old regular swing widget. It will draw pretty pictures, let you drag them around, and generally indulges you as you make a nuisance of yourself.

JGraph though has a number of fairly horrific flaws. First of all, it’s impossible to build. Now, I’ve seen my fair share of badly written ant build files. I’ve seen build files that force you to define environment variables. I’ve seen build files that require defecating all over your ANT_HOME/lib dir, I’ve even seen build files that don’t check for directories before they try to output stuff into them. What I have not seen is a build file that plain refuses to do anything useful. First, the build.xml is not in the top level dir, it’s in a directory called….script. This directory also has a motley crew of bat and sh files. (one each for ant, compile, doc, make, and port!). The documentation, needless to say, goes out of its way to avoid giving any hints as to how this lovely component can be built. Just to spice things up a bit, there’s a TransferHandler.java file sitting there in the script dir. No matter how I run ant, no matter what directory I run it from, and no matter what env vars I specify, I cannot achieve build nirvana. The best I can do is get the build file to feebly create some directories then fail to populate them with anything meaningful.

Thankfully, it’s possible to download a reasonably recent release. Sadly though, the build hurdle was a sign of things to come, rather than a freak accident.

JGraph allows you to pretty much do anything with graphs, and a lot of things you shouldn’t do with them. Unfortunately it suffers from trying to be far too clever. For example, by default it has a hugely annoying set of key bindings that I’d bet most graphs do not require or even support. Things like cloning, grouping and suchlike. The approach in general seems to be ‘enable everything and force to the user to disable it’, with the cutesy opensource approach of never actually specifying how to disable stuff. Another oddity is that the documentation goes to some length to explain the distinction between graphs and trees (and how the latter is a subset of the former), yet JGraph itself often tries to uncomfortably shoehorn itself into some of the craziness that goes on in javax.swing.tree.

Then there’s the design issue. JGraph brags of being very much in the Swing mold. Amazing, it’s managed to outswing Swing. Not only do you have fullblown MVC (which swing does NOT have), but there’s also an extra layer of ‘views’. For anyone who has done a lot of swing work and tried to be strictly MVC, you’re probably twitching in discomfort now at the thought of having to deal with such a horrible design. It just doesn’t work. There’s no way of enforcing the contracts, and you end up with a big mess of classes where things are kinda-controller-kinda-model-kinda-view-kinda-somethingelse (varying degrees of each). Graph insertion can be done in so many ways that invariably, the model is modified by the view, the model modifies the controller, and there’s you crying like a little girl being drowned in a tub of congealing spaghetti.

Setting all that aside, there are also some foolish implementation choices. For example, there is an Edge.Routing interface (yes, it’s an inner interface, joyjoy). This interface gives you a list of points, and you’re free to define your own router and modify these points. The advantage of allowing this is that you can handle vertices that join onto themselves, or defining 90 degree angle lines between vertices. The problem with this though is that edges are often NOT just a list of points, and can well be curves of some sort or another. The current implementation, from what I can tell, makes it impossible to have a custom routing algorithm that does loops for self-references.

While it provides for huge flexibility, there are many points where the design was simply not thought out very carefully, and you end up having to contort yourself into all sorts of unseemly positions just to get it to look vaguely like what you had in mind.

Having said all that, JGraph really isn’t all that bad. I just wish it focused more on its core competencies and followed the ‘less is more’ principle, while having a rich set of class/libraries/sample code that handle all that extra gunk.

This entry was posted on Tuesday, October 28th, 2003 at 11:51 am and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.