Qodana
The code quality platform for teams
Static Code Analysis for Spring: Run Analysis, Fix Critical Errors, Hit the Beach
Fun fact: 72% of our JVM users use Spring in their applications, especially in industries like manufacturing and finance. Why? Spring makes programming with Java and Kotlin quicker, easier, and safer for everybody – but it also comes with unique challenges.
Why is it so tricky to manage code quality in Spring?
Spring has a rich API interface with annotations and configuration files – a broad system with many specifics. It’s a framework that works like glue for your app, determining how you structure, build, and run code, freeing you up to think about which logic to apply.
In a Spring Framework project, you can change one file, and everything will still look correct. However, this small change can easily affect your app’s configuration and lead to errors in other files. It’s possible that you won’t see these errors until you open those other files, which is too late.
To confidently change files in such a project, you need safeguards to help you navigate code quality in such a complex framework. That’s why we originally built the Spring plugin for IntelliJ IDEA to include a wide range of Spring-specific inspections for everyday use. Now, we’ve added Spring-specific inspections to Qodana.
Spring, Qodana, and IntelliJ IDEA: How do the three work together?
The out-of-the-box experience of IntelliJ IDEA gives you everything you need for typical Java and Kotlin development, including Spring. The plugin contributes various checks for Spring Framework and comes bundled with the Qodana JVM linter.
You can find the full list of inspections for Spring Framework in IntelliJ IDEA under Settings | Editor | Inspections by searching for “Spring” to filter out irrelevant inspections.
The same checks run in the IDE when you write code and even include server-side analysis. This means that if you missed some issue in the IDE, it will be detected by the Qodana linter in the CI pipeline.
The Qodana report will reveal the issues that snuck into the project, and everyone on the team will know. Qodana makes code reviews a team sport ahead of runtime, improving overall code quality and bringing enhanced collaboration to your team’s workflow.
Spring inspection groups
Spring inspections can be grouped by use case into checks for issues related to autowiring, configuration files, the data access layer, the web layer, and many more. Let’s take a closer look at some of these groups.
Spring autowiring inspections
As Spring’s programming model relies on annotations, the various components are typically scattered across the project and often reside in different files and packages. It’s not immediately obvious whether the required dependencies exist, whether there are no conflicts, or whether the references to lifecycle methods are correct. These problems fall into the category of autowiring issues, and this is the most typical group of issues that developers face when working with the Spring Framework.
You can spot many autowiring issues in Spring’s context in the editor, highlighted as you type. These include minor recommendations, such as avoiding field injection, or bigger issues, such as a mistyped package name in the ComponentScan annotation.
Let’s look at an example of a situation in which changing one component in a Spring application may cause the failure of another component.
In Spring applications, it’s possible to describe a dependency between components using the @DependsOn annotation, where a dependency name is specified as a string. The components might reside in different parts of the project, and a change in the dependency could potentially break the lifecycle of a dependent component.
In the screenshot above, the IDE reports that the dependency referenced in the @DependsOn annotation parameter cannot be resolved, even though the GeneralConfig class that implements the component is visible in the project tree.
The problem is a typo in the reference name: instead of “generalconfig” (all lowercase letters), the value should be “generalConfig” (with a capital letter “C”) – that is the convention used in Spring Framework for referencing components in the context of the application.
Even though the issue is highlighted in the editor, it’s easy to miss this error if the change is made elsewhere without updating the reference value. The compilation process won’t detect this issue and simple unit tests won’t catch it either.
What we need is a minimal set of integration tests and additional static code checks. This is where Qodana comes in handy, as this type of issue is included in the report that JetBrains’ flagship code quality platform generates.
Application configuration inspections
Configuration issues are annoying. A little typo in a configuration file can cause an application to misbehave or even crash.
Configuration inspections report unresolved and deprecated configuration keys and invalid values in the configuration files of Spring Boot application properties, which can lead to runtime errors.
For instance, the configuration might include deprecated property names. This may occur when we upgrade the version of Spring Framework in the project but remember to update the configuration accordingly.
Another type of configuration issue involves the misspelling of property values. For instance, in the screenshot above, the value of the spring.devtools.restart.poll-interval property is highlighted in red. This value should be spelled as “5m” instead of “5min”.
Qodana inspections for Spring Data
Spring Data relies on its method naming convention to generate database queries. Although this approach is very convenient, it’s easy to miss the convention unless you’re paying very close attention.
In the example above, the convention for the findByType method signature requires the PetType class as a parameter, but Integer was used as a parameter instead. To fix this, we can either extract a JPQL query into a Query annotation for the method or simply change the parameter type.
There are more checks that verify that the code using Spring Data follows the applicable conventions. For instance, you’ll be notified if the method name doesn’t match the property name of the entity.
Inspections for Spring MVC
Data access isn’t the only place where Spring Framework relies on naming conventions. Another example where you need to be aware of the conventions is the implementation of the web layer.
When working with Spring MVC, typically we refer to external resources or path variables by name. It’s easy to make a typo and then the external resource won’t be resolved.
The inspections for Spring MVC can also detect the unresolved references in the PathVariable annotation and missing resources for template engineers like Thymeleaf.
The powerful combination of Spring, Qodana and IntelliJ IDEA
Spring Framework is a popular yet complex framework where a lot of its functionality is based on naming conventions, or relies on component name references that are not validated at compile time.
IntelliJ IDEA validates Spring Framework conventions as you type in the editor, while Qodana builds on top of IntelliJ IDEA’s static analysis engine to provide visibility into the project for the whole team.
As a direct result, you can use Qodana to increase productivity, improve code quality, and provide learning opportunities to developers at various stages of seniority.
Got questions on code quality for the Qodana team?
Reach out to qodana-support@jetbrains.com – or follow us on X (formerly Twitter) and LinkedIn for code quality updates. You can also view the documentation to get started.
Subscribe to Qodana Blog updates
