Return-Path: Delivered-To: apmail-db-jdo-dev-archive@www.apache.org Received: (qmail 73536 invoked from network); 21 May 2005 19:55:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 21 May 2005 19:55:43 -0000 Received: (qmail 49452 invoked by uid 500); 21 May 2005 19:55:43 -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 Delivered-To: moderator for jdo-dev@db.apache.org Received: (qmail 45154 invoked by uid 99); 21 May 2005 19:53:39 -0000 X-ASF-Spam-Status: No, hits=3.9 required=10.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST,FORGED_YAHOO_RCVD X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mtNyDILpAf+fPnJQQH3NtUXigrxswIMgbyDkr/GtRmgx7pDen1fCinlS9lInG65whVZSRDpSzNowVvq9LbrRJBZ9tuc8e4Wy+ywseXL8lfVkqp6tPxAzaWyvM1MQN5RPumRTUK8UWUM7XaY0VuhPj7IKZ7A+TlKFkf45fG5Gwyo= ; Message-ID: <20050521195335.97563.qmail@web31804.mail.mud.yahoo.com> Date: Sat, 21 May 2005 12:53:35 -0700 (PDT) From: Geoff hendrey Subject: Question on TCK11 To: Michelle Caisse , Michelle Caisse Cc: jdo-dev@db.apache.org, jdo-tck-ext@Sun.COM In-Reply-To: <428CF7FD.7020003@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Department.hashCode method is using a persistent field to compute the value of the hashcode, in TCK11. Note that in the Sun version of the TCK, which JDOMax passes, hashCode is NOT overidden for Department. I think it is wrong to override hashCode and equals for any class using datastore identity. This was the subject of 35 or so emails on the experts group, and this was the position espoused by Craig. Craig laid down the law: "If you don't have a set of fields that uniquely form an application identity, then you should not implement equals. You *should* delegate to Object.equals" Please let me know if an implementation is expected to handle cases when the user overides equals and hashCode for datastore identity? Certainly, JDOMax does NOT, and is failing a good bit of the Apache TCK11 because of it! -geoff __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail