The BileBlog

When it comes to naming conventions, the core JDK has its fair share of ludicrously chosen names. While there isn’t a horrifically large number of these, what is there is bad enough to make up for the lack of quantity in an impressive lack of quality.

One of the offenders is that Thread class. I give you…isInterrupted, and interrupted. Intuitively enough, one version of this method clears the interrupted status, the other does not. Probably more familiar is the ubiquitous System.arraycopy. Would it have killed them to uppercase the C?

Lest you think that these naming heresies are restricted to method names, we have the entirety of java.logging. What next, java.xmling? java.utiling? javax.webbing? There is also the wonderful java.nio. It isn’t non-blocking IO (based on the contents of the package), so the other alternative is the ridiculos ‘new IO’. What happens in 3 years time when the even newer IO shows up? java.enio? How about in 5 years when the novelty has worn off and there’s nothing new about the ‘new IO’?

However, the JDK’s errors aren’t so bad in the grand scheme of things. The crimes committed by other developers are far far worse. Worst of all are the C rejects, with their underscore fetish. MS morons bring in their own style of idiocy, with an insatiable lust for Hungarian Notation. Seeing mStrObj is likely to result in violent spasms for even the most battle hardened amongst us. No less evil is m_thefield, or p_myfield. Use a civilised IDE if you’re so obsessed about distinguishing fields from variables, you dinosaur.

Finally, for all you CORBA tards, I is ALSO unacceptable. Nobody cares, just use sane names without the ludicrous prefix to denote interfaces and we might consider letting you back into civilised society.

It never ceases to amaze me how many people seem to just not ‘get’ the java naming conventions. I used to think it’s a matter of common sense and a simple logical process, turns out there’s art involved too. Who knew!

It’s surprising how many J2EE application servers go out of their way to be impure java. For the uninitiated, java has a perfectly functional launch model. You can specify all your classpath dependencies via a manifest file, and all your environment variables on the command line (of course, being a considerate developer, you make sure your app runs with sensible defaults if no env vars are specified). All you have to do is double click on a jar file (if you’re a windows weenie or enlightened OSXer), or run it with java -jar myapp.jar (if you’re a linux zealot, solaris diehard, enlightened OSXer, or anything else vaguely unixy).

Yet, despite this wonderful system (which does have its flaws, admittedly), most application servers go out of their way to make the process more complicated, less intuitive, more cumbersome, and generally as uncivilised as possible.

For example, Weblogic comes with a bevy of cmd and sh files. They all gleefully call one another, and have much hardcoding in them to explicitly disallow anything other than their official platforms to run. Amusingly enough, a few minutes of hacking away at these evil monstrosities and you’re able to get Weblogic running wonderfully on OSX, even if BEA recently proclaimed to me that they have no plans whatsoever to offer any sort of anything that is vaguely usable on OSX. The strange part is that the ONLY requirement is to make some of those idiotic cmd and sh files a bit more generic and usable, and suddenly, you have a developer preview edition of Weblogic on OSX.

Next up is JRun. This little appserver, written in pure java, has the most bizarre startup system of them all. I realise it’s quite functional and works nicely, but they try so hard to avoid using anything vaguely standard that it’s actually impossible to get their product to run on a platform they don’t officially support. They compile native binary launchers that presumably do very little beyond look for a JVM, specify a startup directory and JRun configuration. Still, at least after constant pestering they provide an OSX version.

As for Websphere, O Websphere…you evil monster. The pain, the horror, the sheer weight of a Websphere install is enough to make the baby Jesus cry hot tears of frustration. Yet again, a breathtaking array of launcher files (all platform specific). They win extra points for having most of their tools runtime.exec() their own launcher files, thus wisely ensuring that life is as difficult and unwieldy as possible for anyone wanting to fix that mess. Needless to say, Websphere is so tied to specific platforms that the server won’t even start up without invoking native code.

Tomcat also deserves an honourary mention, for pretending that it’s possible to have object oriented shell scripting, and splitting off functions into a number of scripts. Again, going out of its way to be un-userfriendly and unwieldy. Of course, this doesn’t matter much to tomcat users as Jakarta could feed them a fistful of steaming turds and they’d run off and write rave reviews about how innovative the flavour is.

As much as it pains me though, I have to give credit to JBoss. They seem to ‘get it’ as far as launching is concerned, and provide a nice jar file you can run. The only shame is that that is the high point of JBoss, and everything that happens after that initial launch is less impressive. Orion likewise manages to provide a simple and wonderfully effective launch mechanism.

I realise that in some cases, native code is needed. I also realise that in order to appease the marketing windows gods, you need to provide a .exe launcher. Please please don’t crap on the rest of us who don’t fill their underpants at the sight of a terminal though.

Generally, it’s a pretty bad idea to bite the hand that feeds. Alas, I can hold my silence no more. I’m tired of having to wait endless hours to read my own damn blog. I’m tired of people sending me emails telling me that my blog is down, or that they can’t read comments, or that the layout is broken.

