Views on CDI and What’s New in JavaEE6

In the light of this article which was criticized for not mentioning JavaEE6, I’m going to discuss JavaEE6 innovations.

JavaEE 6 is still new – only one application server is certified and ready – Glassfish. JBoss AS is on the way. So, what is new in JavaEE 6:

  • EJB 3.1 – EJB Lite – a lighter version, excluding MDBs, web services, remote ejbs, timers, corba and the new @Asynchronous annotation. @Asynchrounous invocations (like in Spring) allow for a method to be invoked in a different thread (and return immediately). A new thing is also the embeddable EJB container (EJBContainer.createEJBContainer()) for easier, out-of-container unit-testing.
  • JSF 2.0 – annotation support, ajax support, new scopes. Much easier to work with than JSF 1.2
  • CDI – that’s the big difference from JavaEE 5 – CDI is a JavaEE-wide dependency injection framework.
  • The Web profile – the most used pieces of JavaEE (servlets, jsp, EJB, JSF, CDI, JPA,..) can be supplied by an application-server vendor. The server will be certified as implementing the Web profile, without the need of implementing all the rest of JavaEE that is more rarely needed.
  • JNDI names should be standard – i.e. different containers are not given the choice of JNDI names.
  • More things that I’m not aware of, but a re probably also improvements

Now this all sounds good – new features coming in, simplifying development. As mentioned, the most powerful addition seems to be CDI.

Why I can afford to write about CDI? I chose my university graduation project to be a partial implementation of JSR-299 (the CDI JSR), so I’m familiar with the whole specification. (Before you start wondering – why would a student be experienced enough to make any judgmenets – I’m studying remotely, and meanwhile I have more than 3 years experience as a full-time Java developer). It should be noted that Gavin King and the expert group have done a great job in specifying a standard DI framework, and have covered a lot of corner cases. There are a lot of articles on CDI already, so I’ll just mention some of the major points:

  • JSR-330 annotations support (@Inject, @Qualifier, etc)
  • Qualifiers are not strings – they are java types (annotations), so you have compile-time safety
  • interceptors and decorators – two distinct ways of adding functionality to existing objects (AOP is a term to mention regarding these two)
  • events – used to promote loose coupling – a DI implementation of the observer pattern.
  • inject most JavaEE components in most JavaEE components – you can inject EJBs, JSF managed beans, JavaEE resources, transactions, persistence contexts, etc. And you can inject these into servlets and other EJBs, JSF managed beans. The most important thing is that you can have just POJOs and inject them in other POJOs – something missing previously in the EJB injection model (you couldn’t inject a helper class for example – it had to be an EJB)

One thing that is still strange to me about CDI is the notion of bean archives. All classes in a jar/war archive that has beans.xml (can be empty) and meet some standard requirements (non-abstract, non-inner, etc) are eligible for injection. But when you think of it – how many times have you started your application, forgetting to annotate your spring/guice bean? For me it’s not quite rare.

Now, onto some concerns that I have about CDI:

  • interceptors are only annotation-based. This is sufficient in most cases, but I find the AspectJ syntax very useful from time to time. For example you can declare that all methods of classes in a given package (and its subpackages) are intercepted by a given interceptor. You can’t do this in CDI. One can argue that you shouldn’t, because it’s not the correct way, and you should actually use an interface, and, say define a decorator for it, but the AspectJ syntax is really practical.
  • no XML. This is “advertised” as a huge plus, but it’s also a drawback. Sometimes you want the beans that are most central to your application to be defined “in one place”. It’s easier to trace, reconfigure, etc. In spring, for example, you can have zero-XML as well, but I still use it for some of the beans. Mostly those that are more configuration-related and less functionality-related. (Yes, there is an extension for CDI that adds xml support)
  • Runs portably only in JavaEE environment. It’s logical since it is part of JavaEE, but it could really be handy if it was standardized to run in a servlet container. Yes, there are extensions that allow this, but more on that in a while.
  • “Annotationary” – since there is not xml configuration, there are a lot of annotations. The typical scenario would require only two annotations (@Inject @SomeQualifier), but at some point your classes might start looking “very annotated”. For class-level annotations especially. Yes, you can use a stereotype, but there is no point in creating a stereotype for 1 bean.
  • In order to instantiate 3rd party beans, i.e. such that are not in bean-archives, you need a producer. Not so much of a headache actually, but I wonder how will these producers that exist simply for the sake of creating 3rd party objects be structured in the project.

