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

Java to IDL 2005 RTF — All Issues

Open Closed All
All Issues

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

Treatment of classes with writeReplace/readResolve methods

  • Key: JAV2I14-11
  • Legacy Issue Number: 2552
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We should consider whether a Java class that has a writeReplace or a
    readResolve method (with the appropriate signature for use by object
    serialization) should map to a custom valuetype in IDL instead of
    a normal valuetype. We should also think harder about the impact
    of writeReplace/readResolve semantics on non-Java ORBs: can non-Java
    implementations properly receive and send instances of such classes,
    maintaining all the proper sharing, without running into type checking
    problems, and without any additions to non-Java ORBs?

  • Reported: JAV2I 1.0b1 — Fri, 19 Mar 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section: 1.3, Page: 1-21

  • Key: JAV2I14-10
  • Legacy Issue Number: 10336
  • Status: closed  
  • Source: Borland ( Naveed Shaikh)
  • Summary:

    Java to IDL Language Mapping Specification doesn't cover the mapping for Java enum from JDK 1.5. We propose the following mapping to be included in the specification. Mapping for Enumeration: When used as a parameter, return type or member variable, Java enum in JDK 1.5 is mapped to the OMG IDL type ::javax::rmi::CORBA::EnumDesc. The corresponding representation in Java class is: package javax.rmi.CORBA; public class EnumDesc implements java.io.Serializable

    { // Holds the value of enum public String value; // Name of enum class public String className; static final long serialVersionUID = ...; }

    The mapping in IDL will be: module javax { module rmi { module CORBA { valuetype EnumDesc

    { public ::CORBA::WStringValue value; #pragma ID value "RMI:EnumDesc/value:xxxxx" public ::CORBA::WStringValue className; #pragma ID className "RMI:EnumDesc/className:xxxxx" }

    ; #pragma ID EnumDesc "RMI:EnumDesc:aaaaaa:xxxxxxxxx" }; }; };

  • Reported: JAV2I 1.3 — Tue, 5 Sep 2006 04:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

defaultWriteObject clarification

  • Key: JAV2I14-8
  • Legacy Issue Number: 6992
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We have recently found an interop problem with another Vendor's orb and wanted some clarification on the customer marshaling format wrt defaultWriteObject. 1.4.10 says:

    For serializable objects with a writeObject method:
    b. boolean - True if defaultWriteObject was called, false otherwise.

    However it is mute on the subject of writeFields and readFields. The Java serialization spec indicates that defaultWriteObject and writeFields are somewhat equivalent, so (a) one could argue that the boolean should be true if writeFields has been called. (b) One could also argue that the spec doesn't say this and so the boolean should be false. My feeling is that (a) is correct (and this is what the other orb does) but that it should be called out explicitly in the spec.

    Comments appreciated

  • Reported: JAV2I 1.3 — Tue, 17 Feb 2004 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Mapping CORBA activity exceptions to Java

  • Key: JAV2I14-9
  • Legacy Issue Number: 7217
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The CORBA activity specification (Additional Structuring Mechanisms for
    the OTS, v1.0, OMG document formal/02-09-03) introduced three new system
    exceptions (INVALID_ACTIVITY, ACTIVITY_COMPLETED, and ACTIVITY_REQUIRED)
    that were incorporated into CORBA 3.0.

    The JCP J2EE Activity Service for Extended Transactions (JSR 95) adds
    three equivalent exceptions
    javax.activity.InvalidActivityException
    javax.activity.ActivityCompletedException
    javax.activity.ActivityRequiredException
    to the Java platform.

    The Java to IDL mapping should be extended to map these CORBA exceptions
    to the equivalent Java activity exceptions, just as the three CORBA
    transaction system exceptions are currently mapped to the equivalent
    JTA exceptions in the javax.transaction package.

    Proposal:

    In section 1.4.8, add the following rows to table 1-2:

    CORBA Exception RMI Exception
    --------------- -------------
    INVALID_ACTIVITY javax.activity.InvalidActivityException
    ACTIVITY_COMPLETED javax.activity.ActivityCompletedException
    ACTIVITY_REQUIRED javax.activity.ActivityRequiredException

  • Reported: JAV2I 1.3 — Fri, 2 Apr 2004 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Custom marshalled abstract interfaces and Java/IDL

  • Key: JAV2I14-7
  • Legacy Issue Number: 6411
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says:

    "Other Java objects are marshaled in the form of an
    IDL abstract interface (i.e., a union with a boolean discriminator containing either an
    object reference if the discriminator is true or a value type if the discriminator is false)."

    However, the Java/IDL spec does not mandate that all Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2.

    Clarification appreciated

  • Reported: JAV2I 1.3 — Mon, 3 Nov 2003 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Request clarification on copyObject(s) semantics

  • Key: JAV2I14-5
  • Legacy Issue Number: 5991
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    Questions have come up recently about copyObject behavior, both within Sun and from customers.
    The main question is whether it is necessary to actually copy immutable objects, or can copyObject( obj )
    simply return obj for immutable objects. The standard immutable
    objects in question are String and the primitive type wrappers (Integer etc.).

    Looking at ptc/02-01-12, the main part of the specification that is relevant is section 1.5.1.6,
    on the bottom of page 1-52. The statement is made here that "(copyObject and copyObjects) observe
    copy semantics for value objects that are equivalent to marshalling, ...". What exactly does
    equivalent mean here?

    It seems to me that the most important property here is that any sequence of method invocations
    made by the "client" do not affect the results of any sequence of method invocations made by
    the "server" (or vice-versa). This is normally the case for immutable objects that are copied by reference.
    However, locking of an object passed by reference is possibly observable. Normally, the
    "client" and the "server" in the colocated case are actually running on the same thread, but
    each role could pass object obj and copyObject(obj) to a different thread. Different results
    are then possible for the copy/non-copy case, depending on the locking behavior of the threads.

    There are old parts of the rmic -iiop code and the Sun ORB, dating from the days when Sun and IBM
    were jointly developing RMI-IIOP, that show evidence of both possible interpretations. For
    example, StubGenerator.mustCopy( TYPE_STRING ) returns false, so that a method that takes
    only one or more String arguments would not have a call to copyObject(s) generated in the stub.
    However, the implementation of Util.copyObject(s) always copies String instances.

    I would like to see the text clarified in the specification to explicitly state whether immutable
    objects need to be copied or not.

  • Reported: JAV2I 1.3 — Mon, 7 Jul 2003 04:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Custom marshalled abstract interfaces and Java/IDL

  • Key: JAV2I14-6
  • Legacy Issue Number: 6410
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says:

    "Other Java objects are marshaled in the form of an
    IDL abstract interface (i.e., a union with a boolean discriminator containing either an
    object reference if the discriminator is true or a value type if the discriminator is false)."

    However, the Java/IDL spec does not mandate that all Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2.

    Clarification appreciated.

  • Reported: JAV2I 1.3 — Mon, 3 Nov 2003 05:00 GMT
  • Disposition: Resolved — JAV2I 1.4
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT