From jdo-dev-return-6620-apmail-db-jdo-dev-archive=www.apache.org@db.apache.org Fri Oct 12 15:57:58 2007 Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 30232 invoked from network); 12 Oct 2007 15:57:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Oct 2007 15:57:58 -0000 Received: (qmail 95677 invoked by uid 500); 12 Oct 2007 15:57:46 -0000 Mailing-List: contact jdo-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jdo-dev@db.apache.org Delivered-To: mailing list jdo-dev@db.apache.org Received: (qmail 95666 invoked by uid 99); 12 Oct 2007 15:57:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Oct 2007 08:57:46 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of cbeams@gmail.com designates 64.233.184.226 as permitted sender) Received: from [64.233.184.226] (HELO wr-out-0506.google.com) (64.233.184.226) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Oct 2007 15:57:48 +0000 Received: by wr-out-0506.google.com with SMTP id 70so525480wra for ; Fri, 12 Oct 2007 08:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:x-priority:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; bh=vo5NuSIQWw3igz3PONqBU+Tw06ljzUhZPjwABKRHGpM=; b=uVz8KqzNquY+ghYIP15TPMGF4L49nOzICJcPdu68MRtVN8l8NVFvBJ0RDcpOpt4OgRqd64HQGP59PJhQn/LewXnGq8WoUC3ghuogBTbtxuuOb31/D+Qg0CTYHNwIgaN+U7zCpVppMY5ex+VLKXNiFFebybyAFyZLcQO2/4H9o60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:x-priority:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer; b=QEk5s7P/f2TAQu5CPZU7fuWFBZTlPRZQ4T5VuQB30dKodjCH0e6Illd93waU5c/8LHqBQPdlydLfN0xKWfBfkJ4OUyvFtahMtrlXc+RYR8nBxki1zAMXP9IVTZbzjbk12L8xVUeRMKwuzMCs2lL2OwHPmhrCDJ+J4uiWbXROc3Q= Received: by 10.90.69.8 with SMTP id r8mr5016256aga.1192204646678; Fri, 12 Oct 2007 08:57:26 -0700 (PDT) Received: from ?10.5.15.101? ( [209.133.30.215]) by mx.google.com with ESMTPS id c38sm1291385anc.2007.10.12.08.57.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 12 Oct 2007 08:57:25 -0700 (PDT) In-Reply-To: References: <002201c7ff98$1cd03ef0$0500000a@ILANC> <66EB04BE-8CF9-4635-A9D7-628B97B33CE9@SUN.com> <009301c7ff9e$dc3895c0$0500000a@ILANC> <46F9578E.4020002@sun.com> <001401c7ffad$1a30cf60$0500000a@ILANC> <46F9688D.1020903@sun.com> <001901c8001c$97a92c70$0500000a@ILANC> <46FAA1CC.7070504@sun.com> <007c01c806dc$8da7b810$0500000a@ILANC> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <337CE0B0-BFF3-489D-B6B2-EF0BD0F4F96C@gmail.com> Content-Transfer-Encoding: 7bit From: cbeams Subject: Re: Vote: Remove/deprecate 'Implements' annotation and XML element Date: Fri, 12 Oct 2007 08:57:25 -0700 To: jdo-dev@db.apache.org X-Mailer: Apple Mail (2.752.3) X-Virus-Checked: Checked by ClamAV on apache.org 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! >