Java EE 6 doesn't "just work" in even trivial real-world uses

Lincoln Baxter III writes that with Java EE 6, It all “Just works”.

Personally, I have not found that to be the case in even simple, toy applications.

I suspect it'll be true in a few years, probably after a much needed "Java EE 6.2" and some major bug-fixing. Right now it all "just works" ... except when it doesn't, which is frequently, due to spec oversights, bugs, and a general lack of real-world use and testing.

Using CDI "just works" until you realize that @Inject isn't supported in obvious places like a @FacesConverter due to limitations in JSF2/CDI integration. OK, that's easily worked around by looking up a managed bean from the FacesContext and getting the desired EJB from the @Inject site on that managed bean. Except that the ejb injection site is null during that phase of processing, having been helpfully cleared by CDI, so you get a null pointer exception that looks downright inexplicable until you figure out that CDI is clearing the injection site behind your back. (See: this report and this Mojarra bug). In that case I eventually found out how to look up the desired EJB via the BeanManager (See: http://dominikdorn.com/2010/04/cdi-weld-manual-bean-lookup/) but it certainly doesn't "just work" even between ostensibly co-operating, integrated technologies.

I hit that roadblock *after* getting stuck on a Glassfish/CDI integration bug (https://glassfish.dev.java.net/issues/show_bug.cgi?id=13040) that means that those nice new no-interface views of local EJBs don't actually work if you inherit methods from a superclass and are using Glassfish (even 3.1 as of build 15).

To add to the confusion, often using the JSF2 injection support to do something works, but CDI doesn't, or vice versa. And where the JSF2 or CDI injection support works on Glassfish it'll often fail on the (admittedly alpha) JBoss AS 6 or vice versa.

This is in my first JSF2 project on a Glassfish 3.0.1 container, using all the new "just works" stuff, and I must say that it sure as hell doesn't "just work" some of the time.

Another factor that doesn't help is all the legacy surrounding Java EE / J2EE. It's hard for someone trying to learn Java EE 6 to separate it from all the JE22 4 and Java EE 5 stuff. Even within Java EE 6 there's "new legacy", things that are effectively deprecated even though they've barely been released. Consider JSF2 scope annotations (replaced by CDI), JSF2 @ManagedBean (replaced by the Managed Beans specification, then promptly replaced again by CDI, all within the span of the Java EE 6 spec) and JSF2 injection support (replaced by CDI). It takes a great deal of sorting out before you can have much idea what the real, practical difference is between:

@javax.faces.bean.ManagedBean
@javax.faces.bean.SessionScoped

and:

@javax.inject.Named
@javax.enterprise.context.SessionScoped

let alone @javax.annotation.ManagedBean (hooray pointless duplication).

Then there's un-muddling the chaos of @Inject, @EJB and @Resource (which I'm still struggling with, since @EJB seems to be used by CDI in a *completely* *different* context), the difference between injecting an EntityManager via @PersistenceContext vs @Inject, etc.

No, it really, really doesn't "just work". It's a nightmare of overlapping, muddled conflicting specs and half-integrated half-co-operating implementations with weird quirks and holes in their support. It really needs an EJB 6.2 release that clearly deprecates all the old stuff and documents how it all interacts.

I've finally got to the point, in my efforts to learn about Java EE 6, where I'm starting to see the bigger picture of how it's *supposed* to work, and supposed to fit together. I can see now how it's meant to be simple to use, and if you don't hit any of the exciting bugs it even can be simple to use and nice to use.

The biggest single improvement that could be made to Java EE 6 is the heavy use of the @Deprecated annotation on 80% of the existing public interfaces, and the option to deploy an app in a CDI-only, no-JSF2-injection, legacy-free environment where attempts to use legacy container services are detected as errors (in development mode) or are ignored/fail (in production mode).

It'd also help to have some centralized documentation that's not focused on one particular implementation, framework, etc, and clearly takes account of spec versions so as to disambiguate discussion about J2EE4, Java EE 5, Java EE 6, and Java EE 6.1.