SpringBatch - javaconfig vs xml

问题:

I have been using Xml configuration for Spring Batch for a while, and feel it is simpler and concise. However, nowadays, people are suggesting to use javaconfig over xml. I googled this topic.

This site tells us why javaconfig is better https://blog.codecentric.de/en/2013/06/spring-batch-2-2-javaconfig-part-1-a-comparison-to-xml/

Top reasons to choose javaconfig over xml:

1. We want to do some basic configurations in the framework. People add a dependency to our framework library and import those configurations according to their needs. If these configurations were written in XML, they would have a hard time opening them to look what they are doing. No problem in Java.
2. There’s no navigability in XML. That may be okay as long as you don’t have too many XML files and all of them are in your workspace, because then you can take advantage of the Spring IDE support. But a framework library usually should not be added as a project to the workspace. When using Java based configuration you can perfectly jump into framework configuration classes. I will talk more about this subject in a following blog post.
3. In a framework you often have requirements the user of the library has to fulfill in order to make everything work, for example the need for a DataSource, a PlatformTransactionManager and a thread pool. The implementation doesn’t matter from the perspective of the framework, they just need to be there. In XML you have to write some documentation for the users of framework, telling them they need to add this and this and this Spring bean under this name to the ApplicationContext. In Java you just write an interface describing that contract, and people using the library implement that interface and add it as a configuration class to the ApplicationContext. That’s what I did with the interface.

This site tells us why xml is better https://dzone.com/articles/consider-replacing-spring-xml

Top reasons to choose xml over javaconfig

1. Configuration is centralized, it’s not scattered among all different components so you can have a nice overview of beans and their wirings in a single place.
2. If you need to split your files, no problem, Spring let you do that. It then reassembles them at runtime through internal tags or external context files aggregation.
3. Only XML configuration allows for explicit wiring – as opposed to autowiring. Sometimes, the latter is a bit too magical for my own taste. Its apparent simplicity hides real complexity: not only do we need to switch between by-type and by-name autowiring, but more importantly, the strategy for choosing the relevant bean among all eligible ones escapes but the more seasoned Spring developers. Profiles seem to make this easier, but is relatively new and is known to few.
4. Last but not least, XML is completely orthogonal to the Java file: there’s no coupling between the 2 so that the class can be used in more than one context with different configurations.

I concluded that xmls can still be used, if you are creating standalone batch jobs and if you are not creating any new frameworks by integrating with Spring Batch.

Any disadvantage of xmls that I am missing out ?

回答1:

Let me add a couple of additional thoughts on the topic.

What I really like when using javaconfig is the ability to create your jobs dynamically. E.g., you could have an inputparameter with filenames and then create a job that executes reading and processing this files in parallel by creating a step for every received filename. (using a MultiResourceItemReader would do this sequentially). Moreover, depending on inputparameter, you could also define the job flow differently.

My thoughts on your reasons why choosing xml over javaconfig: point 1: this doesn't really count in my opinion. You can have your own configuration classes, you can define your own packages. You could even put them in own modules. This is just a matter, how you organize your code.

point 2: again, this doesn't count as well. You can split your configuration in as many classes as you'd like. You can use the @Import and @ContextScan annotation in order to integrate what you want into your context.

point 3: autowiring can also be very explicitly, if you do it by class and not by interface. Moreover, you can also call directly the method annotated with @Bean. An example:

@Configuration
public MyBeanFactory {
   @Bean
   public MyBeanInterface bean1() {
       return ...;
   }

   @Bean
   public MyBeanInterface bean2() {
       return ...;
   }
}

@Component
public MyBeanuser {

  @Autowired
  private MyBeanFactory beanFactory;

  @PostConstruct
  public void afterPropertiesSet() {
     // this will actually set the bean that was created an registered in the
     // spring context and not simply call the the method and create a new
     // instance. So  this wiring is very explicitly
     setProperty1(beanFactory.bean1());
     setProperty2(beanFactory.bean2());
 }

In the end, I guess it is also a matter of taste. I was using xml-configuration for over 5 years in the context of spring batch. Two years ago, we completely switched to use javaconfig instead of xml. And honestly, I haven't found one single reason why I should want to go back to use xml. However, this is my "matter of taste".