When using annotations you will reduce the amount of xml
instead of using XML for transactional management, marking a method as transactional with an annotation makes perfect sense, since this is information a programmer would probably wish to know.
There is a wider issue here, that of externalised vs inlined meta-data. If your object model is only ever going to persisted in one way, then inlined meta-data (i.e. annotations) are more compact and readable.
If, however, your object model was reused in different applications in such a way that each application wanted to persist the model in different ways, then externalising the meta-data (i.e. XML descriptors) becomes more appropriate.
Neither one is better, and so both are supported, although annotations are more fashionable. As a result, new hair-on-fire frameworks like JPA tend to put more emphasis on them. More mature APIs like native Hibernate offer both, because it's known that neither one is enough.
It depends on what everything you want to configure, because there are some options that cannot be configured with anotations. If we see it from the side of annotations:
It's up to you what is more important...
The key difference is that you don't have to recompile the code for all changing server-specific configurations, just edit the xml file. There's also the advantage that some configuration changes can be done by team members who don't understand all the code involved.
When using annotations you will reduce the amount of xml, the big drawback here is is that your configuration is scattered around all your classes. No central location for your configuration.
When using xml it can become verbose, but you have 1 location to look for your configuration.
So I tend to end up with a mixture of both. The coarse grained configuration is done in xml and the fine grained is done within the class. So that you have a somewhat reduced configuration and a central place for your main configuration and finer grained inside your classes
Stereotype annotations are markers for any class that fulfills a role within an application. This helps remove, or at least greatly reduce, the Spring XML configuration required for these components. Specifically, the roles or stereotypes defined in Spring today include Repository, Service, and Controller
The Four Types of Spring Stereotype Components and Their Purposes
Per the Spring documentation, in addition to simplifying configuration and wiring, stereotype annotations make your application components "more properly suited for processing by tools or associating with aspects."
Since Java adopted annotations, I’ve heard a lot of discussion around whether to prefer annotations over external configuration files (often XML) and vice versa.
I think the decision boils down to two criteria:
1) Can annotations simplify the metadata?
If annotations do not reduce the amount of metadata that you have to provide (in most cases they do), then you shouldn’t use annotation.
I think the more important thing to considered is whether a configuration change could break behavior or not. If not, then you can feel comfortable applying the change while the system is running in production. External config files are the best place for the metadata in this case because you don’t want to have to recompile your code to make the change.
However, if a metadata change could break behavior then you’ll want to test the change by going through a full release cycle (change code, build, test, deploy). If you’re going to go through a full release cycle there is practically no benefit to not recompiling besides the 5-10 seconds you save in compile time. The more important thing to consider is which method of metadata definition is simpler.
For example, Hibernate mappings are often in XML, but annotations often provide the ability to specify the same mappings with significantly less metadata. Any changes you make to your mappings (whether in XML or annotations) could potentially be behavior breaking. You’re not going to change your mappings dynamically at runtime, are you? So, annotations seem like a much better choice.
[Note: I might consider using XML metadata for Hibernate when mapping to a legacy database because the annotations can often become bulky. Also, you are forced to use XML if you want to map the classes against two different databases with different schemas. I haven't heard of a way to specify two mutually exclusive sets of Hibernate annotations on my classes. Even if this did exist it would be complex, which violates my first criterion for selecting annotations over XML