For all you people, I’m not the kind of person who gets off on tinkering endlessly with my blog so that I get to feel clever and geeky. In fact, I have no clue how it works. I just picked a style, and enter in my rants on a nice big textarea.

Now, since Roller is so rubbish, I thought it’s worth spending a few seconds investigating why this is. Firstly, it seems that hibernate is to blame. Not because hibernate is rubbish (calm down Gavin), but because Dave Johnson, in his infinite wisdom, thought that he could create hibernate sessions willy-nilly, all the time, for every little thing. Rather overzealous, really.

Now, this isn’t such a crime. After all, almost everyone has at some point committed some crime that slaughtered performance and made you laugh sheepishly and turn a glowing shade of purple as your shame is discovered by someone else. It happens, no big deal. However, in the real world, these things happen during that elusive phase known as stress testing. For those of you unfamiliar with this concept (a surprising majority), I’ll give you a brief explanation. It involves simulating a load of users onto your wonderful little app. There are a myriad of tools desperate to help you accomplish this task, ranging in price and functionality from PureLoad and Mercury’s LoadRunner, to Microsoft’s web testing tool and even shitty little JMeter. There’s no shame in using said tools. You might think you’re too macho to not know intuitively what scales and what doesn’t. However, it’s better to lose a little face up front and swallow the indignity of using a tool to help you out, than to be publicly flogged after your system is in a production environment.

Back to Roller. Admittedly, all I’ve done is spent a few minutes looking at the code. I’m armed with an interesting tidbit, which is that it was originally written as a sample ‘real world’ J2EE app. With apps like this, it’s hardly surprising that J2EE gets such a bad rep. If anything, the roller code is a superb example of how NOT to write a J2EE app.

For example, there is persistence code for Castor, Hibernate, and Prevayler. when will Castor users just give up and stop their Midas-like touch of shite from infecting everything? Why bother trying to shoehorn such disparate persistence engine in? Is the need to gain validation from a bunch of geeks that strong?

The taglibs also provide their own contribution to the crapfest. Wonderful examples of html-in-code. Plenty of css styles hardcoded in. Still, at least the jsp pages are code-free eh?

As if that wasn’t enough, insult is added to injury by slapping Struts onto the whole pile. Good luck trawling through the tens of *Form and *FormEx classes and managing to ever get anything done.

Yes, it’s free. Yes, I use it and am glad for the service. However, neither of those is a reason to paint a rosy picture of its status or dubious claim to fame. Popular it may be, but I hereby relegate the roller code to the Jakarta school of coding. How appropriate it is that freeroller runs on Tomcat!

Oh, big thanks to Aeden for showing me how to make comments show up in a popup. It now takes a mere 3-4 tries to get to see comments, down from the 20-30 it used to.

Despite my ranting and raving, it looks like the just4log guy is a glutton for punishment. He’s gone and released a new version. The killer feature now is the ability to add log statements to entry and exit points of every method. Needless to say you need to preprocess your class files through an ant task to gain this amazing functionality. I mean really, if you’re going to butcher bytecode for such nefarious purposes, you should at least try and be vaguely fashionable and use some AOP. The ‘hello world’ of almost every AOP system out there involves logging.

Jason also demonstrates once again his sledgehammer approach to life. Find a tool you like and harpoon every problem you come across with said tool. Ignore geometry of said problem’s pegs, and its relation to said tool’s shape and size. Take a deep breath Jason, I’m about to turn your brain inside out. I can use EJB’s, and I can also think that inheritance is a good thing. However, and here’s the truly zen aspect of it all, that does NOT imply that I use EJB’s with inheritance. Each has its place. You yourself just posted that remote, distributed, scalable architectures are not some kind of holy grail to be pursued at all costs. Most people I suspect rarely write anything more challenging than an intranet app with, if you’re really lucky, about 100 users. So for those kinds of projects, bragging that your app will scale to thousands of users is entertaining, but rather pointless as it’s a claim that’ll never be challenged by real life.

Finally, for those who didn’t ‘get’ it, I am in fact an op on #java, and I thoroughly recommend those of you who are prone to getting upset easily and crying every few minutes to stop in there, we’ll show you how to develop a thicker skin in no time. The rest of you can stop in too, since it’s a lot more fun than doing any real work.

Another recent trend in new projects these days is a profusion of jars. Now, reusability is a good thing, but on the other hand, I’m surprised by how eager developers are to chain themselves to external libraries often written by hobbyists in their spare time.

Unfortunately, tools like maven just make this problem so much worse. Some lunatics had this idea that your dependencies become manageable and controlled once you slap on something like maven. In fact, all maven does is let you live in this fantasy lalaland where you get to pretend your dependency problems have magically been poofed away by a little jakarta fairy.

Case in point (sorry Mike) is JIRA. Lovely tool, works nicely and so on and so forth. However, if you dare, have a peek in the WEB-INF/lib directory. There are nothing less than THIRTY SIX jar files in there. This is more jar files than most appservers require (even if you include spec API jar files like servlet.jar and friends). JBoss of course is a notable exception, which has more jars than Marc Fleury has crayons.

