From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9654 invoked by alias); 27 Jul 2006 16:32:34 -0000 Received: (qmail 9636 invoked by uid 22791); 27 Jul 2006 16:32:33 -0000 X-Spam-Check-By: sourceware.org Received: from outmail128157.authsmtp.net (HELO outmail128157.authsmtp.net) (62.13.128.157) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Jul 2006 16:32:30 +0000 Received: from [192.168.1.32] (host217-37-65-246.in-addr.btopenworld.com [217.37.65.246]) (authenticated bits=0) by squirrel.dmpriest.net.uk (8.13.6/8.13.6/Kp) with ESMTP id k6RGWKnN010040; Thu, 27 Jul 2006 17:32:20 +0100 (BST) Message-ID: <44C8EAD2.5070607@object-refinery.com> Date: Thu, 27 Jul 2006 16:32:00 -0000 From: David Gilbert User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) MIME-Version: 1.0 To: Jeroen Frijters CC: Roman Kennke , classpath@gnu.org, mauve-discuss@sourceware.org Subject: Re: Testing JDK bugs? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Server-Quench: 79f85483-1d8d-11db-b770-001185d377ca X-AuthRoute: OCdyYgsUB1ZZRRob BmULDStKRB85DhpG AxIIMU5ALVQIUwlL IwBRKV9FNUAYWVBB XzMTX00aUlpuIyYp dAhRbQNNY01EXAdg UkkHQFNVCgZvHxoE GBwaVAZwchpGNiV2 BzEFJS4lXEV6dUJ9 DExUEW5IYm42YGUb WENFdldcJB5Lf0sX dwJ4U3MQYWUGZ3Jl E1RsYDs4Kw9Semxp TxoRLFQdCWQnPXY2 Wh8ZSl1z X-Authentic-SMTP: 61633132333134.squirrel.dmpriest.net.uk:199/Kp X-Report-SPAM: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-Virus-Status: No virus detected - but ensure you scan with your own anti-virus system! 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/msg00012.txt.bz2 Jeroen Frijters wrote: >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." > >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. > >Of course, things aren't black and white and issues should be decided on >a case by case basis, but considering the spec holy is not doing anybody >any service. > > I'm sorry to have set you off. Bear in mind that there is a difference between the theory and the practice here...I'm not too hung up on the theory, and I think the remainder of my original post made that clear. Regards, Dave