BT
x Your opinion matters! Please fill in the InfoQ Survey about your reading habits!

Spring 3.0: Java 5 Required, Adds New Expression Language and REST Support

by Ryan Slobojan on Dec 16, 2009 |

A new version of the Spring Framework, version 3.0, was released today. InfoQ spoke with Juergen Hoeller, technical lead of the Spring Framework project, to learn more about this release and the changes that it brings to the Spring portfolio.

Hoeller indicated that the major new features which are present in Spring 3.0 are:

  • Java 5 required - The core APIs have been updated to use Java 5 features such as generics and annotations, and Spring 3.0 now requires Java 5 or later
  • Spring Expression Language (SpEL) - Similar to the Unified EL found in JSF, construction of rich expressions is now greatly simplified
  • Extended support for annotation-based components - Some of the Spring JavaConfig capabilities have been migrated into the core framework, such as @Configuration, @Bean and @DependsOn
  • Declarative model validation using constraint annotations - JSR 303 support has been added, and validation rules can now be added to beans using annotations such as @NotNull and @Max(23)
  • Comprehensive REST support in Spring MVC - Support for building RESTful servers and clients has been added
  • Java EE 6 support - Many of the Java EE 6 features such as JPA 2.0 and JSF 2.0 are supported, and they work on non-EE 6 containers like Tomcat and J2EE 1.4 app servers
  • JSR 330 support - The javax.inject annnotations introduced by JSR 330 are now supported
  • Annotation-based formatting - Bean fields can be automatically formatted and converted using annotations such as @DateFimeFormat(iso=ISO.DATE) and @NumberFormat(style=Style.CURRENCY)

A comprehensive changelog and reference documentation are also available.

Hoeller touched upon SpEL in a bit more detail:

SpEL is a rich expression language that syntactically follows Unified EL, quite similar to the use of expressions in JSF. We have our own expression parser with special capabilities that we are taking advantage of: for use in bean definition configuration but also for use in projects like Spring Integration. In Spring core, "#{...}" expressions may be used in many places such as XML bean definitions and @Value annotations, dynamically referring to other beans by name and dereferencing their properties in a concise fashion.

For example, the following XML block (from the 3.0 documentation) uses SpEL to configure the properties of a Spring bean by reading from the JVM's System properties:

<bean class="mycompany.RewardsTestDatabase">
    <property name="databaseName"
        value="#{systemProperties.databaseName}"/>

    <property name="keyGenerator"
        value="#{strategyBean.databaseKeyGenerator}"/>
</bean>

The new REST support was also explained a bit:

Our challenge was to bring REST support to the world of Spring MVC, putting powerful new functionality into the hands of MVC users. We decided that native MVC support for path variable extraction, content negotiation etc was the right way to go here - considering Spring MVC's strengths and taking them to the next level, without breaking the fundamental architecture. This worked out well and makes it straightforward for existing Spring MVC applications to adopt REST features too.

Our primary focus is on web user interfaces following REST conventions. Next to that, there is also an increasing interest in REST-based web services on a Spring MVC basis, in particular in combination with the OXM (Object/XML Mapping) module that became part of the Spring core now. Finally, we are providing client-side support in the form of a Spring-style RestTemplate class, for interacting with a REST-oriented backend server programmatically.

For those who are on Spring 2.5 and who have updated their code to follow the annotation-based style which was adopted in that release, the upgrade path should be a smooth one - new features may be used selectively after upgrading to 3.0, and no fundamental architectural changes are needed. For those who are using older variants such as the form controller class hierarcy, these are still supported in 3.0 but are now deprecated. To use new 3.0 features, a move to the annotation-based @MVC style is required. For Spring 2.0 users, 99% of the code should continue to work, however older components such as Apache Commons Attributes, WebLogic 8.1 and WebSphere 5.1 support have been removed.

When asked about future plans for the Spring Framework, Hoeller said that development will continue to be heavily influenced by the other projects in the Spring portfolio, such as Spring Integration, Spring Web Flow, SpringSource dm Server and Spring Roo. For the 3.1 release, the feature set will be heavily influenced by Spring Integration 2.0 and Spring Web Flow 3.0 with capabilities such as first-class conversation management, extended support for scopes, and refinement of the annotation-based component model being planned. After the planned release of 3.1 in mid 2010 there will be a follow-on 3.2 release, but the specific plans for 3.2 have not yet been finalized.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Fix the links, please... by Nikita Ivanov

Fix the links, please...

Re: Fix the links, please... by Ryan Slobojan

Hi Nikita,

Thanks for the catch - all of the URLs in the documentation apparently changed between RC3 and GA, so what worked last night didn't work this morning. :)

I've fixed up all of the links in the article above.

Thanks,

Ryan Slobojan
Chief Editor, InfoQ.com

Spring 3 vs EE 6 by William H

I don't want to start a tedious flame-war but with both Spring 3 and Java EE 6 out of the door I'm curious to know which platform architects would choose for a new project and why.

Re: Spring 3 vs EE 6 by adrian collheart

As it is, most java developers have probably been using technologies that Spring was inspired by for several years now.

In short, who actually cares about any of this? I know I don't and I earn my money writing server side Java code (eclipse, Java EE, Jboss). I think whatever makes it into a Java EE release matters more than anything that made it into a new Spring release.


Okay, just kidding ;) This was a typical Spring fan reply I copy pasted from one of the many Java EE news blogs that we saw the previous days and where I interchanged "Spring" and "Java EE".

I can't really give you an informed answer though. Personally I would choose Java EE, but this is just my personal preference. I've yet to check out what exactly it is that Spring 3 offers. Overall it's very exciting though that two of the top Java frameworks have both seen a very major new release a nearly the exact same time.

Re: Spring 3 vs EE 6 by totoro totoro

I would continue to use spring because I have lot of experience with it. Of course I would use JEE annotations for JPA, validations, etc.

Re: Spring 3 vs EE 6 by Gavin King

I would continue to use spring because I have lot of experience with it. Of course I would use JEE annotations for JPA, validations, etc.


Suppose you had the option of using CDI annotations in Spring for dependency injection, just like you have the option of using JPA annotations and APIs with Hibernate, and Bean Validation and some of the common annotations stuff in Spring today. Would you use them? If not, why not? If so, don't you think it would be good for Spring to give you the option?

Spring 3 by Gavin King

So, judging only from the "major feature" list (and I accept that lists like this are always simplifications and don't necessarily reflect all the work that went into a release), this release sounds quite disappointing, given the major version number increment.

Java 5 required


Not really a "feature" as such.

Spring Expression Language (SpEL)


This looks like more or less a straight copy of what we've been providing in Seam for several years. Interestingly, we've begun moving away from this stuff, because we don't love the lack of typesafety.

Extended support for annotation-based components


From my cursory review of this stuff, this looks far inferior to the approach taken in CDI. It looks like an annotation-ized version of the Guice Java-based bean declaration. i.e. a kind of Java-based replacement for XML-based bean declarations. In my opinion, CDI does much better by simply eliminating the notion of centralized configuration entirely. Perhaps at some very abstract level, the Spring @Configuration and @Bean stuff is similar to CDI's @Produces and @Alternative, but from what I can see, I think CDI gets much closer to the ideal of "configuration by exception". And of course, since CDI was not carrying a lot of legacy baggage, it has a cleaner model overall.

(P.S. Before flaming me on this, take the time to actually learn CDI and understand how CDI addresses this stuff.)

Declarative model validation using constraint annotations


I'm very happy to see that Spring has adopted this stuff. Bean Validation is a really useful spec, led by Emmanuel Bernard from the Hibernate team (and I'm proud to say I contributed a couple of ideas to this spec), and is a required part of the EE 6 platform. I hope that the Spring team is also open to adopting and supporting the CDI APIs.

