From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3518 invoked by alias); 18 Aug 2011 08:12:48 -0000 Received: (qmail 3507 invoked by uid 22791); 18 Aug 2011 08:12:46 -0000 X-SWARE-Spam-Status: No, hits=-8.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS 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; Thu, 18 Aug 2011 08:12:28 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p7I8CSj3013123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 18 Aug 2011 04:12:28 -0400 Received: from dhcp-lab-190.englab.brq.redhat.com (dhcp-2-245.brq.redhat.com [10.34.2.245]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p7I8CQq0015053; Thu, 18 Aug 2011 04:12:27 -0400 Message-ID: <4E4CC9DA.1030704@redhat.com> Date: Thu, 18 Aug 2011 08:12:00 -0000 From: Pavel Tisnovsky User-Agent: Thunderbird 2.0.0.23 (X11/20090825) MIME-Version: 1.0 To: Dr Andrew John Hughes CC: mauve-discuss@sourceware.org Subject: Re: Fix for test gnu/testlet/java/lang/Integer/parseInt.java References: <4E4BEA69.9040702@redhat.com> <20110817162659.GB9583@rivendell.middle-earth.co.uk> In-Reply-To: <20110817162659.GB9583@rivendell.middle-earth.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00004.txt.bz2 Dr Andrew John Hughes wrote: > 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. Hi Andrew, you are right that we have not FS TCK so the precise JRE behaviour is questionable, but I think that any JDK/JRE which identifies itself as "1.6" should conforms to "Java Platform, Standard Edition 6 API Specification", at least from common developers point of view. > 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. Yeah, that's true because I've tried it using gij: $ gij -version java version "1.5.0" gij (GNU libgcj) version 4.6.0 20110603 (Red Hat 4.6.0-10) Its interesting because it is identified itself as "1.5.0" and parse the string "+10" without problems. > 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. Ok, I'll look into it, thank you for review! > >> --- 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 > >