Do we have 100% support for Spring using annotations now?

[Shantha Dodmane]

Hi Eugen Paraschiv,

I'm much comfortable with Spring using annotations.
But I see most of the companies are still using Spring using XML. So I must know Spring using XML to be part of now a days competitions.
Do I need to learn Spring using XML now?.
Do we have 100% support for Spring using annotations now?
How long it may take companies to move on to 100% annotations based Spring ?

[Tim Cooke]

It's not about moving "on to 100% annotations based Spring", annotations are not supposed to supersede xml driven configuration. The introduction of annotation driven config just provides you with a different way to configure your Spring managed classes. Sometimes using annotations is the right thing to do and makes your code nice, whereas other times using annotations is just nasty and an xml config is the right thing to do.

So to answer your question: "How long it may take companies to move on to 100% annotations based Spring ?"

Answer - Probably never. Because xml config is still a very valid design choice.

[salvin francis]

Shantha Dodmane wrote:
I'm much comfortable with Spring using annotations.

Don't you think that its simpler to make changes in a single config file without touching and re-compiling your code ?

[Martin Bechtle]

salvin francis wrote:

Shantha Dodmane wrote:
I'm much comfortable with Spring using annotations.

Don't you think that its simpler to make changes in a single config file without touching and re-compiling your code ?

I strongly disagree. I use Java because it's type safe: I know that even if it may contain bugs, my code runs correctly. Compilation takes less than a few seconds. Debugging an XML file because you mistyped something takes a lot more.
It's the same as dynamic languages vs static languages: you gain productivity by writing less lines of code, but then you loose it again by debugging all the time.

File-based configuration makes sense if you don't want to hard-code stuff: database url or password, options, these kind of things. Beans and dependency injection, instead, should be done in your code.

[Silviu Burcea]

salvin francis wrote:

Shantha Dodmane wrote:
I'm much comfortable with Spring using annotations.

Don't you think that its simpler to make changes in a single config file without touching and re-compiling your code ?

Going for annotations gives you type safety. There is no panacea for configuration.

[salvin francis]

Martin Bechtle wrote:
I strongly disagree.

Well then, lets agree to disagree

Martin Bechtle wrote:
I use Java because it's type safe: I know that even if it may contain bugs, my code runs correctly. Compilation takes less than a few seconds.

I agree, you get type safety with annotations. But it comes with a cost of modifying code. Compilation plus packaging and re-deploying a new War/Jar may not be a simple task.

Martin Bechtle wrote:
Debugging an XML file because you mistyped something takes a lot more.

This is quite subjective to opinion. Even Spring will cry if I try to assign Onions to Animals and would directly point it out.

Martin Bechtle wrote:
It's the same as dynamic languages vs static languages: you gain productivity by writing less lines of code, but then you loose it again by debugging all the time.

Again, this is based on the assumption that you have badly goofed up your configuration xml

Martin Bechtle wrote:
Beans and dependency injection, instead, should be done in your code

Why ?

[salvin francis]

Just a side note, I am not completely against annotations. I too use it extensively especially in hibernate configurations for pojos and similar. But I feel against completely annihilating xml
but, YMMV

[Martin Bechtle]

Hi Salvin!

salvin francis wrote:

Martin Bechtle wrote:
Debugging an XML file because you mistyped something takes a lot more.

This is quite subjective to opinion. Even Spring will cry if I try to assign Onions to Animals and would directly point it out.

Yes, he will cry at runtime, after several seconds of redeploy time. I prefer to get most errors at compile time. Sure, I won't get all of them, but still, I prefer.

salvin francis wrote:

Martin Bechtle wrote:
Beans and dependency injection, instead, should be done in your code

Why ?

Because the beans and their relationships define how your application works. I prefer to externalize stuff only for configuration purposes.

[salvin francis]

Martin Bechtle wrote:
Beans and dependency injection, instead, should be done in your code

Then why inject at all ?
While I could agree with you over the using annotations for transactional purposes, etc.. I would definitely not prefer dependency injection via code.

[Martin Bechtle]

salvin francis wrote:

Martin Bechtle wrote:
Beans and dependency injection, instead, should be done in your code

Then why inject at all ?
While I could agree with you over the using annotations for transactional purposes, etc.. I would definitely not prefer dependency injection via code.

Right... but what are the implications of this? I mean, even if you just change an XML file, you still have to build and deploy a new version of your application in production. And it's definitely harder to debug, as opposed to a simple breakpoint in JavaConfig. I see only maluses, no bonuses. Am I missing something that you find really useful with XML config?

