DownloadTube

What do I find? Well, the console output (standard size console), is 73 pages long. Of those 73, 61 are stacktraces (it’s hard to tell, but it’s one exception that’s nested about 12 times). Nice to see they’re still letting the same old inbred halfwits code. Of the remaining 12 pages, I’m given some very crucial information about startup, stuff that will hugely aid debugging and my usage of said server, I’m sure.

I mean, who wouldn’t want to know a 800 character IOR corba unique identifier (or two)? Surely the fact that the patch URL is ‘null’ is of vital importance! Don’t even get me started on those bastards who think that ‘Initialized REST’ is a useless bit of info. Why, we should all refuse to use those cryptic servers who don’t tell us all these vital things we must know in order to use J2EE!

Anyway, in the time it took me to write this, server is now up. The shameless little runt even admits to taking 2m:31s:305ms just to start up, clean, without a single application deployment (by me anyway).

Let’s try shutdown….Not as bad now. A mere page and a half of output, and about 10 seconds. Why a server has to take 10 seconds to shut down when it doesn’t have anything deployed yet is a mystery best left unsolved.

There are some silver linings though. For one thing, JBoss 4.0 should serve as a great motivator for the Geronimo folks. It sets such a low bar that their goal actually seems attainable (as long as they avoid going after commercial vendors, who will wipe the floor with them). It’s also an excellent advert for BEA, IBM, and pretty much all the other players in the field. People who start with JBoss will learn to appreciate professional products so much more (alright, well maybe not websphere, but anything else).

For anyone having high expectations of JBoss 4.0, time to put them away. It’s the same old shit, just 9 times the size, half the speed (well, twice the slowness, to be accurate), 3 times the incompetence, and an order of magnitude more hype. Calling this ‘professional’ open source can only be a very very sick joke, or the most filthy example of doublespeak yet this year.

Still, to their credit, the jboss fucktards have realised one vital fact: it’s pointless to spend money on development or developers if you’re stick with a truly rotten team at the core, and much more useful for the ‘business’ if it were all poured into marketing, where the art of conning people is far far easier to perfect than with boring old code.

If by some freak accident of nature you’ve managed to last this long, it’s ready to finally ‘find bugs’. Here we have more unwelcome anal intrusions in the form of a modal progress dialog. The progress dialog will happily write things to the UI console, except that because it’s modal, you have no way of actually looking at all the things it’s whining about. Of course, the warnings are deliciously verbose too, with every line beginning with a full timestamp and the fully qualified class name of the internal handler that reported the issue. I am utterly baffled by this classname fetish that opensores projects have. What exactly do you people get from showing your classnames to your end users? Is it some kind of freakish penis waggling maneuver? A bizarre mating ritual? Emotional issues resulting from being beaten and molested as a child?

Of course, the modal progress dialog has a cancel button, and if you press it you get….another modal dialog, asking you to confirm. Now I’m no grizzled UI veteran, but in all my years of using computers, I have yet to find an OS with such a bizarre paradigm. Real innovation here guys, a modal dialog with one button, that confirms with another modal dialog when you press said button.

The default settings are also of highly dubious quality. Every time you return a Date field for example will cause findbugs to throw a hissy fit. Ignoring results from reading streams (something which is often perfectly legitimate) is also whineworthy.

Of course, should you wish to change these detectors, your eyes will be stabbed yet again with this unfathomable UI. You’re presented with a JTable where the detector fully qualified class names are listed, along with ’speed’ and ‘enabled’ columns. Of course, since it’s open source, nobody knows how to actually use a JTable, so the columns are all the exact same size. This results in every single class name being truncated, for your maximum viewing pleasure.

What is it with open sores projects and usability? I am baffled by all the energy and effort expended by any open sores project with a UI to avoid usability and principles of good design at all costs.

Maybe it’s a subconscious effort to emulate linux. Just as children will adopt the bad habits of their parents, java open source fuckwits will emulate the linux approach to UI; a disgusting soup of every possible ingredient ever conceived by man or nature coupled with a sickening obsession with every ugly default possible.

Today’s vomit lands on a tool that seems to be gaining some popularity; FindBugs.

In addition to the open source curse, FindBugs is unfortunate enough to have been conceived as an academic project. Those facts combined have meant the kiss of death for this poor little app.

Where does one start? Well, lets first create a project. Here’s the first mystery. You have 3 areas, one of which contains ‘archives or directories’, the second of which contains source directories, and the third is for classpath. Now, I’ve only been doing java for about 8 years, so I might not be familiar with all the lingo, but how on earth is a ‘archive or directory’ different from ‘classpath’? Of course, there are no hints or tooltips as to what should go in these areas.

If you haven’t yet deleted this miserable little app and fired off an angry email to its hapless developers by now, you’ll notice the second bit of mindless cruelty they’ve chosen to inflict on the poor sap attempting to use it. While the file chooser allows for multiple files to be selected, the app itself will merrily ignore these and simply pick the last one you chose. I suppose that’s one way to discourage people from having lots of dependencies.

