There is a bug in the java orb such that we are unable to have a ORBit2 (gnome-2.0) client invoke a java method on a Java Object.
I've attached the source files I've been using, its a simple test program that
illustrates the problem.


Running the simple Java "Hello World" server , the ORBit2 client tries to call method defined in the IDL. However a BAD_OPERATION( when using java1.4) / DATA_CONVERSION (java 1.3) exception occurs.

Below is a printout of the request from the ORBit client and the reply
it recieves from the Java ORB

Basically the Java ORB returns an incorrect value for the endian-ness
(byte order) of the data that it returns in response to a CORBA IIOP
request.

Here's the request orbit sends. The first line of each message is the
header.

Outgoing IIOP data:
0x 0 47 49 4f 50 1 1 1 0 54 0 0 0 XX XX XX XX |GIOP....T...**** ---
                         ^^^ ^^^^^^^^^^^
flags: +-- 4 byte size
                    1 indicates little encoded little
                      endian endian

0x c 1 0 0 0 1 0 0 0 c 0 0 0 1 1 1 1 |................ ---
0x 1c 1 0 1 5 9 1 1 0 90 f7 ff bf 1 0 0 0 |................
0x 2c 1c 0 0 0 af ab ca ff 0 0 0 2 72 ef d1 3d |............r..=
0x 3c 0 0 0 8 0 0 0 0 0 0 0 0 1 0 0 0 |................
0x 4c a 0 0 0 73 61 79 48 65 6c 6c 6f 0 49 0 0 |....sayHello.I..
0x 5c 0 0 0 0 XX XX XX XX XX XX XX XX XX XX XX XX |....************

This is the reply from the Java ORB

Incoming IIOP data: connected
0x 0 47 49 4f 50 1 0 0 1 ec 0 0 0 XX XX XX XX |GIOP........**** ---
                         ^^^ ^^^^^^^^^^^
flags: +-- 4 byte size
                    0 indicates big encoded little
                      endian endian

***** Endianess flag different from actual encoding of length field *****

0x c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 |............... ---
0x 1c 0 0 0 6 0 0 0 98 0 0 0 0 0 0 0 28 |...............(
0x 2c 49 44 4c 3a 6f 6d 67 2e 6f 72 67 2f 53 65 6e 64 |IDL:omg.org/Send
0x 3c 69 6e 67 43 6f 6e 74 65 78 74 2f 43 6f 64 65 42 |ingContext/CodeB
0x 4c 61 73 65 3a 31 2e 30 0 0 0 0 1 0 0 0 0 |ase:1.0.........
0x 5c 0 0 0 5c 0 1 1 0 0 0 0 10 31 32 39 2e |...\........129.
0x 6c 31 35 36 2e 32 32 36 2e 32 31 33 0 4 d0 0 0 |156.226.213.....
0x 7c 0 0 0 19 af ab ca ff 0 0 0 2 72 ef d1 3d |............r..=
0x 8c 0 0 0 8 0 0 0 1 0 0 0 0 1 0 0 0 |................
0x 9c 0 0 0 1 0 0 0 1 0 0 0 14 0 0 0 0 |................
0x ac 0 1 0 20 0 0 0 0 0 1 1 0 0 0 0 0 |................
0x bc 4e 45 4f 0 0 0 0 2 0 3 0 0 bf ff f7 90 |NEO.............
0x cc 0 0 0 2 0 0 0 26 49 44 4c 3a 6f 6d 67 2e |.......&IDL:omg.
0x dc 6f 72 67 2f 43 4f 52 42 41 2f 44 41 54 41 5f 43 |org/CORBA/DATA_C
Received exception 2: 'IDL:omg.org/CORBA/DATA_CONVERSION:1.0'
system exception
system exception de-marshaled
Clean demarshal of exception on id 0xbffff790

And ORBit fails to decode the reply


This bug appears using 1.4.0-beta2, 1.3.1_01 and jdk1.2.2_07 on both linux and solaris.

There is no workaround, so until this is fixed, we are blocked on a
Sun strategic project impacting the Solaris desktop and the use of Java on Solaris and Linux. This bug makes it impossible to deliver Java Accessibility on Solaris.