XML Vs Annotations: Analytical approach

Question

I intend to use the Pugh Decision Matrix to analytically reach a decision on this long running debate about the best approach (only with an academic interest though, it will be difficult to take sides).

I invite you to suggest appropriate criteria for the comparison between these two approaches.

Answer 1

On the annotation side:

• less files to maintain
• proximity of persistence information

On the XML side:

• separation of concern
• orthogonality of persistence (ability to have several different mappings for the same classes)

Answer 2

My suggestions for Criteria:

1. Ability to change config in a central location (easy with xml, hard with annotations)
2. How adaptable to change is each mechanism (changes in methods, classnames, structure etc)
3. Efficiency (how writing do I have to do)

But it's an interesting exercise though ultimately it does depend on the context and purpose of the beans you're creating.

For example, in the context of spring and annotations: To configure lots of "workhorse" beans (standard beans which don't require customisation or access to 3rd party resources) annotations wins hands down. I know, I had to use xml to configure these and it was a nightmare, fortunately we had pseudo annotations in the form of xdoclet that helped. The key differences here is that when using annotations you don't have to specify the details of the class, that is known already.

But then another context where I want to configure the beans; change properties, plugin a different bean, create instances of already existing classes, access 3rd party resources (jndi resources etc) or configure an entity manager - xml is the only way to go. In this context I typically don't have access to the source code of the class, I'm creating beans from libraries.

Answer 3

I came up with the following criteria (numbers in square brackets signify the weightage on a scale of 10, a higher number indicates greater importance):

1. Developer Ease/Efficiency [7]
2. Code Readability [8]
3. Architecture Issues (Separation of Concerns) [9]
4. Code Maintenability [6]
5. Adaptability to changes (How easy is it to make changes in metadata?) [6]
6. Run Time vs Compile Time [4]
7. Pluggable Code (Need for Different config files for different Databases or DEV environments; Mapping classes against two different databases with different schemas) [5]
8. Code Refactoring (How easy is it to refactor?) [5]
9. Reference/Study Materials [3]
10. Metadata Redundancy [5]
11. Application Portability [5]
12. API Support [2]