Some of these dependencies have no place being there at all. For example, why is ejb.jar in WEB-INF/lib? How about mockobjects that are only used during testing? bsf AND bsh? A veritable cornucopia of *-DEV.jars, signifying a cvs version pulled in at some point in the past (not hint of when, naturally).

It is this slaphappy ‘oh I need one class that performs this handy util functionality…I know! I’ll bring in the whole jar and everything will be great!’ attitude that is responsible for this jar infestation.

Here is a radical suggestion, THINK about your dependencies. Imagine having to track whatever project you’ve just tied your code to. Imagine having to follow up with releases, bugfixes, changes, and suchlike. Imagine having to test compatibility with every release. Imagine writing all those testcases.

Wouldn’t it be an awful lot easier if you were to just write that piece of functionality, or grab that one class without bringing on all those extra pains?

Give it a shot, pretend it’s fashionable (you read it in a blog, so just blindly follow like you tend to do anyway). Your users will be happier, they’ll get that warm fuzzy feeling of ‘wow, this project’s developers lovingly handcraft their product, they don’t use a sledgehammer for everything they come across during their day’.

So, you’ve heard of irc, you’ve heard of that most chaotic network of all, efnet. You think a #java channel on there might just be the right blend of craziness and tomfoolery for you, and decide to take the plunge and join.

Maybe you have a question, maybe you want to meet likeminded people, maybe you’re living in your mother’s basement and have no life to speak of, but need to feel some sort of validation from other similarly unlucky losers.

Whatever the reason, you’ll need to be armed with a few simple rules in order to survive this dog eat dog new world you’re entering.

Oh how I shudder when I see that awful enhancement. Alas, it’s far too easy and alluring to succumb to this terrible infestation. You can barely move these days for all the bsh-1.2b7.jar files strewn about so carelessly and haphazardly.

What is so evil about beanshell, I hear the stupider readers inquire. Well, let me tell you. In very very few cases, it’s a perfectly legitimate API. It makes for a great teaching tool, and can be handy dandy for debugging and suchlike. However, as a core feature, it’s rubbish.

If you want a scripting language, then don’t use Java. Simple. if you enjoy severe lack of type safety and more dynamic binding that you can shake a stick at, don’t use Java. If you want to allow your users to inject random bits of code that do not adhere to any sort of contract in ways that man and God did not intend, then please, please, go take up Python and stop depositing your smelly turds over our language.

The problem is, those selfsame people who will allow you to embed beanshell scripts in xml files are those who will squeal like stuck pigs when confronted with a jsp scriptlet. Now I ask you, what is the difference? It’s a trick question, because there is NO DIFFERENCE. In both cases, you’re embedding code in a script. Believe it or not, the arguments for and against either technique are identical. You’re sacrificing compile time safety, you’re adding ugliness, mixing concerns. You’re gaining ease of development, lack of contracts, and ability to go crazy.

So, admit it. If you’re advocating beanshell, then you automatically lose all rights to bitch against code in jsp pages. Just because it’s an xml file does not mean its inherently superior or cooler, despite what 2001 told you.

It seems that java.net now has a poetry corner, of all things. I’d like to know how on earth this can be deemed relevant, interesting, insightful, curious, or even mildly titillating. Come on! Granted there’s a severe drought when it comes to worthwhile blogs. Credit where credit is due, java.net at least manages to on the whole present a level of professionalism and quality that javablogs can maybe dream of one day. it’s a testament as to why offering power to the masses is just about the stupidest thing to happen to the internet.

So come on java.net blogs, don’t be fooled by all those people who claim that javablogs is far superior. Don’t try to descend into that same pop content. Keep the jealous peons out, censor them, delete their posts, flog them for incoherent ramblings. Above all, for the love of god, don’t let them start posting their incredibly bad poetry and/or personal angst.

What is it with people always wanting so share their terrible writing anyway? Whether it be poems, psychobabble, or stream of conscience nonsense, the end result is always the same. The reader feels mildly embarrassed and uncomfortable reading such trite hackneyed scribbles. It’s the same feeling you’d get if just went to Les Bernardin here in NYC with someone who kept chewing loudly with their mouth wide open, gawping at everyone like some slack-jawed country bumpkin.

As an aside, freeroller seems to have decided to function again, much to the amazement of everyone. I wonder if we’ll ever find out what was broken and how it was fixed. I’m sure it’s a temporary glitch anyway and it’ll be back to its old habits any minute now. Tomcat IS a production worthy server you know. Honest.

So the long awaited JSR is finally open to the public at large to ogle and dissect. Relative to other JSR’s, this one isn’t nearly as bad as it could have been. Admittedly, it’s hard to match the abysmal quality of some of those.

