With Weld 1.0, the reference implementation of JSR 299 – Java Contexts and Dependency Injection now released, attention at JBoss has no doubt turned to Seam 3 which is going to be built on top of Weld. Red Hat and JBoss are committed to returning innovations back the JCP as is the case with Seam which not only resulted in JSR 299, but has also influenced a number of other JSRs especially JSF 2. With JSR 299 standardizing the Seam ‘style’ of development it also brings about a some fundamental game changes for Seam 3 (hence the title) as much of the strength of Seam becomes part of the JEE standards.

One problem I have with Seam is the all-or-nothing level of intrusion it has. I’m either working on a Seam app, or I’m not, and I pretty much have to commit to it at the start of the project. One thing Spring had going for it was you didn’t need to commit to it initially. You could start your web app, and then just add in a little bit of Spring at a time. You could continue adding Spring until it is littered all the way through your code.

Developers can be finnicky at times, and find topics such as heavy app servers and framework lock-in (even to the standards) to be more of an issue than they should be. On this level, Seam really lost out since it was based on standards, ran on an app server (although it ran in many environments), and there was a degree of lock-in as a Seam project, not much more than any other framework based project.

However, Seam itself is an excellent framework and it certainly helped make JSF 1.2 a more usuable framework. Most of those holes are now patched permanently with JSF 2.0 which logically would mean that JSF 2.0 is up to par with JSF 1.2 plus Seam. Well, not quite, although JSF has come a long way I think the one reason Seam soothed a lot of pains was not just down to the fact that it made JSF 1.2 usable. It was also because of the additional functionality it provided above and beyond the average web framework. First was the conversation scope which not only provided a more versatile scope than request and session scope, but also laid the foundation for resolving other problems. With conversation scope we are able to easily handle multiple browser windows/tabs, including independent page flows within those tabs as well as providing Workspace management. Second, it was a full stack solution with a (softly) predefined set of libraries providing different pieces of the stack. No more piecing together different technologies and getting it to work properly, you got everything in one bundle to create stateful rich web applications.

There are probably interesting times ahead for Seam with the evolution of JEE 6 and the release of CDI. EJB 3.1 continues the trend of making EJBs easier than ever, JSF 2.0 makes it a more pleasant experience (now with AJAX), and Weld now provides us not only with a standards based, contextual dependency injection framework, and also makes conversational applications possible out of the box. Many of the great things Seam offered is now available in JEE 6 as part of a standard stack. This is an exciting prospect for developers and makes the JEE 6 stack far more attractive, but doesn’t it also reduce the need for Seam?

JEE 6 isn’t simply Seam standardized, nor is it even Seam lite. There are still a number of larger features in Seam not available in JEE and rightfully so since there are a number of functions which are too specific to be standardized. This particularly applies to the features that span across multiple technologies that fit into neither the CDI, JPA, or JSF libraries. Interestingly, the Seam name would also still be suitable as a framework used to stitched them all together which was originally the concept for Seam. JSR 299 offers not only a firm base onto which you can implement those features, but allows implementing them as expansion plugins to the CDI framework through which most of Seam 3 will be implemented.

My hope is that Seam 3 will consist of a set of fairly independent plugins that can be added to applications in the form of CDI / JSF plugins so there is less lock-in and more of a sense of adding Seam where it is needed. This way we don’t need to start with a Seam application from the start, we can start with a standard plain old JEE 6 web application using EJB, CDI, JSF, JPA and add the Seam features as needed. Another benefit here is that when we add Seam components in such a manner, we are not adding framework code, we are adding features that works on top of our existing framework since the base code for such features is already in the JEE stack. This has worked well in the past on various different platforms, specifically in Java with JSF and the different component libraries available for it.  I think this softer approach to integration will make it more appealing in the long run, . While JEE 6 may have lower barriers to entry for this functionality, JBoss have shown they are able to compete in such environments, for example on the JSF front they have previously competed with different stateful and conversational frameworks.

Overall, things are looking very interesting for the future of JEE 6, and its progress has sparked a resurgent interest from developers. JSR 299 fills an important gap in JEE giving developers a powerful and feature filled standard web stack which can be extended easily. While it may remove some of the need for Seam, it also offers more opportunities for Seam to integrate with the new stack effortlessly and build on it with more features.