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.

No doubt someone will counter with the fact that thousands of people use Spring and all is well. Yes, thousands of people also used EJB2, oddly enough the very same places that switched to Spring. What are the chances of all these venues suddenly becoming full of wise intelligent developers who from now on will only make sensible sane well considered decisions?

That problem makes it somewhat understandable that the Spring guys, in order to defend their fucked up theassness, deride annotations and proclaim that declarative xml goop is Rod’s Holy Word. Go forth and write xml, Rod proclaims, and the unwashed masses go forth and positively ooze angular brackets. Stupid fucks. Still, all is not lost, in cases where it’s possible to shoehorn annotations into Spring’s archaic innards, they’ll enthusiastically proclaim it Useful and Recommended, such as the @Transactional annotation.

The other common argument is ‘you don’t spend too much time in Spring’s xml compared to time spent in your code’. Sure, I also didn’t spend much time writing ejb2 descriptors either (xdoclet did it), yet everyone bitches about those. Why can’t we apply the same standards to Spring?

Fundamentally, Spring has a tough time accepting that the world has moved on, and that its approaches are starting to look a wee bit outdated. Even EE 5 in many cases looks more modern and usable than some of its approaches. Thanks to its widespread use, they can, much like the JBoss people, maintain an insular world view where they’re surrounded by sycophants who do nothing but bend over with a shiteating grin plastered over their sallow filthy faces.

Your configuration bean bullshit still doesn’t cut it, dependencies are best expressed where they belong, in the damn source code itself.

The fact that XML is, basically, a steaming pile of goatshit is not news. Many many people know this now, yet you have an awful number of people eager to grab a hold of some xml and perform deviant sexual activities in it, around it, and in between its elements.

The problem is that there are some good ideas out there that happen to use xml. Even though xml has nothing to do with the quality of the idea, xml somehow gets credit.

This has become quite apparent lately when participating in some Guice vs Spring debates. The fact of the matter is, Spring’s XML sucks unbelievable amounts of ass. Don’t buy the bullshit hype of Spring 2.0 improving its XML so it’s now all great. All it’s done is made it plausible that one might not jab oneself in the eye with a big black ribbed for his pleasure dildo when confronted with it. I cannot believe that a sane person would think that the Spring 1.x syntax is fit to deposit a big dogturd on, let alone use in any application you’d care to be associated with.

You either have to autowire (which is convenient but too magical as your project grows, not to mention fragile), or explicitly wire stuff in xml, miles away from the source code. Lets not even get started on how abysmal performance is once you’re using a real project with more than 3 beans, or heaven forbid, wiring up actions at runtime. You could play many a game of soggy biscuit while Spring figures out who needs what, when, and why.

Of course, the situation is conveniently disguised by the fact that tools such as IDEA natively grok Spring’s hellish configuration.

Atlassian has captured the hearts and eyes of developers everywhere. The one corner of the market they have not been able to penetrate so far is the minds of these developers.

The new strategy will pose a challenge for the young company, shifting the emphasis from pretty pictures to usefulness is a move fraught with danger, and some analysis are not optimistic. Joel of FogzBugz fame proclaimed ‘Atlassian is doomed to failure, how can any company that doesn’t spend time writing an ASP to PHP compiler to achieve platform independence ever get anywhere? FogzBugz has always focussed on functionality, our 3 customers are more than happy’.

Jiramike, one of the founders of Atlassian, discussed the change in strategy. ‘We’re sick and tired of being the pretty dumb blonde in Java,’ he sighed dramatically.

‘It’s time we move past the cutesy rounded corner and cartoonish icons, we’re a serious company now and I think the joke’s up, customers are demanding a new kind of application. Whereas before all we had to do is slap on a pastel hue and a Verdana font, this market now requires that we develop functionality and serve a business purposes.’

Not all is well with this new strategy however. Some developers at Atlassian have rebelled against this move, and have resigned in protest. A member of this rogue group recently proclaimed ‘I just want to fuck around with ruby now and then and read ajaxian and put in all that stuff, why tf are we switching from our core strengths?’

Atlassian customers however are cautiously optimistic. The open source side is obviously elated, and the codehaus core team was rumoured to be dancing naked in the streets, rubbing genitalia with strangers, in an odd departure from the standard practice of doing ‘comfort grouprubs’ as a consolation prize for either another useless project joins, or a useful project graduating to relevance by moving elsewhere.

It’s a J2ME talk for one, and for another, it’s not really about technology, code, or some guy flapping about helplessly at his IDE while we all patiently wait for something vaguely noteworthy to happen.

Still, personal feelings aside, he’s a rather good speaker, certainly compared to the competition so far. The talk is in fact also awfully interesting, since it deals with higher level issues surrounding J2ME.

Eugene covers all the pitfalls in the mobile Java ecosystem. These are often not technical, but political, or the result of various parties all eager to protect their turfs. I’m not an ME guy, so the talk was a bit of an eye opener onto that world. The ME world seems awfully full of NDAs, secretive partner deals, zealous API protectionist mentalities, and often trying to screw everyone both up and downstream of your slot in the stack in the aim of forcing the users to become coupled to your slice of the pie (whether it be OS, api, vendor, app vendor, retailer, etc).

There’s also an interesting discussion of a commercial application’s lifecycle, and how vendors and partners interact (with detrimental results) with various milestones of the process.