I haven’t verified the above in practice, so they might turn out to be minor drawbacks. The final drawback that I’m going to comment is highly subjective, but it expresses my views on CDI and JavaEE 6. This drawback is the attitude of JavaEE-people. More specifically – the JBoss guys. Most of their presentations start with rants about how bad is spring. “Moving away from the clutter of spring” was a sub-title of a webcast, and there are many more like this. If these accusations were true, or in some way defended by the presenters/writers, it would be only a personal dissonance. But all of their points are contrived:

  • spring is not “cluttered”. Spring provides a lot of extra goodies, but you can include only these jars that you need. If you need JMS, you get the JMS jar. If you want JPA or Hibernate support – get the respective jars. If you don’t want to use Spring MVC, you don’t need get the webmvc jar. Check the maven dependency graph of spring 3 and you’ll see some very substantial effort.
  • XML is not bad. Already discussed that above. And spring does have options for zero-xml config. (JavaConfig)
  • spring is easy to work with and is productive. This is the main reason people are using it. It is not the hype. The hype was there 6 years ago. It is flexibility and maturity that are considered now when people choose spring.
  • Spring is not proprietary and evil. Spring is still open source and likely to remain so. True, it is backed and developed by a large company, but which major software project isn’t?

Another thing worth mentioning – while accusing spring of being cluttered, JBoss have already developed a lot of portable and non-portable extensions for Weld. Soon there will be more, to support other commonly-used libraries, and here we’ll be facing a ‘clutter’ again. Furthermore, some of the most important extensions are not portable. The one that allows running Weld on Tomcat, for example.

In regard to portability, which was the main point of my previous article – I still can’t say much. Perhaps because there is only one application server available. When JBoss is out there will still be only one CDI implementation, because Glassfish uses Weld as well. Note: there are 2 more CDI implementations, but they are not yet GA). The thing is CDI is very JBoss-driven. This is not bad per-se, so I’m just stating this view without any conclusions.

I still suspect that it will be impossible to write fully-portable JavaEE applications. After all it is logical for companies to want to hold their customers. And in this train of thought – it is logical for JBoss guys to hate spring publicly, even though they realize their points are not valid – they have to drive more people into JavaEE, and leave less to spring. (Yes, I’m still making this comparison – spring vs JavaEE, because it is in most cases the choice a company has to make when developing a product)

As a conclusion – I like how the new things in JavaEE sound, but I guess that’s true for any new framework / spec. Real criticism will appear when it starts being used. CDI sounds like a powerful DI framework, especially with its good integration with all other JavaEE components. What I don’t like in all this is the attitude of the competing groups, which both claim the other technology is bad (yes, spring guys also criticize CDI, and according to Gaving King – without any arguments. But I haven’t actually read any criticism from spring’s side.) The general points about JavaEE, and the reason why it has lagged behind, which I made in my previous article, are still valid, but I hope to a lesser extent.


