Top 10 reasons why you should not try Oracle's EJB 3.0 Previews

Lately, I’ve been heavily researching EJB 3.0 in those few moments that I’m not working for any customers. Especially since my trip to JavaOne a few months back, I got the feeling that EJB 3.0 is coming to a level that is close enough to the actual spec that will be released Q1 2006. My experiences in the past however have learnt that being to early investigating s spec almost certainly results in a spec turning an entirely different way. Becoming a total waste of my sparse research capabilities. In order to fully understand a specification it would be nice to get some actual things up and running. For some time now EJB 3.0 previews have been available.

Considering the heavy amount of attention that Oracle drew to their EJB preview implementation I decided to give it a spin. Announcements made at the JavaOne conference and some press releases around the internet gave me the impression that Oracle was also appointed to deliver the EJB 3.0 Reference Implementation somewhere soon. Don’t stop reading here because you will find out down below that this isn’t actually true!

So, here we go…at first sight I have to admit that Oracle’s EJB 3.0 website looks kind of impressive. There is apparently a lot of information available for you to check out. Indeed some of the featured articles and some of the samples can be really helpful understanding the very nature of the new EJB 3.0 specification. I also downloaded their special EJB 3.0 preview version of the OC4J container. Mostly to my misunderstanding as implied by the name of it, this turned out to be a wannabe J2EE 1.4 compatible container with an extra ejb30.jar containing a very rough implementation of the EJB 3.0 specification. A very rough implementation of the EJB 3.0 specification is actually an understatement. One could ask…which EJB 3.0 specification does it resemble most? According to the expert group’s website there have been two early draft specifications and one for public review. Neither of those three is a 100% match with Oracle’s EJB 3.0 preview. This is problematic in a way that when you are trying to verify what you have just read you can’t make any sense of the implementation. Ofcourse I’m not entirely stupid, so this just slows me down in understanding the spec. It’s a pity but hey…if this is all, I can live with it.

Things start getting annoying when stuff specified in about all three of the specifications are just missing, or only partially implemented. Some examples here are missing annotations, or annotations at the wrong level (e.q. class level instead of method level) and so on. A bigger failure in my eyes is that changes to the EJB 2.1 API proposed by the EJB 3.0 spec are simply ignored. So why is that? Well this gave me some thinking, but after a while I found that the OC4J 10.1.3 preview product Oracle is working on is intended to be fully compatible with the J2EE CTS 1.4. Changing the EJB 2.1 API would certainly result in not passing the tests and therefor not being able to be fully compatible with the J2EE 1.4 specification. Obviously Oracle’s OC4J Product Managers aren’t fully aware of CVS’ branching capabilities. Or maybe this proves that OC4J development isn’t under any version control at all! Nah…just kidding here. Ok, I could go on and on, but that’s what I titled this post “a top 10 reasons not to” for, so here goes…

