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:
This site tells us why xml is better https://dzone.com/articles/consider-replacing-spring-xml
Top reasons to choose xml over javaconfig
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 ?
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".