The BileBlog

The current talk I’m in is (allegedly) about EJB 3.0 performance and optimisation. The first ten minutes are, to put it mildly, utterly and thoroughly pointless. What on earth is the motivation to discuss the deployment/initialisation performance? There’s next to no magic involved, a bean is created, stuff is injected into it (looked up from JNDI by the container for you if it’s a naive implementation, or more optimised, either way, pretty cheap). Once that’s done, it’s done, init is complete, nothing to see here.

Sadly, the next bit doesn’t get much better either. We have a discussion of local vs remote session beans. This might come to a shock, but it turns out that….remote beans are slower than local ones! Remote beans should be coarsly grained! Local beans are better! Waggle waggle!

Having made the astounding leap of faith of preferring local beans over remote ones, you should next, apparently, look up resources once then cache them. Will the craziness never end? A revolution in enterprise development is surely afoot.

There were some surprising results though, to be fair. For example, the cost of one interceptor is negligible, but having multiple interceptors is far more expensive. I suspect this is due to a not insignificant amount of incompetence within the implementations that were tested for this talk.

The next bit about transactions, while horrifically sleep inducing, did manage to sneak in a useful tip or two. Thankfully, these were buried in amongst a bunch of other useless guff, so they’re very easy to miss.

There is a hint of usefulness wafting in the air though, with the preview of entity bean optimisations! Alas, this hope is quickly squished as it turns out that this bit is nothing more than a cascade type discussion that proves to be a red herring, as well as a explanation of the difference between eager and lazy fetchtypes (how that could require an explanation is beyond me.)

The most hilarious aspect of the whole talk though is the graphs. For each of the points raised, the poor presenters decided to ‘prove’ their claim with a graph showing the relative performance of the issue at hand. The hilarity however shows up when half the graphs show two tall bars, showing that the point at hand is in fact nonsense, and actually has NO impact on performance. I’m fairly perplexed this approach, given the title of the talk. What exactly is the point of claiming that something is slow, then showing proof it isn’t? Is the talk just horribly mistitled, and should have been called ‘things you might think are slow if you don’t know much about stuff but actually aren’t slow and are in fact irrelevant when working with ejb 3.0 beans’.

The final section shows some real world performance data for various operations, comparing two appservers (referred to as appserver A and appserver B), comparing results for EJB 2.1 and EJB 3.0. I can only imagine that the two servers are Sun’s and JBoss’ (since one appserver was consistently slower across every single test, no marks for guessing which one).

Having managed to blag my way into sitting on the second row during the BEA keynote, and having subsequently borrowed a BEA laptop to bile on, I almost feel bad for doing this. Still, it must be done, life can be so cruel sometimes.

First we have Bill Roth (BEA VP type dude), who starts off with debunking a lot of the shit that spotty little open sores sycophants have been spooging about in the last year or so. You know the usual crud, opensores will 0wn j00, java is cobol, ruby will make your penis big and tasty to hot little teenagers of the girl variety, and so on and so forth.

Patrick Linskey goes up on stage next, I don’t know if he has makeup or not, but his pate looks awfully shiny, so it’s a bit hard to focus. Regardless, the talk starts off with a rather boring ‘middleware is great, we love middleware, middleware is prevalent, middleware lets you write applications, middleware gives you the flexibility to be flexibly flexible, you can embrace change, have sex with it, then surprise it with a hot lunch/cold karl combo.

The next issue to address is whether middleware has been commoditised. Unsurprisingly, the BEA answer is a fairly resounding ‘nooooo’ waily sound. All is forgiven though since Patrick just said ‘holistic’ and you really can’t go wrong with that word.

Bill takes over again, with a great jibe at how stupid IBM is. It’s really hard to agree, one would be hard pressed to find a company that manages to produce as much shit as IBM. Never, ever forget or forgive the crime of java.util.Calendar for which they are responsible.

The one piece of great news is that Spring now supports the non-JPA bits of EJB 3.0 (DI, session/message beans). The best part, of course, is that JBoss now has it stuck to them up the bottom with a sharp splintery thingybobby. There’s absolutely no reason to use it now if you care about EJB. You can use kodo with spring, and have full EJB 3.0 support, running in tomcat if you want. Unless of course, for reasons that are entirely inexplicable, you enjoy chewing off your arm, cramming it up your ass, while singing twinkle twinkle little star in a strained and fairly uncomfortable voice. No doubt the Geronimo people will find this very useful (the spring thing, not the arm-in-anus thing), given that the only hope that poor little project ever has of not being a laughing stock is to beg for charitable donations from other entities that can actually deliver software.

Surprise surprise, it also turns out that SOA is NOT ‘the’ next big thing, but merely ‘A’ next big thing. I’m sure that by next year, we’ll have an ever more sheepish nod in the general direction of this obscene cloudfest.

Patrick however lost me at his praise of Apache. He seems like such a sane normal guy, and here we have a blatant nod in the general direction of Apache. Someone must have given him the wrong suppository to make him say such horrible things, come on, of all people, surely he’d know that Apache does NOT have ‘cool software’?

The real problem I have with this talk though is that the general theme is, unsurprisingly, bullshitty. They basically decided to use ‘blend’ instead of ‘integrate’, and are somehow pimping this as some kind of astounding revelation. Gosh, thank god I attended, I’d never have ever figured out that I should be using the right language for the right task, or that I should pick the right tool for the issue at hand. Now that I can ‘blend’ stuff, I’m sure my productivity will skyrocket! Pffft.

No pimpage is complete these days without some kind of IDE arm flailing with a promise that this could be almost as gratifying as self-asphyxiation. In this case, it happens to be BEA workshop. They’re also doing something some Google AJAX talk I went earlier did; having one guy casually ask the other various leading questions ’so for example, if you change a dependency, it’ll show up right away, right?’ ‘why yes, funny you should ask, but it will show up right away!’ ‘Great!’ ‘Great!’ ‘Wanna cyber?’ ‘Funny you should ask, but yeah!’

Still, despite all that, one can’t deny that having another open source ejb3 provider is a great thing, and being able to run the whole thing standalone via Spring is enough to shake the limpest penis.

UPDATE: I’ve gotten way too many questions about these during the last few hours, so for the uninitiated, here are some definitions:
Hot lunch: the act of shitting in clingfilm stretched over someones open mouth then fucking the mouth and at the point of ejaculation bursting through the clingfilm giving the recipiant a mouthful of shit and spunk, not to be confused with a hot buffet (the act of shitting, pissing and vomiting on your partners chest.)
Cold karl: The act of defecating on a glass table, while another person’s face is directly below the table/feces. Similar to the hot karl (form of assault in which the assailant procedes to fill a tube sock with his own faeces, ready to engage in fierce guerrilla warfare) and the warm karl (The act of defecating on another’s forehead with only a piece of cling wrap separating the feces from the forehead).

There’s something particularly endearing about standing in the lepers line at a particular session at JavaOne this year. The lepers line, in case you weren’t aware, is for the poor sods who showed up to a session thinking they had registered, when they in fact hadn’t. You stick you card on the cute little reader, and it flashes an angry accusatory red, insisting you have not registered. The nearest usher will then calmly but surely place you in the lepers line, where you get to shuffle about uncomfortabely and look like the dumb bastard who couldn’t figure out how to register, or was too lazy to do so.

Having been one of those rejects twice, I’d argue that the members of the line form a kind of silent (and often not so silent) bond. Sure, we don’t know how to navigate one of the most poorly written webapps for selecting and scheduling sessions, but by god, we’ll give it our best shot.

Pitifully, I managed to attend just one session yesterday (not including my own), so there’s not much to report on that front. However, this JavaOne is, perplexingly….vibrant? There’s a certain energy that seems to have been lacking recently. I’ve noticed more than one person comment on the quality of the talks and topics, and how much fewer of them seem to be pointless fluffy Sun penis wagglage marketing poop.

Of course, the real highlight is all the drinking, socialising, and awkward moments when you find out you’ve just accidentally run into Bill Berk and he still hasn’t developed any social graces.

The linux distribution license thing announced yesterday is worthy of note; it’s always thrilling to see another nail hammered into Apache Harmony’s coffin. Why all the members of that project don’t just crawl into Stallman’s beard and die is a mystery as yet unsolved.

Ex-TSS Floyd also launched his new ‘it has nothing to do with tss nor is it competition and I’m not bitter honest honest’ site, infoQ. It’ll be at least interesting to see how the content evolves, given that some of the editors (well, one of) can barely string together a coherent sentence, and has the mental acumen of a small pebble.

Tonight there’s the Geronimo party, where I hope to point and laungh at the fact that these monkeys still seem utterly incapable of doing more than running around very quickly in tight little circles. To reward this rage and anger, they’re going to give me free food and beer. Aint JavaOne grand!

The Axis team is kicking up a big fuss about their recent release of Axis 2 (1.0!) Surprisingly, this library is so so abysmally bad, that I have yet to find someone who has managed to successfully use it.

I will attempt to give a whirlwind tour of some of the things that are wrong with it. Most of these can be seen through a very very superficial cursory glance, it’s stuff that anyone trying a ‘hello world’ app will run into.

The first thing that’d strike any English speaker is how astoundingly bad the documentation is. I take back everything mean I’ve said about WebWork 2’s documentation; it looks like a bunch of professional tech writers got together and produced that, compared to the hilarity in Axis2. Some samplers:

• Modules are in one of three states: “available” and “initialized”.
• When engaging this module to some service or operation , module will be notify by calling this method there module author can validate , add policy and do any thing that he want , and he can refuce the engage as well.

This comical approach to text is followed through in every aspect of this abysmal project. In the code generator for example, the bit that turns WSDL into Java, we have: constructorMap.put("javax.xml.namespace.QName",
"new javax.xml.namespace.QName(\"http://double-double\",
\"toil-and-trouble\")");

