Rob Williams is a probabilistic Lean coder of Java and Objective-C. Rob is a DZone MVB and is not an employee of DZone and has posted 170 posts at DZone. You can read more from them at their website. View Full User Profile

JEE6: Change You Can Believe In

09.10.2010
| 8210 views |
  • submit to reddit

At first blush, JEE6 looked like just the transfer of injection consensus to a standard, and a bunch of long-overdue fixes for JSF. But after a week of using it, the cumulative effect is pretty amazing. I still believe that DI has taken a disproportionate amount of the caloric burn of the last decade, but CDI is a positive development. Per my earlier post, JEE5 was more immediately appealing, but JEE6 is the denser, higher fiber offering. It‘s frankly pretty remarkable how well it all hangs together. Today, I was thinking ‘what is the binding agent here?‘ and the answer came to me pretty quickly: JEE6 represents the final victory of a concept that has been in utero for a very long time. Of course I am thinking of the component.

The concept originated from a speech in 1968 that was directed at addressing the software crisis; unix‘s pipes and filters were the first attempt to embody the concept in practice. But, of course, things didn‘t really happen for objects until the end of the 80s, and then the component reemerged. Unfortunately, in the 90s, the concept was saddled up as a means of system/language interop by CORBA, and interapplication integration by Microsoft (OLE/COM). Having programmed both OLE and COM, the former was a complete joke (though interesting) and the latter was interesting, but it washitched to such a pile of schlock, it was painful. Then came Java and EJB, which, let‘s face the facts, was an unmitigated disaster. EJB 2 really only attempted to address the glaringly absurd omission of asynchronicity. Seriously, tacking on a message-driven bean and having a single onMessage method seemed kind of like progress at the time, but in retrospect, makes you wonder what the team thought was a realistic timeframe for a real, comprehensive approach that could hold water.

Here we are. JEE6 may just be the best real realization (reification) of the concept of CbD to have come down the pike. Now, I know that sounds kind of absurd. But consider: http/html is pretty limited, but finally, with AJAX, REST, and continuations, it almost doesn‘t really matter anymore. Despite its flaws, JSF was clearly the right approach because doing interface without any components is beyond absurd. Count on this, if nothing else: the emergence of real component frameworks, e.g. IceFaces, RichFaces, PrimeFaces, was just a warmup. JSF2 is going to make things so much better on the component side of things, we should finally see components that are flexible, layered, adaptable. RichFaces is great, but clearly, it‘s showing the painful effects of swimming against the stream.

John Vlissides, one of the legendary Gang of Four authors, converted to components shortly before his untimely death. It is ludicrous to not see the efficacy of them, not just in the ui, but all the way down to resource layers. Clearly, one of the reasons that it took so long is components don‘t make much sense unless they are part of a system that is pretty comprehensively componentized from top to bottom. Finally, consider the fact that people are deploying serious apps now on glassfish that are tiny. There‘s something kind of scary about being told most of what you need will be waiting for you in the container, but on the other hand, a little anxiety often accompanies tremendous evolutionary milestones.

 

From http://www.jroller.com/robwilliams/entry/jee6_change_you_can_believe

Published at DZone with permission of Rob Williams, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Reza Rahman replied on Fri, 2010/09/10 - 10:59am

Rob,

I have to say this is an excellent and rather accurate take on Java EE 6. Going forward, we do hope to maintain focus on the basic concept of components, declarative services, ease-of-use, near-zero-configuration and modularity as well as expanding the API set where needed (such as perhaps a higher level security API as compared to JAAS).

Cheers,

Reza

Abel Morelos replied on Fri, 2010/09/10 - 11:19am

Great post! I really hope that JEE6 can deliver all the features the community has been looking in other places and painfully implementing/integrating with their solutions. Right now I'm moving to JSF 2.0 for new developments, and I can say I'm really satisfied =)

Henk De Boer replied on Fri, 2010/09/10 - 4:01pm

Nice and articulate article! I agree that it's pretty remarkable how well Java EE 6 hangs together. The CDI model looks very promising and I'm looking forward to see how it continues to evolve.

There is still room for improvement of course. The JSF ManagedBean still exists, and it might be a little confusing for some since this greatly overlaps with CDI (with CDI being the far superior type of Managed Bean).