This is not to say it’s without its faults. For one thing, why on earth is there no instance/lifecycle management? Maybe I’m misreading things, but they seem to have adopted the servlet spec’s approach a bit too greedily. For example, lets say you found a great new portlet that allows you to view your email. Now, the people writing that portlet decide that 1 portlet == 1 mail account. You, on the other hand, are cursed with having to check 2 email accounts. The spec however will force you to deploy it twice in portlets.xml, even though the only difference is configuration data, per person. To allow for this, you would also have to use ridiculous generic names in the descriptor, like ‘Mail 1′ and ‘Mail 2′. I desperately hope I’m wrong on this one, but I see no mention whatsoever of instance management. Of course what will end up happening is that all vendors will add that feature in their own special way, rather than following a nice easy spec.

Secondly, there is no concept of scoped preferences. A preference is either global, or per user. if you foolishly want to have preferences apply to…oh I dunno…say all users that have certain permissions (or any other arbitrary custom named scope), hard luck. Off you go to peruse vendor extensions.

Of course, there’s also the unhealthy obsession with enumerations. Wouldn’t want to upset all those idiot servlet vendors and force them into the 21st century where the Collection API is both commonplace and usable by even the most retarded of developers. Heaven forbid that anyone using portlets might mistake them for not being…well..servlets.

On the plus side, portal behaviour is completely unspecified. Vendors therefore can do all sorts of crazy wacky things, thus leaving plenty of room to differentiate featuresets.

Finally, why oh why does the spec not include a list of changes against the last draft? Some of us poor bastards went ahead and implemented it, and instead of being able to peruse a list of changes and update my implementation accordingly, I’m forced to trawl through the whole tedious spec and update my test cases. Come on spec authors, if the entire j2ee spec can manage out a release history, surely you IBM/Apache buffoons can too.

Ohyeah, Jetspeed is also rubbish. What a hilarious implementation that’ll turn out to be.

First of all, kudos to Alan Green for at least posting a literate rewriting of his initial ‘Too Many EJBs’ spewage. The rewrite is a lot more coherent, and makes a number of reasonable points as well as being wrong in other places. Overall the content is no longer offensively ignorant.

Kudos also to Bob McWhirter of the Werken Company, who took my bashing of his poor workflow API in stride, and even had the honesty to agree with it. What a nice guy.

There were some bad apples though. Carlos Perez vomits up his usual pompous, pretentious, tedious, and conceited tripe. This time in the form of EJB bashing. A number of people have already responded, pointing out how wrong he is. Yes Carlos, the spec doesn’t mandate a lot of things, but many appservers provide these features as standard. Yes Carlos, there are other tools that have always done this, the point is that in J2EE, it’s a SPECIFICATION. This means that in theory, you can write code and have a good chance of having it run on another vendor’s product (no, it won’t be effortless, yes, you will have to write custom descriptors and spend some time and effort testing/checking it). Will you next mock JMS because it also is not innovative for you? After all, MQSeries and Tibco have existed for as long as you’ve been alive almost. I wouldn’t be surprised if poor Carlos is unemployed. Anyone who takes themselves so seriously and writes so tritely must be hellish to work with.

Finally, the dumbest quote of the week was by none other than Jason Carreira, who gleefully proclaimed ‘Inheritance is expensive and often painful. Avoid it unless it’s necessary‘ in a comment to my entry advocating compile time safety. I realise I’m pasting without context, but the comment sounds so hilarious and makes him look so foolish that it’s hard not to burst out laughing at the follies of man.

J2EE on the whole is a rather good thing. For the first time, there is a standard covering this kind of stuff. A lovely unified umbrella on how to write applications that are not tied to any particular vendor. Arguably, there has been some measure of success in this. It is possible (after a few bucketloads of blood, sweat, and tears) to come up with an .ear file that deploys on a bunch of appservers.

Now, there is an overall componentisation aspect to J2EE. The idea being that one builds apps out of a number of components. These components are, on a higher level, things like ejb modules, client modules, and web modules. Drilling down, we have ejb components within an ejb module, servlets/filters/pages within a web module, and whatever you want in a client module. All good and well, there’s no fundamental flaw with that approach.

In practice though, it all goes rather pear shaped. Given this component architecture, it’d be quite reasonable to expect to plug in components in to j2ee apps. So, I am baffled by how difficult it is to do so. Picture the following scenario. You use app X, which comes from some vendor. They supply you with an ear. Now, you want to deploy another webapp within that ear. To do so, you have to modify application.xml. If they send you an upgraded ear, your changes are swatted away. The same problem happens if you want to add any sort of extra module locally, or in fact, any component at all. Want to add an extra filter? Sorry, you’ll have to constantly deal with merging new versions in.

Even the potential for doing this kind of thing was removed from the J2EE 1.4 spec. I really don’t understand the logic behind deliberately crippling a component architecture this way.

Of course, much of the blame lies on the expert groups too. They generally consist of a bunch of complete morons who get off on pimping their own implementation (the ‘I wrote a servlet/jsp book so I should ge to inflict my academic childish implementation onto the rest of the world’ brigade). The formal spec process is nothing more than an official marketing channel for their own featureset and/or incompetencies. Almost every single JSR at some point has something along the lines of ‘well it’s too hard for us to implement that, so lets not put it in the spec’ spewing out of some vendor or the other. End users be damned, it’s all about making these specs trivial to implement for any monkey (witness Tomcat, local entities, filters applied once per request, etc). Many of these things came about through vendors whining sufficiently about their own stupid code.

