Nowadays most of the frameworks are going for annotations driven approach for configuration, example hibernate has annotations which can be used instead of the xml file.
But I dint understand the significance of this. Below is my point for clarification.
1. The code is now coupled with the configuration details making it less cohesive as the code also contains other details other than the logic.
2. When there has to be a change in the configuration it has to be changed in the .java file which needs again build compared to the xml file which needs to be changed and added in the artifact(.jar) explicitly. No need for compilation in case of xml file.
3. If this code is provided as a jar file in annotation approach the code has to be compiled once again and a different jar has to be provided whereas in case of xml file only the xml file has to be changed and moreover no compilation of the source code.
Kindly let me know the benefits of going the annotations way.
Thanks and Regards, Pradeep Kumar
SCJP 1.6, SCWCD 5.0
Are you trying to start a XML/Annotation war ? I'm not stepping in ! One thing I'd like to say is that annotations can usually be overridden by XML (at least that's how J2EE works), so you don't need to recompile if you need to change something. You can override the existing annotation with XML.
But my concern is the code is not cohesive. some junk code is also sitting there other than what the class is supposed to it.
If i ship the code to others who don't need the annotation related stuff then it does not make sense. say i have a POJO with hibernate related annotation. If some other application wants to use my module which does not want to use hibernate. Then they should use hibernate jar to support annotations for resolving compile time errors. This is not fare right.
The reasons you give are exactly the reasons why initially, before annotations were added to Java, people started to use a lot of XML configuration files: it seemed like a good idea to separate the code from the configuration, so that you could easily change the configuration without changing the code, and without cluttering the code up with configuration information.
After a while, however, people noticed that there are also disadvantages of (over)using XML: because code and configuration are separated, it makes it hard to see how things are configured and it makes things quite confusing and complicated when you have lots of XML files.
People started to see that adding configuration information via annotations makes the code easier to understand and to find out how things are connected together, and in practice you often don't need to change the configuration so often that needing to recompile it is a problem.
And, as Christophe says, many frameworks nowadays allow both annotations and XML for configuration, so that for each specific part of your application you can choose which is more appropriate. If you have a POJO which you want to reuse without Hibernate, for example, it will probably be more appropriate to configure the Hibernate mapping with a separate XML file instead of using annotations.
yes I agree that code will be easier to read as the code contains the configuration details but I would not personally recommend as the code will not be cohesive.
Image a class with annotations of hibernate,Spring, JMX etc...... This class can no more be reused outside the application. If we need then we need to resolve the compile time by having all the supported jar files which is not my headache. Also changing the configuration for any of the annotations will lead to compiling and building the application.