It becomes very clear that the authors of the documentation have only the most rudimentary grasp of the finer points of the English language. These kids clearly played truant on the days when coherent sentence structure was taught in school.

For the sake of consistency, this spastic approach is present in every aspect of Axis2. The code is riddled with typos like ’sceahm’, ‘mdoule’, and ‘getFaulReasoFromException’. Lest you be comforted that the idiocy is restricted to abuses of the English language, rest assured the code is equally incompetent. For example, the recommended way to develop is to start from a WSDL then generate java using their helpful plugin. Obviously, the plugin is utterly unstable and will not generate skeletons no matter how angrily you glare at it or how furiously you waggle your genitalia. Apache and Swing do not mix, they never have. Swing development requires people with at least a double digit IQ, which (with maybe two exceptions) nobody at the Java side of Apache has managed to evolve to. I won’t even get started on the numerous usability and UI issues.

The Axis2 main servlet is in fact a worthy contender to Tomcat’s DefaultServlet. The servlet introspects itself! Mapping all its processXXX methods to /servlet/XXX. So much for encapsulation eh, where a class has to allow itself to be extensible enough that you can look at the bottom of the file without having to know anything about the top!

Of course, unlike some bits of Tomcat, ALL of Axis2 is plain old rubbish. Instead of simply substringing a class’ name, the code is littered with Class.getPackage().getName(), nevermind that the javadocs for getPackage make it very very clear that you really can’t expect it to always be not null.

It really is a gift that keeps on giving. Deployment brings its own special joy sauce to burn your eyes out with and make your bottom cry rivers of brown sadness. Everything is hardcoded to a specific context path, and deploying the simplest hello world service is more likely than not to result in a jbossian stacktracefest.

It’s easy to argue that all these issues are technical glitches that can be remedied by hiring a English speaker or two, along with a Java developer. Sadly, the same people who have come up with the implementation of this monstrosity seem to have had a hand in its design and goals.

While the rest of the world is moving to a POJO flexible embeddable testable minimal non-invasive API world, Axis2 is keen to march in the exact opposite direction. Now there’s a repository with a weird fixed structure. There are new file extensions and ‘hot deployment’ modules. Good luck finding an IDE that’ll grok .aar or .mar files. Who the fuck asked for such a feature? Axis is NOT a platform, nor should it ever become one. Of all the thousands of spotty fuckfaced shiteaters who use Axis 1, I suspect there are maybe two that don’t use it in an existing container of some sort, on the server side. Didn’t your mothers warn you against juggling custom classloaders in your webapps? What sort of example are you setting for the hordes of jizzgobbling turdburglars who will look up to this monstrosity?

However, it looks like some of the people involved realise that what they have on their hands is a steaming pile of doggypoo, and have looked around at the Java landscape and observed JBoss’ success, and decided to take a similar approach. Enter marketing!

I had to do a double take when reading some of this stuff. There’s a developer.com article that talks about ‘avoiding mistakes using Axis2′, which on closer inspection reveals how fucked up Axis2 actually is, by accidentally highlighting many of its warts. The author (Deepal Jayasinghe) is obviously an Axis2 developer, as evidenced by the typo in his very first point: Trying To Do Advance Tasks Without Knowing Basics of Axis2

The JBossian approach is scary. As much as I hate Apache, one thing one could always count on is their moralistic holier than thou good behaviour. They won’t lie or decieve, and when they do so, it’s usually out of ignorance and simple minded idiocy than any actual malevolence.

This perception was shattered a couple of days ago. As someone who has contributed the odd piece of XFire documentation, I’m subscribed to watch any changes in the XFire confluence wiki. Imagine my surprise when I see that the ’stack comparison’ page was changed 4 or 5 times by a lead Axis2 developer, Davanum Srinivas. He merrily snuck in and modified the page to make Axis2 look a lot better, both by changing existing points and adding new points that he knew are not relevant to WS in any way, but that Axis2 supports anyway. Is there no accountability? If someone from JBoss has done this there’d be an article on TSS discussing these evil underhanded tactics, but since it’s Apache, we can all ignore it and pretend they’re honest people with no ulterior motives or evil actions.

After all, why would an open source developer like Davanum Srinivas do this, if it weren’t just to set the record straight? Oh wait, he’s the Co-Founder & VP Engineering of WSO2, a consulting company that just managed to get funding for….Axis2, and that coincidentally has some cockamamey scheme on making money off of Axis.

WSO2 is, depressingly, a Sri Lankan company. I say depressingly because I despise all the stereotypes in IT about south east Asian developers. Projects like Axis2 do much to encourage that sort of stereotyping, unfortunately. Digging into the history of the project, the developers brag of the fact that it was written by a bunch of students who knew nothing about xml or web services, or any specs in that space. It should be written off and its developers put out to pasture, and everyone should just switch to XFire to make the world a better place. WSO2 should die the horrible death it has so richly deserved in its short pathetic life.