Will spring boot eliminate XML?

[Enrique M. Talavera]

I prefer to program configurations with annotations than XML, but I read that some configuration must be in xml. I hope Spring Boot remove all the XML configurations one Day xD/

[Craig Walls]

XML configuration will likely never completely go away or be deprecated. But almost all of the Spring projects have made moves to support Java configuration as the primary configuration option in the past several years. AFAIK, Spring Integration and Spring Batch are a few of the last projects to still have a strong hold on XML (even though both are making steps to offer Java configuration).

This is a move in the greater Spring community, not so much attributed to Spring Boot. That said, Spring Boot auto-configuration aims to dramatically reduce the amount of explicit configuration of any form (XML or Java config) in Spring apps.

Short story: The *ONLY* XML config I've written in the past 2 years has been to produce XML examples for people who want to see it. For any real work, I've all but eliminated XML config from my toolbelt.

[Enrique M. Talavera]

Whoa!, thanks for the reply Sr, I really like Spring Boot I will investigate more

[Palak Mathur]

My personal preference is XML configuration. Java based configurations are a pain. It would be nice if we can migrate to some other format like yaml, json. Your code and configurations separation should be maintained and non-Java configurations help you do that.

[Craig Walls]

Palak Mathur wrote:My personal preference is XML configuration. Java based configurations are a pain. It would be nice if we can migrate to some other format like yaml, json. Your code and configurations separation should be maintained and non-Java configurations help you do that.

Everyone has an opinion on XML configuration, for sure. I was skeptical of Java configuration when it first came along, but having worked with it for awhile, I've come to prefer it over XML. Even then, when possible I'd prefer other options where no configuration is required (as in component-scanning/auto-wiring and Spring Boot auto-configuration).

And although Spring doesn't officially support any other non-Java configuration other than XML (unless you count Groovy as non-Java), the framework is extendable enough that anyone could come along and build support for YAML or JSON configuration on top of it. Even so, Java configuration affords some possibilities that XML does not, such as type safety, refactorability, and "intelligent" configuration.

I agree that business logic and configuration code should be kept separate. But Java configuration doesn't prevent you from doing that just because the syntax is the same. Naming conventions and package placement can go a long way to keep configuration code separate from business logic code.

But don't worry. XML configuration won't be going away anytime soon. Even with Spring Boot, all you need is a @ImportResource annotation to add XML config to your app.

[Palak Mathur]

Hi Craig,

Thanks for the reply. I had no argument and thus kept silent. I currently started working on a new Batch project and made all my configurations in Java. I used Spring Boot for @EnableBatchProcessing, and had to create two config files to do what I could have done in a single XML config file. In the beginning it was irritating till I figured out a way to do that. After doing so, I realized that what you said was right. I am interpreting your comment about Intelligence here and agree that it certainly is intelligent way to do configurations. First of all it enforces separation of concerns between different set of configurations. Secondly, it provides a way to Unit Test your configurations. The latter was difficult to achieve in the beginning but I am sure I will improve my skills in doing so. Thirdly, this is but the extension of point one in the sense that it improves readability and maintainability. If I need to modify certain configurations, I just need to go to the config file for the purpose and make changes, test it and I am done. With XMLconfigurations more often than not, rather than separating concerns into multiple contexts, we always put the whole world of configurations in a single file which becomes ginormous in form reducing readability and maintainability. My preferred way from now on is to use Java based config.

I like XML based config and the only advantage that I can think of is immediate feedback and easy to setup.

[Jesper de Jong]

Both XML configuration and configuration through Java annotations have pros and cons. In my opinion neither is better than the other, they just have different strengths and weaknesses.

With XML configuration, you keep the configuration separate from the actual code, so in your code you can concentrate on the business logic and you don't have the noise of configuration information mixed through it. Also, XML configuration files can easily be changed and you don't need to re-compile the code when you make a change in the configuration.

With Java configuration, you can keep everything that's relevant for a class together in the source file of the class. It's easier to see how stuff is wired together, you don't need to go searching for a separate configuration file to understand things are wired up. Also, you don't need to deal with XML, which some people find cumbersome.

What I like about Spring Boot is that it is an "opinionated" framework, which means that it makes lots of default choices for the configuration, and you only need to configure things if you want something different than the default. That makes it easy to get up & running as long as you are OK with the default choices.