2 Test failures in SoundexTest

• Key: CODEC-51
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Henri Yandell
• Fix Version/s: 1.4

Description

Testsuite: org.apache.commons.codec.language.SoundexTest
Tests run: 25, Failures: 2, Errors: 0, Time elapsed: 0.907 sec

Testcase: testUsMappingOWithDiaeresis(org.apache.commons.codec.language.SoundexTest): FAILED
expected:<?000> but was:<>
junit.framework.ComparisonFailure: expected:<?000> but was:<>
at org.apache.commons.codec.language.SoundexTest.testUsMappingOWithDiaeresis(SoundexTest.java:349)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Testcase: testUsMappingEWithAcute(org.apache.commons.codec.language.SoundexTest): FAILED
expected:<?000> but was:<>
junit.framework.ComparisonFailure: expected:<?000> but was:<>
at org.apache.commons.codec.language.SoundexTest.testUsMappingEWithAcute(SoundexTest.java:364)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

Comments

[Henri Yandell]

Unit tests should pass or not be included for a release (imo). Marking as a fix for 1.4.

[Gary Gregory]

Tests pass for me with SVN sources and Ant 1.6.5 on Windows XP SP2+patches with:

• Sun Java 1.4.2_12
• Sun Java 1.5.0_09

[Henri Yandell]

I'll try it out on a few other platforms. OS X and FreeBSD at least.

[Henri Yandell]

I've checked in a change (469593) that makes the jar fail to build if the tests fail.

On OS X both the Maven and Ant pass for 1.5. They both fail for 1.4.
On Linux both the Maven and Ant fail for 1.4 AND 1.5.

I used a different Linux box. This time it's Debian, last time it was Red Hat.

On Debian I'm running 1.5.0_07 and 1.4.2_05. I'll upgrade both and test again.
OS X is running the latest.

[Henri Yandell]

Debian Linux JDK 1.5.0_09 fails for both Ant and Maven.
Debian Linux JDK 1.4.2_12 fails for both Ant and Maven.
Debian Linux JDK 1.6.0-rc-b90 fails for both Ant and Maven.

[Henri Yandell]

And for the hell of it:

Solaris 5.8 - JDK 1.5.0_09, Ant and Maven both fail.
Solaris 5.8 - JDK 1.4.2_12, Ant and Maven both fail.

Given that this is locale specific stuff; these machines are all US installs, so it might be down to that, though the passing under JDK 1.5 on OS X is curious.

[Henri Yandell]

Fails on the nightly build as well - that's another US locale though.

[Henri Yandell]

On OS X JVM 1.4, only the ODiaresis variant fails.

[Henri Yandell]

It seems like it comes down to whether Character.isLetter consider a character to be a letter or not. If it doesn't, then the string gets fully cleaned and returns early. Thus an empty string comes back rather than the expected IllegalArgumentException.

[Henri Yandell]

Confirmed:

public class LetterTest {

public static void main(String[] args) throws Exception { test('ö'); test('é'); }

public static void test(char ch) { System.err.println(ch + " is a letter: " + Character.isLetter(ch) ); }

}

On OS X, the o is false under JVM 1.4 and true under JVM 1.5.
On Linux, the o and e are both false under JVM 1.4 and 1.6. The compiler is also a bit pissed about those characters being in there.
I'm guessing that on Windows these are both returning true.

[Henri Yandell]

Confirmed. Under 1.2 and 1.6, both letters return as true.

[Henri Yandell]

svn ci -m "Modified the test to expect an empty string if the 'fancy' character passed in is not considered a letter by the JVM. See Issue CODEC-51" src/test/org/apache/commons/codec/language/SoundexTest.java

Sending src/test/org/apache/commons/codec/language/SoundexTest.java
Transmitting file data .
Committed revision 476031.

[Henri Yandell]

Is the fix above to the unit test okay, or should we be moving the map(..) check before the clean so it throws an IllegalArgumentException more aggressively?