Comprehensive REST support in Spring MVC


For RESTful web services, I'm actually really impressed by JAX-RS, which is part of the EE 6 platform. I've never been even slightly impressed by Spring MVC. There are better action-based web frameworks around. (Of course, I'm a fan of component based web frameworks like JSF and Wicket.)

Java EE 6 support


While I would certainly like to see Spring get on board with the Java EE web profile, it's worth pointing out that for now, Spring's idea of "Java EE 6 support" is that Spring provides patchwork integration with *some* Java EE 6 technologies. The ones mentioned here are JPA2 and JSF2. But Spring already had integration with JPA and JSF, so it sounds as if they have not done much actual work here. I guess this line item got added by the marketing team, to capitalize on all the EE6 buzz.

JSR 330 support


You can read my criticisms of JSR-330 elsewhere. This is a bait-and-switch spec, which provides no real portability between implementations. It's not even a real spec - it's actually just 5 annotations with javadoc. It can't be used alone, without some additional vendor-specific APIs. (In the case of Spring, XML or @Configuration/@Bean.)

If you want a truly portable solution for dependency injection, you need a full JSR-299 implementation. I hope the community puts pressure on the Spring folks to implement not just 330 but also 299.

Annotation-based formatting


I suppose this is nice.

But, overall, not very impressive. I'm sure the guys have done plenty of work which is not mentioned here, but from this list it seems very difficult to rationalize the major version number increment.

Spring/Java EE Comparison/Contrast by Reza Rahman

I actually did a presentation a few months ago covering what was publicly visible for Spring 3.0 and Java EE 6 in it's still unapproved state. Here it is for anyone interested in taking a look: www.redhat.com/f/pdf/jbw/rrahman_320_spring_fra.... I primarily did it as a tool to see what Java EE might have been missing. I welcome comments on the slides - always good to get more eyes on it...

Generally, I agree with Gavin - I'm not sure what makes this worthy of a major release other than marketing. I think CDI is still a much more intuitive, powerful and clean-room DI system, much like Guice, although it looks like they did make an attempt to add some Guice/CDI-like features in the Java Config/JSR 330.

It also does not solve the fundamental issues I've always had with Spring - increased configuration complexity, legacy bloat and being a non-standard solution now from a commercial company.

At any rate, I wish Spring developers and users best of luck for the new year. Congratulations on the hard work...

Cheers,
Reza

Re: Spring 3 by Adam FitzGerald


(P.S. Before flaming me on this, take the time to actually learn CDI and understand how CDI addresses this stuff.)


I believe that you should be taking your own advice. Your last sentence confesses that there is a lot of work that has gone into Spring 3.0 that you are not aware of, yet you feel compelled to "educate" the rest of us about Spring 3.0. That seems very hypocritical. If you do want to learn more, I suggest first reading Juergen's Spring 3.0 blog post and then the new Spring 3.0 documentation.

Additionally, Spring 3.0 runs on every major enterprise Java application server: the new Glassfish release as mentioned in Juergen's blog, your very own JBoss server and even older versions of many application servers. I think that clearly identifies what a "truly portable solution for dependency injection" should be.

Adam FitzGerald
SpringSource

Re: Spring 3 by Reza Rahman

Adam,

I've looked at both and agree 100% with Gavin. Can you point out what education us ignorant Java EE guys need? What makes it difficult for Spring IoC to fully implement CDI? Rather, what objections to CDI do you have?

Cheers,
Reza

Re: Spring 3 by Gavin King

I believe that you should be taking your own advice. Your last sentence confesses that there is a lot of work that has gone into Spring 3.0 that you are not aware of, yet you feel compelled to "educate" the rest of us about Spring 3.0.


I'm not sure why you put the word "educate" in quotes. I never used that word, and I certainly don't claim to be a Spring expert. But of course, I have worked closely on several competing and related technologies, and I'm sure there are some folks out there who are interested in hearing my take. I note that Spring folks are never shy to let the rest of us know what they think of Java EE related technologies.

That seems very hypocritical.


In what way? I think my post was in good faith.

If you do want to learn more, I suggest first reading Juergen's Spring 3.0 blog post and then the new Spring 3.0 documentation.


I did, of course, review the relevant documentation sections before writing my post. Thanks for the link to Juergen's blog entry. It does indeed mention a couple of additional features, which are again disappointing. Support for the Portlet 2 specification doesn't excite me in the slightest (portlets are a solution in search of a problem). The supposed "Next-generation scheduling capabilities" seem to have a spooky resemblance to the capabilities that have been introduced in EJB 3.1.

So nothing game changing, IMO.

Re: Spring 3 by Adam FitzGerald

Hi Gavin,

The hypocrisy in your statements is clear. You request people to "actually learn" about your own project before criticizing it, yet then profess to not know about the features in Spring 3.0 while criticizing it. Thank goodness that you cleared things up by stating definitively that you are not a Spring expert. I will now be able to weigh your opinion appropriately.

Adam FitzGerald
SpringSource

Re: Spring 3 by Arbi Sookazian

Adam,

I've looked at both and agree 100% with Gavin. Can you point out what education us ignorant Java EE guys need? What makes it difficult for Spring IoC to fully implement CDI? Rather, what objections to CDI do you have?

Cheers,
Reza


I viewed Reza's JBoss world slides comparing EE6 vs. Spring as well as read JHoeller's blog post on Spring 3. The stereotype model in Spring 3 seems very similar to the stereotype functionality/support in CDI. And of course there is some "catch up" stuff in there like SpEL, REST support and timer functionality that was available in EJB3.0.

I don't see how this set of upgrades warrants a new major release of 3.0, you'd think it would be Spring 2.x. Nothing ground-breaking or revolutionary like CDI which enables loose coupling and type-safety with very minimal XML.

And I'd like to see an answer to what objections to CDI SpringSource has.

Is there anything new in Spring 3.0 in terms of concepts? Or a completely new MVC frmwk that is component-based? Or new language support, etc.?

Re: Spring/Java EE Comparison/Contrast by Adam FitzGerald

Hi Reza,

Thanks for the congratulations and offering your opinion. Your inaccurate statements about Spring 3.0 concerning configuration complexity and supposed bloat have been refuted in plenty of other places so I'll leave that conversation to the other thread.

Best of luck in the new year to you and I look forward to the development community in general formulating their own opinons about what technology to use.

Adam FitzGerald
SpringSource

Re: Spring 3 by Gavin King

The hypocrisy in your statements is clear. You request people to "actually learn" about your own project before criticizing it, yet then profess to not know about the features in Spring 3.0 while criticizing it.


What nonsense. I know quite enough about Spring and related technologies to be able to make the comments above. I'll let readers judge whether my comments were uninformed. I notice that they are so far unrefuted. Your ad hominem responses does not constitute refutation. (Very weak effort.) Respond to the substance of my comments, please.

Re: Spring 3 by Ryan Slobojan

Hi,

First off, a few months ago I became the Chief Editor here at InfoQ - I say that because I want to make clear that my opinion here is my own, and not that of the site. Ask anyone that knows me, I'm pretty blunt with my opinions, and they often differ from those around me. :)

Now, with that said, I think that the major revision number is most definitely applicable to this release, and it's due to the very first feature listed - Spring 3.0 now requires Java 5. That means that all of the J2SE 1.4 support has been removed, and things like generics and annotations are now used throughout the codebase. That is a major, breaking change and for that reason it should have a major version increment. If I was to guess, I'd also say it was a lot of work - moving all of those application servers over to Java EE 5 was a major undertaking that took a long time, and it was definitely worthy of a major version increment.

Thanks,

Ryan Slobojan

Re: Spring 3 by Nicklas Karlsson

Well, I don't think anyone(?) really cares if Spring calls their next version "Spring 2.5.1" or "Spring 2010", the underlying controversy is the one created by the overlapping functionality of Spring and EE 6.

There is no denying that Spring has a large user base. It would be a huge benefit to the Java community if they would jump on the Real(tm) EE bandwagon and could be harnessed for producing CDI extensions and modules for the technologies that Spring already integrate.

Re: Spring 3 by Juergen Hoeller

Arbi,

Indeed, there are similarities in the stereotype model and in some other parts. This of course doesn't change the fact that those items are key new features for Spring 2.x users and for Java enterprise users overall, since Spring makes those features available on J2EE 1.4 and Java EE 5 platforms as well - today, consistently, and without the need for a server upgrade or change of server product.

Also, Spring 3.0 is an evolution of Spring 2.5, after all: That's what it needs to be compared to in order to understand the choice of version number. There is not much point in comparing it to Java EE 6 and arguing about its version number on that basis.

Nothing ground-breaking or revolutionary like CDI which enables loose coupling and type-safety with very minimal XML.

Loose coupling and type-safe injection are key features of the Spring world since 2.5, and taken to the next level in Spring 3.0. There was minimal XML involved for such a scenario in Spring 2.5 already (basically no more than what's in persistence.xml for a JPA persistence unit), and with Spring 3.0's AnnotationConfigApplicationContext, it's even possible to do it with no XML at all.

Frankly, the only mistake that we may have made was to not use the 3.0 version number for Spring 2.5 already. According to your analysis of CDI, Spring 2.5 was that groundbreaking back in 2007...

Juergen

Re: Spring 3 by Juergen Hoeller

Reza,

I've looked at both and agree 100% with Gavin.

No surprise - you're clearly on the same agenda with Gavin, here and at TSS. You got to sell the same thing, so why should you ever disagree about an analysis that puts Spring into bad light. It's much easier than sincerely trying to understand Spring, after all.

What makes it difficult for Spring IoC to fully implement CDI? Rather, what objections to CDI do you have?

I told you so at TSS already, so I assume this question is just here for the FUD effect of raising the same question again and again.

Let's turn the question around: What makes it so difficult for Java EE to adopt Spring's basic model? Why do you always have to go different ways, making it artifically hard to extend the common ground between Spring components and native EE components?

FWIW, at least we got JSR-330 as some nice common ground now, and also JSR-250 v1.1 with its @ManagedBean annotation. That gets us pretty far. Even if Gavin isn't fond of it because he couldn't impose his views on those specs as much as he could with JSR-299.

Juergen

Re: Spring 3 by adrian collheart

those items are key new features for Spring 2.x users and for Java enterprise users overall, since Spring makes those features available on J2EE 1.4 and Java EE 5 platforms as well - today, consistently, and without the need for a server upgrade or change of server product.


So let me see if I understand this.

Spring saves me from updating Java EE, but then instead I must update... Spring?

Why exactly is that an advantage? If I'm somehow afraid to update, then wouldn't I just as well be afraid to update Spring? I could also say it the other way around; Java EE 6 makes key features available for Spring 2.0 and Spring 2.5 applications, without the need for a Spring upgrade.


There was minimal XML involved for such a scenario in Spring 2.5 already


This is of course all very nice and all, but Java EE clearly took the lead here. That doesn't really matter by itself, since it's only natural that people are influenced by other people, but it does disprove the point Spring zealots always try to make that Java EE supposedly copies everything from Spring. It's undeniably true that Spring influenced Java EE's move away from EJB2, but *much* more has happened since then and it's certainly not true that Java EE follows some imaginary lead from Spring.

Currently I think Spring has clearly been influenced by recent Java EE developments, perhaps more than they are willing to admit. Again, this really should not be a bad thing as it's the healthy kind of competition that keeps both camps on their toes. Maybe Spring 4 will introduce some brilliant new concept that'll deeply influence Java EE 7, or 8. Who knows ;)

Re: Spring 3 by Steve Hicks

For me as a developer where we are allowed a new infrastructure version (i.e. WebLogic version) every two years then being able to update the programming model on an application release is a major benefit. BTW I know of other large projects that are lucky to get an upgrade every 3 years - this mainly is a matter of the cost of all the various test instances and changes to WebLogic operations from one version to another. This and the ease of jUnit integration testing are two major benefits to me in using Spring. However, let the healthy competition continue.

Re: Spring 3 by Juergen Hoeller

Spring saves me from updating Java EE, but then instead I must update... Spring?
Why exactly is that an advantage? If I'm somehow afraid to update, then wouldn't I just as well be afraid to update Spring?

Well, Spring is usually deployed as part of the application, e.g. in WEB-INF/lib. Updating Spring is just a matter of updating an isolated application's libraries, without affecting other applications running on the same server, and without affecting the server itself.

So for example, Spring 3.0 can be deployed on existing WebSphere 6.1/7.0 installations today. Upgrading the server would be a huge and costly affair there - and it's in control of the data center ops team, not in the application development team's hands - whereas upgrading the application's Spring version often doesn't even require a permission by the ops team to begin with (since it by definition only affects that very application anyway, hidden inside its deployment unit black box).

That aside, for WebSphere concretely, there is of course no Java EE 6 version available and won't be any time soon. I think it's fair to say that WebSphere-based data centers won't see Java EE 6 in production before 2012. But not to beat WebSphere here: JBoss 6.0 is at M1 only, and Java EE 6 in the WebLogic world isn't around the corner either. I think it's a pretty big deal that Spring 3.0 can bring such features to the enterprise world *today*, in production, on existing servers.

Juergen

Re: Spring/Java EE Comparison/Contrast by Reza Rahman

Adam,

Good and thanks for the cross-post. We'll see about your claim of "innacuracies" :-). Thus far, I don't see you having any valid objections that I haven't addressed and I fully agree on letting developers make up their own minds with varied inputs.

Cheers,
Reza

Re: Spring 3 by Reza Rahman

Gavin,

You're obviously not alone in the response by personal attack to the slightest criticism :-).

Cheers,
Reza

Re: Spring 3 by Reza Rahman

Juergen,

Hmm..as far as I can see, Java EE bent over backwards to try and support the Spring model, especially by including JSR 330 in Java EE.

And frankly I still haven't heard any concrete reason not to build JSR 299 support in Spring other than "it's too hard" and "our customers don't want it", neither of which I buy...

Cheers,
Reza

Re: Spring 3 by Reza Rahman

Hear, hear. All you have do to in order to see this is the changes in Spring 2.5 and now Spring 3.0 in response to Java EE 5 and Java EE 6 - of course SpringSource will never admit that and continue with their anti-Java EE FUD instead...

They love bad mouthing Java EE whenever they can and are hyper-sensitive to anything that puts Spring "in a bad light" - talk about a double-standard...

Cheers,
Reza

Re: Spring 3 by Juergen Hoeller

Reza, since you apparently insist on ignoring my previous responses to your "Spring must implement CDI" propaganda (for which, BTW, you failed to identify a target audience yet): Let me quote them from TSS for the record. They are a bit more subtle than "it's too hard", after all. (Dear readers who are not from the EE 6 promotion camp: For full context, see TSS.)

With respect to implementing CDI on top of Spring: CDI unfortunately isn't just a set of interfaces or conventions; it is rather a very prescriptive definition of a framework and its runtime behavior. It is more or less impossible to implement it on top of an existing framework without radically changing the established inner workings of that underlying framework beyond recognition. In that respect, CDI is very different from the likes of JSR-330 and also JPA, both of which can easily be adapted onto an existing runtime while preserving the latter's established behavior as well.

It is fundamentally not in the interest of our user community to disrupt the Spring world for no reason other than a spec that has yet to become relevant even in the EE umbrella (see those JSF 2.0 discussions), and is nowhere near production environments yet. The accepted common ground is JSR-330 rather, which does ease migration quite a bit already. And once again, most of our users clearly chose Spring because of its native style, and they explicitly want us to spend our time evolving that native style; that's what we are hearing every time. We'd rather keep the established Spring foundation as it is and optionally enrich it with parts of EE 6; that works just fine for our users, even if it doesn't fit your agenda.

Juergen

Re: Spring 3 by Juergen Hoeller

Hear, hear. All you have do to in order to see this is the changes in Spring 2.5 and now Spring 3.0 in response to Java EE 5 and Java EE 6 - of course SpringSource will never admit that and continue with their anti-Java EE FUD instead...

So I'd never ever "admit" the Java EE 5 theme behind Spring 2.5. Also, I did not mention Java EE 6 very prominently and positively in my Spring 3.0 GA announcement. Furthermore, I did not mention JSR-330, JSR-303, JPA 2.0 and JSF 2.0, since I would never openly embrace those EE technologies. At least in your distorted and one-sided view of the world, Reza, I would never ever do all of this.

They love bad mouthing Java EE whenever they can and are hyper-sensitive to anything that puts Spring "in a bad light" - talk about a double-standard...

OK. So I've been educating the Spring audience on Java EE 5 and 6 for years, at all sorts of conferences, talking about using Spring on EE 5 and 6 servers - and about all the services that those servers have to offer for good use in Spring-powered applications. That's apparently bad-mouthing of Java EE. I guess I'll have to accept that whatever we do, you'll always put us in the same box anyway.

Juergen

Re: Spring 3 by Reza Rahman

Juergen,

I keep asking the same thing because you keep not mentioning specifics. I'd love it if you can provide a simple, concrete example of what's so hard about CDI to implement in Spring. What requires such pervasive changes? If I am to believe you, you made an analysis of this, so why not point out what the specific problem is? The way I see it, the functionality is 80% there...

Now if the real issue is that you honestly don't think your customers care, why not just say that and keep the long-winded horse manure out?

As to my "agenda", personally I think it is great that you guys aren't implementing CDI. For one, this leaves a big compatibility gap that a well-placed plug-in can fill...

Cheers,
Reza

Re: Spring 3 by Reza Rahman

Juergen,

I guess I'll have to accept that whatever we do, you'll always put us in the same box anyway.


If you and SpringSource are really sincere about this, honestly you would have my every kudos. I would love nothing more to try to think of you guys as friends, even if we are competitors - so no I don't want to put you in any box.

If you want the truth (and the human element to this) it is deeply disappointing that you guys did not embrace the Java EE 6 Web Profile and CDI. As I see it, we put a lot of effort so that folks like yourself could adopt it and end the needless fragmentation in enterprise Java. As I see it, that is to everyone's benefit, especially your server offerings.

It is true you've toned down the anti-Java EE FUD quite a bit in recent years. For one, other than vague statements, you have not had any real technical problems with CDI. I suppose that's as far as things will go this time around. So be it...

Cheers,
Reza

Re: Spring 3 by adrian collheart

Upgrading the server would be a huge and costly affair there - and it's in control of the data center ops team, not in the application development team's hands - whereas upgrading the application's Spring version often doesn't even require a permission by the ops team to begin with (since it by definition only affects that very application anyway, hidden inside its deployment unit black box).


I hear you, and I do see your point, but there's also another side to the story.

What you describe is a very ops team centered, big enterprise kind of approach, with stubborn system administrators put against a team of agile developers. My own experience has mainly be the other way around. Adding libraries to an existing application requires permission of the lead developer, and the co-lead developer, and it must be extensively tested for collisions and overlap with existing libraries, etc. This is especially true when it concerns core libraries like Hibernate, JSF and indeed Spring.

With a Java EE AS however, the whole thing is upgraded in one go, and we can be reasonably sure that all pieces are already tested together as a whole. In a way it's similar to deploying a pre-packaged Linux distribution like Debian or Redhat vs starting with a minimal Linux system and then deploying your own kernel and hacking in your own drivers that came from another source. Most companies would rather upgrade to a new major of minor version of the official distribution, then to let some rogue developer hack in some drivers or back ported stuff.

Then there are also the smaller companies who operate only a few servers. Those companies don't really have an ops team at all and they nearly always run a single application on a single AS on a single (virtual) server. Nevertheless, the application they're running might still be using the whole enterprise spectrum of techniques (MVC, ORM, Services, etc), so either Java EE or Spring is an excellent fit for them. In that case, upgrading Java EE or upgrading Spring basically boils down to the exact same thing. Your own parent company (VMWare) should be well aware of this scenario.

Note that I thus definitely don't say you're wrong or anything. I absolutely believe you when you state that Spring has an upgrade advantage for developers in those very large, very corporate centric enterprises. My point is just that there are just as many cases of smaller companies where it's either a moot point which part of the deployment stack needs to be upgraded, or where the Java EE way is actually easier.


I think it's fair to say that WebSphere-based data centers won't see Java EE 6 in production before 2012.


Probably, but those are exactly the large corporate enterprises I referred to above. Glassfish is here *today* too. Jboss is only at m1, but I looked at their jira roadmap and they have 3 milestones planned and 1 release candidate, with milestone 2 somewhere in february. If their planning is on a linear scale, we should see the GA somewhere next summer.


I think it's a pretty big deal that Spring 3.0 can bring such features to the enterprise world *today*, in production, on existing servers.


Once again, this assumes that I can get permission to upgrade the libraries and programming model easily, while I can't do that for the AS. We're mainly a Java EE shop, with only a small handful of Spring based applications in production. Our main product is completely Java EE 5 based. There is just no way, absolutely no way, I would ever be able to persuade the lead developer to add and deploy the Spring 3.0 libraries to our main product *today*. The mere suggestion of doing that might cost me my somewhat privileged position I currently enjoy for doing interesting projects and would condemn me to some maintenance work for the coming months.

Actually doing that *today* might cost me my job. If I really, really wanted to get Spring 3.0 deployed for our main product, then I would probably have to negotiate first for some couple of months, then some small amount of new code might be written that used Spring 3.0, after which a lot of testing would happen to ensure Spring 3.0 and its libs don't interfere with anything we run now, and only after all of that, it might be deployed into production. Most likely we'll be looking at something like a year down the road. That's not exactly *today*, is it? ;)

On the other hand, I could start writing Java EE 6 code *today* (using Glassfish V3), and when Jboss AS 6 is eventually released, that code would simply run on it too.

Re: Spring 3 by Peter Hendriks

I think it's funny how people keep comparing apples and oranges, and calling each other bad names for doing it at the same time. The same goes for straw-man arguments about suggesting that a version increment means something "revolutionary" instead of breaking bw-compatibility (which it technically should mean if there is no marketing involved). Of course, Spring people will say the new version rocks. As will JCP people of their specs, or JBoss people about their products.

I think Spring 3.0 is a great release for a lot of Spring users. A lot of people actually use Portlets, MVC, have an "old" Java EE 5/1.4 server. If you are in a JCP board and inventing new stuff all the time, I can imagine you may find this stinky and useless, but in the real world, you don't have a choice (or you -want- this choice).

As for JSR-330: I think it's fantastic to have a really really simple spec for DI that can be adopted on both SE and EE, by many frameworks with different views on DI. With CDI, Spring, Guice and Eclipse 4 all supporting this, it'll mean a nice common ground that can be mixed easily and don't require relearning. 100% portability is a myth, and although CDI may help more in this aspect, it is also much harder to adopt to for existing code.

CDI is more powerful, and some frameworks provide the capability on EE 5 servers too. CDI does make my head spin from time to time. I think it'll be interesting to see how much of CDI is actually used in practice, and how easy people will learn this. From where I am standing now, DI without the C is Good Enough, but I am open to learn and am glad the option is available.

Re: Spring 3 by Reza Rahman

Adrian,

Thanks for debunking the big scary app server upgrade myth that SpringSource keeps FUDing about...

Cheers,
Reza

Re: Spring 3 by Reza Rahman

Peter,

The same goes for straw-man arguments about suggesting that a version increment means something "revolutionary" instead of breaking bw-compatibility (which it technically should mean if there is no marketing involved).


Thanks for pointing this out.

If you are in a JCP board and inventing new stuff all the time, I can imagine you may find this stinky and useless, but in the real world, you don't have a choice (or you -want- this choice).


I'm not sure this is fair. This is exactly why most Java EE APIs are pluggable, including CDI, JPA and JSF. You can use Seam/Weld on an older application server deployment without a server upgrade. As to portals, honestly I don't see these in wide use.

As for JSR-330: I think it's fantastic to have a really really simple spec for DI that can be adopted on both SE and EE, by many frameworks with different views on DI.


Totally agree with this viewpoint - exactly why I supported JSR 330 despite it's having many important gaps - such as an actual dependency resolution mechanism.

CDI may help more in this aspect, it is also much harder to adopt to for existing code.


The Spring guys keep repeating this, but I just don't see why this is true. Maybe you can help me out here? What's so hard to adapt to CDI? Do you have a specific example? It's annoying because this is something we've paid close attention to while reviewing CDI.

CDI does make my head spin from time to time.


It would be interesting to understand what parts you are struggling with. As such, this is what I thought of CDI too initially, but realized that was mostly because I was reading a spec, not a tutorial. Maybe may CDI series on TSS can help with this?

Thanks for sharing your thoughts and your relative neutrality.

Cheers,
Reza

Re: Spring 3 by Daoud AbdelMonem Faleh


With respect to implementing CDI on top of Spring: CDI unfortunately isn't just a set of interfaces or conventions; it is rather a very prescriptive definition of a framework and its runtime behavior. It is more or less impossible to implement it on top of an existing framework without radically changing the established inner workings of that underlying framework beyond recognition. In that respect, CDI is very different from the likes of JSR-330 and also JPA, both of which can easily be adapted onto an existing runtime while preserving the latter's established behavior as well.

It is fundamentally not in the interest of our user community to disrupt the Spring world for no reason other than a spec that has yet to become relevant even in the EE umbrella (see those JSF 2.0 discussions), and is nowhere near production environments yet. The accepted common ground is JSR-330 rather, which does ease migration quite a bit already. And once again, most of our users clearly chose Spring because of its native style, and they explicitly want us to spend our time evolving that native style; that's what we are hearing every time. We'd rather keep the established Spring foundation as it is and optionally enrich it with parts of EE 6; that works just fine for our users, even if it doesn't fit your agenda.

Juergen


Sorry but isn't a behavior supposed to be part of a standard So my application behaves the same when run on different implementations?

JSR 330 just happen to not define that behavior that boils down to some labels we shall stick on our artifacts and hope they'll run as intended when I switch let say from Spring to Guice or pico-container!
Sorry I'd rather implement it myself and define my intended behavior (think AOP with annotations) then just stick labels that everyone could interpret on his own!

Again congrats for the major release, and please let's put less politricks and marketing push in innovative work :)

Re: Spring 3 by Reza Rahman

Daoud,

Thanks so much for speaking out. We hope that more people in the community will be aware of this issue and press SpringSource to do the right thing going forward...for their own sake and the sake of all server-side developers that would rather not have needless fragmentation in the Java EE DI space...

Cheers,
Reza

Re: Spring 3 by Solomon Duskis

Reza,

Why should I as a Spring user switch to CDI? Why should a Guice user switch to CDI? The Spring guys were not a part of JSR 299 for a variety of reasons. The Guice guys pulled out of JSR 299. The leaders of useful IoC frameworks don't like CDI. I'm not convinced that I'll have more features, be more productive and have long term maintenance advantages with JSR 299. IMHO, it's up to the JSR 299 folks to win us over; FUD and strong arm tactics won't.

Re: Spring 3 by Dorel Vaida

Reza,

Why should I as a Spring user switch to CDI? Why should a Guice user switch to CDI? The Spring guys were not a part of JSR 299 for a variety of reasons. The Guice guys pulled out of JSR 299. The leaders of useful IoC frameworks don't like CDI. I'm not convinced that I'll have more features, be more productive and have long term maintenance advantages with JSR 299. IMHO, it's up to the JSR 299 folks to win us over; FUD and strong arm tactics won't.


I totally agree with the poster and especially with the last 2 sentences. Spring has been a constant source of innovation starting with it's 0.X version which I was very familiar with as I am with the latest versions. Spring doesn't have any obligation, not even a moral one, to implement / follow any standards. I certainly hope they WON'T. If I want to go the standard way, I know where it is. Thanks Gavin and Reza for the Buzz, we've learned about CDI now huh ? :-)

