Home

News: Next Stop: Spring Framework 4.0

  1. Next Stop: Spring Framework 4.0 (21 messages)

    The current 3.2 generation is a natural conclusion of the 3.x line, with Java-based configuration and REST having been recent focus areas next to Java SE 7 and Servlet 3.0 support.

    For Spring Framework 4.0, our focus is on emerging enterprise themes in 2013 and beyond:

    • First-class support for Java SE 8 based Spring applications:
      language features such as lambda expressions; APIs such as JSR-310 Date and Time
    • Configuring and implementing Spring-style applications using Groovy 2:
      Groovy-based bean definitions; Groovy as the language of choice for an entire app
    • Support for key Java EE 7 technologies:
      including JMS 2.0, JPA 2.1, Bean Validation 1.1, Servlet 3.1, and JCache
    • Enabling WebSocket-style application architectures:
      support for JSR-356 compliant runtimes and related technologies
    • Fine-grained eventing and messaging within the application:
      building on our existing application event and message listener mechanisms
    • Pruning and dependency upgrades:
      removing deprecated features; raising minimum dependencies to Java 6+ etc

    Building on the momentum and the preparation work behind Spring Framework 3.2, we intend to have yet another one-year iteration and reach 4.0 GA by the end of 2013.

    We'll be tracking OpenJDK 8's schedule closely, delivering a first Spring Framework 4.0 milestone as early as April. Details will follow in further blog posts as we get closer to M1.

    Let us know whether you have any particular favorites among the above, specific architectural requirements, plans to adopt upcoming technologies for use with Spring, …

    Cheers,
    Juergen

    P.S.: Don't miss our upcoming webinar on Thursday!
    We'll be presenting recent Spring Framework 3.2 features and will conclude with an outlook for 2013, discussing the Spring Framework 4.0 plan and related work areas.

    Threaded Messages (21)

  2. awesome[ Go to top ]

    can you please simplify some of the "out of control" IOC styles - xml importing xml, annotation using that which in turn can have injection..... its getting out of hands.

    I do understand that developers should know what best way to do it, but i think Spring overall is loosing its promise of " keep it simple". the sze of the jars has grown to a large extent, dependencies are becoming hard to manage. Debugging and maintenance has become nightmare with so many ways of wiring so many things together.  

    I m a big fan of spring - met some of the founders back in the days. So dont get me wrong. just think about it... suggestion.

  3. awesome[ Go to top ]

    The problem is that you cannot please everyone. Some say it does too much. Some say it does too little. I think they have done a good job of breaking it apart so you can just take the things you need. If you just want IoC it is not that much and if you want to stick with XML you can and you can ignore the rest. 

    I would rather have the things available that i need versus having to hack something because it was not there.

  4. awesome[ Go to top ]

    The problem is that you cannot please everyone. Some say it does too much. Some say it does too little. I think they have done a good job of breaking it apart so you can just take the things you need. If you just want IoC it is not that much and if you want to stick with XML you can and you can ignore the rest.

    I would rather have the things available that i need versus having to hack something because it was not there.

     

    its not easy as take only the parts you need. it used to be. Now a days if i use spring MVC, it kind of forces me to use IoC which kind of forces me to have iOc in my domain layer which trickles into my DAO. So its alsomost like SpringWay or highway. its very very difficult to say - i would use spring only for one layer and not another.

  5. awesome[ Go to top ]

    The problem is that you cannot please everyone. Some say it does too much. Some say it does too little. I think they have done a good job of breaking it apart so you can just take the things you need. If you just want IoC it is not that much and if you want to stick with XML you can and you can ignore the rest.

    I would rather have the things available that i need versus having to hack something because it was not there.

    its not easy as take only the parts you need. it used to be. Now a days if i use spring MVC, it kind of forces me to use IoC which kind of forces me to have iOc in my domain layer which trickles into my DAO. So its almost like SpringWay or highway. its very very difficult to say - i would use spring only for one layer and not another.

  6. Slim down Spring?[ Go to top ]

    Now I've never been Spring's biggest fan, so maybe take my words with a grain of salt, but it seems that with each release Spring is getting fatter and more complicated relatively to Java EE.

    With every release I feel less inclined to learn about Spring, and I put it on my TODO to see if the next version is simpler, but unfortunately it never seems to be...

  7. Slim down Spring?[ Go to top ]

    Examples of it getting fatter and more complicated vs  JavaEE?

    For all the extra things it does that i need to do, i have not felt a need to nor can I dump Spring and go with just Java EE. (i.e. I need Spring DM).

  8. Slim down Spring?[ Go to top ]

    I thought Spring dropped DM like a bad habit?

  9. Slim down Spring?[ Go to top ]

    I guess I meant the new name (not the server) ... Spring OSGi

     

  10. Slim down Spring?[ Go to top ]

    Are you referring to the Eclipse Gemini Blueprint project? I'm pretty sure there is no Spring DM / OSGi as they pawned it off on Eclipse a few years back.

  11. Spring is obsolete[ Go to top ]

    ... because Spring's role as middleman between JavaEE and developers became obsolete. Nowadays one is well advised to do reduce dependencies to other frameworks as much as possible (even though Maven is a diligent servant) and rely on current Java EE. Dependency means complexity. There is no need to pull additional complexity into your serverside projects. Spring? YAGNI!

  12. Roles changed[ Go to top ]

    Spring has moved beyond just being a middleman. If you are only doing the things that Java EE covers then you are correct - you should probably not use it. But to assume that all server-side projects have no need for Spring, is incorrect.

  13. Roles changed[ Go to top ]

    I think it's important to point out here that the Java EE ecosystem was never intended to be a walled garden. The Java EE ecosystem comprising of tools like Arquillian, Forge, DeltaSpike, CODI, Seam, PrimeFaces, RichFaces, Camel play an important part to complement the Java EE platform, not to mention implementations like Mojarra, MyFaces, EclipseLink, Hibernate, Weld, Jersey, RESTEasy, CXF, OpenEJB, ActiveMQ and so on.
  14. Spring is obsolete[ Go to top ]

    ... because Spring's role as middleman between JavaEE and developers became obsolete. Nowadays one is well advised to do reduce dependencies to other frameworks as much as possible (even though Maven is a diligent servant) and rely on current Java EE. Dependency means complexity. There is no need to pull additional complexity into your serverside projects. Spring? YAGNI!

    I wish it was totally obsolete, but it does fiddle around too much between me n my container. And that is a worry. It use to be simple proxy pattern to get me better/ easier access, not the middleman has turned the gun on me too. I m being forced to do things certain way. its scary. Its taking over my apps. :)

    Does anyone know if i can use CDI and not use spring IoC that easily ?

     

  15. Spring is obsolete[ Go to top ]

    Does anyone know if i can use CDI and not use spring IoC that easily ?

    If you're building webapps with JSF, my advice would be to use Java EE 6 (JSF, CDI, JPA and if you need it EJBs) with Deltaspike and CODI (for the JSF module : CODI ConversationScoped, ViewAccessScoped, WindowScoped).

     

    If you're building webapps with HTML/JS calling REST services, also just use Java EE 6 (JAX-RS, CDI, JPA and if  you need it EJBs) optionnally with Deltaspike.

    If you need a MVC module, I didn't found one with great CDI integration for now, so I would say to stick to Spring MVC here.

    If you need to create a complex batch, you'll have to roll your own or use Spring Batch - or wait for JSR 352 (Java EE 7).

    But this is just my opinion though

  16. Spring DATA[ Go to top ]

    Is there an alternative in the Java EE stack parallel to Spring Data?

  17. Spring DATA[ Go to top ]

    Just use the appropriate client and CDI. For example, if you are using MongoDB then use the MongoDB Java client and CDI for injection. Does Spring Data do anything other than Spring-ify this type of integration?

  18. Spring DATA[ Go to top ]

    Reading your response.. its clear to me that you have not used Spring Data. If I were you I'll keep my rant to someother post instead of answering an honest question. 

  19. Spring DATA[ Go to top ]

    Actually that's a pretty accurate statement.

    Here is the high level description of Spring Data MongoDB: "The Spring Data MongoDB project applies core Spring concepts to the development of solutions using the MongoDB document style data store".

    Spring Data basically applies the Spring template concept to the MongoDB Java Driver and does little else. It's not a leap to question whether that is even necessary given the fact that the MongoDB Java Driver is already a pretty good API that does not need much mucking around with. If some minor abstractions are desired, one can use CDI with Mongo like this: https://openshift.redhat.com/community/blogs/spatial-jee6-jax-rs-cdi-mongodb-on-paas.

    If a higher level of abstraction is really desired another option is a JPA based tool like Hibernate OGM, EclipseLink NoSQL, DataNeucleus and so on.

  20. Spring Data MongoDB[ Go to top ]

    Just use the appropriate client and CDI. For example, if you are using MongoDB then use the MongoDB Java client and CDI for injection. Does Spring Data do anything other than Spring-ify this type of integration?

    Here's what the Spring Data module for MongoDB adds on top of the MongoDB Java Driver.

    - Powerful object-to-document mapping. The plain driver is more on the JDBC level in terms of mapping capabilities currently. Thus we add an annotation based mapping framework allows you to leverage store-specific features like geo-spatial indexing, field name rewrites, dbrefs etc. We didn't consider JPA a reasonable choice here as you could only support a subset of the mapping annotations of it (what about @Table, @JoinColumn etc.?) plus you'd need proprietary ones anyway to support store specific features. For more details, see: http://bit.ly/sd-mongodb-mapping

    - Template style access to MongoDB. You can argue this means Springifying it but the template pattern itself has nothing to do with Spring in the first place and the implementation essentially gives you three things: transparent resource management (obtaining MongoDB connections etc.), exception translation (you clients catch DataAccessException and not a store-specific one, so that you don't let persistence technology specific details leak into your service layer) and last but not least transparent object-to-document mapping as outlined above. For more information, see: http://bit.ly/sd-mongodb-template

    - Repository abstraction. An interface based programming model to declare repositories for your domain objects with an interface allowing simple declarations like List findByUsername(String username) etc. It supports out-of-the-box CRUD, a powerful sorting and pagination API, derived query methods (as shown) or manually defined queries, Querydsl integration and much more. It's consistent to the implementations of this abstraction that we have for JPA, Neo4j, Gemfire and incubating community contributions for Apache Solr, Couchbase and ElasticSearch. For more information, see: http://bit.ly/sd-mongodb-repositories-quickstart

    To make it easy for JavaEE developers to get started quickly we ship a CDI extension that makes the usage of all this a matter of dropping the needed JARs into the classpath and e.g. @Inject-ing a repository interface into your CDI managed bean. No Spring configuration required, no Spring container running. The sample at http://bit.ly/sd-jpa-cdi is showing the JPA version but it essentially works the same way with MongoDB.

     

     

     

  21. Spring Data MongoDB and CDI[ Go to top ]

    Not sure you are aware of this but Spring Data MongoDB ships with a CDI extension and you can simply @Inject Spring Data repository interfaces into your CDI managed bean. No Spring Config required, no Spring container running. For more details read up my general answer to Shane's follow up question at: http://www.theserverside.com/discussions/thread.tss?thread_id=71606#429107

  22. http://stackoverflow.com/questions/14482298/whats-up-with-the-spring-jdbc-3-2-0-release-manifest