Blogs

SpringSource Blog

Red Hat Reacts to SpringSource's Leadership

Posted on June 3rd, 2009 by Rod Johnson in Spring.

Rod Johnson

As the Register and several bloggers have noted, Red Hat recently announced a defensive move motivated by trying to play catch-up with SpringSource. Clearly the momentum of SpringSource tc Server and dm Server has Red Hat worried, along with the continued advance of the Spring Framework as the de facto standard component model for enterprise Java.

The “JBoss Open Choice strategy� appears to be a repackaging, rather than new technology, which attempts to position JBoss as still relevant in a brave new world of changing requirements. Not only is the repackaging obviously reactive, but much of the messaging itself sounds derivative. On a positive note, it appears Red Hat has finally realized that many developers and customers have long since moved away from the full Java EE stack; that the traditional heavyweight application server has declined in importance; and that the Spring programming model is important to their customer base. We welcome the validation, but this is a great time to reflect on the profound differences between the two companies.

While imitation is the sincerest form of flattery, imitations tend to be inferior to the original. In this case, Red Hat is missing the broader vision behind our product offerings, delivering the next generation of middleware.

While lightweight, modular, and powerful solutions are essential, the customers I talk to also realize the best way to accelerate time to value is to pursue a joined up experience and vision that simplifies enterprise Java throughout the application lifecycle. This explains why SpringSource continues our leadership in the Build phase, with Grails, Spring Roo, the now-free SpringSource Tool Suite and the Spring Framework; has risen to leadership in the Run phase, with tc Server providing enterprise grade Tomcat and dm Server the leader in modular application servers; and offers leadership in the Manage phase with the established Hyperic HQ management product that not merely provides solid management and monitoring underpinnings for tc Server but provides a comprehensive platform for managing modern, next-generation application infrastructure.

But Meanwhile, it appears that Red Hat is still trying to figure out where things are headed:

“With an uncertain future and the ever-changing world of Java, the JBoss Open Choice strategy is designed to provide customers with the confidence, to choose the programming and deployment model that works for them without sacrificing performance,� said Craig Muzilla, vice president, Middleware, Red Hat. “Despite all of the market shifts, Red Hat aims to remain a trusted source for valuable and innovative solutions in the Java market.�

While Red Hat throws up its hands and talks of developer “choice,� they’re ignoring the fact that most developers have already spoken, and the focus should be on providing the best experience for what developers want rather than a scattergun approach. Red Hat is ignoring this reality because it can’t afford to acknowledge it.

The reality: The combination of technologies that Red Hat’s customers are actually choosing is dependent on SpringSource-led technologies: Spring projects; Apache Tomcat and the Apache HTTPD web server. SpringSource’s strong and effective leadership in the Spring community is universally acknowledged. Yet it may be a surprise to many people that SpringSource employees are responsible for the vast majority of bug fixes for Tomcat and the majority of code changes; and include the leading experts and active committers on Apache HTTPD.

Let’s look at the key modern “choices� Red Hat mentions in more detail to better understand their relative importance. As a proxy, I’ve used aggregate US job listings:

Framework jobs, USA

Clearly the big dog here is Spring. Far from a world of “ever-changing programming models� mentioned in the Red Hat press release, we see steady growth to ubiquitous levels. Yet, what does Red Hat have to offer to Spring users? SpringSource has provided the leadership that got Spring to where it is, continues to drive it forward vigorously and with a clear vision to reshape enterprise Java for the better. Red Hat’s “enterprise� Spring distribution is as credible as the “Unbreakable Linux� that even Oracle failed in the market with.

At a high level, there is a clear strategic distinction here: Red Hat is selling open source short. While at SpringSource we see open source as a powerful means to innovate and deliver a superior, joined up experience throughout the application lifecycle, providing strong leadership in each of the build, run, manage phases, Red Hat is abdicating responsibility for shaping the future. (“Dear developer, go figure out what you want, write us, Red Hat, a check when you’re done and we’ll do what we can to help you. Honest.�)

With leadership in each part of the application lifecycle, SpringSource is providing deep support from the core committers and thought leaders, at a level of quality that has earned us a 97% renewal rate for our subscriptions. Red Hat, on the other hand, is trying to commoditize and deliver a “good enough� solution on the innovation of others.

True innovation and mission critical support is just as important with open source as it is for enterprise software. “Maybe good enough� is not good enough, and sells open source short.