The whole idea of separating the deployer and assembler concerns is a good one, Sun should have just carried the idea forward a bit more and considered the use case of ear/module-as-deliverable more thoroughly.

A few months ago, there was some talk of adding werkflow current functionality and mode of operation to osworkflow. This did not happen since a bunch of us objected and felt that the extra dependency really doesn’t gain us much beyond coolness factor and a dependency list the size of maven’s. Since then, looks like those ideas found a happy home in werkflow.

The amazing thing is that there is a company actually funding this silliness. Zenplex must be either eager to be gouged and drained of all blood on the cutting edge, or living in 1999 where anyone with a silly idea could get funding.

So what is so ludicrous about werkflow? For a start, have a look at the dependency list. 18 components. I kid you not. Of these 18, 4 are of version SNAPSHOT, and another 4 are development versions. These jars look suspiciously like all the xml based crap that maven so gleefully pioneered. Wake up folks, xml-as-code is dead, move on. Your friends might still laugh at you for not using xml to drive everything, and stubbornly writing old fashioned code that’s maintainable and legible. However, rest assured that you’re the one wearing underpants, while they are the ones with diapers. You are sufficiently potty trained to determine (all by yourself!) when it is time to slip down said underpants and carefully aim resultant product. Your xml obsessed friends on the other hand live in a world where they excrete everything into their diapers, without a care in the world. They delight in releasing all they have to offer willy-nilly. After all, what’s a little baggage compared to the delight of not having to find an appropriate receptacle or location?

Sure, it’s fun to poo everywhere. The poor bastard who has to clean up after you though is probably less enamoured of the idea.

Still, werkflow is such a successful project and so innovative I’m sure it must be doing well. The website however does its best to dispel that reality, by insisting that the last update was on March 7th. Not only that, but there are also no official builds, and nightly builds have been suspended as of March as they ramp up with using maven. I guess that’s a legitimate excuse, getting up and running with maven does take months of blood, sweat, and tears.

In fact, such is the hatred that werkflow people feel for anything javalike, that they allow you to specify your expression in a bizarre choice of languages, all of which are about as native to java developers as COBOL is to shepherds. If I were a Python buff for instance, I’d delight in being able to specify Python expression. Oh wait, the whole API is JAVA, not Python. Someone clearly got hopelessly confused somewhere along the way.

The website itself is the usual pile of auto-generated worthless drivel. A whole bunch of links about the source code, its metrics, who did what, test reports, development twaddle, and general maven masturbatory material.

Of course, being a potential end user, you might go to the FAQ to figure out how to use this crap, or at least get started. Instead you’re informed of the following:

Almost any reasonable project will have some kind of web presence. Usually you will find an explanation of the project, some kind of overview, and then a drill down view that allows both novice and power users to find the information they need.

POI on the other hand has one of those special sites that sometimes seems to be the unfortunate result of a group masturbatory session for its developers.

The frontpage is useful enough. It tells you where to find news, the point of POI, what it does, and the various formats it supports. All good and well. Now, having read this page, the curious user might be excused for wondering ’so, how do I read an excel file, given that this page here says I can do so?’

This curious user would be rather unlucky though, as clicking through to the HSSF (excel) page managed to make a bunch of paragraphs which don’t really say anything, and when they do, it’s invariably ‘bugger off and go use coccoon’. You have to closely examine the left nav to find links that explain that POI can actually be used, rather than cocoon. The HOWTO page is then one big long blurb (no anchors, of course) which, to be fair, does explain how to do stuff. Shame it’s so annoying to navigate.

Part of the problem, well, the main culprit, is the bizarre behaviour of the left navigation. It goes against all sensible human computer interaction guidelines by changing quite dramatically based on what component you’re looking on. Thus, it isn’t nodes that expand when you drill down, but a whole new navigation set.

Of course, no self-respecting modern day open source project is worth its salt without endless statistics about how many unit tests are currently passing, code coverage reports, bizarre dependency metrics that nobody can understand, and suchlike. These are provided aplenty under the ‘Code’ navigation section. I’m baffled as to how this information is useful for anyone other than POI developers. Do I care how many unit tests pass? If I do, I’d be the kind of person who gets the code from cvs and runs the unit tests myself. Do I get warm and fuzzy feelings from looking at a bunch of random dependency metrics (which currently show nothing, incidentally)? No, I do not. I couldn’t possible care any less.

It’s somewhat interesting seeing the various styles across pages. You can guess who wrote the doc even without the author being mentioned. Here is a breakdown of styles used:

There was no award ceremony last week for the village idiot crowning since nobody managed to truly stand out. This week fortunately we have a clear (if somewhat of a nobody) winner.