13 thoughts on “Views on CDI and What’s New in JavaEE6”

  1. FTR there are three CDI implementations — Weld (from JBoss), OpenWebBeans (from Apache) and CanDI (from Caucho).

    Pete (one of the JBoss guys who is always ranting about how bad Spring is 😉

  2. @Pete – yes, thanks for the note, I know these three (have them checked out), but at the time of writing only Weld is GA (OWB is alpha2, and CanDI is “early access implementation”). I will clarify the original post.

  3. @Gurkan ah, 1 day after my post there is a release of OWB 🙂 It’s not even reflected in their recent news.

  4. Hi,

    Points 1+2: “interceptors are only annotation-based.” and “no XML.” are really the same point made twice 😉 There was, in an earlier draft of the CDI spec, a facility for configuring CDI injection, interceptors, and decorators using a typesafe XML format. After much negotiation within the JCP, it was decided to remove this functionality from the first release of CDI. Instead of XML, we got an SPI for portable extensions that among other things let’s you write your own XML / Java / DSL configuration format. Personally, I think the world is much better off with the SPI than it would have been with just an XML format. The Weld project has gone ahead and implemented something very similar to what was in the spec, and in some future release of CDI, that stuff may be reinstated if there is truly community demand for it (of which I’m somewhat skeptical).

    Point 3: “Runs portably only in JavaEE environment.” This actually isn’t true. Certain features of CDI won’t be available in Java SE, because the underlying EE functionality they refer to aren’t available. But that doesn’t mean that the CDI implementation’s behavior is not well defined under Java EE. I was actually pretty careful to make sure we explicitly identified any functionality which was EE specific. The spec says stuff like:

    “An application that takes advantage of these services may be designed to execute in either the Java EE environment or the Java SE environment. If the application uses Java EE services such as transaction management and persistence in the Java SE environment, the services are usually restricted to, at most, the subset defined for embedded usage by the EJB specification.”

    “All containers must support managed beans, producer methods and producer fields. Java EE and embeddable EJB containers are required by the Java EE and EJB specifications to support EJB session beans and the Java EE component environment. Other containers are not required to provide support for injection or lifecycle management of session beans or re- sources.”

    “Beans and their clients may be deployed in modules in a module architecture such as the Java EE environment. In a mod- ule architecture, certain modules are considered bean archives. In the Java EE module architecture, any Java EE module or library is a module. The Java EE module or library is a bean archive if it contains a beans.xml file, as defined in Sec- tion 12.1, “Bean archives”.”

    Thus the true core of the spec is abstracted away from Java EE.

    Of course, the title of the spec, and the “javax.enterprise” package naming that were both forced upon the EG by Google as a condition of their EC vote doesn’t reflect the fact that CDI also works in Java SE, but that’s politics for ya!

    Not going to comment on Spring anymore, since I think the message that Java EE doesn’t suck is well and truly out there now. But note that a couple of years ago we were having to swim against a tide of folks brainwashed by 5+ years of anti-EE propaganda from SpringSource and others, and it was necessary to be kinda loud and direct to get people to pay attention to the innovations that were going on inside the JCP.

  5. “But that doesn’t mean that the CDI implementation’s behavior is not well defined under Java EE.”

    I mean:

    “But that doesn’t mean that the CDI implementation’s behavior is not well defined under Java SE.”

  6. @Gavin thanks for your extensive comment.

    For the interceptors I was actually focusing on the missing AspectJ syntax (which can be defined via annotations as well). But I guess AspectJ can be added as an extension.

    About the 3rd point – running portably only in JavaEE – for example there isn’t a standard listener (or ELResolver) that would bootstrap the application in a servlet container. Or how do you boostrap CDI in a desktop app. Apart from that I fully agree that the core is JavaEE-agnostic. (What I implemented for my project didn’t have the EE “extras”)

  7. “for example there isn’t a standard listener (or ELResolver) that would bootstrap the application in a servlet container.”

    Well, it seems to me that kinda goes with the territory, more or less. If you’re outside of Java EE, then you can’t expect tight integration with Servlets, JSP, JSF, etc, since these things just aren’t a part of the SE platform.

    “Or how do you boostrap CDI in a desktop app.”

    Well, I admit that it would be nice to have something like the standard boostrap API that JPA has. And certainly a number of EG members were in favor of that. Frankly it’s something else that wasn’t going to be doable politically in CDI 1.0. I expect to see it in a future release of CDI.

    But it’s not really a good reason to use something other than CDI when you’re working in an SE environment, since any other solution, by definition, is also missing a portable bootstrap API. A CDI solution is, at worst, more portable than any non-CDI solution 😉

  8. “For the interceptors I was actually focusing on the missing AspectJ syntax (which can be defined via annotations as well). But I guess AspectJ can be added as an extension.”

    I doubt there would be major difficulties in writing a CDI portable extension that added CDI interceptors according to an Aspect-J-like syntax.

  9. “Well, it seems to me that kinda goes with the territory, more or less. If you’re outside of Java EE, then you can’t expect tight integration with Servlets, JSP, JSF, etc, since these things just aren’t a part of the SE platform.”

    I expressed myself badly. What I mean to say is that you can’t expect tight integration *defined by the specification*. A particular implementation of CDI (e.g. Weld, or OWB) can (will) still provide this tight integration. Indeed the Java EE integration that *is* defined by the spec would give you really, really good guidance on what this integration should look like.

  10. obviously like your web-site but you have to take a look at the spelling on quite a few of your posts.
    A number of them are rife with spelling issues and
    I in finding it very troublesome to inform the reality nevertheless I’ll surely come back again.

Leave a Reply

Your email address will not be published.