@Reposotory
public interface SomeRepo{}

@RequiredArgsConstructor
public class CheckDt{

private final SomeRepo repo;

private List<SomeData> someDataList;

public List<SomeData> getSomeDataList(){
return repo.findAll();

Field-based dependency injection drawbacks
Disallows immutable field declaration
Field-based dependency injection won’t work on fields that are declared final/immutable as this fields must be instantiated at class instantiation. The only way to declare immutable dependencies is by using constructor-based dependency injection.

Eases single responsibility principle violation
As you know, in object-oriented computer programming, the SOLID acronym defines five design principles that will make your code understandable, flexible and maintainable.

The S in SOLID stands for single responsibility principle, meaning that a class should only be responsible for a single part of the functionality of the software application and all its services should be aligned narrowly with that responsibility.

With field-based dependency injection, it’s really easy to have lots of dependencies in your class and everything will look just fine. If constructor-based dependency injection is used instead, as more dependencies are added to your class, the constructor grows bigger and bigger and code starts to smell, sending clear signals that something is wrong.

Having a constructor with more than ten arguments is a clear sign that the class has too many collaborators and that maybe is a good time to start splitting the class into smaller and more maintainable pieces.

So although field-injection is not directly responsible for breaking the single responsibility principle it surely enough helps by hiding signals that otherwise would be really clear.

Tightly coupled with dependency injection container
The main reason to use field-based injection is to avoid the boilerplate code for getters and setters or creating constructors for your class. In the end, this means that the only way these fields can be set are by Spring container instantiating the class and injecting them using reflection, otherwise the fields will remain null and your class will be broken/useless.

The dependency injection design pattern separates the creation of class dependencies from the class itself transferring this responsibility to a class injector allowing the program design to be loosely coupled and to follow the Single responsibility and Dependency inversion principles (again SOLID). So in the end the decoupling achieved for the class by autowiring its fields is lost by getting coupled again with the class injector (in this case Spring) making the class useless outside of a Spring container.

This means that if you want to use your class outside the application container, for example for unit testing, you are forced to use a Spring container to instantiate your class as there is no other possible way (but reflection) to set the autowired fields.

Hidden dependencies
When using a dependency injection pattern, affected classes should clearly expose these dependencies using a public interface either by exposing the the required dependencies in the constructor or the optional ones using methods (setters). When using field-based dependency injection, the class is inherently hiding these dependencies to the outside world.

class FuckingMapperTest {

  @Mock
  private FukinRepo faukinRepository;
  @Mock
  private FukinRepo faukinRepository;
  @Mock
  private FukinRepo faukinRepository;
  @Mock
  private FukinRepo faukinRepository;
  @Mock
  private FukinRepo faukinRepository;
  @Mock
  private FukinRepo faukinRepository;

  @InjectMocks
  private FuckingMapper fuckingMapper;

  @BeforeEach
  void setUp() {
    MockitoAnnotations.openMocks(this);

@ContextConfiguration(classes = {FuckingMapper.class})
@ExtendWith(SpringExtension.class)
class FuckingMapperTest {

  @MockBean
  private FukinRepo faukinRepository;
  @MockBean
  private FukinRepo faukinRepository;
  @MockBean
  private FukinRepo faukinRepository;
  @MockBean
  private FukinRepo faukinRepository;
  @MockBean
  private FukinRepo faukinRepository;
  @MockBean
  private FukinRepo faukinRepository;

  @Autowired
  private FuckingMapper fuckingMapper;