You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Craig L Russell <Cr...@Sun.COM> on 2007/10/12 17:45:41 UTC
Vote: Remove/deprecate 'Implements' annotation and XML element
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!
Re: Vote: Remove/deprecate 'Implements' annotation and XML element
Posted by Matthew Adams <ma...@matthewadams.org>.
+!, f'shizzle, we need to remizzle & dizzepricate.
(I don't know why I wrote my comment using Snooplang.
I must be punchy after talking for 4 days straight.)
--- cbeams <cb...@gmail.com> wrote:
> 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:Craig.Russell@sun.com
> > P.S. A good JDO? O, Gasp!
> >
>
>
Re: Vote: Remove/deprecate 'Implements' annotation and XML element
Posted by cbeams <cb...@gmail.com>.
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:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>