Gcj reversing byte-order of ISO-2022-JP text?

[Brian Matthews]

Gcj seems to be reversing the byte-order when converting ISO-2022-JP to
Unicode. Here's an example:

public class Test
{
    public static void main(String args[]) throws Exception
    {
        try
        {
            String      t = new String(new byte[]
                        {
                            0x1b, 0x24, 0x42, 0x46, 0x7c, 0x1b, 0x28, 0x42
                        }, "ISO-2022-JP");
            String      h;
            int         i, l = t.length();

            for (i = 0; i < l; i++)
            {
                h = "0000" + Integer.toHexString(t.charAt(i));

                System.err.print("\\u" + h.substring(h.length() - 4));
                System.err.print("  ");
                System.err.println((int) t.charAt(i));
            }
        }
        catch (Exception e)
        {
            System.err.println("new String blowed up:");

            e.printStackTrace();
        }
    }
}

$ javac Test.java
$ java Test
\u65e5  26085

That's the expected result per the ISO-2022-JP <-> Unicode tables (for
example, http://x0213.org/codetable/iso-2022-jp-2004-std.txt).

However,

$ gcj41 Test.java -c -g -o Test.o
$ gcj41 -g -o Test --main=Test Test.o \
> -L /usr/local/lib/gcc-4.1.3 -lgcj -L/usr/local/lib -liconv -pthread
$ ./Test
\ue565  58725

Note that it's now E565 instead of 65E5.

This is with:

$ /usr/local/bin/gcj41 -v
Using built-in specs.
Reading specs from 
/usr/local/lib/gcc-4.1.3/gcc/i386-portbld-freebsd6.1/4.1.3/../../../libgcj.s
pec
rename spec lib to liborig
Target: i386-portbld-freebsd6.1
Configured with: ./..//gcc-4.1-20070430/configure --disable-nls
--with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=41
--libdir=/usr/local/lib/gcc-4.1.3
--with-gxx-include-dir=/usr/local/lib/gcc-4.1.3/include/c++/
--infodir=/usr/local/info/gcc41 --disable-rpath --prefix=/usr/local
i386-portbld-freebsd6.1
Thread model: posix
gcc version 4.1.3 20070430 (prerelease)

This is on a FreeBSD system using FreeBSD ports.

This is probably easy to fix if I could find where it's happening, but I
don't know enough about the internals of gcj, gcc, or iconv to know even
where to look.

Any suggestions?

Thanks,
Brian