From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23728 invoked by alias); 27 Jul 2006 17:01:02 -0000 Received: (qmail 23713 invoked by uid 22791); 27 Jul 2006 17:01:01 -0000 X-Spam-Check-By: sourceware.org Received: from cpc1-cmbg8-0-0-cust558.cmbg.cable.ntl.com (HELO zebedee.littlepinkcloud.COM) (82.6.106.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Jul 2006 17:00:59 +0000 Received: from zebedee.littlepinkcloud.COM (localhost.localdomain [127.0.0.1]) by zebedee.littlepinkcloud.COM (8.13.6/8.13.5) with ESMTP id k6RH0ILO011488; Thu, 27 Jul 2006 18:00:18 +0100 Received: (from aph@localhost) by zebedee.littlepinkcloud.COM (8.13.6/8.13.5/Submit) id k6RH0GIQ011485; Thu, 27 Jul 2006 18:00:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17608.61728.239237.86085@zebedee.pink> Date: Thu, 27 Jul 2006 17:01:00 -0000 From: Andrew Haley To: "Jeroen Frijters" Cc: "David Gilbert" , "Roman Kennke" , , Subject: RE: Testing JDK bugs? In-Reply-To: References: <44C8BAFF.6080001@object-refinery.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-IsSubscribed: yes 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/msg00013.txt.bz2 Jeroen Frijters writes: > David Gilbert wrote: > > The theory is easy: Mauve should test AN implementation against THE > > spec. > > Pardon me for beating my favorite horse again, but this assumes that the > spec is somehow more valuable than code and/or that the spec doesn't > contain bugs. In the real world both are buggy and users rarely care > about the spec, especially when their app works on the RI, but not on > our implementation. > > Allow me to rebut another issue that often comes up: "We'll make it spec > compliant and when someone finds an application that depends on the RI > behavior then we'll copy that behavior." That depends on whether or not we think the spec or some implementation is buggy. It is often possible to tell -- some behaviours are just Obviously Wrong. When it's not possible to tell, we have to make a judgment call. > IMNSHO, this is actually a very dumb approach. It makes our > implementation worse than the RI in two ways: > > 1) Apps coded against the RI (possibly) don't work out of the box. > 2) Apps coded against our implementation (and spec) run the risk of > breaking in the future when we randomly decide to start emulating > the RI instead of the spec. Or, just as likely, the "RI" eventually gets fixed. Should we have to wait for that other implementation to be fixed before will allow ourselves to fix ours? That really would be dumb! > Of course, things aren't black and white and issues should be > decided on a case by case basis, but considering the spec holy Beat that straw man! > is not doing anybody any service. Andrew.