@Autowired field injection instead of constructor injection
Part of Architecture & Best Practices, which counts for 15% of the overall score. When this check fires it deducts 4 points from that category, once per scan, no matter how many places it turns up.
What it detects
@Autowired is applied directly to a field rather than a constructor parameter. Field injection hides a class's real dependencies from its public API, makes the class harder to instantiate in a plain unit test without a Spring context, and allows circular dependencies that constructor injection would catch at startup.
Why it matters
Field injection with @Autowired hides a class's real dependencies from its public API: you cannot tell what a class needs just by looking at its constructor, a plain unit test cannot instantiate it without reflection or a Spring context, and it allows circular dependencies between beans that constructor injection would instead catch immediately at startup.
How to fix it
Move the dependency to a constructor parameter and assign it to a private final field. With a single constructor, @Autowired on the constructor itself is optional (Spring uses it automatically); Lombok's @RequiredArgsConstructor is a common way to avoid the boilerplate if this project already uses Lombok.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo