db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cbeams <cbe...@gmail.com>
Subject Re: Vote: Remove/deprecate 'Implements' annotation and XML element
Date Fri, 12 Oct 2007 15:57:25 GMT
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.


- 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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!

View raw message