Re: Fix for test gnu/testlet/java/lang/Integer/parseInt.java

[Pavel Tisnovsky <ptisnovs@redhat.com>]

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
> 
>