Spring Framework Has Three Major Pitfalls — Here’s What To Do

Spring is a classic framework — 50% of developers use it these days, and it’s great for creating standalone production-grade applications. With its new classes, interfaces and APIs aiding the development process, developers must educate themselves to decide whether they want to use it in their coding. This is because misuse of Spring Boot’s new features can lead to bugs, misconfigurations and security issues that can impact code quality.

There are three important points to be aware of when using the Spring framework.

Transactional Operations

Database operations must all be committed in order to be available to other connections. That means that for every operation done to the database, the process entails having to open a transaction, change the data and commit the transaction, or roll back the transaction if anything fails.

Spring can annotate methods to create proxies via @Transactional, generating code that operates seamlessly within the codebase to manage transactions. However, you may have chains of method calls where an operation makes multiple changes to the database and those changes have to be split into several methods for clarity. That’s where transactional propagation takes place.

Usually, we have an entry point method with the @Transactional annotation that starts the transaction. The rest of the methods in the call chain won’t specify the annotation, which allows the first method to do the whole commit. This is the required default propagation method. If there’s no transaction running, it’ll create one.

But reality is often more complex than we would imagine. For example, say you have methods that are part of different operations, and sometimes your method is the only operation that fits. In these chains of calls, we have to keep compatible transaction propagation, but Spring won’t consider the transaction specifications of self-invocation.

So, what does this mean? When you call a method from another one in the same class, Spring will use the “this” approach to refer to the receiver method. Spring then generates the code as a proxy to handle transactions that can’t be executed.

To avoid that, in the methods that can execute other methods inside transactions, we should specify the @Transaction annotation.

Persistent Entities

One of the great things about Spring is its ease of interaction with the persistence layer. In order to use typed objects and properties, Java provides an @Entity annotation to represent a relational table, and Spring provides the @Document annotation to represent MongoDB and ElasticSearch documents. In these cases, Spring can use the information in the element and make a bridge between the object domain and the database domain.

It’s critical to understand here that these objects represent data objects with a direct conversion to the stored elements in the database, meaning all fields carried by that object will be saved in the database. Spring is able to share methods to generate REST API services that execute when the user makes an HTTP request to that server. These methods also enable the use of entities or documents as arguments that Spring will map from the request payload.

To prevent security issues like an attacker impersonating a user, it’s encouraged to use data transfer objects (DTOs) to translate the information coming from the user into the entity or document. This will consider only the necessary information and sanitize the translation too.

Bean Definitions

A main power of Spring is its dependency injection, which enables users to define beans that will be injected into other objects and their lifespan. With this feature, classes only have to know what their dependencies are. It doesn’t require understanding how and when they have to be instantiated and deleted.

Spring also has a bean discovery mechanism; it scans source code packages to search for bean definitions. The Spring context then instantiates them according to the configuration. But with this power comes responsibility. It’s important to be aware that this scanning mechanism can affect overall application performance and induce runtime errors that are challenging to spot while coding. The key to preventing this is always having a package in the application as the starting point of the bean scan for Spring.

Spring, with its dependency injection framework, offers a powerful injection mechanism on the consumer side of those beans. This makes very easy-to-use instances of beans, with specific life scopes, without needing to worry about when and where those beans have been created or deleted. To avoid the injection of beans being done before it’s needed, which can hurt application performance, it’s recommended to not use the @Autowired annotation. Instead, the injection should be requested as late as possible when it’s needed by parameter injection. This will tell Spring that the bean needs to be created right before the creation of the dependent bean.

Final Thoughts

Spring has some fantastic features that aid in the development process, but it also comes with complex configurations. It’s vital to understand Spring’s limitations and drawbacks to get the most value out of it, but that can be tough.

It’s not always clear where the code can potentially create disruption of performance and stability. This is where static analysis solutions like Sonar can help, with rules that cover and spot major issues, providing warning during the coding process as well as performing constant monitoring in the CI/CD pipeline. With the right rules in place to ensure quality, it’s easier to feel confident that the code being written will result in software that adds real value and doesn’t become a liability.