Back to Spring, there is a statement Juergen made earlier which I totally agree with: In essence it states that CDI has to prove itself as a useful thing before Spring goes that way. CDI guys, I can't take your word for it, just calling it so good and complete, right ? If it proves to be useful, I am sure Spring framework/ users will find a way to benefit from it :-)

The purpose of standards is known and aside keeping huge teams / projects in line I don't know any other. If standards keep people warm and safe, it's cool.

I know one thing though: Innovation never came from standardization efforts. So that's why it's good Spring (and others) exists and desn't go standard. Because when everyone did go standard and everyone agreed with each other, EJB happened !. And arguable even worse, Struts happened. And while compared with JSP intermingled with HTML Struts is heaven, other much more innovative and evolved frameworks as WebWork (not to mention Tapestry which was generations ahead anyone at that time :-) ) were put into shadow because Struts was or eventually became supported by a lot of standard or semi-standard people

Gavin, I am not affiliated with anyone at SpringSource and I certainly don't want another flame war started but I remember when I was arguing with JBOSS people, but I don't remember if it was you or others, it doesn't even matter, I was arguing about how Wicket was rocking any java web framework to date (at that time) so I am glad you guys like it now, as a 'component framework' :-)

So standard or non standard, good technology is easy to recognize. And I am not sure pushing it down one's throat is the way to evangelize it. Nor bashing other established or de-facto standards by saying they don't have enough features to justify the version number =)) that was hilarious. If the Spring guys will increase the version weekly I don't care as long it's readable in one line :-D