We’re pleased to see Red Hat follow our lead, and we encourage JBoss customers and prospective customers to look at what they are really building their stacks on and compare the offerings from Red Hat and SpringSource on merit. Clearly Red Hat is deeply worried about SpringSource; it’s time for JBoss customers to come and learn why.

Similar Posts

Share this Post
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • DZone
  • LinkedIn
  • Slashdot
  • Technorati
  • TwitThis
 

40 responses

  1. Martin Vanek says:

    Added on June 3rd, 2009 at 4:32 pm

    Since there is no transaction manager in Tomcat and what's much worse, there is not easy way to bind custom one into JNDI and use it inside Spring container, Tomcat =>Spring dm & tm is big no.
    Light Jetty with Atomikos or heavy JBoss is much more reasonable choice.

  2. Mark Fisher (blog author) says:

    Added on June 3rd, 2009 at 4:54 pm

    @Martin

    Atomikos works fine with Spring, and there is no need to involve JNDI. Check out their documentation here:
    http://www.atomikos.com/Documentation/SpringIntegration

    Regards,
    Mark

  3. Mark Fisher (blog author) says:

    Added on June 3rd, 2009 at 4:56 pm

    @Martin

    Also, for a great example of using Atomikos with Spring including source code and configuration, check out this article:
    http://www.javaworld.com/javaworld/jw-01-2009/jw-01-spring-transactions.html

    Regards,
    Mark

  4. Daniel Alexiuc says:

    Added on June 3rd, 2009 at 5:06 pm

    Yikes! What an aggressive post… I guess there's no reason to pussyfoot though. I wonder why Oracle hasn't bought you guys out yet?

  5. Colin Sampaleanu (blog author) says:

    Added on June 3rd, 2009 at 5:13 pm

    Martin,

    It is quite easy to add in Atomikos as a JTA tranasaction manager into Tomcat.

    That said, a JTA transaction manager, which is not available out of the box in a Tomcat environment, adds essentially no value except when there is a need to do distributed transactions, and for a number of reasons, the vast majority of Java EE applications out there do not use distributed transactions. These reasons include:

    1) Most application transaction use cases simply don't need transactions across multiple resources.
    2) The resources involved may not be XA and distributed transaction capable, or in fact (LDAP) may not even be transactional.
    3) Some app servers which have advertised themselves as XA capable (with a JTA transaction manager), did not actually have a working distributed transaction manager.
    4) In many of the limited set of cases where distributed transactions make sense, they impose such a high performance penalty that people simply don't use them. Case in point lots of apps processing higher volume of financial transactions from a queue and putting them in a database, where they have given up on distributed transactions because of the performance hit, and instead rely on nested transactions and some code which can handle compensation if there is a duplicate message.

    So when working with only one resource, in a non-distributed fashion, JTA adds no value over just driving that resource directly. As a concrete example of the latter, I am talking about driving transactions on the Connection object when using raw JDBC, or working via the Hibernate Session transaction related APIs (where Hibernate will then itself drive transactions on the Connection).

    You do not have to have Spring Framework in the picture here at all, but when you do, you even have the advantage that the code you write is completely agnostic to the question of JTA vs local transactions. It is a simple one line configuration change to pick one transaction management strategy vs. another. Add to this full integration with the data-access functionality that allows removal of much persistence related boilerplate, and consistent handling of persistence related resources within a transaction.

    Colin

  6. Gabriel says:

    Added on June 4th, 2009 at 1:01 am

    Actually, from my experience, Spring is a lot more flexible and provides more developer choices than competing JBoss products.
    For example, I worked a Spring-JPA-JSF application and wanted to enable conversation-scope JPA sessions, so I evaluated Seam and Webflow, and it was a real pain to make Seam work with my existing architecture (layered and with Spring TM), but Webflow worked like charm and required no changes to any layer except the web layer.
    Same thing with other features of Spring – they can be plugged into the application without any limitations and and they simply works, and when you ask questions in the forums you don't get replies in the spirit of "it doesn't work unless you do it the way we intended".
    So I think developer choice IS something SpringSource can be proud of.

  7. jezter says:

    Added on June 4th, 2009 at 2:43 am

    Are you planning to embedded JMS server to dm?
    For me it's a showstopper and I'm still using JBoss.
    Or there's a way to use activemq in simple way? If yes, please – provide some information about configuration.

  8. Pieter says:

    Added on June 4th, 2009 at 3:06 am

    Sounds good.

    You guys are offering support for some JBoss frameworks, am I wrong?

    Spring, even if it's a great framework, isn't that hard to learn, tons of people around the world are able to provide support on it so why not JBoss?

    "As a proxy, I’ve used aggregate US job listings"
    Did you try to add "JBoss" in your comparison? Be fair Rod.

    Competition is good.

  9. Iwein Fuld says:

    Added on June 4th, 2009 at 3:52 am

    @jezter
    ActiveMQ is very simple to use within a Spring environment. Obviously it works the same in a Spring app running anywhere, even on JBoss, so you have a very smooth migration path. We use it throughout our trainings and free examples are abundant.

    I'd avoid the JBoss integration by the way, as it seems much more convoluted than usage from Spring.

  10. Martin Vanek says:

    Added on June 4th, 2009 at 4:53 am

    @Mark
    I'm using Atomikos for years, so I know it well. It is NOT Tomcat Atomikos intergation but just one spring context Atomikos. I work for system integrated doing SOA like things, so our apps regulary spans multiple webapps (https & client cert webservice endpoint, http basic protected gui webapp, etc..) You cannot deploy ear into Tomcat to bundle more wabapps, then you want start more transaction managers? I guess not. Transaction manager have to be only one at least solution wide, if not JVM wide.
    @Colin
    1. Even Petstore requires it. It's a fact. You can ignore that, but it's silly ostrich behaviour.
    2. I know, Webservices (without WS-AtomicTransaction) are much more often scenarion. This is where you have to do last resource optimization by hand. Nothing can help you here.
    3. You are refering to "by default turned off transaction recovery" in JBoss?

    I know that local transaction are fine without XA tm, but I never worked in such limited environment. I'd like to use Tomcat and Spring (dm|tm) derivates, but it is simply not possible no matter what great features they have.

  11. Kit Plummer says:

    Added on June 4th, 2009 at 8:41 am

    Aggressive, and necessary. It is always the innovators who drive the market, not the (stale) 800 pound gorillas, regardless of the technology at hand. I only hope that SpringSource is solid and secure enough to not get consumed by one of those gorillas.

  12. Rich Sharples says:

    Added on June 4th, 2009 at 10:20 am

    Rod, nice post – thanks for the plug.

    Honestly though – Red Hat / JBoss doesn't complete with Spring Source; except maybe for developer attention.

    Our announcement isn't about Spring Source, we have much bigger ambitions :

    http://blog.softwhere.org/archives/865

    - Rich

  13. Stephen Souness says:

    Added on June 4th, 2009 at 10:27 am

    I'd be curious to see what the job figures looked like for "J2EE" or "Enterprize Java", as I can imagine savvy job advertisers would not want to discourage applicants from applying if they had expertise in other J2EE / JEE Application Servers – they are supposed to be based on standards after all.

    Comparing job ad counts for Spring against Richfaces and Seam is probably analagous to comparing job ad counts for SpringMVC against JSP.

    (I'm not saying that I expect there to be more JBoss jobs than Spring).

  14. Rod Johnson (blog author) says:

    Added on June 4th, 2009 at 10:44 am

    @Pieter
    By this metric, Spring overtook JBoss almost 3 years ago, and has since pulled far ahead.
    Rgds
    Rod

  15. Alessio says:

    Added on June 4th, 2009 at 5:04 pm

    Hi Rod,
    I do think that springsource is going in the right direction, Red Hat is trying to adjust the sight before it's too late:
    For my experience half of the application that now are running on an heavyweight application server can run also on a lightweight solution (tomcat…), some times the choice of an application server is due to politic reasons or marketing.
    As now spring is suitable for marketing, as jboss: Today in a pre-sales activity or in a CV "spring" is a good buzzword as jboss or SOA. I think that this is the real preoccupation of RH, there were some alternatives to jboss, but they never surpass Jboss in popularity. Spring as framework did it. Spring as application container (dm and tc) can do that.

    Regards,
    Alessio

  16. Pieter says:

    Added on June 5th, 2009 at 2:24 am

    @Rod
    "By this metric, Spring overtook JBoss almost 3 years ago, and has since pulled far ahead."
    Really, it seems you are totally wrong, or maybe I'm missing something?
    http://www.indeed.com/jobtrends?q="java spring", "jboss"&l=

    Of course you can make the same metric replacing "java spring" with "spring" but then I propose the next killing framework name will be named "summer", just a question of relevance.

    Conclusion: Obviously you can't rely on these metrics so don't use it as an argument, we (IT architects, consultants) don't deserve such approximation from you.
    Spring rocks for sure but is still far behind jboss in terms of searched skills, I see it with my own customers, everyday, that's a fact.

    More important, I love Spring AND JBoss (AS and frameworks), both are done by the most technical/skilled/genius staffs of the java community.
    "The enemy of my enemies are my friends", I guess you should focus on long term enemies rather than wasting time on a short term ego.

    Anyway, I wish you the best.

    Pieter.

  17. Guy Pardon says:

    Added on June 5th, 2009 at 10:24 am

    @Colin

    XA is unneeded in many web app scenarios, which is why Atomikos does not focus on web apps. However, in JMS-JDBC integration scenarios, things are a bit different.

    Regarding performance of XA vs non-XA: I don't think it is as bad as you say. We (at Atomikos) are working on a performance test suite so we can publish official results wrt both cases.

    Best
    Guy

  18. Kristof Jozsa says:

    Added on June 5th, 2009 at 1:14 pm

    I hope you guys once get back to the path you originally started on. Anyone remembers those days? cheers..

  19. Kristof Jozsa says:

    Added on June 5th, 2009 at 3:10 pm

    I second Kristof's comments.

  20. Federico Dal Maso says:

    Added on June 7th, 2009 at 3:58 am

    I think we (developers) don't need of aggressive posts, but we need of a clear vision about your plans on some future technologies. I choose you if I understand where do you want to go, and how.
    I think the main key-technology, potentially disruptive for spring approach, is JSR-299 specification leaded by Jboss/Red Hat. I think it is a beautiful approach, a step beyond the current spring framework one, because of its design and abstraction and not because of its ownership.
    Thus, my question is: which is SpringSource plan about JSR-299 integration/implementation?

  21. rainwebs says:

    Added on June 7th, 2009 at 4:57 pm

    @Federico Very funny what you think about JSR-299. Even if the container is now an EJB-Lite, it is still an EJB-Container that you need to use all this. And I can't recognize anything innovative in the current spec Feb 09 draft. Seems to me something similar we already saw with EJB 3 and JPA. The JCP standardizes something that is adopted by the market already and tries to marriage the new established ideas with everything antiquated the JCP ever released in the past. Did you have a look at the code examples? More annotations in it than classic Java statements. Nice. So, what will SpringSource do? Take all the useful and integrate it in the Spring Framework – and ignore the useless rest ;-) .

  22. Guy Pardon says:

    Added on June 8th, 2009 at 1:25 am

    @Federico

    JSR-299 = JSF EJB – seems to me like the merging of two overloaded monster specs that are each at the very basis of JEE complexity… Light-weight solutions like Grails or Wicket are much more fun to use, at least in my experience.

    Cheers
    Guy
    PS my view does not represent SpringSource's – so I guess your answer is still underway;-)

  23. Hernán Moreno says:

    Added on June 8th, 2009 at 10:26 pm

    I personally think that 299 is a good step forward. I checked the examples, the specification and from my point of view I consider it as beautiful. It's taking as a core the smart design of Google Guice and the elegance of scopes as Spring currently does, plus a robust event model and other goods. In the other hand Spring is doing an excellent leadership in JEE space, delivering quality and innovation, no questions about that. JEE6 will be really interesting because it's a reaction to Spring innovation, and as a result, we (developers) can expect even more innovation in both sides and this is something good for java's health.

  24. Tancor Fleut says:

    Added on June 10th, 2009 at 3:52 am

    I can't believe SS went for such cheap PR tactics… very sad…

    The times are long gone since Spring was 'lightweight' wake up – it became heavyweight long time ago.

    @Guy: JSR-299=JSF EJB??? did you even had a look at it? Btw Wicket is getting it's integration in RI…

    @rainwebs: EJB Lite will actually be lighter than Spring (surprise… not…!)

    By reading this post it (end especially the text in bold) it appears that SS is the one that worries and not Red Hat. I just hope the parties will some day work together and stop behaving like kids in sandbox.

  25. donny says:

    Added on June 10th, 2009 at 4:32 am

    Spring is lightweight. You can write Spring app that doesn't require container or server. If the DI framework requires you to run your app on the server then it's not lightweight.

  26. Hernán Moreno says:

    Added on June 10th, 2009 at 5:08 am

    @donny

    Actually, just to be more accurate,Spring it's a container among other things :-) Check this url, FYI:
    http://static.springframework.org/spring/docs/2.5.x/reference/new-in-2.html#new-in-2-ioc

    The RI of 299 doesn't need any "Server" by itself. You can play with it without any EJB dependency even with Java SE, but if the application executes in a Java SE environment, an embeddable EJB Lite container has to provide Java EE services such as transaction management and persistence, that's it.

    Also in the same way, Spring provides a very nice JPA integration/Transaction management with "the Spring IOC Container", among other integrations,so you get everything in the same Spring box.

    The arrival of JEE6 will be really interesting in the java world. IMHO.

  27. Tancor Fleut says:

    Added on June 10th, 2009 at 8:14 am

    Spring is a container in itself. Yes JSR299 would need a ejb lite container (reusable and decoupled which you can't say of others, and btw the reference implementation IS going to support SE not only EE), but what if this 'heavy' container is actually smaller than spring…? boo hoo…

    Many developers are 'afraid' of EJB (JSR299 isnt all about ejb btw) when in fact they never even tried it… as a someone once said: "first see it then beleive it", welcome to the real world :)

    What I mean is that SS distantiates itself from developers by choosing tactics like this blog post.

    I made my comments biased on purpose just to indicate the contrast SS is creating all by itself. I see similar tactics (just a bit extremer) used by another (very big) Company…

    I even wont be surprised if my comments got deleted…

  28. donny says:

    Added on June 10th, 2009 at 10:58 am

    what i meant in my previous post is web/servlet container ^^

  29. Gabriel says:

    Added on June 10th, 2009 at 1:06 pm

    @Tancor

    JSR299 is "heavier" than Spring in that it's comparable to Spring DI WebFlow and it defines a strict way of configuration, while Spring is a collection of separate libraries (with dependencies of course) that you can include in your application according to your needs and configure in your way (XML, annotations, programmatic or invent some new way).

    Spring does not depend on the JCP (which is full of politics), its development is directed by user requirements, and it's very modular so you can take only what you want and integrate it painlessly into an existing application.

    The way I see it JSR299 is a subset of the entire Spring stack, and as I said with Spring you can use only the parts you want, so what is the advantage of JSR299 ?

  30. Guy Pardon says:

    Added on June 10th, 2009 at 1:20 pm

    @Tancor

    Quoting the JSR home page: "The purpose of this specification is to unify the JSF managed bean component model with the EJB component model, resulting in a significantly simplified programming model for web-based applications."

    Did I misread this as the JSR being about JSF plus EJB? Maybe. Did I read the draft of that spec? No – a RedHat license pops up and I want to read/understand the legal talk first.

    Either way, JSF alone is already enough to make me run and not look back (just my personal opinion;-)

    Also, about Rod's post being aggressive or not: I can still remember when M.F. was leading JBoss.

    Peace! (quoting again;-)
    Guy

  31. Hernán Moreno says:

    Added on June 10th, 2009 at 6:19 pm

    For those that don't believe.

    http://in.relation.to/Bloggers/JSR299ProposedFinalDraftSubmitted

  32. Federico Dal Maso says:

    Added on June 11th, 2009 at 3:38 am

    If you think JSR-299 implies J2EE or JSF or Web Container or other tecnologies, I think you don't understand what JSR-299 is.

    Essentially it is a IoC model extended by contextual injection and designed with a strongly type safe approach in mind.
    All injections is dinamically resolved at runtime using arbitrary and extensible/customizable contexts. The keypoint is that JSR-299 introduces a new level of indirection (the caller, the business process… or everything that you will be able to define as "context") in a native per-call runtime resolved IoC.

    The meta-annotation based type safe resolution of dependencies is absolutely amazing.

    It's easier to wrap Spring and Guice using JSR-299 rather than the vice versa.

    I think the biggest error is the (old) name: Web beans. If you read the spec, you realize the web, or the J2EE environment are not the targets, but a particular implementative case.

  33. Gabriel says:

    Added on June 11th, 2009 at 4:41 am

    @Federico

    "t's easier to wrap Spring and Guice using JSR-299 rather than the vice versa."

    Why would anyone want to do anything of that sort? Use the right tool for the job.

    If you find that JSR299 fits in your model – do use it, but changing an existing application to fit the JSR299 model (or any other JSR) seems very wrong to me unless you get real benefit from JSR299, and as I said this is a subset of Spring's features with less flexibility.

  34. rainwebs says:

    Added on June 11th, 2009 at 10:17 am

    @Gabriel Absolute correct.

    What is the use case for JSR-299? For all using Spring there is nothing in it that is appealing. Maybe it helps to let guys using only JCP specs understand why the others use Spring already – and let them rethink their architecture.

    In Garvins post are some interesting statements:

    http://in.relation.to/Bloggers/JSR299ProposedFinalDraftSubmitted

    "However, JSR-299 does not currently define a bootstrap API for starting and running the container standalone in the SE environment. Instead, this API is being defined by JSR-330. Unlike JSR-299, JSR-330 is not defining everything that is needed in order to write portable applications. So you'll still need JSR-299 if you want your application to be portable to other container implementations. Therefore, we plan a maintenance release of JSR-299 that includes support for the JSR-330 bootstrap API. For now, if you want to run JSR-299 in the SE environment, you'll need to use a vendor-specific bootstrap API."

    This is only valid to me if I ignore Spring usage at all.

    This comment I like most:

    "Great work! Hopefully JSR-299 integration into JEE6 won't suffer by delaying JSR-330 spec. Reading IBMs vote statement makes me doubt in keeping the timeline. :-( Please make me think wrong!"

    Rod, seems that your suggestion let some JCP guys get into trouble. Well, this "non existing" container dependency is really awkward ;-) .

    For more discussion have a look at my blog "JSR-299: Beating the Dead J2EE Horse".

  35. Rod Johnson (blog author) says:

    Added on June 11th, 2009 at 1:07 pm

    @Pieter

    Sorry, I missed your comment earlier.

    By this metric, Spring overtook JBoss almost 3 years ago, and has since pulled far ahead.

    Really, it seems you are totally wrong, or maybe I'm missing something?
    http://www.indeed.com/jobtrends?q="java spring", "jboss"&l=

    You are indeed missing something. No one searches for the literal string "java spring". You need to use "and" to search for jobs mentioning both Java and Spring. Then you get exactly the comparison I described: Spring long ago overtook JBoss as a skills requirement and has since pulled far ahead.

    Rgds
    Rod

  36. Gavin King says:

    Added on June 12th, 2009 at 12:14 pm

    "Did I read the draft of that spec? No – a RedHat license pops up and I want to read/understand the legal talk first."

    That license is the standard boilerplate evaluation license that the JCP requires for JSRs. We were asked by Sun to add it to the spec. I'm sure you've agreed to the same license many times for other JCP specifications.

    Clearly you have some misconceptions about JSR-299, that arise from you not having read the spec. Sorry, but the need to agree to the standard JCP evaluation license doesn't really excuse you for making uninformed comments .

  37. Guy Pardon says:

    Added on June 13th, 2009 at 5:46 am

    "That license is the standard boilerplate evaluation license that the JCP requires for JSRs."

    This one seemed different IMO: I have seen numerous Sun licenses but none with Red Hat in it. That is why I didn't proceed (yet) – I like to know what I agree to first, and I just need some time to look into the legal terms first.

    "Clearly you have some misconceptions about JSR-299, that arise from you not having read the spec."

    It certainly seems so, doesn't it? However, and again: whatever little I know is based on the abstract that is right there, on the JSR page – maybe it could be improved so that it reflects the nature of the spec?

  38. A.J. Segal says:

    Added on October 29th, 2009 at 3:31 pm

    @Rod

    I'll take standards any day. Seam rules … no JBoss AS required. Nice hair cut by the way.

  39. Oleg Zhurakousky says:

    Added on October 30th, 2009 at 10:31 am

    @A.J. Segal

    What is a standard? Hmm… let me look:
    http://www.thefreedictionary.com/standard
    1. "Something, such as a practice or a product, that is widely recognized or employed, especially because of its excellence"
    2. " Widely recognized or employed as a model of authority or excellence"
    3. "Commonly used or supplied"
    http://www.merriam-webster.com/dictionary/standard
    1. "something established by authority, custom, or general consent as a model or example"
    http://www.wordreference.com/definition/standard
    1. "a basis for comparison; a reference point against which other things can be evaluated"

    You can clearly see that the words used are: excellence, commonly used, model or example etc. . ., which perfectly fits Spring manifesto ;) The fact that it was so widely adopted by the community as a more superior programming model then J2EE is a perfect testament to that, and because it is so widely adapted by the true community makes it a defacto standard ;)
    And btw, JCP is not about standards. It is a process that attempts to dictate how things should be done and is heavily influenced by 800 gorillas (to promote their agenda and products) and not the community.

  40. Jim McLean says:

    Added on October 30th, 2009 at 10:36 am

    Don't feed the trolls.

11 trackbacks

Leave a Reply