InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Dependency Injection harmonized for Java EE 6

Posted by Geoffrey Wiseman on Aug 05, 2009

Sections
Development
Topics
Java ,
JCP Standards
Tags
Spring ,
JSR 299 ,
Guice ,
JSR 330

Earlier this year, Google Guice and SpringSource announced that they were co-operating on a standard set of annotations to be used for dependency injection which were proposed via JSR-330. These annotations didn't line up with those proposed for JSR-299, which generated controversy that has now been resolved, with JSR-299 adopting the JSR-330 annotations and both moving forward to be part of Java EE 6.

Some of the original concerns and discussion around the conflict between the proposals included:

  • Gavin King: I think it would be a huge mistake to introduce a second set of annotations which are semantically identical to those in 299 and address the exactly the same problem
  • Bob Lee: While 299 may be fine for small scale EE applications and cute examples, its global configuration and lack of explicitness makes it unsuitable for the multi-million line applications like we have at Google. We can easily support 299-style configuration on top of Guice, but we can't do everything we do with Guice using 299. We have no reason to switch. Personally, I think you've innovated far too much in 299 and don't fully understand the implications on maintainability of users' code.
  • Alex Miller: "this treads perilously close to the territory of JSR 299", "
  • Antonio Goncalves: "I hope we are not starting a new battle like the one between Java Module (JSR 277), Modularity Support (JSR 294)"
  • Rickard Öberg disagreed with the approach: instead of having something like a generic @Inject annotation, which can mean anything and therefore nothing, we have opted to use annotations which specify the scope of the target object

JSR-330 passed its JSR review ballot, but a number of the voters emphasized the need for harmony between the two specs:

  • Sun: In this respect, we request that this JSR and JSR-299 coordinate their efforts so that they can jointly deliver a single, consistent and comprehensive dependency injection standard for the SE and EE platforms. Such coordination must take place before the Public Review of this JSR.
  • Red Hat: However, we recognize that there is some community support for this proposal, and we're therefore holding back on forming a final opinion until the Expert Group produces a public draft. If some level of alignment could be reached between this JSR and JSR-299, which does define a truly portable model for dependency injection, we would be more likely to vote to approve the JSR. Red Hat hereby commit to doing our part to help achieve this outcome.
  • Ericsson: We support the effort to standardize dependency injection for Java SE but would like to stress the importance of coordination with JSR 299 to get a consistent solution for both Java SE and EE.
  • IBM: IBM agrees with the need for a specification describing Dependency Injection for SE applications. However, the proposed injection patterns are divergent from those defined or being defined in the EE platform. The SE/EE injection programming model must be aligned into a single extensible programming model that defines a core set of functionality for SE and extends that with EE functionality. Therefore, IBM will not support either JSR 299 or 330 going to final state without that alignment.
  • Oracle: While being supportive of this JSR, Oracle is seriously concerned about both the completeness of this proposal w.r.t above, as well as the significant opportunity for divergence with JSR 299 that may lead to serious fragmentation of the platforms. Therefore, we would like to see coordination between this JSR and JSR 299 before this JSR goes to Public Review. We also believe that a revision/Maintenance Release of JSR 250 would be a suitable delivery mechanism for DI-related annotations. We hope and expect that such a coordinated effort will result in consistency across the SE and the EE platforms in provide a standard dependency injection mechanism that satisfies all the needs.

The conflict between these specifications has been resolved. JSR-330, "Dependency Injection for Java" and JSR-299 "Contexts and Dependency Injection for the Java EE platform" have been harmonized, JSR-299 will adopt the JSR-330 annotations, and both will be part of Java Enterprise Edition 6. Community reaction seems to be positive thus far (Matt Corey, Jeremy Norris, Alex Miller, Oliver Gierki, Niklas Gustavsson).

Next ? by ariant tristan Posted
Yawn by James Richardson Posted
  1. Back to top

    Next ?

    by ariant tristan

    Can't wait to see the next stage of both this specs.

  2. Back to top

    Yawn

    by James Richardson

    Just another HibernateDaoFactoryBeanContextFactoryImpl.

Educational Content

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.

Beauty Is in the Eye of the Beholder

Alex Papadimoulis discusses ugly code, where it comes from, how to avoid it, and how to get rid of it.

Architecting Visa for Massive Scale and Continuous Innovation

John Davies examines Visa’s architecture and shows how enterprises have architected complex integrations incorporating Hadoop, memcached, Ruby on Rails, and others to deliver innovative solutions.

Max Protect: Scalability and Caching at ESPN.com

Sean Comerford unveils ESPN.com’s architecture, what components are used and why, and the current changes the website goes through.

The Seven Deadly Sins of Enterprise Agile Adoption

Are there repeated patterns of failure on Enterprise Agile Enablement efforts? Sanjiv and Arlen discuss Seven Deadly Sins to avoid when adopting Agile in an enterprise.

Questions for an Enterprise Architect

Erik Dörnenburg answers: What is Enterprise and Evolutionary Architecture?, discussing 4 issues: Turning strategy into execution, Ensuring conformance, Where do the architects sit? Buying or building?

Wrap Your SQL Head Around Riak MapReduce

Sean Cribbs explains what Map-Reduce and Riak are, why and how to use Map-Reduce with Riak, and how to convert SQL queries into their Map-Reduce equivalents.