Isn't there a gap to address between (small ?) web applications that can be deployed on highly mutualized platforms with reduced cost, and (big ?) entreprise applications with dedicated servers ?

There is a huge offer of PHP/MySQL web hosting, and now "Google App Engine" just starting as beta, but very limited Java (JEE or just servlet). Didn't the J2EE spec miss something here ?

[quote post="310"]Consider the trend (over the past year or two) by Web CMS vendors toward embedding, bundling, or otherwise targeting Tomcat as a runtime framework instead of, say, JBoss.[/quote]

Would that be the same CMS vendor mentioned here.

http://www.jroller.com/robwilliams/entry/alfresco_and_spring_a_canto

A CMS that clearly shows how you can easily exceed the heavyweight of EJB with Spring alone. Maybe they moved to Tomcat hoping to save some memory footprint for all those config files, factories, and beans. Why pay the price for two implementations of the same thing - ignoring the different colored wrapping.

William

Hi Rod,

I never really cared much for Spring's XML nightmare and I think you can see this on TSS postings going a long way back well before your recent announcements. I have always challenged your gangs view of transparency and lack of coupling to Spring via XML which in itself is actually a coupling. Maybe you should do a little bit more searching. That does not mean that I do not recognize the market shared gained by Spring and the need for a management solution which we delivered.

I am getting tedious? Your bad mouthing of other companies is not? Other companies in your words is practically everyone other than SpringSource "As the standards and the products based upon them have gathered pound after pound of cellulite"

Lets re-edit you blog entry picking out what you are trying to say.

[others]… Loser….bloated, overweight, tired, ….. drained…..morbidly obese legacy…. decline
[springers] leaner
[others]… lukewarm… gasp….bloatware
[springers] greater modularity…. radical change … rejuvenate
[others] …. pound after pound of cellulite chubby
[springers] competition
[others] continued monopoly …… many cumbersome and irrelevant legacy APIs….

Wow and that was not the entirety. I do not think I could take anymore of this talk if that is what is called.

Rod I find is ironic that as soon as you went commercial that your first offerings in this space are actually bloatware in themselves and this is not just talk. Anyone who has ever studied information visualization or read a chapter in one of Edward Tufte books would quickly realize that your "new commercial" stuff is full of complete and utter chart junk (chart junk in the technical sense with regard to data to ink ratio) and ironically built on the foundations that you keep telling us is bloatware.

William

To be honest - William makes an excellent point. IMHO Spring is now at a point where its 'conceptual surface area' a term coined by Joshua Bloch is getting (too?) large. Due to the constraints of being backward compatible, and the fact a lot of stuff out there uses Spring, the framework has left its 'green field' and has to try to stay focused. With the trend of 'right sizing' the JEE platform, the Spring framework is at risk to become the bloated stack of the (near) future.

Rod,

I'll agree with most of what you are saying , but maybe I'm missing something when you say

[quote post="310"]The market will need to address the gap between Tomcat and WebLogic/WebSphere.[/quote]

I thought that was the sort of space that both Spring and JBoss were aiming at? E.g. When you need Tomcat and just 1 or 2 other Enterprise features such as messaging or transactions. Both JBoss and Spring appear modular enough to use in this fashion. And both are pushing OSGi and modularization. And both are much more capable than just this 'middle space'.

Or was this trailer for your next blog post where you pull back the curtain and reveal Spring as the answer?!

Paul

William,

[quote post="310"]Anyone who has ever studied information visualization or read a chapter in one of Edward Tufte books would quickly realize that your "new commercial" stuff is full of complete and utter chart junk (chart junk in the technical sense with regard to data to ink ratio) and ironically built on the foundations that you keep telling us is bloatware.[/quote]

I share your dislike of "chart junk" and my did my PhD thesis on getting it out of the development process. I also studied infoviz, am a big fan of Tufte and have read his books and attended his seminars. But I have a pretty different point of view on your bloatware argument. Even if Spring were not the most concise way to represent an application, the combination of configurability, simplicity and power have made it a de facto choice for building Java apps. Assuming that it were possible to have a more concise combination of language and framework, I doubt that the resulting apps would be 2x as concise because the underlying problem is essential complexity (discussed further in a JDJ article. A framework that's simple enough to make apps concise and powerful enough to support their essential complexity should be sufficient to become a standard programming model for enterprise Java. And that's where I think we're at with Spring.

The problem of the remaining "chart junk" that shows up in our daily development activities stems from the fact that for any task that we do, a lot of Java and XML that's unrelated to the task-at-hand keeps polluting the screen. For this reason the SpringSource tool suite has incorporated Mylyn's Task-Focused Interface, which, simply put, cuts all the irrelevant junk out of what you see when you're programming. To see what I mean check out the screenshot in my recent blog posting.

So even though everyone may not agree, I think it's pretty neat that we're seeing SpringSource putting such an emphasis on cutting the fat from both the framework and the tools.

I'm wondering…how is Spring going to avoid becoming the next Java EE bloatware and stay lightweight as it adds onto its stack. As Spring continues to expand offerings like the Oracle Advanced Pack, etc. it is growing into a bigger monster than the lean, lightweight framework it started out as. Will Spring keep the framework clean and lightweight by simply droping legacy support, leaving the users of Spring 1.x, 2.x, without forward compatibility? How is the Spring Framework, and its extensions going to avoid becoming the next "legacy" and stay lightweight?