title: SpringBatch - javaconfig vs xml
body: <p>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.</p>
  
  <p>This site tells us why javaconfig is better  <a href="https://blog.codecentric.de/en/2013/06/spring-batch-2-2-javaconfig-part-1-a-comparison-to-xml/" rel="nofollow">https://blog.codecentric.de/en/2013/06/spring-batch-2-2-javaconfig-part-1-a-comparison-to-xml/</a></p>
  
  <p><strong>Top reasons to choose javaconfig over xml</strong>:</p>
  
  <ol>
  <li>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.  </li>
  <li>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.</li>
  <li>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.</li>
  </ol>
  
  <p>This site tells us why xml is better <a href="https://dzone.com/articles/consider-replacing-spring-xml" rel="nofollow">https://dzone.com/articles/consider-replacing-spring-xml</a></p>
  
  <p><strong>Top reasons to choose xml over javaconfig</strong></p>
  
  <ol>
  <li>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.</li>
  <li>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.</li>
  <li>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.</li>
  <li>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.</li>
  </ol>
  
  <p><em>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.</em></p>
  
  <p><strong>Any disadvantage of xmls that I am missing out ?</strong></p>