Firstly, the usual batch of retorts and thinly veiled insults. Andy Oliver (jakarta POI head honcho and all round pretentious git, hilariously refers to his blog as ‘America’s Blog’, not realising how that comes across) seems to think that all one has to do to ‘hani-ize’ a article is to add in ’sucks’ and random insults at various points. Oh you poor deluded ignorant bastard. If ONLY it were that easy. You have no idea how difficult it is to be so consistently negative, and to scrupulously avoid cheerful happytalk. Much to my dismay, there are plenty of good software products out there, as well as talented developers. The temptation to promote and applaud can sometimes be quite strong. Sure, it’s easier to be negative than to be positive, but it gets surprisingly difficult to remain so. Anyone curious enough, please do try it. Nurture the evil within, and admit your true thoughts about your coworkers, peer developers, friends, or even pair-programming gimps. Now see if you can do it every single day. Good luck!

Back to the crowning ceremony. This week’s winner is one Mr Alan Green for his remarkable ‘Too Many EJBs’ blog entry (go to javablogs and look at the 4th most popular entry for 10 Jul 2003, or don’t bother, I’ll summarise below). Now, there have been some very intelligent insightful articles and discussions about why EJBs suck, and how they very often fail to address the problem they’re aimed at. Our Mr Green though seems to have absorbed some of the words of those discussions, and strung them together in some bizarre order to come up with some very disturbing language.

The cunning aspect of his entry is how he pretends to give an objective technical listing of EJB pros/cons. For pros, he has 3, for cons, 9. Hmm, fair enough, EJBs do have a lot of cons. Sadly, his collection seem to be written more by a ignorant simpleton than anyone with any actual knowledge. For example, the cons list uses the term ‘a LOT’ (in caps) in 3 of the points, which just oozes professionalism and objectivity. He also states that Most commercial EJB containers are heavy-weight monsters that eat memory and CPU cycles for no discernable benefit. Perhaps a more accurate description would have been ‘they’re enterprise products that cater to a different market and user than my l33t php app’.

Somehow, after listing this highly dubious collection of cons, he arrives at the astounding conclusion that you gain ALL possible advantages of an EJB architecture by just using ONE bean. Yet, miraculously, the disadvantages increase with every single additional bean you deploy. Maybe he just forgot to include a few pages of explanation as to how he leapt from the cons list, to that impressive conclusion.

So, Mr Green, here is your village idiot hat. It is bloggers like you that inspired me to start my blog (of course, I sold out within a few days, but oh well). The fact that any idiot with a keyboard can splatter their filth and have it be taken seriously is very, very disturbing. The amount of java blogs which do nothing but that is outright depressing. Worst of all, this pitiful excuse for a coherent entry managed to worm its way to the top 5 most popular entries on javablogs.com. Bad taste knows no bounds.

What’s with this new obsession with doing away with any form of compile time safety? A while back there was talk on the xwork list about doing away with Action, and allowing users to use any random object as an action. Alongside this there is current talk of doing away with the *Aware interfaces and just relying on conveniently named methods. Neat hack, to be sure, but why this strange aversion to any sort of contracts for classes?

Forgetting the fact that reflection IS slower than direct method invocation (try it, JDK 1.4 makes it less than 100 times slower, but it’s still slower). Plus there’s the fact that you’re no longer able to use any decent tool to find dependencies or any sort of ‘tell me which classes adhere to this contract’ query.

Reflection has this strange coolness factor attached to it. Slap a few classnames in an xml file, and suddenly you can hear the fapfap of developers masturbating everywhere to this amazing new pluggability. Allow for special method names (a la webwork ‘execute’) that are picked up at runtime and that sound will become a deafening roar.

Amazing, in the case of webwork, there is a voice of sanity in the form of the much maligned Pat. He likes interfaces, he likes contracts, he likes objects implementing interfaces to specify their contracts vs having similar names somehow denote special meanings.

For example, many IoC implementations will use the setter/getter paradigm to set components on an object. Now, this functionality in principle is the exact same thing across classes. Yet, they’re different signatures, and the only way of detecting this similarity is by doing a global search for setMyTawdryManager. You can’t do a find usages, because there’s no explicit contract that anyone is sticking to. It’s simply a matter of spelling.

Besides, what is so bad about designing up front? Yes, it does put those of you who are completely inbred at somewhat of a disadvantage, but really, it’s effort worth spending. It also means you’ll be rewarded with compile time safety. As uncool as that sounds, it means that you’ll get helpful error messages, and that holy grail that all of you squeal for, faster development time. Reflection does have its uses, but if you’re designing a system where EVERYTHING is done by reflection, chances are you’re more concerned about bragging rights than producing something worthwhile.

All the cool kids these days have their panties twisted into various uncomfortable shapes over this IoC nonsense. It’s as if it’s this amazing new technology that will reinvent the way people write java apps.

