Let's say that we use the @Autowired
annotation over various fields in a class, and that we didn't write setters or constructors that can also set the fields.
Question - what should the access modifier be, private
or package-private
(i.e. none) ?
For example:
public class MyClass {
@Autowired
private MyService myService;
}
vs
public class MyClass {
@Autowired
MyService myService;
}
In the first case (private
fields) Spring uses reflection to wire up the field, even if it doesn't have a setter.
The second case (package-private
fields) allows us to be able to access those fields (for example, to set up mocks) if we need to extend the class for testing purposes.
So both cases work fine, but which is more recommended, particularly with regards to testing?
I think the properties should be
private
:As it is always good to have getter methods to provide access to the properties instead of allowing other classes to have direct access to them.
And for testing purposes, injection of
mocks
ofprivate properties
will work the same way as that ofpackage-private
properties.For example, with
Mockito
, you can inject a mock ofprivate MyService
intoMyClass
as this:The first case also allows you to inject mocks depending on the framework. For example using the
@InjectMocks
annotation of Mockito. You also haveReflectionTestUtils.setField
in Spring test, ...I'm personally not too fond of modifying classes too much for testing purposes, so I would go for the first case. But at the end of the day this mostly depends on your preferred test framework.
I would generally NOT use @Autowired for private fields or methods. @Autowired means, somebody from outside will set this field. "Private" on the other hand means nobody except this class is allowed to use it.
Mixing @Autowired and private can theoretically cause problems, if the JIT compiler somehow optimizes this code. It can be a Java Memory Model concurrency related problem, which will be production-only and impossible-to-reproduce.
I would make the Autowired fields at least package visible. As free bonus it will allow to write unit tests without tricks and workarounds.
UPDATE: Additionally I would declare such fields as
volatile
to avoid Java Memory Model related visibility conflicts. Spring developers do some tricks to make autowired fields work without explicitly synchronizing the access, but I am not sure these tricks are working smoothly in any JVM on any hardware.I generally prefer having the field private and using setter injection:
allowing the service to be @Autowired, but set with a mocked instance for unit testing.
I would rather use private on @Autowired fields, for a few reasons: