InfoQ has published a their questions and my answers about CDI and Weld.

A developer new to Java EE posted in the Weld forum asking for advice on getting started learning EE 6. I've decided to promote part of my response in the forum to the blog.

So, what should I start learning. Java EE 5 and Seam? Java EE 6 and Weld? Is there any learning material about 6 and Weld right now?

Unless you plan on putting your system into production inside the next 2-3 months, you should start learning CDI and Weld. CDI defines the basic infrastructure you'll use to get the various kinds of Java EE components working together (and much more).

You also need to decide what web framework to use. This is the hard bit for most people.

• You could use plain servlets and JSP, which in EE 6 both include out-of-the-box CDI integration. However, most people prefer to use something with more features. But honestly, if you're new to enterprise Java, it's not a bad place to start. The latest servlet spec lets you use annotations, which is a big step forward in usability.
• JSF2 is included as part of the platform, and is integrated with CDI out of the box. Many people find JSF difficult to learn. We believe that for some kinds of applications, it pays off in the end. Unfortunately, most of the books and articles about JSF make it appear much more complex than it actually is. In particular, the specification is horribly written and not worth reading (so I won't link to it). Take a look at the Weld examples to get a taste of what JSF2 is really like.
• An option we recommend is Wicket. Wicket is an alternative to JSF that is easier to learn. Weld comes with Wicket integration.
• There are many other possibilities including about a thousand frameworks which are basically alternatives to the servlet API. Struts2 and Stripes seem like popular options. I don't find any of these kinds of frameworks very interesting or sexy, but they're usually easy to learn. It should be very relatively easy to integrate any of them with Weld.
• A final option worth mentioning is GWT. GWT is an entirely different beast, with its own Java to JavaScript compiler. It's great for certain kind of application. We should have GWT integration for Weld available very soon.

My personal view is that you should start out by looking at either JSF and/or Wicket, unless you're truly a beginner at this, in which case start with writing some plain servlets. If these options don't suit your needs, cast a wider net.

You'll also need a persistence solution. For most people writing EE 6 applications that means JPA2. There are at least three excellent implementations of this specification to choose from, including ours. You'll probably want to use JPA2 together with Bean Validation.

Once you've got a handle on CDI, JPA2, and whatever web framework you decide to use, take a look at EJB 3.1, and the more advanced functionality it offers for integrating with data stores and messaging, and managing asynchronicity. Unfortunately, the EJB spec itself is quite hard to read, so you should probably try to find a good tutorial. Be careful, there is still a lot of information about EJB 2 out there on the web. EJB 3.1 is a quite different beast.

The question of backward compatibility is something that all framework developers wrestle with. The term means different things to different people:

• For some folks, it means that JAbstractFactoryBeans 2.0 is allowed to add new features to JAbstractFactoryBeans 1.0, but shouldn't change the way we do anything that 1.0 already does.
• For others, it means that JAbstractFactoryBeans 2.0 should continue to support all the APIs and metadata formats that JAbstractFactoryBeans 1.0 supported, but that it is allowed to provide new, improved approaches to the old problems.

I'm often of the opinion that both of these require too much; that as long as there is a reasonable migration strategy from JAbstractFactoryBeans 1.0 to JAbstractFactoryBeans 2.0, together, possibly, with some kind of interoperability between the two framework versions, then you're doing your users a favor by encouraging them to migrate their code to the new, better approach.

But this kind of thinking definitely doesn't wash in the JCP. Within the JCP, Red Hat represents one extreme. We're always pushing for changes, for replacing the old broken stuff with something better. At the other extreme, however, are the folks who believe that evolving things slowly is an excellent goal in and of itself, that almost anything which disrupts existing users is to be treated with extreme skepticism, and, perhaps, that admitting mistakes makes us look bad. (Yeah, sure, you're right, I guess that's a somewhat unfair characterization.)

What's really interesting about EE 6 is that Sun found a new trick to balance the competing interests. Rather than drop support for a bunch of broken stuff (entity beans, web services, and a couple of other embarrassments), Sun came up with the notion of profiles. All the good, useful stuff gets called the web profile. All the other stuff is still supported, but it's only required in the full profile. (Full of ... ?, I hear you ask.)

I'm exaggerating slightly. There are a few useful things (for example: JMS, timers, async methods) in the full profile that are not in the web profile. But vendors are allowed to provide those things if they like.

If you've been living under a rock, here's what's required:

The following technologies are required components of the Web Profile:

• Servlet 3.0
• JavaServer Pages (JSP) 2.2
• Expression Language (EL) 2.2
• Debugging Support for Other Languages (JSR-45) 1.0
• Standard Tag Library for JavaServer Pages (JSTL) 1.2
• JavaServer Faces (JSF) 2.0
• Common Annotations for Java Platform (JSR-250) 1.1
• Enterprise JavaBeans (EJB) 3.1 Lite
• Java Transaction API (JTA) 1.1
• Java Persistence API (JPA) 2.0
• Bean Validation 1.0
• Managed Beans 1.0
• Interceptors 1.1
• JSR-299 1.0
• JSR-330 1.0

Actually, there were some folks in the EE EG who argued very hard that the web profile should be even smaller than this. They thought (think?) that the EE web profile should be basically servlets, JSP, and then whatever proprietary frameworks tickle your fancy. We made the case very strongly that this was a step too far, and that the web profile should contain everything you need to be able to build a web application. That the platform should be the basis for an ecosystem, not a way to bless totally proprietary stacks.

The concrete benefits of this new web profile include:

• a smaller set of technologies for folks who found the full EE overwhelming (and folks like me, who find some of it underwhelming)
• a lower barrier to entry for implementors (watch out for guys like Caucho, who should be able to build out Resin into a compliant Web Profile)

The truth is, the pace of change of a platform is one of the hardest things to get right. Go too fast, and your users waste time having to constantly adapt to semi-arbitrary changes. I've seen some frameworks alienate their communities that way. Go too slow, and you get behind the curve, encourage the growth of competing alternatives, and divide the ecosystem.

Modernizing Java EE has been a long, hard struggle. I'm sure most users think we erred on the side of too slow. But I think the new Web Profile is the first EE release that gets it right.