Let me digress into a side story now. It was the summer of 2000. The dotcome had started its dotgone, and alltrue.com was nothing more than a bunch of money that some VC plopped down. I joined there to basically built out the whole site. The initial proposal was to use ATG Dynamo (they had some consultants recommend that). ATG Dynamo is a decent enough server with a reasonably silly pricetag ($40k). This was rather irritating as I had just discovered the joys of the Orion appserver, which outperformed Dynamo in pretty much everything (but also had none of the extra fancypants features).

So, a switch to Orion enabled the powers that be to blow their budgets on some other useless toy (they picked a couple of F5 bigIP loadbalancers for $40k instead), but anyway. The problem having switched away from Dynamo was the reliance on Dynamo’s Nucleus architecture. Nucleus is a rather cool idea, which if you had access to any Dynamo docs would see bears a surprising resemblance to one picocontainer. Now, instead of relying on constructors, you could glue your components together via a pretty gui (which boiled down to properties files, at the time). Your objects were treated as beans, and their dependencies were set via setters. You could use a beaninfo if you really wanted non-default bean property behaviour. You didn’t have to worry about the implementations if you didn’t want to, and you could do fancy stuff like pluggable implementations and so on. Basically all the picocontainer blurb applies (the ‘container’ portions), without the silly constructor stuff. Scope and lifecycle management were provided for free by Nucleus, as was caching, clustering, and all those yummy bits we take for granted now. For Alltrue, the bits that were used from Nucleus were rewritten to form the core architecture that was not dynamo-dependent. It lacked the fancypants gui to string components together and so on, bu in terms of design, it was very much the same. It took a couple of weeks to whip up a Nucleus type container that resolved dependencies, did civilised instantiation and generally went about its merry IoC way.

Thus, type 0 IoC! It just happens to exist in a commercial, closed source, impossible to download server (at least, back in the day).

If only ATG were now smart enough to pimp their product accordingly. That poor company is cursed with the single worst marketing department ever to be inflicted on a product. Dynamo isn’t so bad (once you overcome how incredibly proprietary everything is), and in fact has some neat features that could really get some decent hyping. Instead they focus all their attention on fellow marketoids and stick to buzzwords. I’m surprised their developers haven’t committed mass suicide yet to end the horror of seeing their work so bastardised.

So you see, IoC is nothing new. People have been using it for years and years, and in fact it’s a fairly common pattern. I am somewhat disturbed by all the ‘aha!’ness of it all. It isn’t THAT amazing, yes, it iS that simple, and no, it WASNT just discovered. Using constructors is simply yet another way of doing the same damn thing, and not a particularly mindblowingly clever one at that.

Given that sf.net’s anon cvs servers are now about as useful as a fork in the eye, some of us folks under the opensymphony umbrella though we’d give java.net a whirl. OpenSymphony currently hardly ever makes any releases (our release manager got bored with the whole ‘release stuff’ aspect of his job), anonymous cvs access is rather crucial if you want anything that isn’t a year old/unmaintained.

So, the first step is in creating the projects. This we did manage to do, and it was a reasonably painless experience. The next hurdle to overcome though was somewhat more significant. OpenSymphony consists of many projects (most of which are useless, but that’s another issue altogether), rather than one project under which all source code lives. Conveniently, java.net fully supports subprojects. The helpfiles even tell you to pick a parent project if it’s a subproject, all part of the ‘add a project’ documentation.

However, the actual ‘create a project’ form is trickier to navigate. The chief obstacle is the glaring lack of any field mentioning parent projects in any shape or form. As far as the reality of creating a project is concerned, parent projects are nothing more than a figment of the helpfile’s imagination.

A quick email or two to some sort of support address (again, quite well hidden and ambiguous) and we eventually get back a response (half a day later) informing us that in order to create a subproject, we have to include a NOTE in the description specifying that it is a subproject. I realise we’re all expected to be top notch developers with astounding problem solving abilities. However, never in my wildest dreams did I consider that specifying a parent project in some random free form textarea is the way to go.

All this was a day or two ago. Needless to say the two newly created projects have STILL not been moved to the correct parent project, despite their descriptions being suitably amended to include that all-important ‘this is a subproject of XXX’ addendum.

To add insult to injury, the site itself is horribly awkward. It suffers from the same symptoms that the JDC does but to a more severe degree. Namely, the automatic login is hopelessly broken for anyone outside of Sun. It works once, and that’s it. Come back later, and you’ll be greeted by that snide login box, taunting you with its all too frequent intrusions.

Having logged in, you would think that you’d be given some visual indication of this fact. Needless to say, you’d be completely wrong. The homepage of java.net is I suspect static (index.html), and so logged in or not, you will always see a ‘login’ link on the left nav. God did not intend this when he invented login. He clearly stated that a login should change the login link to something more descriptive or useful, like…oh I dunno…how about….logout?

If you do click on this login link, you’d be forgiven if you thought it would take you to your logged in page. Not so! Instead you’re taken to the login box AGAIN! Suspiciously, the top left tabs contain ‘my pages’ and ‘projects’, yet you’re sitting there staring yet again at the login box, which is quite clearly neither of those tabs (yet, ‘my pages’ is highlighted).