1. The most obvious reason not to use it is because it simply isn’t compatible with whatsoever version of the EJB 3.0 specification. I’m pretty sure that for some readers this reason alone should do the trick.
   
   
2. If you’re still not convinced, have a look at the JavaDocs. What JavaDocs?! Right! There is a recognizable JavaDoc structure to the HTML documentation..errr..files but thats about it. Some of the annotations present in the JavaDocs do not exist in the latest implementation and vice versa.
   
   
3. With previews come questions. Questions are meant for forums. Forums are intented to be both questions and answers. Not just questions…
   
   
4. OC4J 10.1.3 is available as a preview release. OC4J 10.1.3 Developer Preview 2 is available as a preview release. OC4J 10.1.3 Developer Preview 3 is available as a preview release. OC4J EJB3 Preview is available as a preview release. OC4J Developer Preview 4 is available as a preview release. Alright..this is confusing…wait there is this download button on the OTN EJB3 Homepage..let me press it…what does it download?? oc4j_extended.zip Good luck!
   
   
5. Major.minor.fix I thought this is a straightforward way of labeling your products. Following this logic OC4J 10.1.3 Preview 1 (supporting J2EE 1.4) is a fix to OC4J 10.1.2 (supporting J2EE 1.3). Alright…but what is OC4J 10.1.3 Preview 4?? Answer: J2EE 1.4 with a Java EE 5 core technology preview!
   
   
6. The OTN EJB 3.0 Homepage contains a nice collection of sample code or HOWTO’s as Oracle labels them. Unfortunatelly they stopped working after OC4J EJB 3.0 Preview. Good luck hacking your ant build and property files. Some annotations are no longer recognized by the compiler.
   
   
7. HOWTO samples are meant for notepad. There is no decent way to get those things to work with a decent (annotations supporting) IDE such as Eclipse. Unless you are willing to spend two days hacking ant files and Eclipse project settings.
   
   
8. Oracle has some nice flash demos of the upcoming JDeveloper 10.1.3 product, which is – you guessed right! – available as a preview. Unfortunatelly you can’t get the EJB 3.0 HOWTOs to work since EJB 3.0 support is not available in the preview version.
   
   
9. Mandatory changes to the EJB 2.1 API proposed in the EJB 3.0 specification are ignored in Oracle’s implementations. I already told you why.
   
   
10. As I mentioned in another post, Oracle did not even bother to vote for the most recent JSR 244 ballot. How serious are they taking J2EE development anyway? This may be my weakest argument not to use the preview, but at least the fact alone is not speaking in their favor and I had to have 10 reasons :o)

So…a bit frustrated about my own top 10 I decided to send an e-mail to the EJB 3.0 expert group. Curious whether an implementation with a quality like this could be an official Reference Implementation somewhere soon. Within the hour I received the following reponse from expert lead and one of my personal alltime Java heros: Linda DeMichiel:

        Bert,

        Oracle is not delivering the EJB 3.0 reference implementation.

        Oracle is delivering the reference implementation for the Java
        Persistence API. We are fully confident that the reference
        implementation for the Java Persistence API portion of EJB 3.0
        will be of very high quality, since it is based on the
        highly-regarded and well-established TopLink product.

        Oracle has provided a “preview” release of an EJB 3.0
        implementation on their developer web site.   Such preview
        releases have been of great use to us in validating the
        concepts of the EJB 3.0 specification, but, as such, should
        not be expected to be definitive, complete, or yet product-quality.

        I hope this helps clarify.

        Linda DeMichiel

        EJB 3.0 Specification Lead
        Sun Microsystems

Although Linda states that even rough implementations can be very helpful to the EJB 3.0 expert group I doubt it that implementations of this dubious quality should be released to the public at all. Of course you cannot expect that previews are up-to-date all the time, but come on, JavaDocs this empty and of previous versions of the implementation should definitely be kept in the dark than publicly available as *the* documentation of a preview product. Next to that, there are also significant errors in consecutive versions of the preview implementation. Simply reading your own forums points these errors out in capitals. Crafting up a known issues list is the least you can do.

I’m pushing my luck here, but personally, I don’t think that commercial vendors should be allowed to deliver a reference implementation at all, as they will always use it to get some sort of competitive advantage. One could easily state that the only thing that Oracle seems to be interested in regarding EJB 3.0 is pushing their Toplink product. This does not seem to be the right rationale for producing a reference implementation.

EJBs have been under heavy fire with developers over the past few years and delivering a crappy reference implementation would be the least it
needs now.

If you will this whole post can be seen as some plain old Oracle bashing and I won’t deny writing it for your entertainment, but I like to make the following comment: I do respect Oracle’s intention to share and I always appreciate it when companies spend their research dollars contributing to the greater Java cause, but let this post be a warning to all of you that just like me spend their own, or their companies research dollars, on experimenting with products/technology like this. Guess we fell for it once again…we simply have to wait for some decent Reference Implementation due somewhere Q4 2005. As Linda says that she is fully confident that the reference implementation will be of very high quality, we should be too. Until then…stay away from the preview!