${taskforce.name} Avatar
  1. OMG Task Force

Java to IDL 2005 RTF — Open Issues

Open Closed All
Issues not resolved

Issues Descriptions

No wire format defined for java.lang.reflect.Proxy classes

  • Key: JAV2I14-2
  • Legacy Issue Number: 7595
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    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.

  • Reported: JAV2I 1.2 — Tue, 20 Jul 2004 04:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

ORB shutdown should be configurable

  • Key: JAV2I14-3
  • Legacy Issue Number: 5853
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    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.

  • Reported: JAV2I 1.2 — Fri, 7 Feb 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Custom Marshaling Format Clarification

  • Key: JAV2I14-1
  • Legacy Issue Number: 5879
  • Status: open  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: JAV2I 1.2 — Fri, 7 Mar 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT

Guidance on RepositoryIDs for primitive types

  • Key: JAV2I14-4
  • Legacy Issue Number: 5891
  • Status: open  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    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?

  • Reported: JAV2I 1.2 — Tue, 18 Mar 2003 05:00 GMT
  • Updated: Wed, 11 Mar 2015 11:15 GMT