|
Home > Archive > Apache JDO Project > October 2007 > Vote: Remove/deprecate 'Implements' annotation and XML element
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Vote: Remove/deprecate 'Implements' annotation and XML element
|
|
| Craig L Russell 2007-10-12, 1:11 pm |
| | |
| cbeams 2007-10-12, 1:11 pm |
| 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:
>
>
> 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.
>
> 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
>
> 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!
>
| |
| Matthew Adams 2007-10-12, 7:11 pm |
| +!, 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 <cbeams@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:
>
> @Implements
> October 16, it's gone.
> XML element)
> attribute that is
> enhance classes
> implemented
> analysis. In this
> declare which
> load all of the
> persistence-capable
> inheritance tree
> tree as well.
> such by annotations
> duplication?
> implemented persistence
> capable class.
> and removing the
> semantic
> interfaces versus the
> of is whether an
> managed, but I
> classes/interfaces
> http://java.sun.com/products/jdo
>
>
|
|
|
|
|