What is the difference between @Inject and @Autowired in Spring Framework? Which one to use under what condition?

Question

I am going through some blogs on SpringSource and in one of the blogs, author is using @Inject and I suppose he can also use @Autowired.

Here is the piece of code:

@Inject private CustomerOrderService customerOrderService;

I am not sure about the difference between @Inject and @Autowired and would appreciate it if someone explained their difference and which one to use under what situation?

Solution 1

Assuming here you're referring to the javax.inject.Inject annotation. @Inject is part of the Java CDI (Contexts and Dependency Injection) standard introduced in Java EE 6 (JSR-299), read more. Spring has chosen to support using the @Inject annotation synonymously with their own @Autowired annotation.

So, to answer your question, @Autowired is Spring's own annotation. @Inject is part of a Java technology called CDI that defines a standard for dependency injection similar to Spring. In a Spring application, the two annotations works the same way as Spring has decided to support some JSR-299 annotations in addition to their own.

Solution 2

Here is a blog post that compares @Resource, @Inject, and @Autowired, and appears to do a pretty comprehensive job.

From the link:

With the exception of test 2 & 7 the configuration and outcomes were identical. When I looked under the hood I determined that the ‘@Autowired’ and ‘@Inject’ annotation behave identically. Both of these annotations use the ‘AutowiredAnnotationBeanPostProcessor’ to inject dependencies. ‘@Autowired’ and ‘@Inject’ can be used interchangeable to inject Spring beans. However the ‘@Resource’ annotation uses the ‘CommonAnnotationBeanPostProcessor’ to inject dependencies. Even though they use different post processor classes they all behave nearly identically. Below is a summary of their execution paths.

Tests 2 and 7 that the author references are 'injection by field name' and 'an attempt at resolving a bean using a bad qualifier', respectively.

The Conclusion should give you all the information you need.

Solution 3

To handle the situation in which there is no wiring, beans are available with @Autowired required attribute set to false.

But when using @Inject, the Provider interface works with the bean which means that the bean is not injected directly but with the Provider.

Solution 4

The key difference(noticed when reading the Spring Docs) between @Autowired and @Inject is that, @Autowired has the 'required' attribute while the @Inject has no 'required' attribute.

Solution 5

As of Spring 3.0, Spring offers support for JSR-330 dependency injection annotations (@Inject, @Named, @Singleton).

There is a separate section in the Spring documentation about them, including comparisons to their Spring equivalents.

View more solutions

Comments

[Sagar V]

I don't have an answer, since I'm new to this too, but this might help sakaenakajima.wordpress.com/2010/08/10/…

[RustyShackleford]

Duplicate: stackoverflow.com/questions/13657787/import-custom-java-clas‌​s

[Alex Theedom]

The difference between '@Inject' and '@Autowired' is explained well in this article alextheedom.wordpress.com/2016/02/13/…

[Ziaullhaq Savanur]

Please have a look at this link: concretepage.com/spring/… This feature is supported in @Inject automatically without any (required=false) attribute

[Alex Barnes]

So in theory if you used @Inject you could replace spring with another DI framework e.g. Guice and inject your dependencies in the same way.

[Brad Cupit]

At the risk of being pedantic: @Inject is a separate JSR (JSR-330) from CDI (JSR-299).

[Thomas]

That article is a great explanation of the the three annotations. I had to re-read it after the first swipe; but, an excellent article.

[Agoston Horvath]

If you rely on JSR-* annotations only, sure, you can replace you DI framework. But will you? Once you've started using spring, chances are you've used a lot more of it than just DI. You won't just make a change; and even if you do, it's not a few search & replaces that is going to make or break the move. On the other hand, Spring's own annotations offer you a lot more functionality. Mastering a good framework will give you more than hardly using many.

[Igor Donin]

This is so important, and has been overlooked in the most upvoted answers.

[Alex Theedom]

Even though the '@Inject' does not have a required attribute the Java Docs state: Injection of members annotated with '@Inject' is required. Which seems to imply that if an member is not found its inject will fail. See Java Docs: docs.oracle.com/javaee/7/api/javax/inject/Inject.html

[Amrinder Arora]

Sun is dead. Long live the sun.

[Aditya]

I agree with you that we dont change the DI frameworks often . However if our source code has multiple packages and if you want to build a common package which you want to share across multiple projects and then going with @Inject JSR annotation is better than using @Autowired which locks your code base with spring DI.

[mattyman]

what do u mean by required?

[Lucky]

@mattymanme From the docs, "By default, the autowiring fails whenever zero candidate beans are available; the default behavior is to treat annotated methods, constructors, and fields as indicating required dependencies. This behavior can be changed by setting the required attribute to false". E.g: @Autowired(required=false).In simple terms, "The required attribute indicates that the property is not required for autowiring purposes, the property is ignored if it cannot be autowired."

[Kevin Cruijssen]

Thanks a lot! The article answered multiple of my answers in my search of finding the differences and similarities between Spring and JavaEE, as well as a few other questions I had.

[tranquil]

By default required parameter is set to true for Autowired. Ref: docs.spring.io/spring-framework/docs/current/javadoc-api/org‌​/…

[Kay]

how often are you going to change the framework? just curious

[tarn]

look in to source code public interface Autowired { /** * Declares whether the annotated dependency is required. */ boolean required() default true; } public interface Inject {}

[Dan Chase]

Question here, what do you mean when you say Spring supports JSR? Doesn't the container support JSR independent of Spring, and a requirement for the container to be J2EE compliant? Do you mean that it wraps the functionality? If Spring didn't "support" it, wouldn't the annotation from javax still work by default?

[Andre Steingress]

It's not a must to run Spring in a JEE container, you can also use it in a servlet/JSP container like Tomcat and still have the JSR-330 support. Spring is a separate DI container, it does not "interchange" CDI beans with the host JEE server if its that what you mean. You may either use CDI in a JEE container, or Spring beans - but you can't use both (out of the box).

[Witold Kaczurba]

On most of projects I saw Autowired rather than Inject. I understand the rationale of the answer but I cannot upvote.

[Marcus K.]

Using @Inject alone won't ensure framework independence. You'd also need to declare injectable beans without framework dependent mechanisms like Spring's @Component or application.xml, but use @Named and @Singleton on class level. No idea if any Spring project really declares beans like that today - I even never heard of any project which migrated from Spring to JEE...

[Ziaullhaq Savanur]

Please have a look at this link: concretepage.com/spring/… This feature is supported in @Inject automatically without any (required=false) attribute

[Ziaullhaq Savanur]

Please have a look at this link: concretepage.com/spring/… This feature is supported in @Inject automatically without any (required=false) attribute

[Deqing]

So I suppose this CDI is not in OpenJDK?

[Ranjithkumar]

What's no 'required'?

[Adam Horvath]

By writing @Autowired(required = false) you can finish the initialization of your component even if Spring was unable to wire (inject) the member. @Inject will throw an exception in such case, without the opportunity to continue with construction/injection.