Re: Problem with CollationElementIterator.jdk11 testcases

[Brian Jones <cbj at gnu dot org>]

Can't remember exactly why I got involved, but the test I think was
broken before I made a change so I decided since I didn't understand
how the values were supposed to be generated precisely to make the
test expect what the JDK actually does.

If you understand what is broken here, and likely things in both the
test and Classpath, then I'd like to get it fixed.

Brian

Stephen Crawley <crawley@dstc.edu.au> writes:

> Hi Brian,
> 
> I've been trying to work out why Classpath (over Kissme) is failing
> 16 test in gnu.testlet.java.text.CollationElementIterator.jdk11.
> For example:
> 
> FAIL: gnu.testlet.java.text.CollationElementIterator.jdk11: 
>   next() 0 (number 1)
> FAIL: gnu.testlet.java.text.CollationElementIterator.jdk11: 
>   primaryOrder() 0 (number 1)
> 
> Examining the testcase code, and comparing the test results with those
> for various Sun JDK's, it seems that the Classpath implementation is
> returning different collation key values.  The testcase is expecting
> the JDK value and is barffing.
> 
> But I don't think that this is correct.  Nothing I could see in the Sun
> javadocs that specifies what the precise key values should have.
> Rather, the specification says that the key values simply have to have
> specific ordering characteristics.
> 
> What do you think?
> 
> -- Steve
> 
> 

-- 
Brian Jones <cbj@gnu.org>