Ryan has posted 17 posts at DZone. You can read more from them at their website. View Full User Profile

Bill Burke's Interesting Perspective on Java EE Standards

  • submit to reddit

A well known Spring biased / anti Java EE personality wrote the following comment in an article comparing Spring MVC's RESTful web service API with the Java EE 6 standardized JAX-RS API:

Spring MVC REST annotations caught up, and may have surpassed the JAX-RS annotations. I'm looking forward to new and exciting features that a single entity like SpringSource can pump out; a JSR committee can't have as quick feature turn around.

A well known proponent of Java EE standards, Bill Burke of JBoss, responded with:

I think that's a bit unfair. JAX-RS is a specification not a product. I'm sure JAX-RS implementations like Jersey, RESTEasy, and CXF can innovate just as fast, probably faster, than anything SpringSource comes up with. The difference is of course, that these projects will bring back their innovations to a future JAX-RS revision so that all can share and so that such an important API isn't controlled by one commercial company.

IMO, its just sad that SpringSource has the inherent need to do their own thing for something as trivial as JAX-RS.

When another commenter listed a handful of features that the Jersey implementation has built in addition to the standard API, Bill writes:

Yeah, RESTEasy supports same kinda stuff, but additionally asynchronous HTTP, client and server caching, interceptors, and an annotation-driven client framework. I know a lot of the stuff in Jersey, RESTEasy etc. will be in the next revision of the spec. IMO, specs aren't for innovation, they are for consolidation.

Bill made very good points, and I'm glad he helped to balance the view for readers. Hopefully insightful comments like these help to undo the damage from years of venomous anti-Java EE propaganda that the Spring community has been subjected to.

Other good examples of consolidation are the JAX-WS, CDI, JPA, Bean Validation, and JSF 2.0 specifications.

From http://www.ryandelaplante.com

Published at DZone with permission of its author, Ryan Developer.

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


Reza Rahman replied on Mon, 2010/02/15 - 12:58pm


Thanks for pointing out the flip-side of this often used fallacy. "Standardization vs. open-source" is indeed a totally false dichotomy (curiuosly similar to the arguments made by some of the non-open source commercial vendors). At any given time, any standards compliant implementation (open source or not) will have features that go beyond the standard (the best of which go into a future revision of the standard by gaining acceptance through collaboration in a standards body). RESTEasy and Seam 3 are good examples of that, as is our CanDI, EJB 3.1 Lite or JAAS/security implementation in Resin. This on it's own, I don't think is good enough reason for being too tightly tied to any single product (unless the gap is particularly wide like Spring 2.0 and EJB 2.x). It is a good reason to keep an eye out on various implementations and choose the best one available at any given time for a given project. This is especially true of highly pluggable products like JSF, JPA, JAX-RS and JAX-WS.

I disagree with the opinion that standards just consolidate and don't innovate on their own right. When vendors come together, they innovate in the process of standardizing as well. Good examples of this are the annotation paradigm in EJB 3/Java EE 5, a lot of the CDI (JSR 299) features as well as curiously enough, JAX-RS itself. I doubt this is Bill Burke's opinion since we has one of the folks that are responsible for EJB 3.0/Java EE 5.



Ryan Developer replied on Mon, 2010/02/15 - 2:32pm

Thanks for the comment.  I think Bill's point about consolidation is that if a new standard API is going to be created, then there should be multiple existing solutions to feed from.  Improvements can and should be made during the standardization process with input from developers who have a lot of experience in that domain. 

JSR 310 Date & Time API is making imrpovements to the Joda Time API.  Interestingly it looks like JSR 310 is being revived and might possibly make it into Java SE 7:


Would you say Joda Time is innovative, or JSR 310?  Or both?  I would say Joda Time is innovative, and JSR 310 is doing some necessary refactoring to make it fit in cleanly with Java SE. 

When people say standards bodies should not try to innovate, one example comes to mind: Container Managed Persistence in EJB 2.x.  TopLink and other ORM products were around, but the expert group chose to create something entirely new that was ultimately deprecated and replaced with an API based on TopLink & Hibernate.  I think that kind of innovation within stnadards bodies should be avoided.  Some people think the same about JSF 1.0.  I don't have an opinion on that because I haven't studied JSF's origins or the web framework landscape of that time period.

Reza Rahman replied on Mon, 2010/02/15 - 3:02pm in response to:


I understand what you are saying, but like anything else in life, I don't think it is sound to make too many generalizations.

Yes, we all know that EJB 2.x was a bad idea. However, as I mentioned, there are many examples where innovation through the standard is effective (and in some cases unavoidable). It all depends on who is doing the innovating and why they are doing it. From a personal standpoint, I would certainly not be shy of bringing up good ideas in an expert group or opening up a JSR if there is true technical merit. One value of the standardization process that I have seen is that weak ideas and edge case features often don't make the final cut. It's also important to note that developers do have input into the standardization process, just as they have into an open source product for example. The most visible means of such input are the many independents that work inside the JCP (myself included).



P.S.: As much as there are many problems with EJB 2.x/EJB 1.x/CORBA that persisted way too long, the fact is that it did bring many ideas to the mainstream that influence us even today - for example the idea of declarative services provided transparently by a run-time. The same I think applies to the early versions of JSF too (BTW, I do think that JSF 1.x+Facelets+RichFaces and JSF 2 are excellent solutions).

Comment viewing options

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