On Sat, 2006-02-04 at 15:08 +0100, Roland Weber wrote:
> Hi all,
>
> I just executed the test cases for HttpComponents http-core. I get one
> failure...
>
> test:
> [javac] Compiling 39 source files to
> /home/rweber/HttpComponents/trunk/http-core/target/tests
> [java] .......F..................................
> [java] .........................................
> [java] .........................................
> [java] .........................................
> [java] .........................................
> [java] .................................
> [java] Time: 0.154
> [java] There was 1 failure:
> [java] 1)
> testBytesToString(org.apache.http.util.TestEncodingUtils)junit.framework.ComparisonFailure:
> expected:<...?ezi_z?m?> but was:<...?ezi_z?m?>
> [java] at
> org.apache.http.util.TestEncodingUtils.testBytesToString(TestEncodingUtils.java:82)
> [java] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [java] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> [java] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>
> [java] FAILURES!!!
> [java] Tests run: 238, Failures: 1, Errors: 0
>
>
> I promise I didn't touch the EncodingUtils class. The failing test seems to
> rely on a specific JVM behavior when passing an unknown character encoding:
>
> public void testBytesToString() throws Exception {
> String s = constructString(SWISS_GERMAN_HELLO);
> byte[] utf = s.getBytes("UTF-8");
> byte[] latin1 = s.getBytes("ISO-8859-1");
> ==> byte[] def = s.getBytes();
>
> String s1 = EncodingUtils.getString(utf, "UTF-8");
> String s2 = EncodingUtils.getString(latin1, "ISO-8859-1");
> ==> String s3 = EncodingUtils.getString(def, "THIS JUST DOES NOT SEEM
> RIGHT");
>
> assertEquals(s, s1);
> assertEquals(s, s2);
> ==> assertEquals(s, s3);
>
>
> This test case seems to check JVM behavior rather than HTTP components code,
> or am I missing something? For comparison, I've installed some more JDKs.
> I get the error above with blackdown 1.4.2 and IBM 1.5.0:
>
> java version "1.4.2-03"
> Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-03)
> Java HotSpot(TM) Client VM (build Blackdown-1.4.2-03, mixed mode)
>
> java version "1.5.0"
> Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20051104)
> IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20051103
> (JIT enabled)
> J9VM - 20051027_03723_lHdSMR
> JIT - 20051027_1437_r8
> GC - 20051020_AA)
> JCL - 20051102
>
>
> I get a different error with IBM 1.4.2:
>
> java version "1.4.2"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2)
> Classic VM (build 1.4.2, J2RE 1.4.2 IBM build cxia32142-20060120 (SR4) (JIT
> enabled: jitc))
>
> [java] 1)
> testBytesToString(org.apache.http.util.TestEncodingUtils)java.nio.charset.IllegalCharsetNameException:
> THIS JUST DOES NOT SEEM RIGHT
> [java] at java.nio.charset.Charset.checkName(Charset.java:305)
> [java] at java.nio.charset.Charset.lookup(Charset.java:439)
> [java] at java.nio.charset.Charset.forName(Charset.java:477)
> [java] at
> java.lang.StringCoding$DecoderCache.makeDecoder(StringCoding.java:109)
> [java] at java.lang.StringCoding$1.run(StringCoding.java:155)
> [java] at java.security.AccessController.doPrivileged1(Native Method)
> [java] at
> java.security.AccessController.doPrivileged(AccessController.java:351)
> [java] at
> java.lang.StringCoding$DecoderCache.getDecoder(StringCoding.java:152)
> [java] at java.lang.StringCoding.getDecoder(StringCoding.java:304)
> [java] at java.lang.StringCoding.decode(StringCoding.java:383)
> [java] at java.lang.String.<init>(String.java:740)
> [java] at
> org.apache.http.util.EncodingUtils.getString(EncodingUtils.java:74)
> [java] at
> org.apache.http.util.EncodingUtils.getString(EncodingUtils.java:96)
> [java] at
> org.apache.http.util.TestEncodingUtils.testBytesToString(TestEncodingUtils.java:78)
>
>
> Something is fishy here. My platform is Gentoo Linux on Intel x86-32.
>
> cheers,
> Roland
Hmm. I cannot reproduce it on my box (Ubuntu Linux 5.10). Anyway, I'll
look into the problem and get it fixed
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
