Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Before trying to answer your question, let me just add an important piece of information: <a href="http://jcp.org/en/jsr/detail?id=330" rel="noreferrer" title="Dependency Injection for Java">JSR 330</a> (<code>@Inject</code>) was standardized by Guice and Spring projects (<a href="http://googlecode.blogspot.com/2009/05/javaxinjectinject.html" rel="noreferrer">announcement from May 2009</a>) and is being <a href="http://relation.to/Bloggers/JSR299ProposedFinalDraft2" rel="noreferrer" title="JSR 299 Proposed Final Draft 2">reused in JSR 299</a>. This covers basic DI mechanisms in terms of declaring an injection point.</p> <p>Now, back to the question - with the disclaimer that I have far more experience with Spring than with Guice.</p> <p><strong>Enterprise capabilities in Weld</strong></p> <ul> <li><a href="http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/injection.html#alternatives" rel="noreferrer">Alternative configuration mechanisms</a> have a very clean design in JSR-299 and allow for configuration mechanisms outside of the Java code (<code>beans.xml</code>).</li> <li><a href="http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/events.html" rel="noreferrer">Events</a> are a very powerful thing and fit nicely with JMS. I just found an <a href="http://guts.kenai.com/guts-events/dependencies.html" rel="noreferrer">Event Bus for Guice</a>, but I cannot say how that compares.</li> <li><a href="http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/extend.html" rel="noreferrer">Portable extensions</a> are an SPI that can be used to integrate with existing technology or wrap legacy code in a clean way.</li> </ul> <p><strong>Advantages / Disadvantages</strong></p> <p><em>Note: I will try to add a few items here later, but this answer is already longer than I had expected, sorry.</em></p> <ul> <li><p><strong>Weld/CDI</strong></p> <ul> <li><em>Standardization</em>: If something is standardized and there is a good implementation, a lot of people will be using it. Example: <a href="http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/scopescontexts.html#d0e1766" rel="noreferrer">Built-in scopes</a> in Weld provide a few more scopes than <a href="http://code.google.com/p/google-guice/wiki/Scopes" rel="noreferrer" title="Scopes in Google Guice">Guice</a> or <a href="http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-scopes" rel="noreferrer" title="Bean scopes in Spring">Spring</a>. All of these can be extended, but application frameworks will rather rely on standard scopes if they are being used by a large community.</li> <li><em>Container support</em>: this is similar to the previous item, but a major argument for adoption. Major open source application servers, such as Glassfish and JBoss 6 provide CDI support (see <a href="http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/environments.html" rel="noreferrer" title="Application servers and environments supported by Weld">here</a>).</li> </ul></li> <li><p><strong>Guice/Spring</strong></p> <ul> <li><em>Actual application</em>: Most of the existing applications will be using Guice/Spring already. Spring/Guice have always built on standards and provided new capabilities where no standards existed or could not be used. If you follow with the respective best-practices, the framework will help you make your application standards-based and clean.</li> </ul></li> </ul> <p><strong>AOP and Interceptors</strong></p> <p>This is a very heavily discussed topic, and I cannot favor one over the other. Both mechanisms are very powerful but require at least a minimum understanding of the application's architecture. Also have look at <a href="http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/decorators.html" rel="noreferrer">Decorators</a> and the previously referenced <a href="http://docs.jboss.org/weld/reference/1.0.1-Final/en-US/html/events.html" rel="noreferrer">Events</a>. It is best to go with the right tool, but don't forget that if a developer has to work with one of these mechanisms it is a good thing if he/she understands the concept.</p> <p><strong>Performance</strong></p> <p>Unfortunately I could not look into this yet, but there are a few rules I try to follow, especially when using a framework that gives you a lot of functionality without you noticing it:</p> <ul> <li>Whenever possible, prefer a single wiring step over multiple lookups at runtime.</li> <li>If possible, do all the wiring on application initialization.</li> <li>Any interception step or AOP proxy adds a few method calls to the stack.</li> </ul>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload