From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4678 invoked by alias); 27 Jul 2006 09:49:53 -0000 Received: (qmail 4662 invoked by uid 22791); 27 Jul 2006 09:49:50 -0000 X-Spam-Check-By: sourceware.org Received: from kennke.org (HELO box7954.elkhouse.de) (213.9.79.54) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 27 Jul 2006 09:49:46 +0000 Received: from [212.126.219.82] (helo=[192.168.1.112]) by box7954.elkhouse.de with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1G63Uj-0002dL-AW; Thu, 27 Jul 2006 12:53:33 +0200 Message-ID: <44C88C1B.6000408@kennke.org> Date: Thu, 27 Jul 2006 09:49:00 -0000 From: Roman Kennke User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: David Gilbert , classpath@gnu.org, mauve-discuss@sourceware.org Subject: Testing JDK bugs? Content-Type: text/plain; charset=ISO-8859-15; format=flowed 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/msg00009.txt.bz2 Hi lists, hi David (you wrote most of the tests I'm gonna talk about..) While trying to clean up some Mauve failures I came upon a couple of tests that fail on JDK because they test strictly against the spec where the JDK isn't as strict. This is mostly bounds checking, where the spec says throws BadLocationException if invalid or similar. I think the JDK simply doesn't perform explicit checks in the Content implementations. See for example the tests for GapContent and StringContent. Now I am not sure how to handle this. I've commented these tests out locally, simply to avoid clutter in the Mauve output. The question is how to interpret the spec. Adding the throws BadLocationException does mean (to me) that the impl may or may not throw a BadLocationException, but the application should be prepared to deal with it anyways. Moreover, the throws BadLocationException is specified in the interface. The implementations are not required to throw the BadLocationException if they decide to deal with wrong input themselves. For instance, the GapContent implementation (ours as well as JDK) can very well handle Position outside the range, because it only calculates offsets. The situation gets worse. There are a number of tests both in Mauve and in the Intel testsuite that actually test the JDK behaviour of _not_ throwing the BLE, sometimes indirectly (via a Document impl or so). So we can't get to fully PASS with Mauve. We should decide if we want to test strict spec compliance or reference impl compatibility. So far the decisions in GNU Classpath have been made in favour of (bug-) compatibility over strict spec compliance, so I think we should do the same for Mauve. Anyway, I think we should either disable the spec-compliance checks or the RI-compatibility checks or both in Mauve so that we have at least a chance to reach 100%. Any opinions on that? /Roman