I haven't fully reviewed this proposal, but I do know that using
implements/@Implements only served to confuse me in the past. I kept
thinking: isn't this information superfluous? Should the enhancer
have been able to figure this stuff out by static analysis?
So if it is in fact not needed, I'm a big +1.
Thanks,
- Chris Beams
On Oct 12, 2007, at 8:45 AM, Craig L Russell wrote:
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 me
the '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!
