Java Standards Redux – Spring Licensing Fallout
In this post I talked about how the Java standards are important to ensuring java has a long and fruitful life. This post references Spring as an example but was written before the fallout from the Spring licensing issues. This fallout tends to back up the argument that standards are important, although since there were no standards at the time for Spring to follow, it is not a totally valid position.
Over the years, many people have been knocked for claiming that Spring is a proprietary framework. How can it be when it is open source would often be the argument. Proprietary in its literal sense means that it has one owner or controller which is true for Spring for the most part. A less formal definition when discussing programming, Java in particular, is that it does not follow any open standards. Spring broke a lot of new ground which in many cases, meant that there were no standards or only bad standards to follow. However, a number of developers also bought into using other Spring features like the Templates to aid them in their development.
Now that Spring has penetrated developers code to a large degree, vendor lock in was in place for many companies with large spring based projects and Rod and Co turned off the free beer once everyone was hooked. Again, it’s their business, their platform, and they can do with it as they like.
However, if the Java platform had a set of good standards for defining framework functions, then nobody would seriously bother with a non-standard framework, and nobody would be able to shut off the tap because they could be replaced in an instant by an alternative implementation of the standard. Again, this reinforces the need for good standards (like EJB3.1 appears to be) and also for timely updates to the standards.
4 thoughts on “Java Standards Redux – Spring Licensing Fallout”
Lately I have been playing with Oc4j, Tomcat, Glassfish and JBoss, before that, I had only played with Spring (Tomcat was irrelevant, it was there only to start Spring) and now I have realized why Spring is much more comfortable, even with all the enhancements of JEE5: Spring is ?inside? your application.
But with J2EE is the other way around: Read more: http://luxspes.blogspot.com/2008/07/spring-vs-j2ee-application-servers.html
(I don’t have a blogger/google account so I posted my response here)
While I agree that Spring puts the app server in the code, I’m not sure it is the right answer, or at least, it is the right answer as long as you ignore the reasons it is the wrong answer.
There is a reason for having the app server separate, for having container services that you don’t need to worry about. I think I have mentioned somewhere here that having spring close to your code is nice and comfy, and also removes a lot of complexity that makes Spring attractive.
However, the easy option isn’t always the best option, not that I think complex is always right, but once you get Spring that close to your code, it’s hard to pull it out again. With the app server supplied services,you can (technically) swap them out for alternatives.
Also, note that you can use an embedded EJB alternative (OpenEJB, JBoss Microcontainer) and use it in a Spring like fashion close to your application code and use any web container you want. Plus, when you need to you can go throw it on a big application server.
Apparently, there is some move to standardize some of the factors making different EJB containers so incompatible (i.e jndi naming standards).
Well, I have tried, and switching a project that uses Spring between Tomcat, JBoss, Glassfish and Oc4j is a lot easier than doing the same without Spring, removing Spring maybe hard, but why should I remove Spring? Of course it would be nice to have a standard governing Spring, but the sad truth is that right now, there is no standard that allows me to easily switch from Spring to Guice, would be nice to have that, but until then, I find I work less whenever I use Spring, and I can easily switch from expensive app servers (Oc4j,WebLogic,WebSphere) in to free ones (JBoss, Glassfish, Tomcat, Geronimo,Jonas,Jetty) and I do not even need to learn how to write deployment descriptors, because, you know, there is not even an standard way to define a JNDI datasource in a deployment descriptor that works on all application servers, you have to do it different for each application server… unless you are using Spring.
I have not tried OpenEJB, but JBoss Microcontainer was really dissapointing (it does not seem to be a priority for JBoss guys, it can not even run two Seam apps in the same application server) and it really heavyweight (And I am not talking about dependencies, I am talking about the time it takes to lauch, around 30 seconds, Spring launches almost instantly). And don’t get me started on unit-testing, Spring unit-testing support is easy and fast (compare with the unit-testing support in Seam, initially it looks nice, until you realize it is extreamly slow (more than 20 seconds to launch courtesy of the JBoss Microcontainer).
Spring has been there since 2002 and JEE is still far away from being real competition, it may be true that you can (technically) swap them out for alternatives, but the sad fact is that, right now, (actually not technically) only Spring can provide you with the ability to easy swap between different application servers (and do not even get my started on the nightmare that is having shared .jars between application in the same application server instead of having them inside WEB-INF/lib).
Comments are closed.