public inbox for mauve-discuss@sourceware.org
 help / color / mirror / Atom feed
* Problem with CollationElementIterator.jdk11 testcases
@ 2003-06-11 14:19 Stephen Crawley
  2003-06-11 22:37 ` Brian Jones
  0 siblings, 1 reply; 3+ messages in thread
From: Stephen Crawley @ 2003-06-11 14:19 UTC (permalink / raw)
  To: Brian Jones; +Cc: mauve-discuss


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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Problem with CollationElementIterator.jdk11 testcases
  2003-06-11 14:19 Problem with CollationElementIterator.jdk11 testcases Stephen Crawley
@ 2003-06-11 22:37 ` Brian Jones
  2003-06-11 23:42   ` Stephen Crawley
  0 siblings, 1 reply; 3+ messages in thread
From: Brian Jones @ 2003-06-11 22:37 UTC (permalink / raw)
  To: Stephen Crawley; +Cc: mauve-discuss

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>

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Problem with CollationElementIterator.jdk11 testcases
  2003-06-11 22:37 ` Brian Jones
@ 2003-06-11 23:42   ` Stephen Crawley
  0 siblings, 0 replies; 3+ messages in thread
From: Stephen Crawley @ 2003-06-11 23:42 UTC (permalink / raw)
  To: Brian Jones; +Cc: Stephen Crawley, mauve-discuss, crawley


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

I'll get onto it right away ...

-- Steve

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2003-06-11 23:42 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-11 14:19 Problem with CollationElementIterator.jdk11 testcases Stephen Crawley
2003-06-11 22:37 ` Brian Jones
2003-06-11 23:42   ` Stephen Crawley

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).