From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 696 invoked by alias); 17 Aug 2011 16:27:25 -0000 Received: (qmail 670 invoked by uid 22791); 17 Aug 2011 16:27:23 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,T_HK_NAME_DR X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Aug 2011 16:27:04 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7HGR3OD010424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 17 Aug 2011 12:27:03 -0400 Received: from rivendell.middle-earth.co.uk ([10.3.113.13]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p7HGR0c6031994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Aug 2011 12:27:02 -0400 Date: Wed, 17 Aug 2011 16:27:00 -0000 From: Dr Andrew John Hughes To: Pavel Tisnovsky Cc: mauve-discuss@sourceware.org Subject: Re: Fix for test gnu/testlet/java/lang/Integer/parseInt.java Message-ID: <20110817162659.GB9583@rivendell.middle-earth.co.uk> References: <4E4BEA69.9040702@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E4BEA69.9040702@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact mauve-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: mauve-discuss-owner@sourceware.org X-SW-Source: 2011-q3/txt/msg00003.txt.bz2 On 18:20 Wed 17 Aug , Pavel Tisnovsky wrote: > Greetings, > > I think that the regression test "gnu/testlet/java/lang/Integer/parseInt.java" > should be fixed to work correctly for pre JDK1.7 case (JDK1.0 .. JDK1.6) and > also for JDK1.7 case. The difference between JDK1.6 and JDK1.7 is in the > behaviour of method Integer.parseInt() when string beginning with '+' sign is > parsed: > > Integer.parseInt("+42") > > JDK1.6 throws exception in this case, but parsing the same string is perfectly > valid in JDK1.7. So I added the condition to the test which checks what JDK is > being tested (I can't figure out how Mauve harness checks the "Tags: JDKxx" > tag). I also changed the message printed in case JDK1.7 does not work correctly. > > Is it possible to push the fixed test to Mauve repository please? > > Thank you in advance, > Pavel Such tests are dubious because they assume compliance to one particular version, which has never been true of GNU Classpath and can't be verified due to the lack of a Free Software TCK. There will also be versions of OpenJDK7 that report as "1.7" but don't yet have this change. Have you tested this with GNU Classpath? I'm pretty sure it will break the test there as it has the modern behaviour, but most GNU Classpath VMs tend to report earlier versions due to the level of bytecode they support. As the old behaviour is specific to versions of Sun/Oracle's JDK implementation, it should check that this implementation is being used as well, rather than just the version. > --- gnu/testlet/java/lang/Integer/parseInt.java 2008-05-12 23:35:49.000000000 +0200 > +++ gnu/testlet/java/lang/Integer/parseInt.java 2011-08-17 17:17:16.000000000 +0200 > @@ -106,15 +106,31 @@ > } > > // In JDK1.7, '+' is considered a valid character. > - try > - { > - i = Integer.parseInt("+10"); > - harness.check(true); > - harness.check(i, 10); > - } > - catch (NumberFormatException nfe) > - { > - harness.fail("Leading '+' does not throw NumberFormatException"); > + // it means that the following step should be divided > + // for pre JDK1.7 case and >= JDK1.7 > + String[] javaVersion = System.getProperty("java.version").split("\\."); > + if (Integer.parseInt(javaVersion[1]) >= 7) { > + try > + { > + i = Integer.parseInt("+10"); > + harness.check(true); > + harness.check(i, 10); > + } > + catch (NumberFormatException nfe) > + { > + harness.fail("'+10' string is not parsed correctly as expected in JDK1.7"); > + } > + } > + else { // pre JDK1.7 branch > + try > + { > + i = Integer.parseInt("+10"); > + harness.fail("'+10' must throw NumberFormatException"); > + } > + catch (NumberFormatException nfe) > + { > + harness.check(true); > + } > } > > try -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37