An interesting description of people’s interaction with mobile devices is to recognise and work with the fact that users exhibit ’snacking behaviour’, in terms of their expectations, demands, and usage. Applications that follow these principles are far more likely to succeed and result in happy user noises.

All in all, a pretty decent talk, where I learnt that dealing with ME is an awful pain in areas that like being painfree.

The one thing you can say about the intarweb that we’ve all come to know and love is that it’s full of some very very bizarre people. Said people will more often than not manifest their deepest dirtiest wishes in the form of midget sex, goatse collages, lemonparty, horses doing unspeakable things to a variety of human orifices, and the shiny white boots of tubgirl. The content in itself isn’t necessarily that disturbing; more disturbing is those who find such material personal fetishfodder.

Of all these fetishes though, none are as freaky as our dear old Ceki’s logging obsession. We’re coming up to the 10th year anniversary of his initial logging spasm, and the little rumpranger shows no sign of tedium nor flagging of unmentionables.

Most people think that the freak just sharted out log4j and saw his creation, and pronounced that it was good. Most people are also exceptionally stupid, ignorant and naive, which perhaps explains the earlier perception.

So what is slf4j? Well, it’s a….facade for other logging systems! It’s a replacement for clogging! Now here’s the clever bit, instead of all that magical dynamic discovery mumbo jumbo, the binding from slf4j to a concrete implemention is done at….compile time! Want to switch logging implementations? Simple, recompile your app!

Of course, having written a logging api, the next natural step is to write a logging api api. slf4j of course does nothing by itself. Instead it has two implementations, nlog4j and SimpleLogger. By now, even the most hardened logging chozgobblers are likely suffering from serious shrinkage.

It’s amazing that after all these years, there are still some people who think that time and effort should be invested in more implementations of the same tired old ideas. Is this guy at all in touch with what goes on in the real world? Exactly how many cloggings does the world need anyway? Why oh why oh why do we need wrappers around logging libraries? Has anyone, ever, in the entire history of java, and in all the millions of projects out there, ever, ever switched a logging implementation, and thought ‘using clogging was such a good idea after all!’

HTMLUnit, for those who are unaware, is basically a piddly little framework that lets you create web requests, and parses back the resultant html/javascript and lets you click on things programatically to simulate actual users.

Thankfully, the name is a total misnomer. For one thing, it’s not about unit testing at all. Therefore, has nothing to do with JUnit. It wisely avoids the spastic route taken by things like xmlunit, which provides classes tightly coupled to JUnit.

The premise is a pretty decent one, it’s the implementation, as usual, which makes the baby jesus cry hot tears of rage and anger while biting off the nearest nipple.

First problem, I see maven crud splattered all over. My heart sinks as I see the 3 tongued kisses of death; maven.xml, project.xml, and project.properties. This cannot possibly go well. Amazingly, there’s a build.xml there too, so I might be spared. I’m not hopeful mind you.

To cut a long story short, the file is a herring sporting a horrific red hue. Making this thing work would require an impressive collection of miracles from all major religions.

So we’re onto maven. Running maven, of course, is always a great excuse for a day out, maybe catch a movie or two, and a nice dinner, while it figures out what day it is, what it should do about it, and how to calculate the worst and slowest way of running a few thousand tests.

Eventually, a feeble jar is farted out. Plopping said jar in my tests reveals a rather dismal result. Cookies no longer work across invocations.

Ohdear. Nevermind, I’m a java guy, I can debug this sort of thing. Armed with nothing more than an abiding hatred for java developers and a trusty debugger, I sally forth into the brackish waters that are the htmlunit source code.

Hrm, here we go. At some point, one of these gurus of incompetence decides that we should internally store a map of HttpClients, keyed by host url. Thusly can clients be reused and state preserved across invocations, for a given site.

Said guru however didn’t actually bother fix the thing that gets stuff out of said map. So while the key is now host + port, the blocks that attempts to retrieve things from the map does not include the port. These days, every url has a port, thusly, much wailing and gnashing of teeth ensues.

Apparently, this problem has trickled down to other lost souls who use htmlunit cvs, such as the canoo people, who also have the odd user bleating about cookies being ignored.

So after a few days of pointlessly scrolling around, I find the culprit. It’s at this point that I completely lose it and start laughing hysterically. I can’t quite believe the test I’m looking at.

It’s sad and pitiful that things like this happen. It’s even sadder and even more traumatising that it’s not that rare, and is even more common than not. The collaborative effort of so much incompetence should not happen, it should be a freak accident that only happens very rarely, instead of daily, over and over again.

IE6 did have a lot of oddities and require hacks, and I really think Microsoft is right in fixing the bugs even if it means some hacking sites will break.

I know everyone likes backwards compatability, but every once in a while, something has to be overhauled. If IE7 can be repaired to the point where IE7 code will work essentially the same on FireFox, and vice verca, than fantastic. This is a long term solution.

I’m with Microsoft on breaking some compatability. I’d rather have a platform where I don’t have to hack in the future than have IE continue to be so very odd.

Also, something that’s a bit off topic, about spyware.

Will it be possible for system administrators to set a stricter policy on browser plugin\addon installation? Currently at my office I put FireFox on the systems, and because FireFox downloads plugins from a closed network, users don’t stumble on websites that automatically install malicious-but-obnoxiously-legal spyware “addons” and “toolbars” and “plugins”. The vast majority of users don’t understand these things, and the warning message IE pops up is just gibberish. They ignore it and agree to install. If I could put a restriction on that, nontrivial to override, I’d be happy as a clam.