``++@ComponentScan++`` is used to find which Spring ``++@Component++`` beans (``++@Service++`` or ``++@Repository++`` or ``++Controller++``) are available in the classpath so they can be used in the application context. This is a convenient feature especially when you begin a new project but it comes with the drawback of slowing down the application start-up time especially when the application becomes bigger (ie: it references a large JAR file, or it references a significant number of JAR files, or the base-package refers to a large amount of .class files).
``++@ComponentScan++`` should be replaced by an explicit list of Spring beans loaded by ``++@Import++``.
The interface ``++@SpringBootApplication++`` is also considered by this rule because it is annotated with ``++@ComponentScan++``.
* https://sites.google.com/site/appsdevelopersindia/google-blog/optimizingspringframeworkforappengineapplications[Optimizing Spring Framework for App Engine Applications]
\[~alexandre.gigleux] the title says "fine-tuned" and the description says "replaced". Should title be "should not be used"?
=== on 21 Jun 2018, 16:35:00 Andrei Epure wrote:
This rule partially overlaps with https://jira.sonarsource.com/browse/RSPEC-4604[RSPEC-4604] with regards to ``++SpringBootApplication++``. RSPEC-4604 suggests having either ``++@SpringBootApplication(exclude = {})++`` , or using ``++@Import++`` - like this rule
=== on 22 Jun 2018, 09:28:14 Alban Auzeill wrote:
Even if it overlaps with RSPEC-4604, [~andrei.epure] and I decided to add it to SonarJava because this rule is not in the "Sonar way" profile. So it will be not be noisy, but useful to those who requires it.
=== on 29 Aug 2018, 18:30:14 Michal Domagala wrote:
Are you aware of https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#beans-scanning-index[beans-scanning-index]?
Did you notice that you refer to article from 2012 (Spring 3) \https://cloud.google.com/appengine/articles/spring_optimization ?
=== on 14 Mar 2021, 18:08:06 Stéphane Nicoll wrote:
Spring Boot developer here.
Unfortunately, I think this rule is misleading. The impact of component scanning is very low, even with somewhat large application. We've implemented a compile-time indexer that really makes a difference with thousands of beans from tens of thousands of candidates.
A better way to structure this rule would be to guide users to rationalize the candidates in a given package. So, for instance, avoiding the use of `@ComponentScan("org")` or even`@ComponentScan("org.mycompany")`. Component scan is better use on the project's asserts (i.e. `org.mycomponent.myproject`). For libraries or reusable components, `@Import` is a better choice indeed.