For those who are interested in DI, today Google Guice Team has released Final Version 3.0, go and grab it. Interested in some of the new features? It's a long list, but here it goes:

• JSR 330 support
• New Persist extension
• ToConstructor Bindings
• Better OSGi support (and generally improved support for multiple classloaders)
• New methods in Binder: requireExplicitBindings & disableCircularProxies
• Much simpler stack traces when AOP is involved
• Exact duplicate bindings are ignored (instead of an exception being thrown)
• Repackaged cglib, asm & guava classes are now hidden from IDE auto-imports
• Source can be built with Maven
• General extension & SPI improvements:
• Extensions SPI, with support from the Multibindings, ServletModule and AssistedInject extensions.
• @Toolable, for use by extensions in Stage.TOOL
• All binding implementations implement HasDependencies
• Scope improvements:
• Scopes.isSingleton
• toInstance bindings are considered eager singletons in the Scope SPI
• Singleton providers that return null are now scoped properly.
• Fail when circularly dependent singletons cannot be proxied (previously two instances may have been created)
• Provider Method (@Provides) improvements:
• Logger dependencies now use named instead of anonymous loggers
• Exceptions produce a simpler stack
• Private Modules improvements:
• If a single PrivateModule is passed to Modules.override, private elements can be overridden.
• If many modules are passed to Modules.override, exposed keys can be overridden.
• Multibinder & MapBinder extension improvements:
• permitDuplicates -- allows MapBinder to inject a Map> and a Map> and Multibinder to silently ignore duplicate entries
• Expose dependencies in Stage.TOOL, and return a dependency on Injector (instead of null) when working with Elements.
• Co-exist nicely with Modules.override
• Work properly with marker (parameterless) annotations
• Expose details through the new extensions SPI
• Servlet extension improvements:
• Added with(instance) for servlet bindings.
• Support multiple injectors using ServletModule in the same JVM.
• Support thread-continuations (allow background threads to process an HttpRequest)
• Support manually seeding a @RequestScope
• Expose details through new extensions SPI
• Fix request forwarding
• Performance improvements for the filter & servlet pipelines
• Expose the servlet context (ServletModule.getServletContext)
• Fixed so a single ServletModule instance can be used twice (in, say Element.getElements & creating an Injector)
• Fix to work with context paths
• AssistedInject extension improvements
• New FactoryModuleBuilder for building assisted factories
• Injection is done through child injectors and can participate in AOP
• Performance improvements
• Multiple different implementations can be created from a single factory
• Incorrect implementations or factories are detected in Stage.TOOL, and more error-checking with better error messages
• Work better with parameterized types
• Expose details through new extensions SPI
• ThrowingProviders extension improvements
• Added a new CheckedProviders interface that allows more than one exception to be thrown.
• Added @CheckedProvides allowing @Provides-like syntax for CheckedProviders.
• Dependencies are checked at Injector-creation time and during Stage.TOOL, so they can fail early
• Bindings created by ThrowingProviderBinder now return proper dependencies instead of Injector.
• Struts2
• The Struts2 extension now works again! (It worked in Guice 1.0 and was somewhat broken in Guice 2.0)
• Added to Injector: getAllBindings, getExistingBinding, getScopeBindings, getTypeConverterBindings.
• Added to Key: hasAttributes, ofType, withoutAttributes
• Various bug fixes / improvements:
• Prevent child injectors from rebinding a parent just-in-time binding.
• Non-intercepted methods in a class with other intercepted methods no longer go through cglib (reducing total stack frames).
• Allow Guice to work on generated classes.
• Fix calling Provider.get() of an unrelated Provider in a scoping method.
• MoreTypes.getRawTypes returns the proper types for arrays (instead of Object.class)
• JIT bindings left in a parent injector when child injectors fail creating a JIT binding are now removed
• Overriding an @Inject method (if the subclass also annotates the method with @Inject) no longer injects the method twice
• You can now bind byte constants (using ConstantBindingBuilder.to(byte))
• Better exceptions when trying to intercept final classes, using keys already bound in child or private module, and many other cases.
• ConvertedConstantBinding now exposes the TypeConverterBinding used to convert the constant.

@Inject Hot Beef

Does it finally have lifecycle management?

I personally don't like dependency injection with Java tag.   I feel that tags are already over used.   There are now way to many tags in Java code.   Think of testing tags (JUnit and others), Mock object tags, database tags (ex: JTA or Hibernate), JEEE tags and some more I am leaving behind.   Now we want to add another layer of tags.   Tags are already a mess in Java.

I would prefer that a framework like Guice offer both complete XML specified dependency inject like Spring Framework and tags for those who want it.

 

Hi Colbert,

I am assuming that by tags, you're referring to annotations. The numbers of annotations in java or JEE does not really equate to a "mess". Annotations are a nice way to add/modify behavior to an object, I think that it is really up to the designer/developer to use it judiciously. If you end-up with a class with annotations all over the place, my first inclination will be to deduce that the class is not refined enough, too many responsibilities or has to many dependents...

On that note, congratulations to the Guice Team....

Refactoring is a real pain when you do DI using XML, and trust me, refactoring is something that you are doing many many times so you wan't it to perform as smooth as possible! Also how many times you've had single character spelled wrong in your XML file and then getting obscure stacktraces from your application server. Another issue with XML is that then all the DI magic is completely invisible from the code. This is sometimes good thing though but typically developers like to instantly see that "Hey, in this method we got DI magic going in here, I can see it because of the annotation!"

The biggest downsize using XML is that it's not Java and therefore java compiler's and IDE's support for it are quite poor.

Curious.. this is something that always bothered me (maybe bother is the wrong word.. maybe "escaped me" is better).. When using the Annotations in Spring.. And you have a @Service class.. and you make a Mock.. How do you get Spring to know to inject the Mock vs the Real one when running JUnits.. I always got the "ambiguous " error.. Using XML I was always able to redefine the impl for the service interface.. In @Annotations the solution (@Qualifier) always seemed "messy". Felt like I was gibing control back to the consumer.. I assume since you like Annotations you have a clean solution? Would love to hear about it.. The XML based configs can also be a nightmare..

Congratulations to Guice team for the new release, Nice to see the JSR 330 support and struts2 fixes

servletworld

Çini Silimi ve Karo Silimi i?lerine yo?unla?an firmamiz sizin için mermer ve zemin silimi i?lemlerini de yapmaktadir. Dizayn Restorasyon, Restorasyon Çini bak?m?, temizli?i ve beyazlat?lmasi i?lemleri yapilmaktadir.