Java to IDL Language Mapping Avatar
  1. OMG Specification

Java to IDL Language Mapping — Closed Issues

  • Acronym: JAV2I
  • Issues Count: 7
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

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