Then there's EJB3.1, which by itself works great, feels very lightweight and integrates really well with all other parts of Java EE 6. Still, it's a different component model than CDI and one just has a feeling that it doesn't have to be.

One other small thing on my wish-list is that maybe sending JMS messages could do with some small modernization of the API. The current API works with a connection based approach that just feels a little old-fashioned and verbose. Most projects I encountered that use JMS have created some sort of wrapper for the JMS api. Receiving (JMS) messages with Message Driven Beans is really easy, so why shouldn't sending be?

Cloves Almeida replied on Fri, 2010/09/10 - 4:58pm

Henk, the Seam guys are trying to make CDI the "lingua franca" for component development, wrapping and extending "obsolete" component models like JSF and EJB.

The best part about CDI is that it was built with extensibility in mind. This means (and work is already in progress), that simply by adding a jar to your war/ear file, you could @Inject a Topic/Queue, Event<Message>.fire for producing a message, or @Observe incoming messages.

And being contextual, only the producer must deal with instantiation/connection and other lifecycle related tasks. Think of it like GC vs manual memory allocation. The application logic gets so much cleaner.

I'm really impressed by JEE 6. And for those that want a great component-oriented alternative to JSF I recommend Vaadin, a server-side only, swing-like, GTW based presentation framework. IMO, ahead of JSF 2.0

Henk De Boer replied on Fri, 2010/09/10 - 5:05pm in response to: Cloves Almeida

Indeed, Seam is doing some amazing stuff, including plugging a few holes that JSF 2.0 'forgot', like injection in converters and validators.

Can't wait for the Seam 3 final ;)

Wujek Srujek replied on Fri, 2010/09/10 - 5:46pm in response to: Henk De Boer

And I can't wait for any of the EE 6 compliant application servers to be final, really final, meaning: working, production ready. Currently neither JBoss 6 nor GlassFish 3.x are usable. I have spent numerous hours hunting bugs, creating test cases and filing bugs, just to see that they remain untouched (GF). I got older by a few years in the last 3 weeks, during which I worked with GF and tried out JBoss. I invented so many workarounds for bugs found while trying to invent workarounds for yet different bugs that I simply lost count what is what. Don't get me started on GF 3.0.1 'supposedly' Final that dates back to 19.12.2009, which was so broken that even EAR deployment for anything a little more complex that trivlal didn't work.It's 8 months after that date, and still not really much better, 3.1 focuses on features (clustering, for example) rather than fixes.

Don't get me wrong, I love the general ideas of, say, CDI - I read the specs, and they look promising; it's the current implementations that makes me grit my teeth.

Henk De Boer replied on Fri, 2010/09/10 - 5:57pm

Well, the JBoss AS 6 M releases are clearly marked as beta/alpha quality, so you really shouldn't expect much of them in term of stability.

Overall I do agree that the amount of bugs in many 'production ready' systems is insane. Hibernate for instance has so many bugs, it's not funny anymore. How could any AS build with Hibernate ever be certified? Half the functionality defined by the JPA spec simply doesn't work on Hibernate because of bugs that have been open for -years-.

And take Eclipse. Don't get me wrong, I love this IDE, but the amount of bugs is just unbelievable. Are really so many people using Eclipse? How do they all cope with these bugs?

It really doesn't matter where you look, JBoss AS, Spring, Wicket, even Tomcat... so many bugs, so many headaches because of them...

I do wish that vendors first and foremost address the stability in their products. Yes, I would like some additional things in the Java EE spec to be addressed, but this desire simply pales compared to the wish of having stable implementations of stuff.

Nicklas Karlsson replied on Mon, 2010/09/13 - 12:16am

I hope that the "Managed bean" concept will be streamlined more between CDI/EJB/JSF in the future. And that *any* server-instantiated component can be made injection-enabled. I'm not saying all components *should*, just that the option would be nice.

Rob Williams replied on Tue, 2010/09/14 - 12:04am in response to: Henk De Boer

Amen, Brother.

King Sam replied on Fri, 2012/02/24 - 9:32am

IMO, JEE getting closer to Spring on every spec revision increment, while some clever(!) experts of it spreading little obstcales against its father to prevent it being fully compliant with the specs. Like difficulty in implementing CDI on top of Spring DI. Anyway, at least it is nice to know they are on the right track, and not loosing their way :-)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.