Annotated POJOs are still POJOs !?
Originally Posted by yatesco
I just see your argumentations about annotations in POJOs and I wanted to share my opinions with you and others Spring Team and users.:)
I am fully with what Bill (wpoitras) explain concerning annotation and marker interface: they dont specify functionnality. But you can use it to add or change POJO functionnalities, or ignore it.
The real debate is Annotation vs XML binding... I prefer Annotation and I am still waiting Spring team to put that in his top priority.
That is wrong from smart java developers. They give precedence to model design before looking at the persistence constraint/model. If you consider an EJB3 Entity bean, it is a POJO (with or without annotation). You add annotation, to give enough information, to do the crud operations behind the POJO, by the Persistence manager(PM). If there is no PM in your environment, your EJB3 entity POJO can still be used as any other POJO with no constraint on the environment. This is also true for the EJB3 sessions.
Like I said, if people started writing POJOs and then decorated them into EJB3s that wouldn't be so bad, but people won't do that, they will write EJB3s and then consider them POJOs as a secondary (if at all) concern.
So, what we developers need, is support for specialized operations on those POJOs:
- other specialized services
SpringFramework2.0 is potentially the best container, for those needs. But it lacked java oriented interface, at the beginning, and the new solutions Spring Team are taking out today (Pitchfork, spring-javaconfig packages) are the way to go, without a doubt. They are very timid in that offer and they are continuing to market the fact that XML binding is the best way to achieve the needs of java developers. I think XML binding is usefull and complementary for infrastructure configuration. But can't in my feeling be the preference of smart java developers.
Spring have demonstrated the way to simplify the JEE development process, but don't forget that before Spring, IOC was for long time handled by Apache offer named Avalon, and other IOC-like framework. But their environment was so tedious and difficult to implement and use until Spring offer. So many java developers sense what they want to benefit from those IOC containers.
If the Spring Team don't give quickly all the support for their actual java developers to integrate spring artifacts via annotation, they will loose the community interrest in favor of solutions like glassfish, geronimo, and JBoss.
There are many reasons for that :
1. For java developer, coding by XML is a constraint, and they are more confortable in java code.
2. They don't want to manage 2 sources of specification. Annotation is the way to centralize all the specs in on source
3. XML binding is more complex for java programmers than the Spring Team may think. There is a learning curve to master the spring xml config files
4. The springframework 2.0 is builted on a dying java 1.3 1.4 plateform, to support big corporations unable to switch quickly to java1.5+. That code can't be as optimal as a code written exclusivelly for java 1.5+.
5. Open source Developpers will prefer to select new containers to take avantage quickly of new technology.
In conclusion, It must be left to developers to say if annotated POJOs is POJOs or not. Their judgement will come from the expected runtime behavior of their favorite container.
Today My preferences have moved from:
- Hibernate, Spring, Tomcat
- glassfish, Toplink-essentials, [Spring]
but I hope to end with functionnal (in full EJB3 container)
- Spring(Pitchfork+JavaConfig) + Toplink-essentials