As a result of the JBoss expose here and elsewhere, various trade rags have picked up the story. It made it onto slashdot. The comments there of course are equally hilarious and depressing. Amazing how many people fail to grasp the difference between an anonymous post and a fake persona post. Still, that’s to be expected from a bunch of spotty gentoo tuggers anyway.

Not to be outdone, JDJ had to jump in the fray. Needless to say, I strongly approve of their article. I’m hopelessly biased against JBoss so that couldn’t possibly surprise anyone. Cameron buying me so many drinks has also clearly affected my judgement, but oh well.

However, the real fun starts if one were to look at what else is going on at JDJ now. On the one hand we have a sane sensible article about happy community building and a mild waggle of the finger in the general direction of JBoss, and on the other hand we have….immature BEA bashing.

This farce started a couple of days ago, when JDJ ran an article about BEA ‘firing’ sys-con and electing to go with another publisher for an ‘official’ Weblogic magazine. BEA pointed out that sys-con’s Weblogic magazine is unaffiliated with them and suchlike and so forth.

At this point, it’s pretty clear that various head honchos at sys-con all simultaneously soiled their panties and suffered a fairly embarrassing bout of serious backdoor leakage. What follows is an amateur campaign of insults that would be quite newsworthy if it wasn’t trumped so thoroughly by those JBoss tards.

JDJ is now merrily in the process of running at least one or two disparaging BEA articles a day. These articles are hilarious. It’s like watching a three year old spastic child shaking his fists and expressing his anger by leaking from all orifices. Pretty it is not.

Another example is method ordering. There is currently a need for TNG to (internally) choose a different invocation order for the total set of test methods, but the design as it stands currently makes this change very difficult and tricky. Thus, another bad design!

On the other hand, there are plenty of other well designed areas which have been reused in some fairly unexpected ways, all of which points to decent design.

TDD for example has an interesting approach to design. It assumes, up front, that you can’t design your way out of a wet paper bag. You write tests that ensure the system does exactly what it’s supposed to do, nothing more and nothing less. You want to change things? You do it the brute force way by stomping all over your codebase and endlessly refactoring, it’s a lot more work but, in theory, any thoughtwanker can do it. Of course the downfall of THAT approach is that some portions of TDD STILL end up requiring someone intelligent, so you’re back to square one of needing someone smart, instead of swappable sweatshop bodyparts.

Yet at the end of the day, a depressing majority of java codebases look like a 3 year old had sat down in front of a large bucket of design patterns and plucked a fistful and hurled them in the general direction of some code. Proving that the tooling approach can, at best, only help the mediocre claw their way up to the average.

There are a ton of developers who can write a mean algorithm. They can identify a problem and manage to digest the salient points with enough success to plop out an implementation that does exactly what it says on the tin.

Interesting enough though, this has sweet FA to do with design. Yes, the piece of software performs its function beautifully, efficiently, and one could argue, elegantly. That says absolutely nothing about its design.

Java, specifically, goes a long way towards ramming down a set of design principles. Said principles are followed fairly blindly by most practitioners. The OSS world is awash with examples of people who have read the right books, but have absolutely no skill or talent at conceptualising or grokking the underlying principles behind the books. To them, the design pattern is an end goal, not a tool. To pick one example (out of thousands), look at Matt Raible’s OSS efforts. It has inheritance! It uses PATTERNS! It is LIGHTWEIGHT! Yet, I’d argue that it’s very badly designed (if you don’t believe me, just try getting it to do anything other than the very very basics.)

So what’s the acid test for a good design? I have no idea. The closest I could come up with is A good design allows your code to do things you never expected it to have to do. It’s not about ‘oh I’ll add an interface here so I can plop in different implementations’ when there’s no sane reason you’d ever need more than one implementation, for example. Having made that assertion though, I’d imagine it’s pretty clear by now that I have no solution or fix. If you’re into that sort of thing, you can try befriending a fowlerbot, working your way to the top, then perhaps running your genitalia over his beard in the hope of getting some use out of the smug bigoted little fucker.

hanks to everyone who sent in their own examples of pain and horror of bad code. As the saying goes, when you laugh, the world laughs with you. When you cry, inflict your pain on the world so it cries with you. Inspired by all that bad code, I feel that not enough attention is being paid to that other evil-that-can-barely-be-named, bad javadocs.

Every time I see javadocs unmodified from their generated-by-an-IDE form, I feel like grabbing a blunt object and repeatedly stabbing the author in the face until there is nothing left but a bloody pulp. There are few things as offensive as 5-6 lines of absolutely NO new information.

For example, people who like to have such gems as @param myvar. What on earth does that tell us? That the method takes in a parameter named ‘myvar’? Isn’t that blatantly obvious from the method signature? How does this merit all this extra wasted space? Alongside this horror, there is the despicable @return aString taunting us with its unhelpfulness. The same applies to throws docs listing just the name of the exception.