Re: Spring 3 by Dorel Vaida

Oh and btw, the Spring guys did start some projects (small ones) which are quite innovative. I let you discover them so the surprise will be more pleasant :-)

Re: Spring 3 by Senthil Kumar

Reza,

Why should I as a Spring user switch to CDI? Why should a Guice user switch to CDI? The Spring guys were not a part of JSR 299 for a variety of reasons. The Guice guys pulled out of JSR 299. The leaders of useful IoC frameworks don't like CDI. I'm not convinced that I'll have more features, be more productive and have long term maintenance advantages with JSR 299. IMHO, it's up to the JSR 299 folks to win us over; FUD and strong arm tactics won't.


I totally agree with the poster and especially with the last 2 sentences. Spring has been a constant source of innovation starting with it's 0.X version which I was very familiar with as I am with the latest versions. Spring doesn't have any obligation, not even a moral one, to implement / follow any standards. I certainly hope they WON'T. If I want to go the standard way, I know where it is. Thanks Gavin and Reza for the Buzz, we've learned about CDI now huh ? :-)

Back to Spring, there is a statement Juergen made earlier which I totally agree with: In essence it states that CDI has to prove itself as a useful thing before Spring goes that way. CDI guys, I can't take your word for it, just calling it so good and complete, right ? If it proves to be useful, I am sure Spring framework/ users will find a way to benefit from it :-)

