Hi Ilan,+1 to remove/deprecate the implements element and @Implements annotation.
If no adverse comments are received by Tuesday October 16, it's gone. On Oct 4, 2007, at 4:15 PM, Ilan Kirsh wrote:
Hi, The 'Implements' annotation (and the equivalent XML element) remind methe 'persistence-capable-superclass' XML attribute that is deprecated now.
Yes, for JDO 1, we tried to have it possible to enhance classes when not all of its dependencies (superclasses and implemented interfaces) were available for loading and analysis. In this environment, it was necessary to explicitly declare which interfaces were implemented because you could not load all of the directly implemented interfaces to see which persistence-capable interfaces were indirectly inherited.
But now, enhancement requires access to the entire inheritance tree and it makes sense to also require the implements tree as well.
If persistence capable interfaces are marked as such by annotations (or in the XML metadata), why should we have this duplication? Implementations should be able to find implemented persistence capable interfaces as they find a super persistence capable class.
True, and I support deprecating the xml attribute and removing the @Implements annotation.
Unless someone can justify why there would be any semantic difference between explicitly declaring the interfaces versus the enhancer finding them. The only thing I can think of is whether an explicitly named interface would have an extent managed, but I think that you can only query over the extent of classes/interfaces that themselves declare that an extent is managed.
Craig
Ilan Kirsh ObjectDB Software http://www.objectdb.com
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
