EJB3: What childish examples don't tell you
I’m going to do something different to pretty much everyone else talking about the EJB3 spec draft. I’m actually going to…provide feedback! While it’s fun to say how great and cool it is, and potentially even more fun to wring my hands, make obscene elephant comments, and cry over how it’ll damage my past and future book sales (known as brucetating about), I will choose to actually talk about the spec itself, and the problems with it as it stands.
The first impression one gets is that it’s really, really, a draft. Mistakes abound, it lacks much polish, but all that’s to be expected, and it’s certainly better than to be left in the dark until a more serious offering emerges.
The first traumatising feature is the prevalence of ‘magic’ methods. Want to be able to do a 2.x style ejbRemove method? No problem, just define one! No interface to implement (if you don’t want to), no compile time contract, just a bunch of random magic method names. This isn’t restricted to method names too, you can even have interface names happen magically simply by suffixing Bean, Impl, or EJB to your beans! Of course, if you happen to screw up and mistype a letter or two, that easy unit testability will come in handy. Why allow unit tests when you can enforce them, by ditching all compile time contracts!
Also, is anyone else distraught by the obsessive use of the acronyms POJO/POJI? While it’s understandable that a bunch of open sores asshats enjoy indulging in this fappery, I find it highly upsetting that this ‘street lingo’ has made its way into a supposedly professional serious spec. Is it so hard to say JavaBean/Interface? What’s even funnier is that in every case, the POJO/POJI silliness is never used standalone, but always in paranthesis after ‘regular java bean’ and ‘regular interface’ respectively.
One of my biggest pet peeves remains unanswered too, there is no support for collections of dependents. All those millions of times where it’s useful to just have a collection of strings remain ignored and unheeded.
The EntityManager methods are also baffling, to say the least. The create method, bizarrely, is a no-op if the entity’s identity already exists. No duplicate entity exceptions thrown, no boolean return value, nuthin’. Just a simple no-op. There’s also the joys of the ‘merge’ method. The merge method is, from what I can tell, an update that handles disconnected and container-bound entities. Why it isn’t called ‘update’ is so far, rather unclear.
Surprisingly for a J2EE spec, we have that bane-of-specs, the ‘or’ word. Quoting from the spec: ‘transaction commit will fail, or
an exception will be thrown’. If there’s one mantra that all expert groups must live by, it’s clarify. You never ever want to use or
in that manner. Specs are there to say X MUST do Y, X can NEVER do Z, and so on. Orisms just make you look silly and get you laughed at (just look at the JDO guys).
The spec also has its share of bad examples. One section consistently and persistently (no pun intended) shows examples of public fields. Are we regressing to the horrible old EJB 1.1 days again? They should at least be protected, for the love of god.
Finally, and perhaps the most criminal aspect of the whole thing, is the rampant hardcoding of all things sqly into your source code as annotations. It looks like we’ve come full circle now, with table names, join strategies, column information and the like all firmly embedded in source code. Even more distressing is that nowhere is there mention of being able to override this with descriptors. Basically anyone who understood or utilised the deployer role in a J2EE environment just got shat on from a great height.
I realise that the majority of ‘J2EE’ developers out there are hibernate humping web pillowbiters, writing random intranet apps with 10 users. That’s fine, you all serve a fine purpose and more power to you. However, there are actually people out there who haven’t yet taken the enterprise out of J2EE, so a little more consideration from the expert group towards these people would go a long way in ensuring you attract more than the spastic TSS metoo opensores penis grabbing pondscum.
DISCLAIMER: Please don’t take all this as facts, read the spec yourself, and for the love of god, prove me wrong.
July 6th, 2004 at 3:40 pm
Looks to me like EJB 3.0 beans will be half java, half annotation.
How lovely.
July 6th, 2004 at 4:20 pm
I haven’t looked at the EJB3 spec yet, and now I’m afraid to. :(
July 6th, 2004 at 4:38 pm
“transaction commit will fail, or an exception will be thrown”
Can this be suffixed with, “We haven’t yet decided which”, or is this a “Choose Your Own Adventure“ story?
July 6th, 2004 at 4:53 pm
I did: I read the spec and I proved you wrong, but there’s not enough space in the margin to reproduce my proof.
July 6th, 2004 at 4:58 pm
Ah yes… the elusive “proof”; perhaps you can post your 3-pager that proves -1 is negative (my personal favorite)
July 6th, 2004 at 5:21 pm
LOL, or how about “there exist infinitely many twin primes but … oh wait I fscked that one up too.”
July 6th, 2004 at 7:17 pm
Basically anyone who understood or utilised the deployer role in a J2EE environment just got shat on from a great height.
Well, let’s pitch in for a washcloth and get both of them cleaned up straightaway.
July 6th, 2004 at 9:15 pm
Annotations is the greatest evil IMO.
Another crap since XDoclet born?
Well, maybe only __they__ will think this way?
July 7th, 2004 at 4:21 pm
Isn’t a bean a subset of POJO? I thought POJO was any type of Java Object, no?
July 7th, 2004 at 4:24 pm
Great bile BTW.
July 7th, 2004 at 5:03 pm
Regarding the Deployer role–it’s not the typical case, but I don’t think it’s a tiny group either as the comment above indicates. ANYBODY who wants to write a J2EE package that runs on more than one database or app server cares about unnecessary intermingling of deployment settings and source. Granted 75% of software dev is in-house, but the other 25% (Hani’s company included) won’t be happy.
July 8th, 2004 at 2:05 pm
Boring bastards!! Maths sucks, you all suck. The only proof I need is an app that works and lets me get to the pub quicker. I don’t care if I hard code or write XML, bollocks to those who come after. Let me at my pint you gobshite wankpots. Go and pick your pimples while I’m enjoying myself.
July 8th, 2004 at 2:43 pm
Use of the word POJO reminds me of watching a cheap Austin Powers movie!!
What else they are going to come up with? How about using Fat Bastard for Swing Clients?
Include that toy stuff groovy into J2SE, so that some shitter can call it “its grooooooooovy baby”.
Is it POJO a typo for MOJO?
July 8th, 2004 at 4:47 pm
I have a Math BS and I hate math ;-)
July 8th, 2004 at 6:12 pm
And BTW Hani,
I tried to find you in javaone conference.
But did not succeed because i was not there!
July 9th, 2004 at 1:34 am
Holy one, you’re so funny. Suck my dick.
July 9th, 2004 at 5:50 am
excelent. holy one you can have my dick too. I keep it for the special occasions. I hope you haven’t lost your MOJO ;D
July 9th, 2004 at 9:14 am
Right, EJB 3.0 entity beans are not POJOs : they are BPOJOs (Bastard Plain Old Java Objects), i.e. POJOs without encapsulation…
July 9th, 2004 at 10:50 am
Hey, Hani. I don’t usually find myself in your space, but someone told me that you blogged the spec and curiosity got the best of me. Although I don’t personally subscribe to your brand of potty-talk I certainly have to acknowledge your talent for creative expletives and humor.
At the risk of being grouped in amongst the gang of 7-year-old groupies I wanted to ask you to send your feedback to the ejb3-feedback@sun.com alias. The issues that you raise have almost all been discussed in similar terms and with similar arguments in the expert group and it would be helpful if you and others added your thoughts. This is exactly the type of feedback that we are looking for (though not necessarily in this form — you may or may not want to edit it before sending ;-)
Thanks,
Mike
July 9th, 2004 at 11:15 am
Hehe .. Mike said “potty-talk” .. hehe ..
July 9th, 2004 at 4:33 pm
And he used an emoticon. Only 7-year-olds use emoticons.
July 10th, 2004 at 12:05 am
What other brands of Potty Talk are there? I see a new cottage industry forming for you Hani.
July 11th, 2004 at 6:37 am
Brucetating about, would that be referring to Mr. Eckel or Mr. Tate?
July 13th, 2004 at 9:15 am
Hmmm… I though I could find here a few serious comments but it seems unlikely now…
July 13th, 2004 at 1:03 pm
[Trackback] Cada vez gosto mais daquele blog :-)
o cara escreveu um review do early draft do EJB 3.0 muito bom, entitulado: “O que os exemplos de criancinha não te mostram”, tahh bem, a tradução do titulo pode não ser exatamente esta, mas a ideia é a mesma …
July 13th, 2004 at 1:09 pm
Finally…someone who recognizes that annotations are a disgusting way to intermix code and configuration!!! The whole frickin point of config files, be they XML or whatever, is the keep that information out of the code. Aren’t we regressing with Annotations…
July 13th, 2004 at 2:12 pm
Annotations will be great for EJBs. Everything in the ejb-jar.xml should be Annotated. They are meant to be standard and in most ways define the expectations of the EJB writer. All bindings however, should go into a server specific xml file – and should not be annotated. If the spec and more importantly the appserver forces us to annotate their specific bindings – we need to pile them up and hack their limbs of (nope..I don’t practice Islam – but in this scenario – the punishment fits the crime).
Magical methods — the EJB spec people have tilted completely in the opposite direction towards the open source -lets see how convoluted we can make this- junkies – instead of finding the right median.
July 13th, 2004 at 3:18 pm
Annotation hater, I think you confuse annotation with configuration. E.g. in many cases you don’t want to have the specifics of a transaction as part of some business code exposed in a configuration file, so that some random admin on a customer site fucks it up.
In fact most of the settings in ejb-jar.xml should be annoted so they cannot be configured in a way that breaks the app.
Annotations are a great way for a developer to tag information to your code which a container can further evaluate at runtime.
July 13th, 2004 at 3:53 pm
My question is how annotations are going to be handled for vendor specific directives and multiple vendor directives in general. Seems ripe for annotation pollution that will dwarf the actual business code.
July 13th, 2004 at 8:23 pm
“Brucetating”…have to remember that one.
Good bile blog.
July 14th, 2004 at 12:38 am
fate is now featured on TSS, the site he was lambasting last year. YOU SELL OUT!!!!!!!!!!!!!
July 14th, 2004 at 12:34 pm
just look at http://www.jroller.com/page/fate/?anchor=foaf_can_foad , it is full of crap. you should clean something
September 24th, 2004 at 10:22 pm
I have a math minor and I suck at math :@)
November 18th, 2005 at 2:46 am
I agree, this specification is geared more towards hibernate users. Guys switching from hibernate take only a day or two. For JDBC guys, I would advise better use hibernate descriptors(more stable and complete) than ejb3 descriptors..