On InfoQ, Spring's Jürgen Höller says this about the EE 6 Web Profile:

Implementing this profile is not very attractive. I am yet to see a vendor who is aiming to implement this profile but not the full profile.

So I asked Scott Ferguson from Caucho. He replies:

We definitely are aiming for the web profile.

So I hope that's the last we hear of this particular item of FUD. I promise to keep you guys up to date with future FUD, as it emerges.

By the way, I have friends who are using Resin and the built-in CDI implementation, CanDI, with great success.

Matt Corey writes:

Whew, it's been a while since I've started looking at what's new in Java EE 6, partially because I've been fiddling with the newest addition to the Java EE portfolio -- JSR-299, aka CDI, f/k/a Web Beans, and this one could be big... Let's start with a bang -- CDI will eventually push EJB to obscurity...

The good news is that Matt seems to like CDI. The bad news is that for now there are questions out there about how CDI and the new managed beans spec affect the future of EJB.

Matt goes on to say:

CDI has the potential, I believe, to provide all of the most commonly used services that the EJB spec provides, and let's face it, this mean transactions, timers, asynchronous process with MDB's, and now Singleton Startup beans.

My take on this is a bit different. First of all, it's important to understand that there is no such thing as a CDI bean. CDI applies to any managed bean. Some managed beans are EJBs. When we need to use the EJB services in a managed bean, we just add a @Stateless, @Stateful or @Singleton annotation, and away we go. Nevertheless, it doesn't seem necessary to require this lifecycle annotation if all we want to do is add declarative security or transaction management to a bean.

My view, for now, is that we can divide the functionality defined by the EJB spec into two categories:

1. functionality which makes most sense for components which are entrypoints to the application - endpoints for remote invocations delivered via RMI, HTTP or message-oriented middleware, and
2. functionality which should be available to beans which are part of the internal implementation of the application.

In the first category I include things like:

• the basic stateless/stateful/singleton lifecycle model, which has always made most sense for entrypoints,
• remote and web service endpoint interfaces, and
• message-driven beans.

In the second category, I would put:

• declarative concurrency management,
• declarative transaction management, and
• declarative security.

Even though these things are most useful at system entrypoints, they are also needed at a finer grain. And they're also needed for entrypoints which are not EJBs - for example, Servlets. So I think it's very likely that Java EE 7 will generalize these features to work for all Java EE components. That's certainly what we'll be arguing for.

If EE 7 does move in this direction, you'll be able to use plain managed beans in many cases which currently require EJB, and EJB itself will take on a clearer role in the EE architecture. EJB will be the spec with defines the programming model for remote and asynchronous invocation endpoints. It's likely that with this more focused identity, EJB will be a more manageable technology.

Of course, there's going to be couple of things which don't fit clearly in either category. The ones I'm most doubtful about are timers and asynchronous methods. These could, perhaps, be generalized to all managed beans, but it's not clear to me that there's a real need.

DZone recently interviewed me about CDI and Weld. Please, no more jokes about the hat. I had a horrid morning that day and had to run off to the interview without a shower, breakfast or coffee.

I called EE 6 the beginning of a whole new ecosystem. Some of you guys are probably thinking this is hyperbole. Well, here's why I think it's possible.

For several years, web application developers have been trapped between too much and too little. A servlet container like Tomcat doesn't provide all the infrastructure they need, missing critical items like transaction management, persistence and container managed beans. But many teams also feel that Java EE containers like JBoss have been forcing stuff down their throats that they simply don't need or want to know about. They don't need or want a CORBA ORB, support for EJB 2.x, a web service stack, EARs, remote EJBs, etc.

Meanwhile, vendors like JBoss have also been trapped. The EE brand is important to us since it signals to our customers that code written for our platform is portable to other implementations of Java EE, and that existing applications that were written for our competitors' products can easily be ported to run on our platform. Unsurprisingly, we share the opinion of many developers regarding the usefulness of certain technologies that were required by Java EE. For example, most of us were shaking our heads in astonished despair while the lemmings were following each other off the WS-WXYZ cliff a couple of years ago. What we've had to do is quietly implement these bits and then hope that our users don't actually use them for anything.

Other vendors, such as Caucho, chose a different path. A small company, the cost of implementing everything that was required by Java EE, including many technologies that just weren't interesting to their customers, was simply too great a burden. So they provided a servlet container, with a partial implementation of certain EE APIs. Of course, potential customers could never be certain about portability between Resin and other servers.

In this confusing environment, many developers rejected EE, and cobbled together their own stack of technologies based upon a plain servlet container like Tomcat. Since integrating these technologies was difficult - servlet containers have never provided much support for framework integration - solutions like the Spring framework popped up, with pre-built integration for a wide variety of technologies. Spring eventually involved into a proprietary container that competes with the EE platform. Unfortunately, the proprietary nature of Spring has resulted in vendor lock-in and slower innovation. Innovation in Spring has been so slow that Spring itself now looks decidedly creaky and old-fashioned compared to technologies like CDI that arrived much later.

Java web development is now so fractured that it's very difficult for framework developers like me to write code that works in all these environments. For example, transaction management, for which a complete, standard, solution has been available since 2002, is now a total mess.

Here's how Java EE 6 changes all this.

The Java EE Web Profile defines a smaller container, with just the technologies that most developers really need: servlets, JPA, JTA, CDI, EJB Lite. That makes EE easier to implement, which might result in a more vibrant market, with more implementations, and shorter release cycles. It definitely removes the main reason many developers give for not adopting Java EE.

Even better, the CDI portable extension SPI makes it much easier to integrate technologies into the Java EE environment. And, since some CDI implementations also run in a plain servlet container like Tomcat, CDI can also serve as a foundation for integrating technologies into these environments.

Thus, we've laid the technical foundation for a new ecosystem. A platform developers can be comfortable with, that lets vendors focus on things their customers actually care about, that framework developers can easily integrate with. The only missing ingredient is for the community to get excited about this stuff. :-)

The Java EE 6 platform, along with Contexts and Dependency Injection, Bean Validation, EJB 3.1, JPA 2 and Servlet 3 have just been approved by the JCP EC. This completely changes the landscape for people developing web and enterprise applications in Java. There's just so much to digest here, and so many problems that are finally solved. EE 6 is something of a new start, and the beginning of a whole new ecosystem. Congratulations!