If by some miracle you haven’t given up by now and still are determined to see some personalised content, you would have to click on the ‘my pages’ link, where lo and behold, FINALLY some content vaguely relevant to you.

I hate ranting against Sun because everyone else does. It’s so easy and fashionable. It also puts me in the filthy position of being on the same side of an argument as the JBosshive. A position that makes my eyes bleed and my skin crawl. For the love of god Sun, get some competent people to develop that site for you, and try to use the damn thing and see how uncomfortable it is.

Based on using a large variety of products, both commercial and opensource, I have learnt a few things about how to best report errors to your users. I will attempt to distill these gems into a few brief pointers that are guaranteed to bring you hot love from the coldest of users.

Alrighty, time for the usual collection of apologies, taunts, retractions, and outright lies. So here we go.

First up, kudos to Floyd Marinescu who didn’t burst into tears when I ranted against TSS (and was jolly nice in his email to me). The javalobby folks on the other hand did not find the JL bashing quite as amusing, and sent their collective glares/indignation my way. So, in conclusion, the users of TSS and JL are incredible morons. The people who run TSS are cool, and the people who run JL have no sense of humour. I suppose it isn’t too hard to see that, given that JL has a much higher ratio of utterly retarded articles.

I’d also like to apologise for my rant on osworkflow. I got rather excited about letting out all the things I hate about Pat that I forgot to remain on-topic. Just goes to show that personal insults are infinitely more enjoyable than boring tech talk. Pat however wasn’t nearly as upset as he should have been and took it all in good humour, which takes away a lot of the fun of ranting, to be honest.

Regarding prevayler, I still absolutely stand by what I said. My rant had some inaccuracies in it (the comments cleared that up though), so I apologise for that. The principle remains though. Ohyeah, and famous people using it is just about the most ridiculous advocacy claim I’ve heard. Famous people use Windows too, but I don’t see all those cool linux kids tripping over themselves to switch back because their favourite pop star uses Windows. Prevayler still is, at the end of the day, nothing more than fancy candy wrapping around basic serialization. So move along folks, nothing to see here.

More mud slinging comes from Carlos Perez, who tries to indulge in a ludicrous one-upmanship against my claim that bytecode manipulation and dynamic proxies are often abused by insisting that a class is not the same as an object, and that THAT’s the real problem. Please don’t let that guy near any sort of real life decision making body. When I’m king of the world I’m going to send most of you ‘let me write endlessly about philosophical meta-programming crap and crayon in endless prototypes and proof-of-concept’ bastards back to academia where you belong.

It wouldn’t be fair to bash TSS while ignoring the festering sore that is JavaLobby. TSS is a relatively new site and is a mere pretender to the throne that JL sits astride.

Before I launch into a dissection of the evils of JL, I note with interest that even though javablogs.com shows my previous blog entry near the top of today’s popular entries, JL’s list of popular javablogs seems curiously bileblog-free. Now, I perfectly understand the urge to not link to my blog and to explicitly remove it from their list. On the other hand, it could just be a technical glitch, we’ll never know!

Still, that’s perfectly in line with many things JL has done over the years. My first negative experience with them was at the of the first JDJ awards. Imagine my dismay to see that Rick Ross, head honcho of an organisation which purports to advocate all java everywhere, sends out an email to all members urging them to vote for his own commercial product, because it powers javalobby. Now, as any paid employees of Rick Ross will attest, he’s a fairly slimy businessman who is out to milk everyone for all they’re worth (there’s a hilarious log of him, his wife, his CTO, and various employees airing ALL their dirty laundry in public on IRC from a year ago). It was still surprising to see him so brazenly use JavaLobby as just another tool in his quest to riches (via the silly UserMagnet product). Still, at least their unsubscribe instructions worked (JDJ, pay attention).

To be fair, the new layout is fairly clear. It doesn’t try to bombard the user with information, nor is it coloured by Marc Fleury’s children. However, the content suffers from the usual ailments that are caused by users with an intelligence quotient matching the size and variety of the Muslim pantheon. It’s really, really poor.

Some examples, Jan Koops thinks that checkstyle and PMD should merge, and should furthermore use bcel. This is considered a frontpage story; the mind boggles. Fred Grott is, as usual, desperately whoring for clickthroughs, fame, and fortune by endlessly pimping out the couple of things he knows about J2ME. He’s writing a childish game for the love of god, it’s not THAT amazing. Other ludicrous links include a number of rants about how opensource is great, and Sun sucks. Here’s a hint, if you want to successfully rant at something, pick the opposite side to everyone else. Siding alongside them will make you nothing more than a worthless me-also.

The real genius, as with TSS, is in the user comments. It’s as if there’s a conspiracy theory to try and discredit Java at every turn. Most posts are so astoundingly retarded they had to have been the result of endless hours of meetings with the sole agenda of ‘how to best give the idea that java developers are inbred dullards’. Anyone dissenting is usually labelled a Sun employee, everyone agreeing is probably engaged in sexual relations with someone from the JSS JBoss crowd (they both have a thing for opensores).