[salvin francis]

Martin Bechtle wrote:
Am I missing something that you find really useful with XML config?

Finally !! I thought you'd never ask

Here are my thoughts on this:

The xml provides a single location where all configs are done

You get a holistic view of the entire application

You don't need to read through individual class codes

Structural re-configuration is easy.

Even a newbie looking at a complete new project is able to grasp which class is related to which without even opening classes.

See, as I mentioned before, I am not completely against annotations, I too use them. But some tasks like creating a structure where classes are related to each other and injections are better represented in XML.

[salvin francis]

You also might want to see this:
https://coderanch.com/t/61289/oa/Xml-based-configration-Annotation

[Martin Bechtle]

And wouldn't you like to have a single Java file with a @Configuration class creating all your beans? You still get all the points you mentioned, plus:

errors at compile time

easy debugging

ide autocomplete

even a complete newbie to Spring can understand java code, without knowing how xml config works

The first time I saw JavaConfig in Spring a few years ago I though to myself: man this seems so easy!

[Tim Cooke]

Martin Bechtle wrote:Am I missing something that you find really useful with XML config?

Let's say my application supports MySQL and Oracle databases. I have written DAO's for both and I'm using Spring to inject the Oracle DAO into some other service class.

Let's say my customer now decides that they've had it with paying Oracle oodles of cash in licencing and they want to switch to MySQL. No problem, I can reconfigure my application without having to produce and version a new build. Just a Spring xml config change and a server reboot. Job done.

That's one example, of course there are others.

[Martin Bechtle]

Tim Cooke wrote:

Martin Bechtle wrote:Am I missing something that you find really useful with XML config?

Let's say my application supports MySQL and Oracle databases. I have written DAO's for both and I'm using Spring to inject the Oracle DAO into some other service class.

Let's say my customer now decides that they've had it with paying Oracle oodles of cash in licencing and they want to switch to MySQL. No problem, I can reconfigure my application without having to produce and version a new build. Just a Spring xml config change and a server reboot. Job done.

That's one example, of course there are others.

Right, but wouldn't you overwrite the XML file once you deploy a new version? I think this kind of configuration goes against best Continous Integration practices. Is it possible to keep the XML outside the war/jar package? In that case it would really make sense.
If I had to do an app supporting both Oracle and MySql without an ORM, I'd prefer to have JavaConfig read a configuration file somewhere, like ~/.myAppSettings/config.properties, and wire up all dependencies consequently.

[Tim Cooke]

Martin Bechtle wrote:Is it possible to keep the XML outside the war/jar package? In that case it would really make sense.

You can do that yes, but I'd not be entirely comfortable with that. Spring xml configs are heavy on implementation detail quoting class names with full package prefixes which aren't super friendly to application support and configuration maintenance people. Plenty to get wrong, and get wrong big.

In our application we use Spring xml configuration for everything but our MCV controller classes for which we use annotations. We also use Spring Profiles to selectively enable and disable certain bean wiring configurations in our xml. For example:

<beans profile="oracleDao"> <bean id="dbDao" class="com.timdrivendevelopment.dao.OracleDao" /> </beans> <beans profile="mySqlDao"> <bean id="dbDao" class="com.timdrivendevelopment.dao.MySqlDao" /> </beans>
Now the configuration switch item is outside of the Spring xml file.

[Martin Bechtle]

Tim Cooke wrote:

Martin Bechtle wrote:Is it possible to keep the XML outside the war/jar package? In that case it would really make sense.

You can do that yes, but I'd not be entirely comfortable with that. Spring xml configs are heavy on implementation detail quoting class names with full package prefixes which aren't super friendly to application support and configuration maintenance people. Plenty to get wrong, and get wrong big.

In our application we use Spring xml configuration for everything but our MCV controller classes for which we use annotations. We also use Spring Profiles to selectively enable and disable certain bean wiring configurations in our xml. For example:

<beans profile="oracleDao"> <bean id="dbDao" class="com.timdrivendevelopment.dao.OracleDao" /> </beans> <beans profile="mySqlDao"> <bean id="dbDao" class="com.timdrivendevelopment.dao.MySqlDao" /> </beans>
Now the configuration switch item is outside of the Spring xml file.

Right! Profiles! I still prefer JavaConfig but at least now xml config is starting to make sense to me. Thank you for your time Tim and Salvin