The purpose of standards is known and aside keeping huge teams / projects in line I don't know any other. If standards keep people warm and safe, it's cool.

I know one thing though: Innovation never came from standardization efforts. So that's why it's good Spring (and others) exists and desn't go standard. Because when everyone did go standard and everyone agreed with each other, EJB happened !. And arguable even worse, Struts happened. And while compared with JSP intermingled with HTML Struts is heaven, other much more innovative and evolved frameworks as WebWork (not to mention Tapestry which was generations ahead anyone at that time :-) ) were put into shadow because Struts was or eventually became supported by a lot of standard or semi-standard people

Gavin, I am not affiliated with anyone at SpringSource and I certainly don't want another flame war started but I remember when I was arguing with JBOSS people, but I don't remember if it was you or others, it doesn't even matter, I was arguing about how Wicket was rocking any java web framework to date (at that time) so I am glad you guys like it now, as a 'component framework' :-)

So standard or non standard, good technology is easy to recognize. And I am not sure pushing it down one's throat is the way to evangelize it. Nor bashing other established or de-facto standards by saying they don't have enough features to justify the version number =)) that was hilarious. If the Spring guys will increase the version weekly I don't care as long it's readable in one line :-D

+1
Can't agree more.
I posted my similar thoughts here

Re: Spring 3 by adrian collheart

