You can now download the JavaOne 2008 presentation Converting (Large) Applications to OSGi I just delivered with Peter Kriens.
The presentation went really well. There was around 700-800 people there and we had some really good questions asked during the 5 minutes we had left for questions. And then many more questions after we left the stage. I felt like a JavaOne Rock Star! :-)
Thursday, May 08, 2008
Wednesday, May 07, 2008
An AJO is not a POJO
A POJO is a plain old Java object. Everyone talks POJOs these days. They are easy to compose and unit test. They are free of coupling to specific infrastructure details. So you can take your POJO to another infrastructure. For example, from JavaEE to Spring or OSGi. I like them and I think it is the right way to do things.
However, people are also fascinated with annotations now. Things like Guice and EJB3 and Glassfish all want you to annotate your POJO. But once you do that, your POJO ceases to be plain. While the non-annotation part of your code is still the same, the annotations in your code mean that your source now has coupling to specific infrastructure details and it is wrong to call is a POJO anymore. You can't compile your code without the proper support for those annotations. If you want to deploy your code in another infrastructure that uses annotations to describe the infrastructure details, you have to add more annotations to your source.
While I see the interest in putting the infrastructure information in the source near where it is used. We need to be honest. Your code is not a POJO anymore. It is now an AJO: an annotated Java object.
However, people are also fascinated with annotations now. Things like Guice and EJB3 and Glassfish all want you to annotate your POJO. But once you do that, your POJO ceases to be plain. While the non-annotation part of your code is still the same, the annotations in your code mean that your source now has coupling to specific infrastructure details and it is wrong to call is a POJO anymore. You can't compile your code without the proper support for those annotations. If you want to deploy your code in another infrastructure that uses annotations to describe the infrastructure details, you have to add more annotations to your source.
While I see the interest in putting the infrastructure information in the source near where it is used. We need to be honest. Your code is not a POJO anymore. It is now an AJO: an annotated Java object.
Subscribe to:
Posts (Atom)