Humans have never liked to spend much time on routine work and tasks that are not related to their goals. In business, to achieve the desired result, we are required to learn fast and experiment fast. Reactivity also applies in real life. It is crucial to react to changes in the market, change strategies fast, and achieve new goals as quickly as possible. The faster we prove the concept, the more value it brings to business, and the less money is therefore spent on research.

For this reason, humans have always endeavored to simplify routine work. Developers are not excluded from that rule. We love everything to work out of the box, especially when we are talking about a complex framework such as Spring. Despite a lot of benefits and advantageous features introduced by Spring Framework, it requires a deep understanding of how to work with it, and novice developers may easily fail when they become involved in an area in which they are not experienced. A good example of a possible pitfall is a simple inversion of control (IoC) container's configuration, which counts at least five possible configuration methods. To understand the problem, let's take a look at the following code sample:

public class SpringApp {
   public static void main(String[] args) { 
      GenericApplicationContext context = 
         new GenericApplicationContext();

      new XmlBeanDefinitionReader(context)
         .loadBeanDefinitions("services.xml");

      new GroovyBeanDefinitionReader(context)
         .loadBeanDefinitions("services.groovy");

      new PropertiesBeanDefinitionReader(context)
         .loadBeanDefinitions("services.properties");

      context.refresh(); 
   } 
}

As we can see from the preceding code, the raw Spring Framework has at least three different ways of registering beans in the Spring context.

On the one hand, Spring Framework offers us flexibility in configuring the beans' sources. On the other hand, there are a few problems that come with having such a broad list of options to do this. For example, one of the problems is XML configurations that we cannot debug easily. Another issue that makes it harder to work with such configurations is the inability to validate the correctness of those configurations without additional tools, such as IntelliJ IDEA or Spring Tool Suite. Finally, the lack of proper discipline in coding styles and development conventions may significantly increase the complexity of a large project and decrease its clarity. For example, the lack of proper discipline in the approaches to bean definition may complicate a future project since one individual developer in the team may define beans in the XML and another may do this in properties. Anyone else may do the same in the Java configurations. Consequently, a new developer may easily get confused by that inconsistency and delve into the project for much longer than necessary.

Along with a simple IoC, Spring Frameworks provide much more complex features, such as the Spring Web module or the Spring Data module. Both modules require plenty of configuration just to run the application. Troubles usually arise when the developed application is required to be platform-independent, which means an increasing number of configurations and boilerplate code, and less business-related code.

For example, to configure a simple web application and nothing else, we need at least seven lines of boilerplate, as shown in the following code:

public class MyWebApplicationInitializer 
             implements WebApplicationInitializer {      
   @Override   
   public void onStartup(ServletContext servletCxt) { 
      AnnotationConfigWebApplicationContext cxt =
            new AnnotationConfigWebApplicationContext();
      cxt.register(AppConfig.class);     
      cxt.refresh();
      DispatcherServlet servlet = new DispatcherServlet(cxt);     
      ServletRegistration.Dynamic registration = servletCxt
            .addServlet("app", servlet);
      registration.setLoadOnStartup(1);
      registration.addMapping("/app/*");
   }
}

The preceding code does not include any security configurations or other essential functionalities, such as content rendering. At some point in time, each Spring-based application had similar pieces of code that were quite unoptimized and required additional attention from developers, consequently wasting money for no good reason.