Because when everyone did go standard and everyone agreed with each other, EJB happened !. And arguable even worse


Well, hate to break it to you, but because of STANDARDS I could actually compile the C code I wrote on my SGI indy to run on my Linux box. Thanks to standards my browser on my Mac can actually make use of this website, and so can people using Windows with maybe a completely different browser. Due to standards, a bunch of queries that I have can be used on different databases. And even though the standardization in DB world is anything but perfect, the differences between dialects are minor and the mental model is the same.

More directly related to this, thanks to standards, we have been able to move three times between application servers. First we moved away from Websphere to Orion, since Websphere became to costly for us and ate too much resources. Then we moved away from Orion since they stopped releasing new versions and embraced Jboss. If it weren't for standards, we would not have been able to make these moves. We would still have been running on Websphere, which at least still exists, but suppose we wrote our code originally for Orion and every API we used was Orion specific? Then we were simply screwed and would have to rewrite our app from scratch for some other technology, possibly keeping parts of it running on Orion in the background for a very long time to come (think about those ancient apps still running on some 70-ties mainframe, with layers of wrapper code around them, simply because each layer was using proprietary technology that is near impossible to move to newer technology).

The argument that you can take a Spring based application to another application server is an rather silly one in this context. Using the same line of reasoning I could state that if I programmed to Orion specific APIs, then this would never matter and my app would still be portable, since I could move Orion to another operating system (say from OS X to Linux). That simply doesn't make sense...

Moving my app from one OS to another is not by virtue of Orion, it's because of the STANDARDS based JVM. Likewise, moving a Spring application from Jboss to Glassfish is not by virtue of Spring, but by virtue of the standardized layers beneath it (here, Java EE and Java SE). In both cases, my application itself would still be tied to Orion respectively Spring.

So even though I'm not claiming one should choose Java EE merely because of the fact that its standard based, I must say that it's a nice addition to an already rich set of features.

Deja vu, all over again by Kit Davies

Wheeeeee! Welcome to TSS c. 2004.

Spring announcing | JBoss rubbishing => hilarity ensuing.

Re: Deja vu, all over again by Lars Vonk

Ah the good old days....
I would also like to take this opportunity to thank all participants of this Thread. Very entertaining. And now: Back to work!

Doh by Tero Vaananen

How did it go again? Standards are good but standardization is bad. The best standard is not the one that implements all the best features (and we can never agree what those are), but the one that is the most widely adopted. When these things are allowed to evolve in the wild, as we say, good enough solutions will emerge. I say good enough, because none of those are perfect.

Not all standardization is bad. Java language standardization is good because it creates a stable platform to build on. Simple things like servlets are good, a web container maybe. But further it goes, it is hard to do up-front standardization. It must be done when there is no ecosystem at all, but only enough to allow that ecosystem to start bringing its own standards out in the open. A living, evolving system and standards if you will. I don't think we have learned this yet.

Re: Spring 3 by Dorel Vaida

Adrian, you are right most of the time, but you didn't get what I said. You basically rant over and demonstrate what I said, that "standards keep people in line" which I never stated it would be a bad thing. Sure it's fine we are able to see the same page in Chrome, Firefox and Safari. Did I like the concept behind Gears ? Sure I did. Was that standard ? Nope. Innovative ? Hell yeah. What I just said is that innovation happens outside standards. Because standard's job is not to innovate. And people can move freely and explore ideas and do what they like outside standards.

Look everywhere around you. Innovation happens elsewhere. And innovation becoming commodity and finally going standard is a good thing.

But we need projects outside any standards space, we need disruptiveness so that we move forward. That's called evolution. One guy coming with a crazy idea and rocking your world and turning it upside down. Like Gregor Kiczales and his team with AOP, Like Gavin did with Hibernate. And Rod with Spring and Ari Zilka with Terracotta, Jonathan Locke with Wicket (tons of examples I'll stop here) and I'm not even going to mention projects outside the Java space. They were nowhere near a standard when they begun. That's called innovation. And that is what I was advocating. Maybe I was clearer this time.

Re: Deja vu, all over again by Dorel Vaida

Back to work on what ? Your CDI project =)) ?

Re: Spring 3 by adrian collheart

Hell yeah. What I just said is that innovation happens outside standards. Because standard's job is not to innovate. And people can move freely and explore ideas and do what they like outside standards.


Sure, I think we're at the same page here ;)

Maybe I was clearer this time.


I think you were. I somehow got the impression that you thought things were bad just because they happened to be in some standard, but it seems that I just understood wrongly. My apologies for that.

Re: Deja vu, all over again by adrian collheart

Wheeeeee! Welcome to TSS c. 2004.

Spring announcing | JBoss rubbishing => hilarity ensuing.


Now you're mentioning it, it does indeed bring back some memories ;)

Re: Spring 3 by Juergen Hoeller

Adrian,

The argument that you can take a Spring based application to another application server is an rather silly one in this context. Using the same line of reasoning I could state that if I programmed to Orion specific APIs, then this would never matter and my app would still be portable, since I could move Orion to another operating system (say from OS X to Linux). That simply doesn't make sense...

I wholeheartedly disagree, and I'm sure so does a large proportion of Spring users who do get a lot of leverage from Spring's portability across different application server products (and also across different generations of the same application server product). Spring's portability is the same category as, say, Struts' or Wicket's or Hibernate's. Are you seriously claiming that it's not important for the latter three to be portable across app servers either? It's exactly the same story for Spring, even if its functionality may be broader.

That said: Java platform standards such as Java SE and also foundational parts of Java EE are of course critical elements of Spring's portability story as well. Just like for other common frameworks in the Java space; the myriad of web frameworks in particular.

Juergen

Re: Spring 3 by adrian collheart

I wholeheartedly disagree


I can't escape the feeling that deep in your heart you don't 'wholeheartedly' disagree ;) You've build a fantastic framework, where a lot of low level details had to be accurately implemented. It's without a doubt that you understand how software architecture and things in general work.

Let me try to better explain what I mean:

Spring's portability is the same category as, say, Struts' or Wicket's or Hibernate's. Are you seriously claiming that it's not important for the latter three to be portable across app servers either?


