The Java to IDL mapping has special cases for methods with parameters or return values of type

java.io.Serializable
java.io.Externalizable
java.lang.Object

They become Anys on the wire, and Anys should have full TypeCode information so that a non-Java IDL based client can still unmarshal them.

See the attached test case (make sure to look at the README for the necessary hand modification of the stub class).

The ORB currently generates an Any with a TypeCode of tk_value, and no other information -- the member count is 0. A Java-only world can handle this by calling extract_Value, getting the repository ID, loading the class, and performing normal RMI-IIOP unmarshaling.

While working on a solution, keep in mind that fixing this correctly will introduce a huge performance implication both for time spent calculating the TypeCode tree, as well as the amount of information going on the wire. This is complicated by the fact that indirections are not allowed for top level type codes. See

http://cgi.omg.org/issues/interop.html#Issue4294

which is currently stalled because the discussion came to the conclusion that it would require a rev to GIOP 1.3.

See comments section.

********************************************************************************

###@###.### 2001-10-11

Fix Verified OK

-With Builds :

- j2sdk-1_4_0-beta3-bin-b83-solsparc-10_oct_2001

- rip_int-1_0-fcs-bin-b65-solsparc-08_oct_2001

- j2sdk-1_3_1-fcs-bin-b24-solsparc-06_may_2001
    
     - j2sdk1_3_0fcs-c-bin-solsparc-apr_27

-With Attached Testcases : interoptest.tar.Z and propstest.tar.gz

-By Doing

: Ineroperabilty test between jdk's for attached test

propstest.tar.gz
            
: Interoperability test between BorlandAppserver 4.5 from borland and

Sun's Javaidl for attached test interoptest.tar.Z

********************************************************************************