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.
7 comments:
It's very interesting article. Thank you for information.
I'm a "A well known Spring biased / anti Java EE personality" (with an emphasis on "well known" :).. thanks!).
I'll follow up on InfoQ, but I was trying to make 2 points there:
1) The Spring Framework has the advantages and disadvantages that come with not being spec compliant
2) Spring MVC Framework has been around for half a dozen years and has a built-in inventory of functionatly that can be used as part of an AJAX web stack
I would like to note that I'm a RESTEasy committer. I also did have some fun with my comment on InfoQ. I'm also glad that the two Bills added counterpoints; I was really hoping for an interesting conversation out of my comment.
Thanks for the comment. If you are looking for an interesting conversation out of your comment, then check out the JavaLobby re-posting:
http://java.dzone.com/articles/bill-burkes-interesting
JavaLobby sometimes re-posts blog entries that they find interesting using my user account. I didn't think this one would be front page material but apparently it is.
A newbie question...JavaEE is container dependent. If i create an app , i need JavaEE server to run that. (As far as i understand) Spring on other hand, does not need any specific server. It can run on any tomcat based server. Please correct me if i am missing something. Is it possible to decouple javaEE from container ? Is there any implementation of JavaEE which is just drop-in ?
Jigar, that is a good question. Java EE is made up of a few dozen specifications that cover a wide range of technologies such as a web framework, SOAP web services, REST web services, container managed transactions & security, asynchronous messaging, etc. When building an application, you don't use everything in Java EE, you use only what you need. Some things, such as container managed transactions and security, add extra features to your classes. To make that work, the container creates an instance of the class for you and you access it through a proxy. That is exactly how Spring does it. Spring is a container too. Containers are not a bad thing. Servlets also run on a container. Tomcat is a servlet container.
Most implementations of specific Java EE APIs can run in tomcat. For example, if you want to use EJB 3.1 in Tomcat you can use OpenEJB. If you want to use JPA in Tomcat you can use Hibernate Entity Manager. If you want to use JSF in Tomcat you can use the RI or MyFaces. If you want to use JAX-RS in Tomcat you can use Jersey, RESTEasy, etc. The thing is Tomcat is bare bones and gives you pretty much nothing. You have to build your own stack of technologies for your application. With a Java EE application server all of the technologies are available out of the box. You just use what you need when you need it. You don't need to bundle 20 MB of dependencies in your .war file, so your .war file stays lean. Application servers like GlassFish V3 dynamically loads only the modules your application uses. It starts up as fast as Tomcat and uses very little memory.
Another benefit of Java EE is that it makes decision making easy. Need RESTful web services? JAX-RS. SOAP Web services? JAX-WS. Dependency injection? CDI. Web framework? JSF 2.0. etc. In the .NET world developers do not have a dozen competing technologies for every single decision they have to make. Java EE standards offer the same thing for Java developers.
I sometimes think that using Tomcat, integrating a dozen libraries and frameworks by hand, and maintaining those libraries (upgrades) is similar to creating and maintaining your own Linux distribution.
Using Java EE is like using a well known, well maintained, widely used Linux distribution like Ubuntu or Red Hat.
Sure the Linux kernel (Tomcat) and is popular, but you also get the Linux kernel when using commercially maintained distribution. For example, GlassFish and JBoss have Tomcat built-in as the servlet container.
Thanks for the valuable info
Post a Comment