From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29207 invoked by alias); 20 Jan 2003 00:09:33 -0000 Mailing-List: contact mauve-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sources.redhat.com Received: (qmail 29190 invoked from network); 20 Jan 2003 00:09:32 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 20 Jan 2003 00:09:32 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h0JNesB07114 for ; Sun, 19 Jan 2003 18:40:54 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h0K09On13735; Sun, 19 Jan 2003 19:09:24 -0500 Received: from [192.168.64.12] (vpn50-8.rdu.redhat.com [172.16.50.8]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h0K09ME05034; Sun, 19 Jan 2003 16:09:22 -0800 Subject: Re: 600+ BigDecimal tests From: Anthony Green To: Stephen Crawley Cc: Mark Wielaard , Dalibor Topic , mauve-discuss@sources.redhat.com, crawley@piglet.dstc.edu.au In-Reply-To: <200301192339.h0JNdufh022135@piglet.dstc.edu.au> References: <200301192339.h0JNdufh022135@piglet.dstc.edu.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 20 Jan 2003 00:09:00 -0000 Message-Id: <1043021531.2354.27.camel@escape> Mime-Version: 1.0 X-SW-Source: 2003-q1/txt/msg00006.txt.bz2 On Sun, 2003-01-19 at 15:39, Stephen Crawley wrote: > * Some of the other tests check exception message strings, and are > failing because the messages are different. > > I don't know whether this is a bug or not. Is Classpath aiming to > give the same exception messages as the Sun JDK implementation ??? I don't think so (could be wrong). I suppose we should remove these tests. > > * The 'has001' failure is due to differences in the way that > Classpath and the SUN JDK are calculating hashcodes. > > I don't know whether this is a bug or not. Is Classpath aiming to > give the same hash code values as the Sun JDK implementation ??? I know that some people have spent time figuring out how Sun hashes various objects, although I don't know if this is a policy. AG