Of course I'm not. Spring itself is portable since it builds on Java SE and Java EE. Struts, Wicket, Hibernate, Mojarra... they are all portable simple because of the fact that they are Java apps. This is however not what I contended. As I tried to explain, Spring may be portable, but the application that builds on Spring is not portable to any other Spring implementation. There simply is only one Spring implementation.

I can write an AdrianHelloWorld class in Java. This class will be automatically portable to every JVM and every AS out there.

Suppose another application happens to build on top of my AdrianHelloWorld class. If that application wants to move anywhere else, it HAS to drag my class along. There is no one else in the world implementing an AdrianHelloWorld class.

This is the kind of portability I referred too. With Java EE, I can move just the app to another implementation, just as I can move the AdrianHelloWorld class to another JVM.

Now dependencies on some libraries are unavoidable. We all include some external libraries, like apache commons, or some PDF generator lib. And yes, we have do drag those along too. So if Apache stops updating some of those libs (they actually did, e.g. commons collections, commons feedparser), then eventually I must still rewrite some of my code if the unmaintained lib really gets too old to be useful.

Nevertheless, I like to minimize those dependencies. All the Java SE APIs are portable. If Sun throws in the towel today, then tomorrow my Java app will run on Apache harmony, or maybe IBM's JVM. Likewise, with Java EE as I explained, when Orion threw in the towel, we could move to Jboss.

When Spring calls it a day, what do I do? What does the fact that Spring can be moved to another AS buys me then? In that situation I don't want to move to another AS. I might be happily running on say Jetty on top of the IBM JDK on top of Linux. That's all not relevant at that point. What matters then is that Spring doesn't release any new versions anymore, and whether I move Spring to Tomcat, to Jboss, to Glassfish, to Mac OS X, Windows, Solaris... nothing will change that fact.

If there happened to be another vendor offering a Spring environment, then I could just move to their implementation and enjoy their future updates. BUT, there isn't such other vendor. There is only 1 vendor offering Spring and that's Springsource.

Now in practice this might not be the problem that we all like to make it. Springsource (via VMWare) will probably be in business for a very long time to come and I have nothing but the slightest doubt they'll call it a day anytime soon, but for the sake of argument let's just get the simple facts straight. I clearly stated that an application running on top of Spring is not portable to another Spring implementation, simply because there isn't one. An application running on top of Java EE is portable to another Java EE implementation, simply because there are plenty. Spring itself is of course portable to every JVM and every AS out there, but this was simply not the point I argued about.

Whether all of this is really important to individual persons is up to them to decide. There also isn't another .NET (yeah Mono, but that hardly counts), and people are happily deploying on .NET and rightfully so don't see it as a risk. With .NET there also is only a single deployment platform (Windows), but again this is not really seen as a risk, since a large and despite all critics reputable company (Microsoft) is backing it.

Re: Spring 3 by Artur Nowak

Peter,

Totally agree with your point of view. Stumbling upon this thread, I was looking forward to learning more about areas where each of the two technologies excel, but having read all of this I'm disappointed with the discussion level, all theses exaggerations and superficial arguments.

Spring has a fairly decent user-base with their apps on Tomcat (and they cannot switch to a full-fledged application server, because for example all they have is a virtual hosting), where the only close competitor is OpenJPA. For them, Spring 3.0 opens a whole spectrum of new possibilities. The major changes that affects them were in fact introduced in Spring 2.5, but the whole discussion on whether the version number for the current release of Spring is justified or not, is fruitless. I think it follows the good old convention of marking the change on technological level (here, the requirement of JRE 1.5), not some marketing buzz.

I am using Java EE on the job for several years now, so (following the trend in this discussion) I should take the side of EE 6. Nevertheless, I feel obliged to refute some biased arguments against Spring. In the end, the client of frameworks are the developers. Everybody was in the position of using something they didn't want, because "the boss" decided to do so, or the company already bought it. But in general, all developers need to choose in which technology they would like to specialize. It creates positive feedback between job market and the adoption of certain technologies (big cash of vendors also matters, but in each equation there are many of factors). Thus, the standards are not only about vendor lock-in and applications portability. They also designate the overall commonness of developers' skills.

In that light, one may argue, that inclusion of JSR-299 is somewhat necessary for Spring. In my point of view, it's contrary. Dependency injection model of Spring gained a wide adoption and influenced other projects, Guice included. JSR-299 isn't "standard". Many products of JCP aren't. The word "standard" means something common for a wide variety of objects. There is a huge leap between a standard and a recommendation. It would be at least unwise for Spring to change the behaviour their users are used to, only because some other solution was blessed by Sun.

The JCP is probably falling apart and we must look at its current fruits with anticipation of what is to come. Java EE 6 was released without waiting for modularity specifications to finish. It is a great gap and a theme where Spring shines. Heck, they already released Spring dm, an application server built on this paradigm. Even Websphere 7 supports OSGi modules now. Chances are that the "standard" will be Jigsaw. Moreover, the standardization process is characterized by huge inertion.

I don't intend merely to denigrate Java EE. It pays my bills anyway. I have a long and tedious experience with well backed standard called BPEL andwell marketed product called WebSphere Process Server. It looks on paper like snake oil. In the reality, at some point, everybody start to write some low-level Java snippets, referencing undocumented capabilities of the product... A specification cannot cover all the use cases, it can only find a greater common denominator of various solutions (or the lowest, in some cases).

To sum up: leaving Spring alone is the best way to sow creative ferment. The innovation they can provide is way more fruitful for the community than the best standard. If one thinks that the standards are the way to go, please look at .NET. Microsoft is really good at standardization.

Re: Spring 3 by Juergen Hoeller

I clearly stated that an application running on top of Spring is not portable to another Spring implementation, simply because there isn't one. An application running on top of Java EE is portable to another Java EE implementation, simply because there are plenty. Spring itself is of course portable to every JVM and every AS out there, but this was simply not the point I argued about.

Alright, understood; you are right with respect to this specific notion of portability, of course. I would just argue that it doesn't matter in practice. Just like with Struts, Wicket, GWT, you name it... The portability of the framework on the app server is what really matters, not the portability of the app code onto another incarnation of the same framework.

It can even be quite an advantage to take the framework code with you from app server to app server: It is at least guaranteed to behave exactly the same wherever it is running, with respect to how exactly it manages the app components... not due to a specification but rather due to the reuse of the actual framework implementation across server platforms.

Also, with respect to your risk mitigation concerns: It is of particular importance that the framework is open source here, and written in the same language that the app is written in. It is not too hard to maintain a branch of the framework yourself if ever necessary, and it is in particular not too hard for some other entity to pick up maintenance if it was ever necessary.

Juergen

Re: Spring 3 by Mr Magoo

With Java EE, I can move just the app to another implementation, just as I can move the AdrianHelloWorld class to another JVM.


What is the mystical world of seamless integration you live in? I have yet to see it? I also got a good laugh out of the guy who said shifting app servers was not a problem. I don't know what dinky little companies you are working for, but they are not the ones I am used to!?

It has been a very revealing discussion. As a long time user of spring as a software architect I thought I would add my 0.02c.

Firstly, I think the criticisms here about spring are completely and utterly baseless. My experiences with spring have always been of an A+ standard. Their commitment to quality releases and design is second to none. There are always trade offs of course and one size does not fit all, but spring covers as many of the sizes as you could expect.
Whenever I want to use an example of architect done well, the spring framework is the one I use. When EJB was a dead (and very heavy) duck, spring came to the rescue for us J2EE developers. Spring's conduct as far as I know so far has been infallible and purely based on serving their customer needs and enabling them, rather than restricting and attempting to squeeze revenue.

To have "people" grumbling about the fact that they did not support their standard is a bit rich. Especially since the standard has yet to bite in the real world. The fact that the major players in this space have thumbed their noses at it does not bode well. It hardly justifies itself as being able to be used it as a club to beat non-compliers over the head with?!

The reasoning provided about Spring's decision seems perfectly valid in my opinion. If the standard has ignored the current players and made itself incompatible then that is no fault of Spring's. The hibernate validation framework becoming a java standard is a good example of how this could have been better managed. Expecting everyone to fall into line simply because you produced official looking paper is a bit rich...and naive.

I agree with the poster saying the onus is on the NEW player to justify themselves rather than vice versa. I don't care how official you sound or who has rubber stamped your certificate, the proof is in the pudding. Currently there is no pudding. From what I gather the bowl is still in the design phase for many app servers!

Re: Spring 3 by Peter Hendriks


"CDI may help more in this aspect, it is also much harder to adopt to for existing code."

The Spring guys keep repeating this, but I just don't see why this is true. Maybe you can help me out here? What's so hard to adapt to CDI? Do you have a specific example? It's annoying because this is something we've paid close attention to while reviewing CDI.

Well, I am not a Spring developer, but from a distance, I would imagine it is a lot more work to support the entire CDI configuration model than it is to just support the receiving end (JSR-330) annotations. The C means that you need to have some notion of context support. In the Eclipse 4 framework, having to support "request" scope seems out of place, but this is part of the specification. The same goes for EL support, it is not something very common outside the web app space.

I think the main reason for Spring to not jump on the bandwagon right away is that they already support a wide array of configuration options for the same concepts (I think about 3 XML dialects, property based and 2 Java based notations), with some extensive tooling support in place. Yet Another Way to configure the same thing (CDI) can become cumbersome, both for Spring developers and its users. Ironically, it can also be a way out for Spring for this problem of too many configuration options.

Also, the Spring XML dialects are tuned right now to support higher level frameworks by mixing short-hand XML with the default DI configuration. I would imagine this to be problematic as well. For Spring, adopting to CDI would mean that they would need to think about these features too. Do they still need them? Do they still want to do it in XML, or in some native Java fashion?

Again this pure speculation from my point of view, you would need to get a real answer from Spring leads, maybe they have a totally different reason not to support CDI right away.

"CDI does make my head spin from time to time."

It would be interesting to understand what parts you are struggling with. As such, this is what I thought of CDI too initially, but realized that was mostly because I was reading a spec, not a tutorial. Maybe may CDI series on TSS can help with this?
More tutorials are always nice. :) I am still getting used to a lack of "follow the annotations" model or a "centralized configuration". In CDI, there a ways to provide alternatives, specialization, disabled beans, etc. The context stuff is powerful, like events, but I am still getting used to not do this myself explicitly in code.

To me, it's also a function of it being a spec, so I *want* to understand every bit of it, whereas in a framework like Spring or Guice I am more inclined to leave topics I won't use anyway. Maybe that's just me being irrational, but in my line of work, if I don't know something in a "spec", that is considered A Bad Thing.

Re: Spring 3 by adrian collheart

What is the mystical world of seamless integration you live in? I have yet to see it? I also got a good laugh out of the guy who said shifting app servers was not a problem. I don't know what dinky little companies you are working for, but they are not the ones I am used to!?


I'm not sure whether this in intended as a troll or not, but in case it's not let me provide an answer.

In general, shifting app servers is not as easy as shifting a Java SE app between a JVM. It's not something you take lightly and certainly not something you do overnight. Nevertheless, it's absolutely doable. After much consideration, we shifted two times. I remember having to change some code that relied on global JNDI names to obtain an EJB object and some place where a datasource was obtained from JNDI. Then at some place a classloader trick was used, which of course didn't work in the new environment, but basically that was about it. Oh, and we had to reconfigure the data source definitions and connection pooling of course, as these were AS specific.

All in all the transition went surprisingly smooth. Not overnight, but a couple of days really. We tested intensively for a few weeks, but everything just worked. We're not a "dinky little company". The code base of all our projects combined is in excess of a million or so lines of code, with every project having some 12 developers working full time on it. Revenue is in the millions too. No, we're not a multi-billion international huge corporation, but we certainly aren't a "dinky little company" either.

Re: Spring 3 by Mr Magoo

I'm not sure whether this in intended as a troll or not, but in case it's not let me provide an answer.


Nothing I write is ever intended as a troll. However I don't shy away from giving my considered opinion as it lies and quite often I am accused of it. It is typically an easy way of dismissing an opinion you do not like.

Shifting app servers code wise is relatively easy. Shifting app servers in a large corporate who already has a deployed app server working perfectly well is a process nightmare.

It is not about the code. I should have been more specific.

Re: Doh by Andrea Del Bene

I think is the best post of the thread :). I totally agree with you.

Re: Doh by Victor Franzonatto

I think is the best post of the thread :). I totally agree with you.²

Re: Spring 3 by Gavin King

Why should I as a Spring user switch to CDI?


To find the answer to this question and more, you'll have to actually take the time to get informed by learning about CDI.

I'm not convinced that I'll have more features, be more productive and have long term maintenance advantages with JSR 299. IMHO, it's up to the JSR 299 folks to win us over; FUD and strong arm tactics won't.


While I love the idea that it's somehow in my power to "strongarm" you, I've got to correct you on this one. It is part of your responsibility to your employer to make informed technology decisions after actually trying out the leading options, of which the JCP standard is clearly one. You simply won't know what is the right option for you, your team, or your project until you have actually tried it out. Of course, a good start is to read the specification or check out the RI.

Re: Doh by William H

I agree with the point but actually I really think the various EE 6 expert groups learnt this lesson a long time ago. Looking at EE 6 I see little in the way of "upfront standardisation." Most of the new features have fed up either through requests from EE 5 developers or from open source projects of one kind or another. So for example:
CDI - mainly Seam and Google's Guice plus a dash from Spring
Bean Validation – Hibernate Validators and lots of others
JSF 2 – Seam again, Ajax4JSF/RichFaces, Facelets etc

I think it’s a pretty exciting time to be involved in Java development. Spring has been a great piece of disruptive technology in the Java space and (along with .NET) has done a healthy job of shaking things up I think Rod Johnson and the others at SpringSource deserve major Kudos for that. I also think they sold out to VMWare at just the right time – smart people.

I'm glad to see the SpringSource folks see some value in JSF 2, JPA 2 and Bean Validation but I'd hoped after some of the positive signs we had from Spring early on we'd seem them taking a more constructive line with EE 6 standardisation. It appears not though - As far as I can see their contribution has been one entirely superfluous JSR and not bothering to vote on anything else. I'm also very puzzled that they decided to create their own REST implementation bound to Spring MVC instead of
simply embracing JAX-RS – this seems like fragmentation for its own sake to me.

I find the "having to upgrade your app server" argument pretty feeble. You might as well argue that if you are stuck on Java 1.4 and want to use Spring 3 you have to upgrade to Java SE 5.The App server is just an application running on the JVM. If I have an app that requires a new version I can always bung it on a dedicated server and be done with it.

Re: Doh by Reza Rahman

Just to close the loop on this discussion from my standpoint, while I do really think the Spring folks should have adopted CDI, not adopting CDI does have some nice side-effects:

1. Java EE can continue to have a competitor in the enterprise Java space.
2. Someone else other than SpringSource can create a Java EE comparability layer including support for CDI and EJB 3.1 Lite (including @Stateless, @Stateful, @Singleton, @MessageDriven) and not just @TransactionAttibute, @Async, @Schedule, etc.
4. Nobody needs to feel like their sacred cow was "strong armed" into doing anything :-).

Cheers,
Reza

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

61 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT