CELEBRATE EARTH WEEK
Save 70% on video training and simulators now through April 27*—use code EARTH. Shop now.
Annotations were originally released in Java SE 5 and have since made EJB 3.0 programming a breeze, eliminating the deployment descriptors that we dread building and maintaining. But eliminating deployment descriptors comes at a cost. Now we need to ask: is it worth the price?
This Monday I'll be posting the first of two articles on building, implementing, and reading Java annotations. Annotations have made enterprise Java programming much easier and have done away with those pesky deployment descriptors in the EJB 3.0 specification. For example, inside an Entity Bean I can add an "@Entity" annotation to mark the bean as an Entity Bean and then I can add an "@Table" annotation that tells my EntityManager what table to persist my Entity Bean to. This makes things a lot easier, but there is something to be said about external deployment descriptors. Namely, what do you do if you need to change a bean's table name?
For example, if MyObject is mapped to MYTABLE, but for some reason I need to change that to be mapped to MYOTHERTABLE, I need to change that table mapping in the annotation and recompile my source code. If, on the other hand, the table name was specified in an external deployment descriptor, I wouldn't need to touch the code. This may seem like an unreasonable requirement, but consider selling an application to a customer and they have their own naming conventions for database tables - how do you support them? If you're Oracle or SAP you kindly tell them to deal with it, but if you're a small company, that might not be a luxury you have.
I love annotations, but I don't know if they're the panacea we have been looking for. What are your thoughts? Has anyone faced this problem in the real-world? How have you worked around it?
Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.