If you want to provide javadocs, great. Anyone using your API will be thrilled and will think good happy thoughts about you. However, I cannot stress enough how satanic it is to provide the illusion of javadocs by having nothing there but skeleton javadocs that suck up valuable precious vertical space. Vertical space in this world, a world horribly skewed in favour of rectangular monitors, is a rare commodity. Lets not squander it so casually.

Another sin regularly committed (although admittedly, one that isn’t as horrific) is ignorance of line breaks and how the standard javadoc doclet handles them. Where you put your full stop (or period, if you’re American) is relevant and important. It isn’t something subject to whimsy or time of the month, there’s a logical approach to it that isn’t horribly complicated. The first sentence gives a brief idea of what you’re talking about. If you have more to say, it goes in the next line and starts off with a new sentence. Think carefully about the first sentence, you don’t want to be like POI, which has the description for the org.apache.poi.hssf.dev package saying a succinct (and wonderfully unhelpful) ‘DEV package serves two purposes’ in the top level index, now do you?

Using any application of size, it’s almost inevitable that you’ll be slapped in the face time and time again with a bevy of NullPointerExceptions.

It’s hard to come up with a reasonable explanation of why these exceptions are so prevalent and commonplace. In fact, I have yet to come across a single application server that has never barfed out an NPE at some point or another.

Granted, in most cases it is the fault of the user; providing less than stellar input. J2EE descriptors are rather easy to get wrong, for example. You’d think though that a company that is able to muster up the resources to build a J2EE stack would be able to expend the fairly minimal amount of extra effort it takes to assume that users will pass in bad info, and handle it in a civilised and sociable manner.

JBoss (sorry, couldn’t resist) is a good example of that incredibly half-assed piss-poor lackadaisical approach. Very often, you get an NPE deep inside of JBoss code. The NPE is often repeated 3-4 times, wrapped inside of 2 or 3 other NPE’s. Sometimes you’re lucky and you actually get a helpful message that subtly hints of a vague area to begin sniffing around. Sometimes it’s particularly cruel and reports the wrong component entirely as the culprit, thus leading you on a wild goose chase familiar to those poor bastards trying to find decent documentation for any open source stuff.

Sadly, this particular ailment isn’t restricted to JBoss. JRun will also barf out endless reams of NPE’s if you so much as sneeze in its general direction. They also are of the ‘lets nest exceptions, it’s very helpful to end users’ school of thought that Weblogic now belongs to as well. Luckily, both of these servers will tend to hide that one crucial line of information describing the error you need in that behemoth of a trace. So if you do read it carefully, you might actually see it.

It really isn’t a very hard concept. Always expect bad input. If it can be entered into your code, then someone somewhere will enter it. Null checks are trivial and buy you a lot of love if they report clearly and coherently what is null, and why that’s bad. Don’t nest it, don’t obscure it, fail fast and helpfully.

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 evening I decided to spend some quality time in my local Barnes and Noble. Usually I stick to the history/current affairs/sociology sections, but today, I ventured further afield into the Java section. I thought maybe I’d learn a thing or two, see what kind of nonsense people are writing about, maybe have a giggle or two at the ludicrous things that people deem book worthy. The most common ’specialised’ book tends to be about Swing. Somehow though, they all assume that the reader is completely new to the subject. No matter what level the book advertises itself as, half the book is always wasted going over the standard Swing components. It’s as if the reader is assumed to be without access to a JDK/javadocs at all, and thus utterly unable to find this stuff anywhere.

Looking onwards, it turns out that this is a rather recurring theme. Almost every single book has, to some degree or another, huge tracts of information that can be gleaned from the most trivial online search/javadoc perusal. Some of the Struts books particularly excel in this space filler technique; often consuming up to 100 pages explaining the statelessness of http, the mystical nature of request/response protocols, and how useful forwards and redirects are, with the obligatory blurb about MVC this and MVC that. Perhaps they all secretly acknowledge that the average Struts developer is a bit less, well, developed than most people, and thus needs a little bit more hand holding. I suppose that does make them well aimed at their target audience, to be fair.

The EJB books also provide much hilarity. I was particularly tickled by a book advertising itself to be all about EJB 2.1. I naively thought to myself ‘Great! Something that’ll explain all the cool new things in a reasonable detail, perhaps even provide good critical analysis’. No such luck. The ‘2.1′ portion of the title turned out to be mostly a marketing gimmick. The OR/QL chapters all were wisely marked with a ‘2.0/2.1′ heading, with little to no 2.1 specific content. There was a little blurb in the back about Timers and web services, but it seemed to be grudgingly tacked on to avoid being sued, rather than any genuine interest in 2.1. Worried that they might alienate the huge swathes of EJB 1.1 developers (a crowd best left to slowly die the painful miserable death they deserve, foolish fashion victims that they are), the book also wisely includes much 1.1 material.

The one book I was actually looking out for was Bitter EJB. I’m vaguely mulling posting an EJB rant, and so wondered if it had anything I should take into consideration before spouting off. Sadly it was conspicious by its absence.

So I’m left wondering, are there any worthwhile Java books out there aimed at developers well versed in the (seemingly black) art of spec/javadoc reading?