The life of a full stack developer is an adventure full of new things to learn daily. This week, after using some templates for about a year based in Spring Boot, I finally came to understand what is going on with @Autowired.
Spring Boot, if you use it for Java development, provides a very clean and easy to use dependency injection model that falls under the @Autowired annotation. It’s "easy to use", that is, once you wrap your head around top-down dependency injection and what it means for instantiated classes. The trick is starting with the SpringWebConfig class, where your instantiated classes will no longer be created with the “new” operator, but annotated wth the @Bean annotation.
In SpringWebConfig.class:
@Bean
public MyClass getMyClass(){
return new MyClass(); // the one place you call new
}
What @Bean buys you is a registration into the Spring context loader, making it available throughout all other classes annotated with @Component. The downside for this is that if you want to use any @Autowired dependency in a class, such as Environment, you have to register that class as a bean and then auto wire an instance of the bean wherever you would have instantiated the class, as with a Test class or main execution class like a Controller or Main. This means classes will be eagerly loaded, creating slightly longer start up times for applications, but less code to write and manage.
Update: I neglected to point out that a benefit of using beans in this way is that they are effectively all singletons. This means they will exist in memory once, which enforces tidy memory management and can improve your application performance at run time. A small recent anecdote: migrating from using jdbc connections in just a handful of classes to using a bean to register a single Spring JdbcTemplate reduced our database open connections from 117 to less than 20. While this means less memory consumed on your application server, it also frees up database server resources that would otherwise be spent maintaining so many connections.
Update: I neglected to point out that a benefit of using beans in this way is that they are effectively all singletons. This means they will exist in memory once, which enforces tidy memory management and can improve your application performance at run time. A small recent anecdote: migrating from using jdbc connections in just a handful of classes to using a bean to register a single Spring JdbcTemplate reduced our database open connections from 117 to less than 20. While this means less memory consumed on your application server, it also frees up database server resources that would otherwise be spent maintaining so many connections.
The trick here is to remember to avoid things like...
MyClass myClassInstance = new MyClass(); // this will cause your autowired instance to throw a null pointer exception.
...and prefer instead something that seems a bit more complex at first glance, but ties lots of things together as if by magic. In the places you would use your class, such as in a test class, access the context scoped class instance this way:
@ContextConfiguration(loader = AnnotationConfigWebContextLoader.class, classes ={SpringWebConfig.class})
public class TestClass{
@Autowired
private MyClass myClassInstance; // at run time, this will be instantiated by the SpringWebConfig class and will be scoped to TestClass
@Test
public void testTheClass(){
assertNotNull(myClassInstance) ; // success!
}
}This does change the way you'll work with constructors. Passing values to constructors doesn't work well in this model. Prefer instead to write methods in your classes that accept configuration parameters, if needed.
You can read much more about Spring annotations here or check out the official reference guide.
