From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9902 invoked by alias); 28 Jul 2006 12:33:11 -0000 Received: (qmail 9892 invoked by uid 22791); 28 Jul 2006 12:33:10 -0000 X-Spam-Check-By: sourceware.org Received: from smtp1.su.se (HELO smtp1.su.se) (130.237.162.112) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Jul 2006 12:33:08 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 868FD740D4; Fri, 28 Jul 2006 14:33:04 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03964-01-23; Fri, 28 Jul 2006 14:33:04 +0200 (CEST) Received: from mail2.physto.se (syslx11.physto.se [130.237.208.17]) by smtp1.su.se (Postfix) with ESMTP id 052CF740A9; Fri, 28 Jul 2006 14:33:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail2.physto.se (Postfix) with ESMTP id E56045B082; Fri, 28 Jul 2006 14:33:03 +0200 (CEST) Received: from mail2.physto.se ([127.0.0.1]) by localhost (syslx11.physto.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29522-08; Fri, 28 Jul 2006 14:33:02 +0200 (CEST) Received: from qcplx01.physto.su.se (qcplx01.physto.su.se [130.237.179.166]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail2.physto.se (Postfix) with ESMTP id 69B915AE2D; Fri, 28 Jul 2006 14:33:02 +0200 (CEST) Subject: RE: Testing JDK bugs? From: Sven de Marothy To: Jeroen Frijters Cc: mauve-discuss@sourceware.org, classpath@gnu.org In-Reply-To: References: Content-Type: text/plain Date: Fri, 28 Jul 2006 12:33:00 -0000 Message-Id: <1154089963.2849.1.camel@qcplx01.physto.se> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 (2.6.1-1.fc5.2) Content-Transfer-Encoding: 7bit Mailing-List: contact mauve-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sourceware.org X-SW-Source: 2006-q3/txt/msg00019.txt.bz2 On Fri, 2006-07-28 at 09:56 +0200, Jeroen Frijters wrote: > Even if something is "Obviously Wrong", it may not be a good idea to fix > it because it would be a breaking change. For example: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6227069 > Obvious? Anyway, IMHO "fixing" something in a compatibility-breaking way simply isn't a fix at all. It's the opposite. However, this goes in the opposite direction as well. And that's when you really need to make a judgement call. I just did so in the BigDecimal patch I just commited (which is why I was rude enough to cross-post it to the main list). Which is that setScale(scale, rounding) should throw an ArithmeticException if scale < 0. The spec says so, and the JRE does so prior to v1.5. In 1.5 it does not (with no change to the doc). So without thinking too hard I figured it was a 1.5 regression and put the exception back in (fixing a mauve regression on our part). After all, this could break compatibility, in theory. Although now I'm not quite so sure, because the probable cause of this is that the divide(BigDecimal, scale, rounding) method which we (and Sun, presumably) implement this on, shows the same behaviour, only the docs have changed. /Sven