From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 708 invoked by alias); 28 Dec 2002 00:50:03 -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 701 invoked from network); 28 Dec 2002 00:50:02 -0000 Received: from unknown (HELO ncsmtp02.ogw.rr.com) (24.93.67.83) by 209.249.29.67 with SMTP; 28 Dec 2002 00:50:02 -0000 Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ncsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id gBS0n2up012509; Fri, 27 Dec 2002 19:49:02 -0500 (EST) Received: from lyta.haphazard.org ([24.74.164.113]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Fri, 27 Dec 2002 19:50:32 -0500 Received: from lyta.haphazard.org (localhost.localdomain [127.0.0.1]) by lyta.haphazard.org (8.12.5/8.12.5) with ESMTP id gBS0nkKH029960; Fri, 27 Dec 2002 19:49:46 -0500 Received: (from cbj@localhost) by lyta.haphazard.org (8.12.5/8.12.5/Submit) id gBS0nk0S029956; Fri, 27 Dec 2002 19:49:46 -0500 X-Authentication-Warning: lyta.haphazard.org: cbj set sender to cbj@gnu.org using -f To: Daryl Lee Cc: Mauve Discuss Subject: Re: API Differences References: <20021226202921.GA23724@tigger.localdomain> <20021227150608.GA6189@tigger.localdomain> From: Brian Jones Date: Fri, 27 Dec 2002 16:50:00 -0000 In-Reply-To: <20021227150608.GA6189@tigger.localdomain> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-q4/txt/msg00089.txt.bz2 Daryl Lee writes: > This is VERY helpful. So helpful, in fact, that the very first two lines > of output (in the java.io section) raise a general question on testing. > > In the transition from JDK 1.1 to JDK 1.2, Sun redefined the behavior of > the FileOutputStream(String) constructor. In 1.1, it threw an IOException; > in 1.2 (and through 1.4), it throws a FileNotFoundException. > > Since there is only one implementation of the API, and since it is trying > to be as up to date as possible, a specification change such as this will > inevitably cause a failure of a 1.1 test, where a 1.2 (or later) test will > pass. The general question is "How to handle such changes?" Or am I > missing something, like the existence of a classpath archived to the JDK > 1.1 spec? This is similar to deprecation, where a method eventually disappears from the API altogether. I don't think it's handled in the current setup but I may be wrong. My guess is that the 1.1 test for that method must be separated into a single file and some flag must be invented or convention taken that lets one specify versions of the JDK the test is okay for and the choose script modified to deal with it. Brian -- Brian Jones