June 26, 2006
Redhat should have bought interface21 instead of JBoss
With the direction Spring is heading in with pitchfork and the new extensibile 'nice' config with the namespace support, I think Redhat may have made a mistake. Spring as a basic framework is probably the nicest one out there right now. I think JBoss's LGPL and heavyweight perception when compared to Spring will work against it and I wonder if it's as easy/clean looking to integrate third party stuff with it as it is with Spring 2.0 now. I don't know, of course, because I can't look at JBoss at all (gotta love viral software licenses). I'm posing a question here, not stating a fact or even an opinion.
But, that said, it'll be interesting to see how the two fare in the marketplace. JBoss SEAM seems a trump card but bijection is hardly a new idea but they've done well in applying it more broadly than just JPA.
The area that I think is Springs greatest strength is in integrating third party stuff in to it. The new namespace configuration is pretty cool. I saw examples of it with Tangosol Coherence and declarative caching somewhere last week and the fact that it can configure third party libraries now as cleanly as it's own ones is a killer feature.
It's an area thats neglected in the standards community which the focus is mainly APIs. JavaEE has connector configuration but it seems too narrow a scope whereas the Spring stuff obviously can configure pretty much anything with a JavaBean in front of it.
I think in the race for a lightweight application server (notice I didn't say J2EE application server) I think Spring is top of the pile right now and it can be bolted on top of almost any application server on the market or used standalone. This pitchfork stuff is interesting, trying to figure out whats in it for BEA, maybe an upsell when JTA/clustering is required.
As far as Sun goes, I don't understand at all. They seemed always against subsetting the Java EE spec but this is exactly what seems to be happening now. The market seems to want to cherry pick which JSRs are in their application server of choice and update those JSRs independantly of the others which makes an overall spec like JavaEE less important for them, i.e. they want everything in J2EE 1.4 and JPA but nothing else, as an example. This isn't the way I thought you could even license the stuff.
Anyway, gotta look to see how I can get ObjectGrid in the Spring Modules stuff. I noticed the source for the coherence work isn't in the Spring Modules source code (all Apache licensed so I can actually look at it for a change) but it's been reference in a couple of articles so far.
June 26, 2006 | Permalink
Spring has already lost the race. By refusing to take part in the JCP and help guide the direction of Java. EJB3, though clearly not as feature-rich as spring, solves the problems that Spring was trying to solve. It actually solves them in an easier to understand way than spring does. People can argue that interceptors and injection are limited out of the box, but it solves peoples need and is standard. Spring has lost. As for being on the cutting edge, Seam makes Spring look like last generation technology. It's a more powerful model, and the approach to integration is simpler.
Posted by: | Jun 26, 2006 7:15:34 PM
Fighting words. But, I can understand why they don't want to do the JCP trick. I reckon it takes at least 2 person years to be involved in a JSR. Thats 2PYs of time for probadly one of your better guy/gals. It's 2PYs that you are not innovating, thats 2PYs on implementing a subset of what you already had which isn't what you would have if you'd been able to continue innovating for 2PYs. I know this from my own experience with this.
EJB 3.0 injection does not do what Spring does, it does a limited subset (surprise, surprise). It cannot configure/wire non J2EE artifacts. It does wire connectors, ejb-refs etc but what if all you do is servlets, what does it buy you then? What does it buy you if you already used Hibernate+Spring and a servlet container. It's standards based but you could argue a defacto standard already existed. It was also portable across runtimes and it worked regardless of the application server version. What if you're running on an older application server version, what good is EJB 3.0 when you need to upgrade the whole runtime to get it. This is whats wrong here. We forgot about customers. They don't want to upgrade just to get an improved particular feature. We took this advice with the ObjectGrid which is available and fully functional on WebSphere 5.0.2 and higher, customers running open source runtimes or customers running competitive runtimes. Springs does this. A standard doesn't give you this.
There are a lot of advantages to a runtime which is portable when compared with different implementations with standard APIs. Same implementation means consistency because no matter how good a TCK is, there are always differences. But, take Spring Vx.y and move it from WebLogic to WebSphere, and it works exactly the same. Sometimes, a common implementation rather than a standard API is what you want.
It also doesn't address configuring third party non J2EE components like caches etc. Springs new config stuff is very cool.
The good news is that EJB 3.0 can be extended using interceptors so that people can continue to use Spring to wire their apps past the EJB level.
As for Spring and SEAM, apples and oranges. Not comparable. What SEAMs does is generalize bijection from JPA to HTTP sessions, JBoss workflows etc. Thats cool. But, it's a different topic. I view both as innovative and not competing technologies.
Posted by: Billy | Jun 26, 2006 8:56:30 PM
Where did you get your 2 person year for a JSR figure from? Is it from personal experience?
As someone who has considered a JSR (Joa-Time) the impression of work sounds about right, but I'd love to know where you got that figure from.
Posted by: Stephen Colebourne | Jun 27, 2006 7:05:13 AM
JSR 236/237 and many others at IBM. 2PYs is what we estimate it takes to do the TCK or RI plus the meetings, the reviews etc. It's a pretty serious dent on who ever does it's time.
Posted by: Billy | Jun 27, 2006 8:16:38 AM
Thanks for the info. It definitely looks like the JDK won't be getting a new datetime API then, as I'm not going to spend 2PY of my personal (non-work) time on it!
Posted by: Stephen Colebourne | Jun 27, 2006 8:34:24 AM
If you're not doing the RI/TCK then it may not be so bad. So I wouldn't get too discouraged if thats not the case.
Posted by: Billy | Jun 27, 2006 9:42:59 AM