Issues for Java to IDL RTF Discussion Mailing List

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5853: ORB shutdown should be configurable Jira Issue JAV2I12-1
Issue 5879: Custom Marshaling Format Clarification Jira Issue JAV2I12-2
Issue 5891: Guidance on RepositoryIDs for primitive types Jira Issue JAV2I12-3
Issue 7595: No wire format defined for java.lang.reflect.Proxy classes Jira Issue JAV2I12-4

Issue 5853: ORB shutdown should be configurable (java2idl-rtf)

Section 1.6.1 states:      "A call to exportObject with no objects exported creates a non-daemon thread that  keeps the Java virtual machine alive until all exported objects have been unexported by  calling unexportObject."      However, there is no implicit way to unexport objects and so this places the burden on the users to do so. It may be that users are not exporting objects themselves but using some layered product that does so - in this case they would have to call a shutdown API in order  for their program to exit. All of these solutions are non-intuitive and not helpful to the user who forgets to call the requied API - their program just does not exit.      I would like to suggest that this behavior be configurable in some way, either via exportObject or via properties so that users and implementors can choose whether or not a particular exported object should cause the VM to stay alive.  

Consider the following Java classes:        public class A implements java.io.Serializable {          // This is a non custom class           // A's data -- omitted          // A's constructors - omitted          // A's methods -- omitted      }        public class B extends A {          // B's data -- omitted here          // B's cobstructors -- omitted here            // This is a custom class              private void writeObject(java.io.ObjectOutputStream s) { .... }            // Other methods omitted      }        public class C extends B {          // This is a non-custom class           // C's data -- omitted          // C's constructors - omitted         // C's methods -- omitted      }        public class D extends C {          // D's data -- omitted here          // D's cobstructors -- omitted here             // This is a custom class          private void writeObject(java.io.ObjectOutputStream s) { .... }            // Other methods omitted      }    Here we have a class inheritance hierarchy as D:C:B:A with A and C as non-custom classes, B and D as custom classes. What is the rmi-iiop data  layout on the wire when an instance of D is marshaled in terms of customer header and data w.r.t. to each of the super classes? Which one of the following layout is correct?          -----------------------------------------------------------------------------------------  a.  |    A-Data    |    B-FV   B-DWO  B-Data    |     CData    |     FV-D DWO-D DData    |       -----------------------------------------------------------------------------------------         --------------------------------------------------------------------------------------------------------------------------------  b.  |    A-FV   A-DWO  A-Data    |    B-FV   B-DWO  B-Data    |     C-FV   C-DWO  C-Data    |     D-FV D- DWO DData    |       -------------------------------------------------------------------------------------------------------------------------------         ----------------------------------------------------------------------------  c.  |    A-FV   A-DWO  A-Data    |     B-Data    |      C-Data    |      DData    |       ---------------------------------------------------------------------------    Terms used for illustration purpose here:    A-FV    ------ means the Format version octet for class A  A-DWO ------ means the defaultWriteObject boolean flag for class A  A-Data  -----  means the data fields of class A.    B-FV    ------ means the Format version octet for class B  B-DWO ------ means the defaultWriteObject boolean flag for class B  B-Data  -----  means the data fields of class B    C-FV    ------ means the Format version octet for class C  C-DWO ------ means the defaultWriteObject boolean flag for class C  C-Data  -----  means the data fields of class C.    D-FV    ------ means the Format version octet for class D  D-DWO ------ means the defaultWriteObject boolean flag for class D  D-Data  -----  means the data fields of class D.

I have noticed that the Sun ORB generates RepositoryIds for primitive types when generating a FullValueDescription that looks like this:      RMI:int:000000000000000000      Now you could argue that the type of int is Integer.TYPE and the function getName() on this class does indeed return "int" however there are explicit mappings for primitive types (int -> IDL long) and this just seems wrong to me.      Should the repid be null or something else? Does it matter?  

Java serialization supports the serialization of proxy classes explicitly. It does this by essentially marshaling into the stream the list of interfaces that the proxy implements and on the other end calling Proxy.getProxyClass() with those interfaces. In RMI-IIOP the proxy class ends up coming across the wire with a repository ID of RMI:\U0024Proxy0:2D4A76C198E9D8DA:0000000000000000 (i.e. $Proxy) which is not a real class and cannot be loaded by the client.      I think we probably need to mandate specific behaviour for proxy classes along the lines of the java serialization spec. A simple approach might be to mandate that the valuetype contain a list of repids, the first being the pseudo-repid for the proxy itself and the other being the repids of the interfaces the proxy supports. The actual data would be that of the proxy itself which is basically the InvocationHandler.