IDL to Java Language Mapping Avatar
  1. OMG Specification

IDL to Java Language Mapping — All Issues

  • Acronym: I2JAV
  • Issues Count: 159
  • Description: All Issues
Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
I2JAV11-152 Java mapping changes for core issue 4337 I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-151 Stub handling of UnknownException I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-150 Missing operations on org.omg.CORBA.Object I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-149 How does a Java ORB implement a write_fixed/read_fixed? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-148 Package name issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-147 What is the IDL for ServiceInformation and/or what is correct Java mapping? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-146 POA changes missing in Java source archive I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-145 Typo on getRaises and setRaises in formal/2002-08-05 I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-144 Streaming Interfaces I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-143 Should javadoc statement be removed or should method be removed? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-142 interfaces that do not extend org.omg.CORBA.portable.ValueBase I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-141 section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-140 local interface mapping underspecified I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-139 IDL to Java Spec Issue : need to add SystemExceptions introduced in CORBA 2 I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-138 CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-137 #pragma prefix issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-136 Vendor-specific ORB_init methods I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-135 How is an ORB to determine whether or not it is in an applet context? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-134 Incomplete union mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-130 Operations signatures include throws clauses on system exceptions. I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-133 ptc/00-01-08: Conflict 1.15.1 paragraph 2 - 1.19.2 paragraph 2 I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-132 mapping for Request.target will not compile I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-131 Issues with Java mapping of Typecode I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-129 policy_type should map to a Java int. I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-128 Incorrect method declaration in CORBA_2_3/portable/InputStream.java and Out I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-125 SystemExceptionHelper missing I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-126 Mapping for Sequences -> Holder I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-127 IDLEntity interface has to be public. I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-124 Need clarification on custructor(s) for stream-based I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-121 Possible problem with IDL to Java mapping of fixed-point decimal types I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-122 Enum mapping issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-123 How can org.omg.CORBA.portable.InputStream.read_fixed possibly work? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-120 OMG ZIP FILE ISSUES for IDL to Java RTF (06) I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-119 OMG ZIP FILE ISSUES for IDL to Java RTF (05) I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-115 OMG ZIP FILE ISSUES for IDL to Java RTF (01) I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-118 OMG ZIP FILE ISSUES for IDL to Java RTF (04) I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-117 OMG ZIP FILE ISSUES for IDL to Java RTF (03) I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-116 OMG ZIP FILE ISSUES for IDL to Java RTF (02) I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-114 org.omg.CORBA.portable.UnknownException does not have all constructors I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-113 IDL/Java: methods marked final in PortableServer.Servant I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-112 Need clarification on custructor(s) for stream-based stubs/skeletons I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-111 Illegal return statement I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-110 Java mapping for PolicyType... I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-109 Valuetype packages I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-108 Modification of Constant Mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-107 Issues with ObjectImpl implementations I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-106 Java - Mapping for Struct issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-105 Dealing with reserved suffixes (e.g. POA) I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-104 _servant_postinvoke I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-103 Serializable objects in Anys need reference semantics I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-102 Need SerializableHolder class I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-101 Incorrect search order for ORB implementation class name I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-99 PortableServer Servant issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-100 orb.properties search should include home directory I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-98 BAD_PARAM issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-97 PSS requiremnets for the ObV/Java mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-96 Proposal for persistent valuetypes I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-95 Java LocalStub I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-94 Helper "narrow" exception clarification I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-93 typedefs in IDl when generating Java code I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-92 Issue with Mapping for Constants within an interface I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-91 Potential problem with Java Mapping ORB init for Applet I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-90 Local stubs proposal I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-89 create_lname & create_lname_context I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-88 Updated proposal for the OBV Java mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-87 Creating TypeCodes safely in java I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-86 Java Mapping for interfaces -- Proposal I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-85 Need overloaded write_Value method on OutputStream I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-84 Problem mapping "global" types in Java mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-83 Evolving the org.omg.* APIs I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-82 final methods on ObjectImpl I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-81 Proposal to change get_value_def in Java mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-80 mapping of IDL enumerations to java I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-79 2 IDL->Java issues on the singleton ORB (02) I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-78 Conext support in Java I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-77 Java RTF issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-74 Compiler-readable code I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-73 Mapping of IDL names that clash with java.lang.Object methods I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-76 Local stubs I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-75 Object._request variants are unspecified I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-70 Changes to Java fixed type mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-72 Changes to Java interface mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-71 Java mapping"s use of _this() I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-69 OutputStream semantics question I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-68 New stream based stubs and location forward I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-67 Add Any.extract_Streamable() I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-66 Proposed change sto IDL/Java mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-65 orb.properties file issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-64 Mapping of IDL constants to Java I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-63 Proposed change to orb.init I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-62 Does object reference == ObjectImpl? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-61 Callback issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-60 org.omg.CORBA.UserException class not specified I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-59 Section 7.1.3 of Java to IDL mapping I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-58 Helper classes are only for user defined IDL types I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-57 Discriminated Union value issue I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV12-19 Naming issues for new ORB methods I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-18 New issue on register_initial_reference I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-21 Make CORBA_2_3.ORB methods available in CORBA.ORB I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-20 New issue: Error in resolution of issue 4699 I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-23 attribute exceptions I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-22 exceptions on valuetype initializers I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-24 OMG Java Language Mapping and the use of Java null I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV11-35 Section 5.14 and 6.11 IDL/Java Language mapping I2JAV 1.0b1 I2JAV 1.0 Duplicate or Merged closed
I2JAV11-34 Problems with IDL unions mapped to Java I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-37 ImplementationDef should be an abstarct class I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-36 Add missing UnknownUserException I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV12-17 Colocated calls in Java I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-16 is_a support in Java for local interfaces I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-15 support for local objects I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-14 Missing elements of the local mapping I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV11-56 Any"s and Exceptions I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-55 Any.insert_Object() I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-54 Chapter 9.8.1 Local stubs-bug I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-53 POA_Interface bug I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-52 Spec insufficient in section 5.2.1 - Reserved Names I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-47 CORBA::DATA::CONVERSION exception for IDL types wchar/wstring I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-46 Current mapped incorrectly in Java language mapping I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-45 Clarify exact list of methods available on singleton orb I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-51 No INV_NO_RESPONSE possible in Java DII I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-50 Reserved names I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-49 Problem with IDL --> Java mapping for Unions I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-48 IDL/Java language mapping, section 5.14, 6.11 I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-44 Clarify the use of return_value() before invoke() in DII I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-43 Fix any"s to have implement copy semantics I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-40 input/output streams should extend java.io.streams I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-39 delegate field in ObjectImpl should be transient I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-38 create_list semantics not well defined I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-42 Make all basic Holders implement Streamable I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV11-41 _orb() is missing from ObjectImpl I2JAV 1.0b1 I2JAV 1.0 Resolved closed
I2JAV12-10 Mapping for Character and String Types I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-13 Anys obtained using the singleton ORB I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-12 Default UnknownException behavior I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV12-11 Should a holder class for ProtectingEntity get generated I2JAV 1.1 I2JAV 1.2 Resolved closed
I2JAV13-10 response_expected value for colocated invocations I2JAV 1.2 I2JAV 1.3 Resolved closed
I2JAV11-28 When to honor the servant delegate in POA? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-27 Displaying SystemExceptions I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-33 Clarification of serialization of Anys and Typecodes I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-32 IDL/Java issue, Mapping for IDL enum I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-29 Any extract operations for tk_abstract_interface I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-31 publication of messaging / unchecked_narrow I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-30 System Exceptions REBIND, TIMEOUT, BAD_QOS I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-26 Usage of ExceptionDetailMessage service context I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-25 Should valuetype helper insert/extract make copies? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-19 Java language mapping: Tie classes for local interfaces. I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-18 How to create marshalel data of java.lang.Throwable instance? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-23 Copying boxed valuetypes on local calls I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-22 Valuetype unmarshalling I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-21 Request clarification for use of alias typecodes in typedef helper classes I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-20 Custom marshal does not work for certain valuetypes I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-16 Java SystemException should contain nested exception field I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-15 Should Any.extract_string work for bounded strings? I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-24 Union exceptions I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-13 DII and SystemException semantics I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-12 Mapping of AbstractBase and abstract interfaces I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-17 ORB Init problems I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-11 Mapping Messaging sendc_ (and sendp_) methods to Java I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-14 Java substitutability issue: value instance -> interface type I2JAV 1.0 I2JAV 1.1 Resolved closed
I2JAV11-10 Standard properties should include initial host and port I2JAV 1.0 I2JAV 1.1 Resolved closed

Issues Descriptions

Java mapping changes for core issue 4337

  • Legacy Issue Number: 4805
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The recent passage of issue 4337 in the core RTF creates a need to update the Java
    mapping to include support for the _repository_id operation. Here is the proposed
    set of updates to the latest (unofficial) Java mapping specifiction (ptc/02-01-01):

    --------------------------------------------------------------

    In section 1.19.11, add the following method to Object after _get_interface_def:

    string _repository_id() ;

    In section 1.20.2.1, add the following method to LocalObject after _get_interface_def
    (this is the local interface part, I am assumming here that local interfaces
    support repository_id. If not, this should just throw a NO_IMPLEMENT exception):

    public String _repository_id()

    { String[] ids = _ids() ; return ids[0] ; }

    In section 1.20.2.2, add the following method to Servant after _get_interface_def:

    public String _repository_id()

    { return _get_delegate().repository_id(this) ; }

    Also in section 1.20.2.2, add the following paragraph after the section
    on _get_interface:

    _repository_id

    Servant provides a default implementation of _repository_id() that
    can be overridden by derived servants if the default behavior is
    not adequate. As defined in the CORBA 3.0 specification,
    section 11.3.1, the default behavior of _repository_id is to
    return the most derived interface of a static servant or the
    most derived interface retrieved from a dynamic servant.
    This behavior shall be supported by the Delegate that implements
    the servant.

    In section 1.21.6.3, add the following method to ObjectImpl after _get_interface_def():

    public String _repository_id() { return _get_delegate().repository_id(this) ; }

    In section 1.21.7, add the following method to Delegate after get_interface_def:

    public abstract String repository_id(
    org.omg.CORBA.Object self) ;

    In section 1.21.8, add the following method to Delegate after get_interface_def:

    String repository_id( Servant self ) ;

  • Reported: I2JAV 1.0 — Mon, 14 Jan 2002 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Sun, 8 Mar 2015 18:39 GMT

Stub handling of UnknownException

  • Legacy Issue Number: 5783
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    Problem summary:
    Following resolution of issue 5465 in vote 4, Section 1.21.6.3
    "Streaming Stub APIs" 3rd main bullet reads as follows:

    • If the CORBA system exception org.omg.CORBA.portable.UnknownException
      is thrown, the stub does one of the following:
    • Translates it to org.omg.CORBA.UNKNOWN
    • Translates it to the nested exception taht the UnknownException
      contains.
    • Passes it on directly to the user

    In order to preserve RMI semantics ORBs implementing the RMI-IIOP
    protocol
    must always translate the UnknownException to the nested exception given
    by UnknownException.originalEx.

    I think there are problems with the new final paragraph
    a. It's unclear whether the additional paragraph requires a change to
    Stub code or to the ORB runtime.
    b. It's undesirable, and unnecessary in this case, to differentiate
    between ORBs which do and do not implement RMI. The rule can, and
    should, be the same for all Java ORBs.
    c. It is incorrect to mandate that any ORB must translate the
    UnknownException to the nested exception because, as the nested
    exception is defined as a Throwable, this isn't always possible.

    Proposal:
    I think it would be preferable to simply reword Section 1.21.6.3
    "Streaming Stub APIs" 3rd main bullet, as follows:

    • If the CORBA system exception org.omg.CORBA.portable.UnknownException
      is thrown, the stub translates it to the nested exception that the
      UnknownException contains, if possible. If this is not possible, the
      stub passes the UnknownException on directly to the user.
  • Reported: I2JAV 1.0 — Tue, 3 Dec 2002 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate change and close issue

  • Updated: Fri, 6 Mar 2015 21:40 GMT

Missing operations on org.omg.CORBA.Object

  • Legacy Issue Number: 5782
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    While reviewing the latest CORBA 3.1 draft, I noticed that a number of methods recently
    added to CORBA::Object are missing from org.omg.CORBA.Object. The list of missing methods
    is:

    get_client_policy
    get_policy_overrides
    validate_connection
    get_component

    A group of related issues in the core RTF (core issues 3403/3772/3793/3322) are all
    centered on questions about access to ORB operations. The solution to this problem
    has converged on making the ORB available on every object reference. I am including this change in
    this issue as well. It turns out that the Java mapping requires updating 4 separate
    standard classes for every new method that is added to CORBA::Object. 2 of the 4
    classes in the mapping already have an ORB accessor. The main change required to
    support access to the ORB is in the LocalObject implementation.

    I plan to include this issue in the next java-rtf vote. Please note the question inline
    below, and let me know if you have any strong opinions one way or the other.

  • Reported: I2JAV 1.0 — Mon, 2 Dec 2002 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 21:40 GMT

How does a Java ORB implement a write_fixed/read_fixed?

  • Legacy Issue Number: 5728
  • Status: closed  
  • Source: Anonymous
  • Summary:

    From the OMG mapping specs:

    org.omg.CORBA.portable.OutputStream [as of formal/01-06-06] defines:

    public void write_fixed(java.math.BigDecimal value, short digits, short scale)

    { throw new org.omg.CORBA.NO_IMPLEMENT(); }

    org.omg.CORBA.portable.OutputStream [as of formal/01-06-06] defines:

    public java.math.BigDecimal read_fixed(short digits, short scale) { throw new org.omg.CORBA.NO_IMPLEMENT(); }

    JDK 1.4 (and prior versions) do not implement the first two items,
    so no portable bindings could be used for these.

    Should there been an
    org.omg.CORBA_2_4.portable.OutputStream and org.omg.CORBA_2_4.portable.InputStream
    that inherit from org.omg.CORBA_2_3.portable.In/OutStream and add these?

  • Reported: I2JAV 1.0 — Mon, 28 Oct 2002 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close no change

  • Updated: Fri, 6 Mar 2015 21:40 GMT

Package name issue

  • Legacy Issue Number: 5696
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    This is an issue for the Java RTF. Related issue in Core RTF is Issue
    5327.

    Originally from Michi Henning:

    suppose the following [pseudo-]idl:

    #pragma prefix "2abc.def"

    module xyz {
    interface q

    {...}

    ;
    };

    It would generate a Java class 'q' within package 'def.2abc.xyz'.
    The package name '2abc' is not that popular with the java compiler
    since it starts with a digit.

    Discussion from Jishnu Mukerji:

    It seems to me that this is more of a language mapping issue. I don't
    think that the Repository Ids have any requirement to be of the same
    shape as a valid IDL identifier. It would be kind of hard to have GUIDs
    as RepId if that were the case.

    But even for IDL type RepIds 12345.com seems to be a perfectly good
    domain name as is 2ab.com. I don't see why these perfectly valid
    domain names should be disallowed because the Java language mapping
    is unable to deal with them.

    Further discussion from Michi Henning:

    One way to fix it would be to state that:

    1) For the Java mapping, any prefix that starts with a digit gets
    translated with an underscore prefix, so 2ab would turn into
    _2ab for the Java mapping.

    2) Characters that can appear in a prefix pragma are limited to
    some set we'd have to agree on. (Probably the same as for IDL
    identifiers, plus '.' and possibly hyphen ('-').)

    Further discussion from Jishnu Mukerji:

    Item 1 in Michi's list needs to be handled by the IDL-Java RTF. This
    message to issues@omg.org is requesting the creation of an issue
    covering this item for the Java RTF.

    Item 2 can be taken care of in the resolution for Core Issue 5327.

  • Reported: I2JAV 1.0 — Wed, 23 Oct 2002 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    close no change

  • Updated: Fri, 6 Mar 2015 21:40 GMT

What is the IDL for ServiceInformation and/or what is correct Java mapping?

  • Legacy Issue Number: 5694
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Are both of these correct?
    [It seems like the Java maps
    "sequence <ServiceDetailType> service_details" instead of "sequence <ServiceDetail> service_details"]

    from formal/02-06-33 "CORBA 3.0 full specification
    typedef unsigned long ServiceOption;
    typedef unsigned long ServiceDetailType;
    struct ServiceDetail

    { ServiceDetailType service_detail_type; sequence <octet> service_detail; }

    ;
    struct ServiceInformation

    { sequence <ServiceOption> service_options; sequence <ServiceDetail> service_details; }

    ;

    from ptc/02-09-09 "Revision of the interim Java RTF Java .zip archive

    package org.omg.CORBA;

    public final class ServiceInformation implements
    org.omg.CORBA.portable.IDLEntity {

    public int[] service_options;
    public int[] service_details;

    public ServiceInformation() {
    }

    public ServiceInformation (int[] service_options, int[] service_details)

    { this.service_options = service_options; this.service_details = service_details; }

    }

  • Reported: I2JAV 1.0 — Mon, 21 Oct 2002 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 21:40 GMT

POA changes missing in Java source archive

  • Legacy Issue Number: 5693
  • Status: closed  
  • Source: Objective Interface Systems ( Mr. Victor Giddings)
  • Summary:

    Summary:
    The following CORBA 2.4 additions to the PortableServer module are missing from the latest Java source archive (http://cgi.omg.org/cgi-bin/doc?ptc/02-06-14):

    • in enumeration ThreadPolicyValue: the MAIN_THREAD_MODEL value
    • in Current: operations get_reference and get_servant

    Proposed Resolution:
    I believe all changes should be binary compatible with the existing distribution. Therefore, no PortableServer_2_4 package should be necessary. It should be sufficient to apply these patches to the next distribution:

    diff -r1.1 CurrentOperations.java
    7a8,9
    > import org.omg.CORBA.Object;
    >
    13a16,20
    >
    > public Object get_reference() throws org.omg.PortableServer.CurrentPackage.NoContext;
    >
    > public Servant get_servant() throws org.omg.PortableServer.CurrentPackage.NoContext;
    >

    diff -r1.1 ThreadPolicyValue.java
    33a34,37
    > public static final int _MAIN_THREAD_MODEL = 2;
    > public static final ThreadPolicyValue MAIN_THREAD_MODEL =
    > new ThreadPolicyValue(_MAIN_THREAD_MODEL);
    >
    44a49,50
    > case _MAIN_THREAD_MODEL:
    > return MAIN_THREAD_MODEL;

  • Reported: I2JAV 1.0 — Mon, 21 Oct 2002 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 21:40 GMT

Typo on getRaises and setRaises in formal/2002-08-05

  • Legacy Issue Number: 5638
  • Status: closed  
  • Source: INRIA ( Philippe Merle)
  • Summary:

    In the IDL to Java Language Mapping Specification Version 1.2
    (formal/2002-08-05), at pages 1-29 and 1-40, all occurrences
    of getRaises and setRaises must be replaced respectively by
    getraises and setraises according to the Chapter 3 of the
    CORBA Specification Version 3.0 (formal/02-06-01).

    getRaises and setRaises were replaced by getraises and setraises
    during the CORBA Components December 2000 FTF (see final
    report ptc/01-11-02).

  • Reported: I2JAV 1.0 — Thu, 29 Aug 2002 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate changes and close issue

  • Updated: Fri, 6 Mar 2015 21:40 GMT

Streaming Interfaces

  • Legacy Issue Number: 5615
  • Status: closed  
  • Source: Anonymous
  • Summary:

    the DataInputStream and
    DataOutputStream are specified in IDL as abstract valuetypes in Chapter
    5, and they do not follow the standard language mapping for abstract
    valuetypes at least in the Java Language Mapping. So does this imply
    that we should move the source file from CORBA_IDL directory to
    CORBA_PIDL directory? The thing compiles alright as IDL but in case of
    Java it does not produce the right Java code

  • Reported: I2JAV 1.0 — Thu, 22 Aug 2002 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Make the required changes to the standard Java source files as described in the revised text

  • Updated: Fri, 6 Mar 2015 21:40 GMT

Should javadoc statement be removed or should method be removed?

  • Legacy Issue Number: 5595
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The org\omg\CORBA\Object.java includes:

    /**
    *@deprecated Deprecated by CORBA 2.3
    */
    org.omg.CORBA.InterfaceDef _get_interface();

    Which causes the the application code:

    public abstract class x extends org.omg.CORBA.LocalObject implements xl {}
    public interface xl extends org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity {}

    to compile with a warning:

    x.java:1: warning: _get_interface() in org.omg.CORBA.Object has been deprecated

    I'm wondering whether the javadoc statement should be removed or whether the method should be removed?

  • Reported: I2JAV 1.0 — Mon, 26 Aug 2002 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    close issue

  • Updated: Fri, 6 Mar 2015 21:40 GMT

interfaces that do not extend org.omg.CORBA.portable.ValueBase

  • Legacy Issue Number: 5586
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The two files org\omg\CORBA\DataInputStream.java and org/omg\CORBA\DataOutputStream.java
    contain interfaces that do not extend org.omg.CORBA.portable.ValueBase.

    The CORBA IDL shows:

    abstract valuetype DataInputStream { ...
    abstract valuetype DataOutputStream { ...

    And the IDL to Java mapping spec states that abstract value types
    map to a Java interface that extends ValueBase.

    Which is correct?

  • Reported: I2JAV 1.0 — Tue, 20 Aug 2002 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:40 GMT

section 1.18.2 of the OMG IDL mapping document ptc/00-01-08

  • Legacy Issue Number: 4804
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There is something that is unclear in your CORBA spec that I think is causing incompatibility problems between various IDL compilers.

    Given the following IDL:

    ------------------------------------------------- struct Protection

    { string str; }

    ;

    typedef Protection ProtectedEntity;

    typedef sequence<ProtectedEntity> ProtectedEntityList;

    typedef ProtectedEntityList ProtectingEntity; -------------------------------------------------

    Should a holder class for ProtectingEntity get generated? I ask this because some IDL compilers generate it and others do not (very frustrating!).

    In section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 spec I found this: "Holder classes are generated for sequence and array typedefs only. The "unwound" type's Holder class is used for the other cases.".

    Since this is a typedef of a typedef, but the original item was a sequence, should the ProtectingEntityHolder.java file get generated or not?

  • Reported: I2JAV 1.0 — Mon, 14 Jan 2002 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    duplicate of 4802

  • Updated: Fri, 6 Mar 2015 21:38 GMT

local interface mapping underspecified

  • Legacy Issue Number: 4323
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The IDL-to-Java ptc/00-11-03 specification says that an implementation
    of a local interface would extend org.omg.CORBA.LocalObject instead of
    org.omg.CORBA.Object. This is underspecified. It does not say
    anything about the generated classes for a local interface, their
    relationships, nor which one should be implemented by an
    implementation. This MUST be specified for local interface
    implementations to be portable.

    I suggest for local interface X the following generated classes:

    interface X extends XOperations, org.omg.CORBA.Object

    This is similar to a non-local mapping except that it does not extend
    org.omg.CORBA.portable.IDLEntity. Although that would not hurt
    anything it is not necessary since a local interface cannot be
    marshaled.

    I suggest the following specification for implementations of local interfaces:

    class XImpl
    extends org.omg.CORBA.LocalObject
    implements X

    An instance would be create using the usual language construct:

    XImpl x = new XImpl(...);

    The above must be specified just like the current spec says what to do
    with a POA-based implementation of a non-local interface, e.g.,:

    class YImpl extends YPOA

  • Reported: I2JAV 1.0 — Fri, 25 May 2001 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

IDL to Java Spec Issue : need to add SystemExceptions introduced in CORBA 2

  • Legacy Issue Number: 3979
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    The mapping from IDL names to Java Class names provided in Page 1-55 Table 1-2 should include the
    following exceptions (introduced in CORBA 2.4) as well.

    TRANSACTION_MODE
    TRANSACTION_UNAVAILABLE

  • Reported: I2JAV 1.0 — Mon, 23 Oct 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity

  • Legacy Issue Number: 3946
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    IDL to Java specification
    ptc-00-01-08
    Section 1.15.2
    Page 56

    Problem:

    CompletionStatus needs to implement org.omg.CORBA.portable.IDLEntity
    since it's mapped as an enum.

    IDLEntity extends java.io.Serializable, and that is crucial for
    CompletionStatus since it's a member of SystemExceptions. If it isn't
    Serializable, then none of the exceptions are, either.

    Solution:

    OLD:
    public final class CompletionStatus {

    NEW:
    public final class CompletionStatus
    implements org.omg.CORBA.portable.IDLEntity {

  • Reported: I2JAV 1.0 — Tue, 10 Oct 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue...editorial change

  • Updated: Fri, 6 Mar 2015 21:38 GMT

#pragma prefix issue

  • Legacy Issue Number: 3923
  • Status: closed  
  • Source: SciTegic Inc. ( Scott Markel)
  • Summary:

    Section 1.5.3 of the OMG's IDL Style Guide (ab/98-06-03) indicates that

    #pragma prefix "omg.org"

    should appear in any IDL file belonging to an OMG-approved
    specification. With the use of this prefix, the RepositoryID of a
    valuetype V in module M would be

    "IDL:omg.org/M/V:1.0"

    Section 1.13.8 of the IDL to Java Language Mapping Specification
    (formal/99-07-53) specifies the algorithm to be used in determining the
    location of a valuetype and its corresponding default factory, where
    location is in the Java package sense. If an ORB vendor follows this
    algorithm, the default value factory will be assumed to be in the Java
    package given by

    omg.org.M

    Following the Java convention of reversing a domain name to obtain a
    package hierarchy, one would expect to have implementation code in

    org.omg.M

    This mismatch requires users to register default value factories, which
    seems to go against the spirit of the second paragraph of section 5.4.3
    of the CORBA 2.3.1 Specification (formal/99-10-07) where the term
    "implicit registration" is used.

    Proposed resolution:

    In the IDL to Java language mapping the omg.org prefix is reversed to
    org.omg.

    Comments?

  • Reported: I2JAV 1.0 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Vendor-specific ORB_init methods

  • Legacy Issue Number: 3913
  • Status: closed  
  • Source: Improv Technologies ( Mary Leland)
  • Summary:

    The first two bullets in Section 1.1.1.1 of ptc/2000-07-03
    refer to the fields DEFAULT_ORB and DEFAULT_ORB_SINGLETON in
    omg/omg/CORBA/ORB.java. However, these fields do not exist
    in that file (nor are they in org/omg/CORBA_2_3/ORB.java).
    The intention of these bullets is to permit vendors to
    appropriately modify the implementations of the ORB_init
    methods, but since these methods are not implemented using
    those fields, the intention is not achieved.

    Proposed resolution:
    Add a point #3 to Section 1.1, along the lines of
    "In certain rare cases, the actual body of a method
    must be replaced by a vendor-specific implementation.
    These cases are clearly identified in this specification
    and by comments in the org.omg.* packages."

    Change the first two bullets in Section 1.1.1.1 to
    "Vendor-specific implementations for the ORB_init
    methods of org.omg.CORBA.ORB must be supplied.
    Since these methods are static, they cannot be
    overridden by the vendor-specific ORB subclass,
    but must be provided in the org.omg.CORBA.ORB class
    itself."

    Add a comment
    /* VENDOR MUST SUPPLY IMPLEMENTATION */
    to the ORB_init methods, and a line in the
    header comments of the org/omg/CORBA/ORB.java
    file saying that implementations of the ORB_init
    methods are required.

  • Reported: I2JAV 1.0 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

How is an ORB to determine whether or not it is in an applet context?

  • Legacy Issue Number: 3912
  • Status: closed  
  • Source: Improv Technologies ( Mary Leland)
  • Summary:

    How is an ORB to determine whether or not it is in an applet context?
    The nearest that I can see is to check for the presence of
    a SecurityManager. If we are in an applet context, then there is a
    SecurityManager present, but the inverse (that the presence of a
    SecurityManager implies that we are in an applet) is not true.
    It is however the case that whenever a SecurityManager is present,
    potentially untrusted code is present, so the same constraints on the
    singleton ORB are probably appropriate.
    Therefore, I propose that the specification be changed to state
    that if System.getSecurityManager() returns a non-null result,
    the singeton ORB should be constrained to creating TypeCodes and Anys.

  • Reported: I2JAV 1.0 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Incomplete union mapping

  • Legacy Issue Number: 3911
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    it appears that the Java mapping for unions is incomplete. For example:

    enum E

    { A, B, C }

    ;

    union U switch (E)

    { case A: long l; }

    ;

    Something like this is actually used in the trader specification. For
    a discriminator value of B or C, the union contains no member (but does
    contain the discriminator value, of course). The problem arises because
    the semantics of an operation can differ depending on the discriminator
    value. For example:

    interface foo

    { SomeType op(in U param); }

    ;

    op() can do different things (and indeed, does do different things in the
    trader spec), depending on whether the discriminator value for the union
    is B or C.

    The problem is that the Java mapping does not offer a modifier for
    the discriminator, thereby making it impossible to control the discriminator
    value if more than one discriminator value is possible for the same union
    member.

  • Reported: I2JAV 1.0 — Thu, 28 Sep 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Operations signatures include throws clauses on system exceptions.

  • Legacy Issue Number: 3818
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    There are several places in the IDL to Java mapping spec
    (ptc/00-01-08) where operations signatures include
    throws clauses on system exceptions. Since system
    exceptions are unchecked Java exceptions, they need
    never be declared in operation signatures. As normal
    Java practice only declares checked exceptions, the throws
    clauses for unchecked exceptions should be removed.

    I have found this problem in the following places in the spec:

    p. 58-61 various methods throw DATA_CONVERSION, MARSHAL, and BAD_OPERATION
    p. 85 get_value_def throws BAD_PARAM
    p. 122 _invoke(...) throws SystemException

  • Reported: I2JAV 1.0 — Fri, 8 Sep 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

ptc/00-01-08: Conflict 1.15.1 paragraph 2 - 1.19.2 paragraph 2

  • Legacy Issue Number: 3904
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    This is a IDL to Java issue.

    ptc/00-01-08

    1.15.1 paragraph 2 states that the "string reason parameter
    ... is concatenated to the id before calling the base
    UserException constructor."

    However, 1.19.2 paragraph 2 states that "no holder and helper
    classes are define for these exceptions," (i.e., Bounds, BadKind,
    InvalidName) ... they are mapped as normal user exceptions."

    Since a helper class is not generated it is impossible to to
    concatenate an id before calling the base UserException constructor in
    these cases.

    Therefore they are not mapped as normal user exceptions. They
    are mapped as normal user exceptions EXCEPT that the additional "full"
    constructor does not concatenate an id before calling the base
    UserException constructor.

    The text and non-normative examples should be updated to make
    this clear.

  • Reported: I2JAV 1.0 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

mapping for Request.target will not compile

  • Legacy Issue Number: 3903
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    This is a IDL to Java issue.

    ptc/00-01-08 specifies the mapping for Request.

    The mapping of target is specified on p 69 as:

    public abstract Object target();

    It should say:

    public abstract org.omg.CORBA.Object target();

    Otherwise it will not compile.

  • Reported: I2JAV 1.0 — Wed, 20 Sep 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue, editorial change

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Issues with Java mapping of Typecode

  • Legacy Issue Number: 3819
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    In the IDL to Java spec (ptc/00-01-08) there are several minor
    editorial errors in the Java mapping for Typecode:

    1. p. 74 the example has

    class TypeCode extends IDLEntity

    However, IDLEntity is an interface, so this must be implements,
    not extends.

    2. p. 75 the declaration

    public abstract short member_visibility( long index )

    should be

    public abstract short member_visibility( int index )

    since the IDL for member_visibility has a long argument,
    and IDL long type maps to int in Java.

    3. Throughout class Typecode on pp. 74-75, TypeCodePackage.BadKind
    and TypeCodePackage.Bounds are illegal java. The exception names
    must either be fully qualified or unqualified with appropriate
    import statements.

  • Reported: I2JAV 1.0 — Fri, 8 Sep 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue...editorial

  • Updated: Fri, 6 Mar 2015 21:38 GMT

policy_type should map to a Java int.

  • Legacy Issue Number: 3801
  • Status: closed  
  • Source: Oracle ( Max Mortazavi)
  • Summary:

    It appears that there's an error in the OMG specification ptc/00-01-08
    OMG IDL to Java Language Mapping. In the mapping for ORB as given in the
    org.omg.CORBA.ORB in section 1.19.10, the IDL signature

    Policy create_policy(
    in PolicyType type,
    in any val
    ) raises (PolicyError);

    has been mapped to

    public Policy create_policy(short policy_type, Any val)
    throws org.omg.CORBA.PolicyError

    However, note that in formal/99-10-07, as in elsewhere, it's clearly
    stated that PolicyType is unsigned long

    4.9.1 Definition of Policy Object

    typedef unsigned long PolicyType;
    // Basic IDL definition
    interface Policy

    { readonly attribute PolicyType policy_type; Policy copy(); void destroy(); }

    ;

    and that the Java mapping for unsigned long is an "int" not a
    "short," as erroneously implied in 1.19.10 of ptc/00-01-08.

    I believe this is an error in the ptc/00-01-08 OMG IDL to Java Language
    Mapping that needs to be cleared.

  • Reported: I2JAV 1.0 — Tue, 29 Aug 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue, editorial change

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Incorrect method declaration in CORBA_2_3/portable/InputStream.java and Out

  • Legacy Issue Number: 3795
  • Status: closed  
  • Source: Oracle ( Hemanth Puttaswamy)
  • Summary:

    Looks like there is a typo in the IDL to Java document(ptc/00-01-08) Section
    1.21.4.

    The method signature

    public java.io.Serializable read_value( org.omg.CORBA.BoxedValueHelper factory)

    has to be

    public java.io.Serializable read_value( org.omg.CORBA.portable.BoxedValueHelper
    factory)

    Because BoxedValueHelper belongs to org.omg.CORBA.portable package.

    Also The method signature

    public void write_value( java.io.Serializable value,
    org.omg.CORBA.BoxedValueHelper factory)

    has to be

    public void write_value( java.io.Serializable value,
    org.omg.CORBA.portable.BoxedValueHelper factory)

    Again for the same reason.

  • Reported: I2JAV 1.0 — Tue, 29 Aug 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    editorial fix, issue closed

  • Updated: Fri, 6 Mar 2015 21:38 GMT

SystemExceptionHelper missing

  • Legacy Issue Number: 3750
  • Status: closed  
  • Source: IONA ( Mark Spruiell)
  • Summary:

    There is no standard way for an application to insert/extract
    a SystemException into/from an Any. This would be especially
    useful for Portable Interceptors, where an exception is provided
    in the form of an Any.

    In the absence of a SystemExceptionHelper.extract() method, an
    application is forced to a) use DynAny or b) compare the
    exception's repository ID against dozens of system exception
    IDs in order to determine which Helper to use.

    Proposal:

    Add org.omg.CORBA.SystemExceptionHelper. All of the standard
    exception Helper methods are implemented.

  • Reported: I2JAV 1.0 — Wed, 19 Jul 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Mapping for Sequences -> Holder

  • Legacy Issue Number: 3788
  • Status: closed  
  • Source: Oracle ( Ram Jeyaraman)
  • Summary:

    Re : ptc/00-01-08 IDL to Java Language mapping spec, Section 1.10

    The <sequence_class>Holder class shown below does not implement org.omg.CORBA.portable.Streamable
    interface, whereas the basic type holders like ShortHolder implement the Streamable interface.

    final public class <sequence_class>Holder {
    public <sequence_element_type>[] value;
    public <sequence_class>Holder() {};
    public <sequence_class>Holder(
    <sequence_element_type>[] initial)

    {...};
    public void _read(
    org.omg.CORBA.portable.InputStream is)
    {...}

    public void _write(
    org.omg.CORBA.portable.OutputStream os)

    {...}
    public org.omg.CORBA.TypeCode _type() {...}
  • Reported: I2JAV 1.0 — Sat, 19 Aug 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

IDLEntity interface has to be public.

  • Legacy Issue Number: 3794
  • Status: closed  
  • Source: Oracle ( Hemanth Puttaswamy)
  • Summary:

    Interface IDLEntity is declared as package private in the IDL To Java document
    (ptc/00-01-08.pdf) Section 14.1.2. I propose it to change it to public.

    from

    package org.omg.CORBA.portable;
    interface IDLEntity extends java.io.Serializable {}

    to

    package org.omg.CORBA.portable;
    public interface IDLEntity extends java.io.Serializable {}

  • Reported: I2JAV 1.0 — Tue, 29 Aug 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    editorial fix, issue closed

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Need clarification on custructor(s) for stream-based

  • Legacy Issue Number: 3707
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    In OMG IDL to Java Language Mapping spec, $1.21.5.1 "Stub/Skeleton Architecture" there
    are examples of stream- and DSI- based stubs/skeletons. These examples do not
    provide any constructors (this mean thay have only default ones). But, it seems that
    signatures of constructors should be clarified, because orb vendors have a freedom in
    defining these signatures. For example, the VisiBroker's 4.0 idl2java compiler
    generates stubs that have only default constructors, but in jdk 1.2 there stubs that
    have only constructors that take org.omg.CORBA.portable.Delegate as a single
    parameter. This leads to impossibility for generated stubs to extend the jdk 1.2
    provided ones.

    Since the example is not normative, vendors are free to add whatever constructors they
    would like. This makes it impossible to generate code for interfaces that are
    inherited from interfaces for which code is generated by another vendor, which is true
    especially in the case of Java 2 and its inclusion of some stubs.

    I would like to propose the following:
    To Seciton 1.21.5.1 under subheading Stub Design, add a bullet:

    Stubs are not required to define any constructors. However, if they do define special
    constructors, a constructor with no arguments must also be defined.

    This ensures that all stubs are guaranteed to have the no argument constructor
    irrespective of whether they have other constructors or not.

  • Reported: I2JAV 1.0 — Wed, 14 Jun 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Possible problem with IDL to Java mapping of fixed-point decimal types

  • Legacy Issue Number: 3668
  • Status: closed  
  • Source: SAP SE ( Evan Ireland)
  • Summary:

    I'm wondering how other folks interpret the following section from CORBA 2.3.1
    (for the CDR Transfer Syntax).

    15.3.2.8 Fixed-Point Decimal Type

    The IDL fixed type has no alignment restrictions, and is represented as shown in Table
    15-4 on page 15-13. Each octet contains (up to) two decimal digits. If the fixed type
    has an odd number of decimal digits, then the representation begins with the first (most
    significant) digit — d0 in the figure. Otherwise, this first half-octet is all zero, and the
    first digit is in the second half-octet — d1 in the figure. The sign configuration, in the
    last half-octet of the representation, is 0xD for negative numbers and 0xC for positive
    and zero values.

    I interpret this to mean that the encoded size of any given fixed-point
    decimal IDL type is determined statically according to the 'digits' and 'scale'
    in the fixed<digits,scale> IDL definition, rather than dynamically by the
    number of digits in the value to be encoded.

    Unfortunately if my interpretation is correct, there appears to be a problem
    in the IDL to Java mapping for fixed-point decimals, as we have
    in org.omg.CORBA.portable.OutputStream:

    public void write_fixed(java.math.BigDecimal value) ...

    Since a Java BigDecimal has a scale but no precision, I would think there
    would be a problem if the BigDecimal value "1.23" was to be encoded as
    a fixed<5,2>, since the write_fixed method has no 'digits' parameter,
    so it doesn't know the correct size for the CDR encoding.
    The 'read_fixed' method on the InputStream class has similar problems.

    Has anyone encountered this issue before, and if so what was the resolution?

  • Reported: I2JAV 1.0 — Wed, 31 May 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

Enum mapping issue

  • Legacy Issue Number: 3669
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The IDL to Java mapping spec (ptc/00-02-07) defines the
    mapping for IDL to Enums to Java. The generated enum
    class contains a method

    public static <TYPE> from_int( int i )

    However, the mapping spec does not call for an exception
    to be thrown if the parameter does not correspond to a
    valid enum for this enum type.

    ptc/00-02-08 defines the standard Java classes for
    the PIDL native types and the ORB portability interfaces.
    It includes several IDL enums in org.omg.CORBA:

    AttributeMode, CompletionStatus, DefinitionKind, OperationMode,
    ParameterMode, PrimitiveKind, SetOverrideType, and TCKind.

    All have signatures similar to:

    public static TCKind from_int( int val ) throws org.omg.CORBA.BAD_PARAM

    This is not compliant with the specification.

    If we look at the definition of BAD_PARAM, it is a SystemException, which
    extends java.lang.RuntimeException, so BAD_PARAM, like all system exceptions,
    is an unchecked java exception. Consequently there is no need to declare
    BAD_PARAM in the signature of the from_int methods. However, the behavior is
    useful and should be specified.

    I think this issue should be resolved with the following changes:

    1. Update ptc/00-02-08.zip to remove the "throws BAD_PARAM" clauses
    on all from_int methods for enums.

    2. Update ptc/00-02-07 section 1.7 as follows:

    replace the paragraph

    "The java class for the enum has an additional method from_int(),
    which returns the enum with the specified value."

    with

    "The java class for the enum has an additional method from_int(),
    which returns the enum with the specified value if the specified
    value corresponds to an element of the enum. If the specified
    value is out of range, a BAD_PARAM exception with a minor code
    of XXX is raised."

    where as usual XXX needs to be filled in with an appropriate minor code.

  • Reported: I2JAV 1.0 — Tue, 30 May 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

How can org.omg.CORBA.portable.InputStream.read_fixed possibly work?

  • Legacy Issue Number: 3686
  • Status: closed  
  • Source: SAP SE ( Evan Ireland)
  • Summary:

    If you look at the signature of org.omg.CORBA.portable.InputStream.read_fixed,
    you will see that it does not accept parameters for the fixed digits and scale.
    Since the GIOP CDR encoding for fixed-point decimals does not include meta-data
    on the wire (e.g. the scale is not explicit in the wire-encoding), how can the
    Java portable InputStream's read_fixed method reliably determine the scale of
    the value being read? Maybe I'm missing something, or maybe the mapping spec is
    just plain broken. Can someone please shed some light on this.

  • Reported: I2JAV 1.0 — Fri, 9 Jun 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, Duplicate of 3668

  • Updated: Fri, 6 Mar 2015 21:38 GMT

OMG ZIP FILE ISSUES for IDL to Java RTF (06)

  • Legacy Issue Number: 3659
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    (6). The mapping for org.omg.PortableServer.Servant.java specifies the
    following signature for _get_interfaces.

    final public org.omg.CORBA.InterfaceDef _get_interface()

    { return _get_delegate().get_interface(this); }

    Also, for org.omg.PortableServer.portable.Delegate.java

    org.omg.CORBA.InterfaceDef get_interface(
    org.omg.PortableServer.Servant self);


    The above mapping for server-side should be changed to match the
    client side mapping. Please note, that in the
    org.omg.CORBA.portable.ObjectImpl, the following signature has been deprecated.

    /**
    *@deprecated Deprecated by CORBA 2.3
    */
    public org.omg.CORBA.InterfaceDef _get_interface() { return _get_delegate().get_interface(this); }

    the new signature according to CORBA 2.3 spec is:

    public org.omg.CORBA.Object _get_interface_def()

    { return _get_delegate().get_interface_def(this); }
  • Reported: I2JAV 1.0 — Wed, 31 May 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:38 GMT

OMG ZIP FILE ISSUES for IDL to Java RTF (05)

  • Legacy Issue Number: 3658
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    (5). The OMG ZIP file is missing the following interfaces:

    ServantActivatorHelper.java
    ServantActivatorPOA.java
    _ServantActivatorStub.java
    ServantLocatorHelper.java
    ServantLocatorPOA.java
    _ServantLocatorStub.java

    In order to enable, application programmers, register their own servant managers
    these need to be provided as part of the PortableServer package (in the absence
    of the local interfaces).

  • Reported: I2JAV 1.0 — Wed, 31 May 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    close, no change

  • Updated: Fri, 6 Mar 2015 21:38 GMT

OMG ZIP FILE ISSUES for IDL to Java RTF (01)

  • Legacy Issue Number: 3654
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    We notice the following discrepancies with org.omg.PortableServer package
    published as part of 00-02-01.tar at the OMG web site. We need to get
    these issues resolved as soon as possible (especially before the next release
    of JDK).

    (1). Following specified interfaces have an extra inheritance from
    an org.omg.CORBA.Object interface.

    org.omg.PortableServer.Current.java
    org.omg.PortableServer.ServantActivator
    org.omg.PortableServer.ServantLocator

    e.g., the actual inheritance hierarchy for Current should be:

    public interface Current extends CurrentOperations,
    org.omg.CORBA.Current, org.omg.CORBA.portable.IDLEntity

    whereas, in the OMG published interfaces it is:

    public interface Current extends
    org.omg.PortableServer.CurrentOperations,
    org.omg.CORBA.Current,
    org.omg.CORBA.portable.IDLEntity,
    org.omg.CORBA.Object

    PLS. NOTE AN EXTRA INHERITANCE FROM org.omg.CORBA.Object interface,
    which should not be there, since there is already an inheritance from
    org.omg.CORBA.Current. Same for other interfaces.

  • Reported: I2JAV 1.0 — Tue, 30 May 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

OMG ZIP FILE ISSUES for IDL to Java RTF (04)

  • Legacy Issue Number: 3657
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    (4). The "const" mapping does not specify "public static final", please note
    that without this, no one will be able to directly access the value specified
    for the const's directly.

  • Reported: I2JAV 1.0 — Wed, 31 May 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    close, no change

  • Updated: Fri, 6 Mar 2015 21:38 GMT

OMG ZIP FILE ISSUES for IDL to Java RTF (03)

  • Legacy Issue Number: 3656
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    (3). org.omg.PortableServer.ServantLocatorPackage.CookieHelper.java is
    published for "native" Cookie. The IDL to Java specification does not specify
    mapping for Helper classes for native types, nor does it mention that one
    exists for native types. This should be removed as part of the ZIP file
    or the IDL to Java specification needs to be modified to completely specify the
    mapping for CookieHelper.java

  • Reported: I2JAV 1.0 — Tue, 30 May 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

OMG ZIP FILE ISSUES for IDL to Java RTF (02)

  • Legacy Issue Number: 3655
  • Status: closed  
  • Source: Oracle ( Anita Jindal)
  • Summary:

    (2). Wrong mapping for all Enum types, specifically method from_int() is not
    according to IDL to Java mapping spec.

    According to ptc/00-01-08.pdf, the mapping for from_int() method is

    // get enum with specified value public
    static <enum_name> from_int(int value);

    whereas in the OMG published interfaces for all Enums, the mapping for this
    signature is something like:

    public static IdAssignmentPolicyValue from_int(int val)
    throws org.omg.CORBA.BAD_PARAM

    PLS. NOTE THAT IT IS THROWING AN EXCEPTION NOT SPECIFIED BY THE MAPPING.

  • Reported: I2JAV 1.0 — Tue, 30 May 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, duplicate of 3669

  • Updated: Fri, 6 Mar 2015 21:38 GMT

org.omg.CORBA.portable.UnknownException does not have all constructors

  • Legacy Issue Number: 3570
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    All system exceptions have the following constructors, (BAD_PARAM as eg.)

    BAD_PARAM();
    BAD_PARAM(int minor_code, CompletionStatus status);
    BAD_PARAM(String message);
    BAD_PARAM(String message, int minor_code, CompletionStatus status);

    UnknownException however has only one. This seems inconsistent.

    Proposal:

    Add the following constructors to org.omg.CORBA.portable.UnknownException
    UnknownException(Throwable orig, int minor_code, CompletionStatus status);
    UnknownException(Throwable orig, String message);
    UnknownException(Throwable orig, String message, int minor_code,
    CompletionStatus status);

  • Reported: I2JAV 1.0 — Wed, 19 Apr 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:38 GMT

IDL/Java: methods marked final in PortableServer.Servant

  • Legacy Issue Number: 3410
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Java language mapping says (p 1-89) that the following four
    methods in PortableServer.Servant may be overridden by application
    programmers:

    _is_a, _default_POA(), _non_existent(), _get_interface().

    The Java source files provided with the written spec. have all
    these methods marked as final, so they cannot be overridden. While
    the spec. says the source files are authoritative, this seems to
    be a clear contradiction between text and code.

    If the intention whether or not these methods may be overridden has
    changed, this needs to be explained in the text (for application
    programmers). Otherwise, it might just be an editorial issue, i.e.
    the Java source files need to be corrected.

  • Reported: I2JAV 1.0 — Sat, 11 Mar 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Need clarification on custructor(s) for stream-based stubs/skeletons

  • Legacy Issue Number: 3323
  • Status: closed  
  • Source: Anonymous
  • Summary:

    In OMG IDL to Java Language Mapping spec, $1.21.51 "Stub/Skeleton Architecture" there are examples of stream- and DSI- based stubs/skeletons. These examples do not provide any constructors (this mean thay have only default ones). But, it seems that signatures of constructors should be clarified, because orb vendors have a freedom in defining these signatures. For example, the VisiBroker's 4.0 idl2java compiler generates stubs that have only default constructors, but in jdk 1.2 there stubs that have only constructors that take org.omg.CORBA.portable.Delegate as a single parameter. This leads to impossibility for generated stubs to extend the jdk 1.2 provided ones.

  • Reported: I2JAV 1.0 — Fri, 11 Feb 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed, duplicate of issue 3707

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Illegal return statement

  • Legacy Issue Number: 3209
  • Status: closed  
  • Source: NetAcquire Corporation ( Joachim Achtzehnter)
  • Summary:

    The method _releaseReply in class org.omg.CORBA.portable.ObjectImpl
    has a return value of type void, yet the specification requires this
    implementation:

    public void _releaseReply(org.omg.CORBA.portable.InputStream is)

    { return _get_delegate().releaseReply(this, is); }

    The return statement is illegal in a method with a void return type. Should
    delete the word 'return' from the specification.

    PS: Editorial: the diagram on page 1-115 has 'CORBA' missing from some
    of the class names.

  • Reported: I2JAV 1.0 — Tue, 11 Jan 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Closed...editorial issue

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Java mapping for PolicyType...

  • Legacy Issue Number: 2823
  • Status: closed  
  • Source: Anonymous
  • Summary:

    formal-99-07-53 (IDL to Java Language Mapping Specification) has the following
    method signature in ORB (page 1-83):
    public Policy create_policy(short policy_type, Any val)
    throws org.omg.CORBA.PolicyError
    whereas formal-98-12-01 (CORBA) has PolicyType defined as (page 4-20):
    typedef unsigned long PolicyType; Thus, shouldn't the Java mapping be?:
    public Policy create_policy(int policy_type, Any val) throws org.omg.CORBA.PolicyError

  • Reported: I2JAV 1.0 — Wed, 28 Jul 1999 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed, editorial change

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Valuetype packages

  • Legacy Issue Number: 2661
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: For certain IDL types defined in an interface Foo, the Java classes are
    placed in the package FooPackage. The reason given in the mapping document
    is that Java classes cannot be defined in Java interfaces, therefore a new
    package is required.

    However, since valuetypes are defined as abstract classes, does that imply
    that IDL types such as struct, exception, etc., that are defined within a
    valuetype are mapped to nested classes of the valuetype class? Or is a
    separate package used, a la interfaces?

  • Reported: I2JAV 1.0 — Tue, 25 May 1999 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Modification of Constant Mapping

  • Legacy Issue Number: 2647
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When we split the mapping of interfaces into the operations and signature
    interfaces, we had to make a decision what to do with constants that are
    declared within interfaces.
    At the time it seemed that most analogous thing to do was to leave it on
    the signature interface.
    Upon further consideration it would probably be better if it were on the
    operations interface. This would make it available on the server side. This
    is a backwards compatible change because operations is inherited by the
    signature interface so the contstant would still be visible to clients
    without changing their code. It only involves a small change to the
    generated code.

  • Reported: I2JAV 1.0 — Mon, 10 May 1999 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Issues with ObjectImpl implementations

  • Legacy Issue Number: 2609
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I have some issues with the defined implementation of methods on
    org.omg.CORBA.portable.ObjectImpl.

    First, document 98-10-14 says the definitive place to find the
    implementation for this class is in some zip file which I haven"t been able
    to find. Is it available somewhere? Since I couldn"t find the zip file,
    I"m depending on 98-10-14 for the implementation.

    Second, given that all ObjectImpl methods delegate their implementation to
    a locally contained Delegate, if any given ObjectImpl subclass has not been
    connected to an ORB, then it does not have a delegate, and calling any of
    these methods causes a NullPointerException to be thrown. Is there a
    "friendlier" way to fail? Or at least a more intuitively obvious
    exception?

    Finally, toString, hashCode, and equals are methods common to ALL Java
    Objects. These methods should ALWAYS behave as expected, ie., no
    exceptions should be thrown. These were NOT defined to be implemented on
    ObjectImpl in CORBA 2.2. They are defined to be implemented by document
    98-10-14. These methods should either: not be implemented at all on
    ObjectImpl; or be implemented in such a way that they do not throw
    NullPointerException.

  • Reported: I2JAV 1.0 — Thu, 15 Apr 1999 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, no change

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Java - Mapping for Struct issue

  • Legacy Issue Number: 2608
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Mapping of OMG IDL to Java, Section 25-20, Mapping for Struct, has a
    String field that is not initialized. I would like to consider that the
    String value is initialized to a empty String within a Struct eg., String
    foo = new String();

    I have an application with a Sequence of Structs. The Struct has two
    attributes, a boolean and String. The boolean is initialized to "false"
    but the String is not initialized. When I try to add the containing
    object, the attribute of Sequence of Structs fails. I do not want to
    require the use to initialize each Struct within the Sequence before
    createing the object.

  • Reported: I2JAV 1.0 — Wed, 14 Apr 1999 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:37 GMT

Dealing with reserved suffixes (e.g. POA)

  • Legacy Issue Number: 2550
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ptc/98-10-14 changes the mapping of names for skeleton classes; for:

    Module M {
    interface Face {};
    };

    the name of the skeleton and tie classes are now M.FacePOA and M.FacePOATie
    instead of the C++-style POA_M.Face and POA_M.Face_tie.

  • Reported: I2JAV 1.0 — Thu, 18 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, no change.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

_servant_postinvoke

  • Legacy Issue Number: 2540
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It would be extremely useful for the _servant_postinvoke call to include
    the operation name since this is a logical place to hook into the POA"s
    servant locator postinvoke method - which needs the operation name.

    Without a provided operation name argument, this information must be
    saved in some other, potentially inconvenient, place.

  • Reported: I2JAV 1.0 — Mon, 15 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed, no change

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Serializable objects in Anys need reference semantics

  • Legacy Issue Number: 2531
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 25.16 (fifth paragraph) says that Streamable types have
    reference semantics. The same should apply to Serializable types,
    for consistency and so that valuetypes can be sent across DII.

  • Reported: I2JAV 1.0 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Need SerializableHolder class

  • Legacy Issue Number: 2519
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is currently no defined way to map out or inout parameters of
    type ValueBase to Java. Since ValueBase maps to java.io.Serializable,
    there shoud be an org.omg.CORBA.SerializableHolder class.

    Proposed Resolution:

    Add SerializableHolder to section 25.4.1.4.

  • Reported: I2JAV 1.0 — Mon, 8 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, no change.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Incorrect search order for ORB implementation class name

  • Legacy Issue Number: 2518
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The first bullet of the search order for an ORB implementation class
    name in section 25.21.7 is:
    . check in Applet parameter or application string array, if any
    This seems wrong

  • Reported: I2JAV 1.0 — Mon, 8 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

PortableServer Servant issue

  • Key: I2JAV11-99
  • Legacy Issue Number: 2514
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The currently specified definition of the org.omg.CORBA.PortableServer.Servant
    class does not correctly implement the behavior specified. In particular, the
    POA returned by PortableServer::Current::get_POA is always used during the
    processing of _this_object() even if _this_object() is not being called on the
    Servant which is currently being invoked as part of the request. This contradicts
    the behavior defined in the first bullet item for _this_object as defined in
    section 25.19.2.1 "Mapping of PortableServer::Servant".

    Also, the overall behavior of _this() may need some tweaking (see my other email
    "Behavior of POA Servant"s _this()"), which may require us to revisit the
    definition of the Servant class.

  • Reported: I2JAV 1.0 — Fri, 5 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    resolved, see revised text

  • Updated: Fri, 6 Mar 2015 21:36 GMT

orb.properties search should include home directory

  • Legacy Issue Number: 2517
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The search for an orb.properties file to set a default ORB class and
    ORB Singleton class looks only in the JDK lib directory. In many
    installations, this is read-only (e.g., on a shared drive) and not
    updatable by users. To allow users of these JDK installations to
    set a default ORB, the search order should be:
    1. The user"s home directory (user.home system property)
    2. The <java.home>/lib directory.

  • Reported: I2JAV 1.0 — Mon, 8 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 21:36 GMT

BAD_PARAM issue

  • Key: I2JAV11-98
  • Legacy Issue Number: 2462
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This issue is with the 1998-08-22 "Mapping of OMG IDL to Java".

    ptc/1998-08-22 (the IDL/Java mapping), section 25.3.5, says that
    if a bounded string is too long, MARSHAL is thrown.

    Meanwhile, ptc/1998-12-04 (2.3a Core chapters 1-15), section 3.17.1, says
    that MARSHAL is to be used for "A request or reply is structurally invalid
    ...indicates a bug in the runtime". Meanwhile, BAD_PARAM says "a parameter
    passed to a call is out of range or otherwise illegal..."

    Based on these descriptions, I propose that BAD_PARAM should
    be thrown in Java when a string exceeds its bound rather than MARSHAL.

  • Reported: I2JAV 1.0 — Mon, 22 Feb 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Make it so.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

PSS requiremnets for the ObV/Java mapping

  • Key: I2JAV11-97
  • Legacy Issue Number: 2256
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The latest ObV/Java mapping, including George"s latest proposal, is not
    usable for values with a persistent implementation.
    I"d really like to solve this issue with the Java & ObV RTF, rather than
    solve it through the adoption of a new spec that updates the Java mapping.

    ==== Issue

    • ObV/Java maps value types"s data members to Java data members
    • providing a persistent implementation for such data members would
      require byte-code post-processing or pre-processing, or
      yet-to-be-specd-and-agreed JVM hooks; we do not see this as viable/
      realistic options.
  • Reported: I2JAV 1.0 — Tue, 15 Dec 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed, no action

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Proposal for persistent valuetypes

  • Key: I2JAV11-96
  • Legacy Issue Number: 2255
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Here is my proposal for how to solve the persistent valuetype problem.
    It allows valuetypes to be used for PSS with getter and setter
    access to the data, without changing the OBV Java language bindings or
    adding new keywords or pragmas to IDL. Any additions to IDL that may
    be desirable for improved functionality (e.g, query and finder support)
    could be designed jointly by the components submission group and the
    PSS group as part of some future RTF activity.

    The proposal is very simple. It is that persistent valuetypes
    must be abstract valuetypes with attributes. The attributes would
    be used to specify the persistent state of the object.

  • Reported: I2JAV 1.0 — Tue, 15 Dec 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed, no action

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Java LocalStub

  • Key: I2JAV11-95
  • Legacy Issue Number: 2251
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: From IDL/Java specification (draft version 3.4 - August 9):

    The remote stub must be named _<interface_name>Stub where
    <interface_name> is the IDL interface name this stub is
    implementing. The local stub must be named _<interface_name>LocalStub
    where <interface_name> is the same IDL interface name. Local stubs
    are defined to be direct subclasses of remote stubs.

    and:

    The _is_local() method is provided so Helper classes may determine if a
    particular object is implemented by a local servant and if so create a
    local stub, rather than a remote stub. This function would typically
    be called from within the narrow() method of a Helper class. The
    _is_local() method may only return true if the servant incarnating the
    object is located in the same Java VM. The method may return false if
    the servant is not local or the ORB does not support local stubs for
    that particular servant. The default behavior of _is_local() is to
    return false.

    The design described in the specification seems to make it very difficult,
    if not impossible, to do the following:

    • Create a proxy that refers to some remote servant
    • Upon a request to the remote servant, a LocationForward is generated that
      refers to a colocated servant.
  • Reported: I2JAV 1.0 — Thu, 10 Dec 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Merge the two stub classes together as one class with as minimal impact on the APIs and performance.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Helper "narrow" exception clarification

  • Key: I2JAV11-94
  • Legacy Issue Number: 2233
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Referring to 23_java-2_3base.pdf, section 23.11.1, page 23-26, second
    paragraph, "The IDL exception CORBA::BAD_PARAM is thrown if the narrow
    fails."

    This statement can be interpreted in two different ways. Does it mean that
    BAD_PARAM is thrown no matter what goes wrong in the narrow call, or that
    BAD_PARAM is thrown only when the parameter doesn"t support the interface
    being narrowed to?

  • Reported: I2JAV 1.0 — Tue, 1 Dec 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    The latter. A different exception shall be raised to indicate other errors.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

typedefs in IDl when generating Java code

  • Key: I2JAV11-93
  • Legacy Issue Number: 2228
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: A question came up regarding the use of typedefs in idl when generating Java
    >code. Since Java has no support for typedefs the alias is not available to
    >any Java code other than the idl generated code. This seems to be a flaw in
    >the design of the idl to Java mapping specification.

  • Reported: I2JAV 1.0 — Wed, 25 Nov 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    The helper is generated for all aliases, it can be used if needed.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Issue with Mapping for Constants within an interface

  • Key: I2JAV11-92
  • Legacy Issue Number: 2096
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Chapter 25 (IDL/Java) of CORBA V2.3-1.3 (Aug 1998), section 25.5.1,
    "Constants Within An Interface", the text says "Constants declared
    within an IDL interface are mapped to fields in the Java interface
    corresponding to the IDL interface".

    The problem is that there are now two Java interfaces produced for an IDL
    interface, the Operations interface and the Signature interface.

    The current client programming model for accessing constants within
    an interface is to say "t.c" (instead of "tOperations.c").

    Therefore, in order to avoid changing the client programming mode,
    I propose that section 25.5.1 be revised to say that constants within
    an IDL interface "are mapped to fields in the Java signature interface..."

  • Reported: I2JAV 1.0 — Mon, 19 Oct 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed, no action

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Potential problem with Java Mapping ORB init for Applet

  • Key: I2JAV11-91
  • Legacy Issue Number: 2079
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: While working on the revised interoperable naming specification,
    a java issue came up with regard to arguments to CORBA ORB_init.

    The PIDL reads as:
    module CORBA

    { typedef string ORBid; typedef sequence <string> arg_list; ORB ORB_init(inout arg_list argv, in ORBid orb_identifier); }

    However the java mapping for init in an applet is:
    // public static ORB init(Applet app, Properties props);

    Using a property list for the argument list results in considerably
    different behavior than the PIDl sequence<string> definition, mainly
    no preservation of sequence order and no repeating elements
    (properties).

  • Reported: I2JAV 1.0 — Wed, 14 Oct 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    resolved

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Local stubs proposal

  • Key: I2JAV11-90
  • Legacy Issue Number: 1994
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Add the following new paragraph after the third paragraph of Section
    25.20.5.1 "Stub/Skeleton Architecture":

    Local stubs shall copy all valuetypes passed to them either as
    parameters or as data within parameters, and shall pass the resulting
    copies to the Servant in place of the originals. The valuetypes shall
    be copied using the same "deep copy" semantics as would result from
    GIOP marshaling and unmarshaling.

  • Reported: I2JAV 1.0 — Thu, 24 Sep 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:36 GMT

create_lname & create_lname_context

  • Key: I2JAV11-89
  • Legacy Issue Number: 1993
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The naming service states that LName and LNameComponent are created
    in C/C++ using the create_lname and create_lname_context functions
    respectively.
    No mention is made as to how this is achieved in Java.

    Should it be possible to simply create an instance of the class using new,
    or is there a need for a factory class?

  • Reported: I2JAV 1.0 — Wed, 23 Sep 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    These functions (library) has been deprecated by the newly adopted Interoperable Naming Service.

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Updated proposal for the OBV Java mapping

  • Key: I2JAV11-88
  • Legacy Issue Number: 1980
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: updated proposal for the OBV Java mapping which addresses
    a number of issues which have been raised by us and others. This
    proposal is based on a number of discussions and previous proposals
    and current OMG submissions (thanks to Simon Nash and Bernard
    Normier). As with previous poposals, these are not currently formal
    proposals, just working drafts.

    Here are the current issues:

    1. Java valuetypes cannot unmarshal recursive references to themselves.
    This is the same problem that occurs with custom valuetypes.

    2. The current language mapping mixes both generated code with user
    written code in the same source file. This poses a very complex "tool"
    issue for IDL compilers which is unnecessarily complex.

    3. Java valuetypes need a way to unmarshal the state of their base class.

    4. The addition of the new Helper interface adds ~400 bytes to every
    Helper class, of which there are about 250 in a typical ORB implementation.
    Which is an overhead of about 100k just to support an optimization of
    a corner case in RMI/IIOP where an RMI type happens to contain an IDL type.
    This doesn"t even begin to address the bloat that would occur to user code
    as well as any additional CORBA services. The space/time tradeoff here
    appears to have gone the wrong way.

    5. The ValueHelper interface contains the method get_safe_base_ids, which is
    inconsistent with current OBV terminology.

    6. The marshaling of boxed types should be considered carefully, because of
    the special casing required for boxed strings, arrays, and sequences.

    7. The compiler should provide compile time enforcement of init() declarations.

  • Reported: I2JAV 1.0 — Fri, 18 Sep 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    resolved, see revised text

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Creating TypeCodes safely in java

  • Key: I2JAV11-87
  • Legacy Issue Number: 1964
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There are problems with creating recursive TypeCodes containing values.Our proposal is really quite simple. We want to add a new class to the
    org.omg.CORBA.portable package defined as follows:

    package org.omg.CORBA.portable;

    final public class TypeCodeLock {
    }

    All generated type() methods in Helper"s could synchronize on the
    TypeCodeLock"s class object to grab a global lock which is used during
    TypeCode creation to guarnatee the atomicity of TypeCode creation.
    Note, this is essentialy what is done in C++ where TypeCodes are typically
    initialized in a global static initalizer which is done from a single
    thread. We are just allowing the typecodes to be created lazily.

  • Reported: I2JAV 1.0 — Wed, 16 Sep 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, no action

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Java Mapping for interfaces -- Proposal

  • Key: I2JAV11-86
  • Legacy Issue Number: 1961
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Sun would like to see the following changes to the mapping:

    • Change the specification to:
    • either not specify that object reference types extend the operations interfaces, or
    • specify that object reference types do not inherit from the operations interface and that the operations interface is just used on the server-side for delegation-based object implementations.
    • The convention established was that the names of all Java classes/interfaces generated for the server-side as well as those that are not visible start with an `_". We would like to stick to the convention and rename the operations interface accordingly.
  • Reported: I2JAV 1.0 — Tue, 15 Sep 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:
  • Updated: Fri, 6 Mar 2015 21:36 GMT

Need overloaded write_Value method on OutputStream

  • Key: I2JAV11-85
  • Legacy Issue Number: 1942
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: We have come across a case in the Java-to-IDL mapping where we
    need another overloaded form of the write_Value method on the
    org.omg.CORBA.portable.OutputStream class.

  • Reported: I2JAV 1.0 — Thu, 10 Sep 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, no action

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Problem mapping "global" types in Java mapping

  • Key: I2JAV11-84
  • Legacy Issue Number: 1941
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current IDL/Java mapping cannot correctly map IDL "global" types
    correctly in all cases.

  • Reported: I2JAV 1.0 — Wed, 9 Sep 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, no action

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Evolving the org.omg.* APIs

  • Key: I2JAV11-83
  • Legacy Issue Number: 1897
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Now that the org.omg.* APIs are built into the JDK core (from JDK 1.2
    onwards), there is an issue with how these could be evolved to
    support changes to the OMG spec that happen between JDK major releases.
    The following is a proposal for how this could be handled.

  • Reported: I2JAV 1.0 — Fri, 28 Aug 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    resolved, see revised text

  • Updated: Fri, 6 Mar 2015 21:36 GMT

final methods on ObjectImpl

  • Key: I2JAV11-82
  • Legacy Issue Number: 1795
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The _get_delegate() and _set_delegate() methods on the Java class
    org.omg.CORBA.portable.ObjectImpl should be marked "final" so they
    can be inlined by an optimizing java compiler.

  • Reported: I2JAV 1.0 — Tue, 11 Aug 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Proposal to change get_value_def in Java mapping

  • Key: I2JAV11-81
  • Legacy Issue Number: 1754
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current support for get_value_def in Helper classes in the
    Java mapping for values is currently has several problems.

    1. It cannot work with the singleton ORB, which means that the API
    is unusable.

    2. It requires the generation of the nearly the exact same code in
    every single value helper which is very wasteful.

    The new proposal is to remove get_value_def from the Value helper class
    and add it to the ORB class

  • Reported: I2JAV 1.0 — Thu, 30 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

mapping of IDL enumerations to java

  • Key: I2JAV11-80
  • Legacy Issue Number: 1752
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: he current mapping of IDL enumerations to Java relies on there being
    one and only one instance of an enum. The instance is held as
    a static variable in the enumeration class. Since there is only
    one instance, identity comparisons are used in comparing enums and
    the enumeration value class does not implement equality or hash
    methods based on the value of the enum.

  • Reported: I2JAV 1.0 — Wed, 29 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, no action

  • Updated: Fri, 6 Mar 2015 21:36 GMT

2 IDL->Java issues on the singleton ORB (02)

  • Key: I2JAV11-79
  • Legacy Issue Number: 1750
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How is an ORB to determine whether or not it is in an
    applet context? The nearest that I can see is to check for the presence
    of a SecurityManager. If we are in an applet context, then there is a
    SecurityManager present, but the inverse (that the presence of a
    SecurityManager implies that we are in an applet) is not true. It is
    however the case that whenever a SecurityManager is present, potentially
    untrusted code is present, so the same constraints on the singleton ORB
    are probably appropriate. Therefore, I propose that the specification be
    changed to state that if System.getSecurityManager() returns a non-null
    result, the singeton ORB should be constrained to creating TypeCodes and
    Anys.

  • Reported: I2JAV 1.0 — Wed, 29 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, no action

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Conext support in Java

  • Key: I2JAV11-78
  • Legacy Issue Number: 1746
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Below are the proposed spec changes to support Contexts in IDL/Java.
    It turns out that some type of API change will be required. As I was
    investigating this further today I realized that one of the methods
    on ORB we have to support Context streaming is a proprietary method
    and not a standard method, so there is no way to create a Context
    object given an InputStream. This makes demarshalling of contexts
    impossible in the stream-based model as it exists today. The proposal
    adds one new method each to InputStream and OutputStream. Also, as
    requested by Simon I have text which states how the Context parameters
    are used in interface method declarations.

  • Reported: I2JAV 1.0 — Mon, 27 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Java RTF issue

  • Key: I2JAV11-77
  • Legacy Issue Number: 1741
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: ObjectImpl._servant_preinvoke(), how many arguments does it take? The
    spec and the consolidated code in the appendix currently differ.

    Are Helpers/Holders for SystemExceptions generated? Are they streamable?
    How does one insert them into an Any?

    (I gain the impression that there has been some work in this area. This
    may no longer be an issue.)

    Why are the mapped classes for structs "final" when little else is? Is
    there a reason for preventing application developers from sub-typing
    them?

  • Reported: I2JAV 1.0 — Mon, 27 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Compiler-readable code

  • Key: I2JAV11-74
  • Legacy Issue Number: 1737
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

    PLEASE PLEASE PLEASE resist the temptation to include consolidated Java
    source code in .PDF files. At least 3 reasons exist:

    • EVERY publication of the consolidated org.omg.* hierachy so far has
      contained code that, even before inclusion in the PDF, simply could not
      have compiled (void functions returning values, non-void functions
      failing to do so, etc.). Errors of this nature arise through having an
      editor have to maintain two seperate copies of the code. The need to
      apply changes twice (to compiler readable and to .PDF) all but
      guarantees that errors will creep in, particularly given that only the
      non-.PDF version can be machine checked.
  • Reported: I2JAV 1.0 — Mon, 27 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Mapping of IDL names that clash with java.lang.Object methods

  • Key: I2JAV11-73
  • Legacy Issue Number: 1734
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It appears that the IDL to Java mapping does not remap IDL identifiers
    that collide with the 9 method names defined for java.lang.Object; i.e.
    "clone", "equals", "finalize", "getClass", "hashCode", "notify",
    "notifyAll", "toString" and "wait"
    If a CORBA/Java server attempts to implement IDL operations with these
    names, it will either overload the Object operations, or give compilation
    errors (for Object methods declared as "final"). In either case, it looks
    like the IDL mapping should treat these names as if they were Java
    reserved words.

  • Reported: I2JAV 1.0 — Sat, 25 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Local stubs

  • Key: I2JAV11-76
  • Legacy Issue Number: 1739
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: - There is no example given in the mapping. I forget the exact problem,
    but some guesswork was required to work out exactly what code should be
    generated.

    • Why should the class name be specified? Surely it is up to the Helper
      to generate instances and thus decide which to create? (I note that
      recent changes have altered this somewhat, with ORBs apparently now free
      to bypass the Helper altogether and instantiate stubs directly. This
      seems like a bad idea.)
    • Why are local stubs disctinct? Given that a local stub has to deal
      with the possibility of an object ceasing to be local, and that it would
      be desirable for a non-local stub to discover that an object has become
      local and make use of that knowledge, surely it is up to ORB
      implementors to have their Helpers make whatever choices are appropriate
      to instantiate appropriate stubs. The way that the mapping currently
      stands, it does not seem to be possible to implement a stub that will
      cope with objects moving into and out of the current JVM and still
      remain compliant.
    • _is_local is redundant. The success/failure of preinvoke is the acid
      test. This also avoids races: if preinvoke suceeds then you know that
      the object is available for a single local invocation. If _is_local
      suceeds, then you know nothing of the sort, you have to invoke preinvoke
      anyway, and if it fails, invoke remotely anyway.
  • Reported: I2JAV 1.0 — Mon, 27 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Object._request variants are unspecified

  • Key: I2JAV11-75
  • Legacy Issue Number: 1738
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is possible that some part of the C++ mapping is intended to apply
    here, but even so, the Java mapping should stand independantly of the
    C++ mapping. Requiring Java developers (of ORBs and of applications) to
    know C++ and the C++ mapping seems excessive

  • Reported: I2JAV 1.0 — Mon, 27 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Changes to Java fixed type mapping

  • Key: I2JAV11-70
  • Legacy Issue Number: 1730
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current mapping for fixed type was written with the intention
    of supporting JDK 1.0.2 as well as JDK 1.1. Recent changes in the
    Java RTF and other recently adopted submissions (Java to IDL) have
    introduced a JDK 1.1 requirement in the Java mapping which make
    it possible to implement certain operations on fixed types in a
    type safe manner instead of the current specification.

  • Reported: I2JAV 1.0 — Fri, 24 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Changes to Java interface mapping

  • Key: I2JAV11-72
  • Legacy Issue Number: 1732
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This issue is based off of discussion with engineers at Sun.

    The recent portability submission introduced changes to the
    mapping for Java interfaces. This change was to generate both
    a signature interface and an operations interface. The signature
    interface is defined to extend the operations interface. While
    the need for both interfaces is clear, it is not clear if the
    relationship between the two interfaces is necessary. The change
    requires additional classes to be downloaded for the remote stub
    case and could potentially impact performance.

  • Reported: I2JAV 1.0 — Fri, 24 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Java mapping"s use of _this()

  • Key: I2JAV11-71
  • Legacy Issue Number: 1731
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current Java mapping for the POA defines semantics for _this()
    (also known as _this_object()) which are consistent with the C++
    mapping. However, the current specification for
    org.omg.PortableServer.Servant does not support those semantics.

  • Reported: I2JAV 1.0 — Fri, 24 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

OutputStream semantics question

  • Key: I2JAV11-69
  • Legacy Issue Number: 1724
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: When an InputStream is created by an OutputStream, is it permitted to
    continue to write anything more to the OutputStream?

    If this is not permitted, we should presumably lock out the OutputStream
    and throw an exception if another write_X is attempted after the
    create_input_stream.

    If this is permitted, we need to say whether or not the things written
    to the OutputStream after the InputStream is created show up in the
    InputStream or not.

  • Reported: I2JAV 1.0 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

New stream based stubs and location forward

  • Key: I2JAV11-68
  • Legacy Issue Number: 1722
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The new portable stream-based stubs for the Java language mapping
    do not properly handle location forwards properly. The ORB must
    be able to give some indication to the ORB that it must remarshal
    in case the ORB receives a locate forward or object forward message.
    The remarshalling is required because the object key in the request
    message may have changed and the alignment will be incorrect.

  • Reported: I2JAV 1.0 — Wed, 22 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Add Any.extract_Streamable()

  • Key: I2JAV11-67
  • Legacy Issue Number: 1705
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: org.omg.CORBA.portable.Streamable extract_Streamable();

    As the name of the operation suggests it allows any Streamable
    value inserted into an Any using insert_Streamable() to be
    extracted. A BAD_INV_ORDER exception will be thrown if the
    operation is invoked on an Any that doesn"t already contain a
    Streamable.

    The addition of this method allows for a more efficient Any
    implementation especially when collocation and DII/DSI is in use.

  • Reported: I2JAV 1.0 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Proposed change sto IDL/Java mapping

  • Key: I2JAV11-66
  • Legacy Issue Number: 1704
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The following proposal describes changes to the IDL/Java mapping
    that will allow values to be marshalled and demarshalled more
    efficiently in both the "forward mapping" and "reverse mapping"
    cases. It also allows other IDLEntity types to be marshalled and
    demarshalled more efficiently in the reverse mapping case, and it
    fixes some problems in the existing spec with marshalling and
    demarshalling values and boxed strings.

  • Reported: I2JAV 1.0 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

orb.properties file issue

  • Key: I2JAV11-65
  • Legacy Issue Number: 1703
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    The search order followed by ORB.init when looking for the names
    of the ORB and ORB singleton classes does not allow a user to
    install a specified ORB as the default ORB, overriding the
    hardcoded default behavior. It is possible to override the
    hardcoded default by setting system properties, but this requires
    running the java command with an explicit -D option every time,
    which is awkward.

    I propose that an additional step be added to this search order,
    between "check in the System properties" and "fall back on
    hardcoded default behavior".

  • Reported: I2JAV 1.0 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Mapping of IDL constants to Java

  • Key: I2JAV11-64
  • Legacy Issue Number: 1701
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The IDL to Java mapping specifies that IDL constants are mapped
    to public static final fields within a Java interface. Examples
    are shown that include "public static final" modifiers for these
    fields.

    The Java Language Specification (Gosling/Joy/Steele) states in
    section 9.3 that "Every field declaration in the body of an
    interface is implicitly public, static, and final. It is permitted,
    but strongly discouraged as a matter of style, to redundantly
    specify any or all of these modifiers for such fields."

    I propose that the text and examples be changed to remove the
    explicit "public static final" modifiers.

  • Reported: I2JAV 1.0 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Proposed change to orb.init

  • Key: I2JAV11-63
  • Legacy Issue Number: 1696
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: How should ORB.init() be fixed?

    ORB.init() should try to find an ORB class in the following order:

    1. Try loading the class using Class.forName(String className) – this is
    to take into account the possibility that the ORB implementation class
    is in the core (for example: com.sun.CORBA.iiop.ORB). If that fails,
    2. Try loading the class using Class.forName(String className, boolean
    initialize, ClassLoader cl), where cl ==
    ClassLoader.getSystemClassLoader(). In the case of an applet, cl ==
    applet.getClass().getClassLoader().

    For sophisticated users who might have a well-behaved ClassLoader that knows
    how to load the ORB implementation, it might be necessary to have a new
    ORB.init() that takes a ClassLoader as an argument. For example:

    ORB.init(String[] args, Properties props, ClassLoader cl);

    In this case, ORB.init() would load the class using the class loader that
    was passed by the user instead of the system class loader.

  • Reported: I2JAV 1.0 — Mon, 20 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Does object reference == ObjectImpl?

  • Key: I2JAV11-62
  • Legacy Issue Number: 1672
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The issue is whether or not code that calls the _this_object method
    of the org.omg.PortableServer.Servant class (which is declared to
    return an org.omg.CORBA.Object type) can assume that the result
    of calling _this_object can be safely cast to ObjectImpl.

    The decision of the RTF was that this is a safe assumption, but no
    change is necessary to the spec because it is already clearly stated
    that all stubs (object references) must be subclasses of ObjectImpl.

  • Reported: I2JAV 1.0 — Mon, 13 Jul 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:36 GMT

Callback issue

  • Key: I2JAV11-61
  • Legacy Issue Number: 1586
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: IIOP only permits requests to flow in the direction that the underlying
    connection was opened. The Java sandbox only allows outbound
    connections. Consequently we are left with a situation where applets can
    only ever make outbound requests, callback objects can never be
    registered. For any sort of asynchronous notification pattern, this is a
    problem. (There is an obvious workaround with blocking calls and a
    waiting thread, but this sort of interaction should never be required of
    application developers.)

    Most products provide a means to handle callbacks in this situation,
    presumably via non-standard mechanisms, I am yet to explore how.

    It would seem that, from the point of view of those involved in this
    RTF, a standardised means to handle reverse calls over IIOP would be
    beneficial.

    Is my reasoning flawed? Is there a revision going on elsewhere to
    address this? Is there interest in standardising this?

  • Reported: I2JAV 1.0 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

org.omg.CORBA.UserException class not specified

  • Key: I2JAV11-60
  • Legacy Issue Number: 1583
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The current mapping does not specify the org.omg.CORBA.UserException
    class. I propose the mapping below. All generated user exception
    constructors should then pass the exception"s id to the UserException
    string constructor. The toString() method on the exception will then
    output the Exception"s type id.

    package org.omg.CORBA;

    public abstract class UserException extends java.lang.Exception
    {
    public UserException()
    {
    }

    public UserException(String r)

    { super(r); }

    }

  • Reported: I2JAV 1.0 — Fri, 26 Jun 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Section 7.1.3 of Java to IDL mapping

  • Key: I2JAV11-59
  • Legacy Issue Number: 1577
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Section 7.1.3 of the Java to IDL mapping specifies new methods
    _request, _invoke, and _releaseReply to be added to both
    org.omg.CORBA.portable.ObjectImpl and org.omg.CORBA.portable.Delegate.

    There is an existing convention that methods on ObjectImpl have
    leading underscores but the corresponding methods on Delegate do not.

    I propose that the new methods on Delegate be named request, invoke,
    and releaseReply to confirm to this existing convention.

  • Reported: I2JAV 1.0 — Wed, 24 Jun 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Helper classes are only for user defined IDL types

  • Key: I2JAV11-58
  • Legacy Issue Number: 1536
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The Java Language Mapping mandates Helper classes for user defined IDL
    types but does not say Helper classes are ONLY for user defined IDL types.
    Please let us all know whether the ObjectHelper class is standard or not.

  • Reported: I2JAV 1.0 — Tue, 23 Jun 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Discriminated Union value issue

  • Key: I2JAV11-57
  • Legacy Issue Number: 1385
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: An IDL Discriminated Union has a discriminator of some type. The
    discriminator is permitted to take any value allowed by its type -
    nothing in the CORBA spec constrains the discriminator"s value to be
    those of the branch labels present in the union or just one catch-all
    default. For this reason, CORBA 2.2, section 3.8.2 defines a Discriminated
    Union"s value as follows: <example>So, if I were to create a foo and set the discriminator to 74, someone
    receiving this instance from me should be able to discern that the
    discriminator"s value was set to 74.

    As it stands, the IDL->Java mapping provides for discovering the value
    of the discriminator, so if some other ORB sent me a foo with the
    discriminator set to 74 I could discern this, but as far as I can tell
    from reading the current IDL->Java mapping (CORBA 2.2 - no relevant
    changes appear to be present on orbos/98-03-10) there is no way that I
    could set the discriminator"s value to 74.

  • Reported: I2JAV 1.0 — Tue, 19 May 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    closed issue

  • Updated: Fri, 6 Mar 2015 21:35 GMT

Naming issues for new ORB methods

  • Key: I2JAV12-19
  • Legacy Issue Number: 4748
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    As we all know, naming things is the hardest part.
    I am writing this as a general reply to the concerns that Simon Nash,
    Ann Dalton, and Franz Hauck have raised about packaging of new APIs.
    This is also relevant to the discussion Simon and I had about a
    relevant JCK rule (I'm still waiting on details from the JCK team at
    Sun on that one).

    I want to focus on just the ORB methods here, which seems to be the
    major problem, although the same ideas should apply elsewhere.

    The APIs that we are talking about are:

    New in CORBA_2_5.ORB (which extends CORBA_2_3.ORB) :
    ORB.id
    ORB.create_local_interface_tc
    ORB.register_initial_references

    In CORBA_2_3.ORB:
    ORB.register_value_factory
    ORB.unregister_value_factory
    ORB.lookup_value_factory
    ORB.get_value_def
    ORB.set_delegate

    This affects the following issues:
    4741 (register_initial_reference)
    4559 (create_local_interface_tc)
    moving CORBA_2_3 APIs into CORBA (I have not yet filed this)
    4699 (is_a support on local interfaces)
    need support for ORB::id (no issue for this yet)

    (4699 does not involved ORB methods, but it's the same issue, because
    vendors have shipped PI implementations before is_a support became
    necessary on local interfaces).

    Here are the goals I would like to achieve:

    1. Add new methods to the CORBA ORB so that users have a better API.

    2. Make CORBA_2_3::ORB methods available in CORBA::ORB.

    3. Still support user code using the CORBA_2_3::ORB methods.

    4. Allow JDK 1.3 licensees to implement the new features legally.

    5. Allow CORBA 2.3 ORB implementations to work unchanged with the
    CORBA 2.5 APIs.

    Proposal:

    1. Add all the CORBA 2.5 methods to CORBA.ORB as concrete methods that
    throw NO_IMPLEMENT.

    2. Also add all the new methods to CORBA_2_5.ORB as concrete methods
    that throw NO_IMPLEMENT.

    3. Copy all of the CORBA_2_3 methods to CORBA.ORB (all of which are
    currently concrete methods that throw NO_IMPLEMENT).

    To evaluate my proposal, let's consider the different combinations of
    JDK and CORBA versions:

    • JDK:
      1.3: No endorsed classes mechanism, CORBA 2.3 ORB
      1.4: Endorsed classes mechanism, CORBA 2.3 ORB
      1.5: Endorsed classes mechanism, CORBA 2.5 ORB
    • CORBA:
      2.3: the current standard in JDK 1.3, and also ptc/01-10-20
      2.5: the next version, probably aligned with the CORBA 3.0
      standards

    Results:

    CORBA 2.5 on JDK 1.5:
    This is what Sun will ship in JDK 1.5.
    Other vendors can use the files in JDK 1.5, or replace with a
    later version if desired.
    User writes new code to CORBA.ORB.
    User code written to CORBA_2_3.ORB and CORBA_2_5.ORB still works.

    CORBA 2.5 on JDK 1.4:
    Vendor swaps in CORBA 2.5 files.
    User writes new code to CORBA.ORB.
    User code written to CORBA_2_3.ORB CORBA_2_5.ORB still works.

    CORBA 2.5 on JDK 1.3:
    Vendor adds new CORBA_2_5 package. CORBA.ORB is unchanged.
    User codes to CORBA_2_5.ORB
    User code written to CORBA_2_3.ORB still works.

    CORBA 2.3 on JDK 1.5:
    Vendor ORB works unchanged: new 2.5 features are not supported.

    CORBA 2.3 on JDK 1.4:
    This is what Sun ships in JDK 1.4.
    Vendor ORB works unchanged.
    User code works unchanged.

    CORBA 2.3 on JDK 1.3:
    This is the baseline that everyone has

  • Reported: I2JAV 1.1 — Fri, 14 Dec 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate joint resolution changes and close issue

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

New issue on register_initial_reference

  • Key: I2JAV12-18
  • Legacy Issue Number: 4741
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The portable interceptors specification added a new method to the
    ORB for registering initial references. This method needs to
    be added to the standard org.omg.CORBA.ORB class.

    We should simply add the register_initial_reference method to
    org.omg.CORBA.ORB and not create another version of the ORB
    class for this purpose.

    Proposed Resolution: Incorporate edits and close issue

    Revised Text:

    In section 1.19.10
    in the PIDL section, add before resolve_initial_references:

    void register_initial_reference( in ObjectId identifier,
    in Object obj ) raises (InvalidName) ;

    in the Java section, add before resolve_initial_references:

    public void register_initial_reference( String id,
    org.omg.CORBA.Object obj ) throws InvalidName ;

    Also update the org.omg.CORBA.ORB class in the omg.zip file.

  • Reported: I2JAV 1.1 — Fri, 7 Dec 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate joint resolution changes and close issue

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

Make CORBA_2_3.ORB methods available in CORBA.ORB

  • Key: I2JAV12-21
  • Legacy Issue Number: 4750
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    It would be much better for CORBA users if the methods are currently
    in org.omg.CORBA_2_3.ORB were available in the org.omg.CORBA.ORB class.
    The best approach seems to be simply to copy the method definitions
    into the ORB class.

  • Reported: I2JAV 1.1 — Fri, 14 Dec 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate joint resolution changes and close issue

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

New issue: Error in resolution of issue 4699

  • Key: I2JAV12-20
  • Legacy Issue Number: 4749
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The resolution to issue 4699 introduced a new method in
    org.omg.CORBA.LocalObject as follows:

    abstract public String[] _ids() ;

    Unfortunately this causes a big problem for current users of
    portable interceptors: any user of PI who implements a local
    interface (for example ServerRequestInterceptor) according to the
    CORBA 2.5 spec will have written code that will not function correctly
    under the CORBA 3.0 revision, due to the addition of this new abstract
    method.

    The fix for this is simple: just change the _ids method to

    public String[] _ids()

    { return new String[0] ; }

    This causes the _is_a method to always return false for old implementations
    of local interfaces, which is a reasonable result, since old implementations
    were written before is_a support was available.

  • Reported: I2JAV 1.1 — Fri, 14 Dec 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate revised text and closed issue

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

attribute exceptions

  • Key: I2JAV12-23
  • Legacy Issue Number: 4793
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The CCM (ptc/01-11-03) has added exceptions to attributes.
    The IDL to Java mapping needs to be updated to reflect this addition.
    Also, the mapping currently says essentially nothing about the mapping of
    exceptions
    on operations or attributes in any context.

    Proposed revised text:

    In section 1.13.2, replace the paragraph

    The mapped Java class contains abstract method definitions that correspond
    to the operations and attributes defined on the value type in IDL.

    with

    The mapped Java class contains abstract method definitions that correspond
    to the operations and attributes defined on the value type in IDL.
    Attributes
    are mapped in the same way as in interfaces, to modifer and accessor
    methods.
    Exceptions are mapped as follows:

    1. If an operation raises exceptions, then the corresponding Java method
    must throw
    Java exceptions corresponding to the listed IDL exceptions.

    2. If a readonly attribute raises exceptions, then the Java read accessor
    method must throw
    Java exceptions corresponding to the listed IDL exceptions.

    3. If an attribute has a getRaises clause, the the Java accessor method must
    throw Java exceptions corresponding to the listed IDL exceptions.

    4. If an attribute has a setRaises clause, the the Java modifier method must
    throw Java exceptions corresponding to the listed IDL exceptions.

    In section 1.12.1, replace the third paragraph with the following two
    paragraphs:

    The Java operations interface contains the mapped operation signatures.
    If an operation raises exceptions, then the corresponding Java method must
    throw
    Java exceptions corresponding to the listed IDL exceptions.

    The Java signature interface extends the operations interface, the (mapped)
    base org.omg.CORBA.Object, as well as org.omg.portable.IDLEntity.
    Methods can be invoked on the signature interface. Interface inheritance
    expressed in IDL is reflected in both the Java signature interface and
    operations interface hierarchies.

    In section 1.12.1, insert after the sixth paragraph:

    Attribute exceptions are mapped as follows:

    1. If a readonly attribute raises exceptions, then the Java read accessor
    method must
    throw Java exceptions corresponding to the listed IDL exceptions.

    2. If an attribute has a getRaises clause, the the Java accessor method must
    throw Java exceptions corresponding to the IDL exceptions listed in the
    getRaises clause.

    3. If an attribute has a setRaises clause, the the Java modifier method must
    throw Java exceptions corresponding to the IDL exceptions listed in the
    setRaises clause.

  • Reported: I2JAV 1.1 — Tue, 18 Dec 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incoporate the revised text and close the issue

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

exceptions on valuetype initializers

  • Key: I2JAV12-22
  • Legacy Issue Number: 4792
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    The CORBA components updates to the Interface Repository defined in ptc/01-11-03
    include the addition of exceptions on valuetype initializers. There is a
    separate
    issue that is required to change the IDL grammar and other text in chapter 3
    to include this. For the purposes of discussion in this issue,
    I am assuming that the appropriate syntax is:

    <init_dcl> ::= "factory" <identifier> "(" [ <init_param_decls> ] ")" [
    <raises_expr> ] ";"

    Proposed revised text:

    In section 1.13.2, replace the paragraph that begins "The value type's generated
    value factory" with:

    The value type's generated value factory interface extends
    org.omg.CORBA.portable.ValueFactory and contains one method corresponding to
    each
    factory declared in the IDL. The name of the method is the same as the name
    of
    the factory, and the factory arguments are mapped in the same way as in
    parameters
    are for IDL operations. If the factory raises exceptions, then the
    corresponding
    Java method must throw Java exceptions corresponding to the listed IDL
    exceptions.

  • Reported: I2JAV 1.1 — Tue, 18 Dec 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate the revised text and close the issue

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

OMG Java Language Mapping and the use of Java null

  • Key: I2JAV12-24
  • Legacy Issue Number: 4794
  • Status: closed  
  • Source: Anonymous
  • Summary:

    We here at Nortel Networks use CORBA extensively. However, we
    have a question regarding the use of Java null, and the most
    recent OMG spec seems to have some mixed messages.

    Section 1.4.1.5 has been there for some time, and it is pretty
    clear what is legal and what is illegal.

    However, in section 1.4.1.4, it seems to say that in the Holder
    class, the Java Strings are initialized to null rather than "".

    We are asking this question because it is affecting one of
    our software products. We are getting org.omg.CORBA.BAD_PARAM
    exception once in a while.

    We are using Sun's JRE ORB(JRE 1.3.1_01).

  • Reported: I2JAV 1.1 — Tue, 18 Dec 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    close issue no change

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

Section 5.14 and 6.11 IDL/Java Language mapping

  • Key: I2JAV11-35
  • Legacy Issue Number: 888
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the class definition for Any there is only
    insert_Streamable(...), but no
    extract_Streamable(...). How do you extract
    streamables?

  • Reported: I2JAV 1.0b1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Duplicate or Merged — I2JAV 1.0
  • Disposition Summary:

    duplicate, issue closed

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

Problems with IDL unions mapped to Java

  • Key: I2JAV11-34
  • Legacy Issue Number: 799
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I have found a problem with the Java to IDL mapping (97-03-01) in the area of Unions. The problem is that the Java-idl mapping does not provide any means by
    which the user can set the value of the union to be one of the non
    branch members of the enum such as B.

  • Reported: I2JAV 1.0b1 — Fri, 28 Nov 1997 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    resolved/closed

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

ImplementationDef should be an abstarct class

  • Key: I2JAV11-37
  • Legacy Issue Number: 891
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue, resolved

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

Add missing UnknownUserException

  • Key: I2JAV11-36
  • Legacy Issue Number: 890
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue, resolved

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

Colocated calls in Java

  • Key: I2JAV12-17
  • Legacy Issue Number: 4701
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    Note: this is NOT issue 3754, but it is related. A new issue is needed
    as described below:
    --------------------------------------------------------------------------
    Issue 3754 (colocated call optimization and portable interceptors) was
    raised some time ago by Harold Carr. This issue discusses the problems
    of supporting portable interceptors for RMI-IIOP calls when the colocated
    call optimization is used. The basic issue is that there is no way for the
    ORB to detect whether a local dispatch to a servant completed normally or
    completed by throwing an exception. This problem exists because the
    current is_local/servant_preinvoke/servant_postinvoke mechanism has no
    way to report normal or exceptional completion of a local dispatch.

    The same problem arises in the IDL stub case as well.
    Both Java mappings can share the same solution here, but a solution requires
    changing part of the portable stub API which is shared by both mappings.

    In the discussion of 3754, Simon Nash asked to reassign the issue from the
    Java to IDL RTF to the Java mapping RTF. We really need two separate issues
    here. I propose that we do the following:

    1. Move 3754 back to the Java to IDL RTF since Harold wrote the issue with the
    RMI-IIOP mapping in mind.

    2. Create a new Java mapping issue for the same problem. The bulk of this message
    should be the new issue.

    Both RTFs will need to consider the issues. The new Java mapping issue will need
    to propose extensions to the portable stub APIs and document the required changes
    in the IDL based stubs, while the resolution to 3754 will need to adopt the
    same new portable stub API and document the required changes in the RMI-IIOP stubs.

    To start a discussion, here is my initial proposal for solving this problem in
    the Java mapping RTF:

    We need to add methods to report the result of the local dispatch. I propose that
    we extend the portable definition of ServantObject as follows:

    abstract public class ServantObjectExt extends ServantObject

    { abstract public void normalCompletion() ; abstract public void exceptionalCompletion( Throwable thr ) ; }

    Another alternative is to extend the Delegate class instead. I prefer the
    ServantObject approach because the method signatures are simpler:
    adding these methods on the Delegate would require passing ServantObject
    as an argument, since multiple threads could be simultaneously invoking
    methods on the same object reference, which would share the same delegate.

    Making this change makes it necessary to consider what happens in
    mixed versions.

    Old stub, Old ServantObject:
    no change

    New stub, new ServantObject:
    stub always invokes either normalCompletion or
    exceptionalCompletion, so the ORB has enough information to correctly implement
    portable interceptor behavior. Note that a location forward (e.g. from a
    ServantManager) is not a problem today, since it happens inside of
    _servant_preinvoke,
    which allows the ORB to correctly handle that case.

    New stub, old ServantObject:
    If a new stub is written to do an instanceof check on
    the ServantObject it gets from _servant_preinvoke, it can correctly determine
    whether or not to call the new methods. There are a number of possibilities
    for the check:

    1. Just use (so instanceof ServantObjectExt) and rely on the ServantObjectExt
    class to be defined somewhere in the environment. New stubs that wanted to
    be compatible with old ORBs would need to be packaged somehow with this
    class in their classpath. The stubs would need the ServantObjectExt class
    both at compile time and at runtime.

    2. A stub could be written to entirely use reflection for the instanceof check
    and the method invocation. This would avoid the requirement to have
    ServantObjectExt in the classpath, but would require more code in the stubs,
    plus run a little slower (probably about 2X slower in JDK 1.4, but in
    earlier JDKs the penalty could easily be 10-20X).

    Old stub, new ServantObject:
    In this case, neither method is ever invoked, so the
    ORB can tell the difference between normal completion and an old stub.
    The PI implementation in this case is free to do anything. However, probably the
    best approach is to extend RequestInfo::reply_status with a new value
    PortableInterceptor::UNKNOWN. Then the local case would always use the
    interceptor points send_other and receive_other with a reply_status set to
    UNKNOWN. This extension requires a new core issue.

    It is worth noting here that the PI change makes it reasonable to consider simply
    changing PI, and avoid changing the ServantObject API and 2 language mappings.
    In this case, a user of PI cannot tell what is happening with colocated calls
    in a very basic sense: did the operation complete successfully or not?
    Many applications of PI (for example, transactions and security) often do not
    require the use of PI in the colocated case. However, one important application
    is best done this way: logging/tracing in a complex system. I believe this
    argues strongly for extending the mapping, since a log entry that cannot distinguish
    success from failure is of little use.

    With the instanceof check, the local code for the sample stub then becomes
    (from page 1-114 of ptc/01-06-04):

    org.omg.CORBA.portable.ServantObject _so =
    _servant_preinvoke( "length", _opsClass ) ;
    if (_so == null)
    continue ;

    Example.AnInterfaceOperations _self =
    (Example.AnInterfaceOperations)_so.servant ;

    try

    { int result = _self.length(s) ; if (so instanceof ServantObjectExt) ((ServantObjectExt)so).normalCompletion() ; return result ; }

    catch (Throwable thr)

    { if (so instanceof ServantObjectExt) ((ServantObjectExt)so).exceptionalCompletion( thr ) ; throw thr ; }

    finally

    { _servant_postinvoke( _so ) ; }

    Note that the instanceof checks are quite fast in modern JVMs,
    so I don't think this adds significantly to the overhead of the operation.
    A reflective solution is also possible, but I am not including that here.
    In any case, the precise code generation should be left to the implementation.
    All that the spec should require is:

    1. If the invocation on the servant completes without throwing an exception,
    then the stub code must call servant.normalCompletion after the invocation
    completes.

    2. If the invocation on the servant throws exception exc, then the stub code
    must call servant.exceptionalCompletion( exc ) after the invocation completes.

    In either case, the servant completion call must occur before the
    _servant_postinvoke call.

  • Reported: I2JAV 1.1 — Mon, 12 Nov 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate the revised text, make corresponding changes in the standard source files, close

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

is_a support in Java for local interfaces

  • Key: I2JAV12-16
  • Legacy Issue Number: 4699
  • Status: closed  
  • Source: Oracle ( Ken Cavanaugh)
  • Summary:

    With the recent adoption of the resolution to issue 4623 (support
    is_a on local interfaces), we need to answer the question of how
    is_a is implemented in Java. I would like to create a new
    Java RTF issue for this, and propose a solution to hopefully start
    some discussion on this issue.

    Proposed solution:

    Change org.omg.CORBA.LocalObject to an abstract class as follows:

    abstract public class LocalObject implements org.omg.CORBA.Object {

    ...

    abstract public String[] _ids() ;

    public _is_a( String repository_id)
    {
    String[] ids = _ids() ;
    for (int i=0; i<ids.length; i++)

    { if (repository_id.equals( ids[i] ) return true ; }

    return false ;
    }
    }

    Then the IDL compiler generates a local implementation base class as follows:

    class <typename>LocalBase extends org.omg.CORBA.LocalObject
    implements <typename> {

    private String[] _type_ids() =

    { ... }

    public String[] _ids()

    { return _type_ids.clone() ; }

    }

    where _type_ids contains a list of repository IDs of the local
    interface and all of its superinterfaces in order from most derived
    to org.omg.CORBA.Object.

    The implementer of a local interface then simply writes

    class MyImpl extends <typename>LocalBase

    { // implement the declared methods }

    and instantiates the local interface by calling

    new MyImpl( ... ).

    Note: a full proposed resolution to this issue should include a static
    delegate for LocalObject, so that the implementation of _is_a and any
    other non-trivial methods can be made pluggable in the JDK. I will raise
    another issue for get_interface_def after we have an issue number for
    this issue.

  • Reported: I2JAV 1.1 — Mon, 12 Nov 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate the revised text, make corresponding changes in the standard source files, close

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

support for local objects

  • Key: I2JAV12-15
  • Legacy Issue Number: 4624
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The CORBA spec Section 3.7.6.1 includes the following:

    • The usage of client side language mappings for local types shall be
      identical to
      those of equivalent unconstrained types.
    • Language mappings shall specify server side mechanisms, including base
      classes
      and/or skeletons if necessary, for implementing local objects, so that
      invocation
      overhead is minimized.
    • Invocations on local objects are not ORB mediated. Specifically,
      parameter copy
      semantics are not honored, interceptors are not invoked, and the execution
      context
      of a local object does not have ORB service Current object contexts that
      are
      distinct from those of the caller.

    The IDL to Java spec section Section 1.12 Mapping for Interface,
    subsection Local Interfaces states that:

    • A local interface <typename> is mapped to interface <typename> which
      extends <typename>Operations, [... which an implementation can extend]
    • A holder class is generated as for non-local interfaces.
    • A helper class is also generated according to the normal rules, see
      Section 1.5,
      "Helpers", on page 1-13.
      No mention is made of Stubs, Ties or skeletons.

    Section 1.20.2.1 Mapping for Local Interface states:
    In the Java language mapping, the LocalObject class is used as a base class
    for
    implementations of a local interface.

    I take it from the above that, quite reasonably, since "invocations on
    local objects are
    not ORB mediated", skeletons/Ties are not required for Java.

    I can't see why Stubs should be required either, but
    Section 1.21.6.1 Stub/Skeleton Architecture states:
    Stubs support both local invocation and remote invocation, except in the
    following
    case: The stub is implementing an IDL interface that may only be invoked
    locally (e.g.,
    PortableServer::POA). In this case, the stub may choose to implement only
    local
    invocation.
    which suggests that Stubs may be required (although the POA interface is
    constrained
    to be invoked locally, but not actually defined as local - is that the
    difference?)

  • Reported: I2JAV 1.1 — Mon, 22 Oct 2001 04:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate revised text and close issue

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

Missing elements of the local mapping

  • Key: I2JAV12-14
  • Legacy Issue Number: 4549
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    In the latest spec of the idl-to-java mapping, I don't see a mapping for
    create_local_interface_tc() on the ORB. Also missing is
    tk_local_interface in TCKind. These need to be fixed quickly as this
    leaves the local mapping incomplete in Java.

    Proposal:

    Section 1.19.9:

    Add tk_local_interface to TCKind
    enum TCKind

    { tk_null, tk_void, tk_short, tk_long, tk_ushort, tk_ulong, tk_float, tk_double, tk_boolean, tk_char, tk_octet, tk_any, tk_TypeCode, tk_Principal, tk_objref, tk_struct, tk_union, tk_enum, tk_string, tk_sequence, tk_array, tk_alias, tk_except, tk_longlong, tk_ulonglong, tk_longdouble, tk_wchar, tk_wstring, tk_fixed, tk_value, tk_value_box, tk_native, tk_abstract_interface, tk_local_interface }

    ;

    // java (add at the appropriate location)

    public static final int _tk_local_interface = 33;
    TCKind tk_local_interface = new TCKind(_tk_local_interface);

    Section 1.19.10
    Copy the new ORB PIDL from CORBA 2.4 spec (which basically adds)

    TypeCode create_local_interface_tc(
    in RepositoryId id,
    in Identifier name
    );

    and add to the Java section:

    package org.omg.CORBA_2_4;
    import org.omg.CORBA.TypeCode;
    public abstract class ORB extends org.omg.CORBA_2_3.ORB

    { public abstract TypeCode create_local_interface_tc(String id, String name); }
  • Reported: I2JAV 1.1 — Thu, 30 Aug 2001 04:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate the revised text and close issue. Also make corresponding changes in the standard source

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

Any"s and Exceptions

  • Key: I2JAV11-56
  • Legacy Issue Number: 1242
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Section 23.13, the signature for insert_Object() is given as,

    // throw excep when typecode inconsistent with value
    abstract public void insert_Object(
    org.omg.CORBA.Object o, org.omg.CORBA.TypeCode t)
    throws org.omg.CORBA.MARSHAL;

    Does this mean if an incorrect TypeCode is passed, eg. tk_short, that a
    MARSHAL Exception must be thrown or could a BAD_PARAM Exception
    be thrown.

    Also, I assume read_value() is meant to insert a complex IDL type into
    an Any ?
    If so, read_value() is supposed to throw a MARSHAL Exception if the
    typecode
    is inconsistent with the value. Does this mean that if a short has been
    written to the
    stream, but the stream is passed with a tk_sequence typecode, then an
    Exception
    should be thrown by read_value() ?.

  • Reported: I2JAV 1.0b1 — Mon, 27 Apr 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

Any.insert_Object()

  • Key: I2JAV11-55
  • Legacy Issue Number: 1167
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In Section 23.13, the signature for insert_Object() is given as,

    // throw excep when typecode inconsistent with value
    abstract public void insert_Object(
    org.omg.CORBA.Object o, org.omg.CORBA.TypeCode t)
    throws org.omg.CORBA.MARSHAL;

    Does this mean if an incorrect TypeCode is passed, eg. tk_short, that a
    MARSHAL
    Exception must be thrown or could a BAD_PARAM Exception be thrown.

  • Reported: I2JAV 1.0b1 — Wed, 22 Apr 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

Chapter 9.8.1 Local stubs-bug

  • Key: I2JAV11-54
  • Legacy Issue Number: 1143
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Chapter 9.8.1
    Says "Local stubs are defined to be direct base classes of remote stubs"
    Does it matter? It is the opposite way as proposed in the drawing in
    chapter 6.4

    MORE FAR-FETCHED IDEA

    What if the Operations interface would not contain the inheritance
    relationship? Wouldn"t that be a step in the direction of being able
    to implement independent interfaces with one class. (To be
    functional this would need matching changes in the tie class)

  • Reported: I2JAV 1.0b1 — Thu, 16 Apr 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

POA_Interface bug

  • Key: I2JAV11-53
  • Legacy Issue Number: 1142
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Chapter 5.2.4
    class POA_<interface_name> is supposed to implement
    <interface_name>Operations.

    However neither specification nor the example contain any
    operations method. The class also are not specified abstract.

  • Reported: I2JAV 1.0b1 — Thu, 16 Apr 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

Spec insufficient in section 5.2.1 - Reserved Names

  • Key: I2JAV11-52
  • Legacy Issue Number: 632
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Reserved words seen as IDL identifiers be prepended by an underscore. Insufficient for Holder, Helper, Package in case where two or three of these strings appear in single identifier

  • Reported: I2JAV 1.0b1 — Wed, 23 Jul 1997 04:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    Clarify the IDL Name conflict resolution rules to resolve this case. Also change the naming rules

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

CORBA::DATA::CONVERSION exception for IDL types wchar/wstring

  • Key: I2JAV11-47
  • Legacy Issue Number: 908
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: This specification defines CORBA::DATA_CONVERSION exception for IDL
    types char/string, but does not define same exception for IDL types
    wchar/wstring. However, in the CORBA 2.1, IDL types wchar/wstring can
    handle any codeset beside Unicode (see section "10.7 Code Set Conversion"
    in CORBA 2.1) as well as IDL types char/string. Therefore, data
    conversion error may occur between IDL types wchar/wstring and Java
    types char/java.lang.String.

  • Reported: I2JAV 1.0b1 — Fri, 16 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

Current mapped incorrectly in Java language mapping

  • Key: I2JAV11-46
  • Legacy Issue Number: 907
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:
    In 2.1 current became a regular IDL interface, so its mapping needs to
    change.
    Proposed Change:
    delete section 23.16.14 on current

  • Reported: I2JAV 1.0b1 — Thu, 15 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

Clarify exact list of methods available on singleton orb

  • Key: I2JAV11-45
  • Legacy Issue Number: 899
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

No INV_NO_RESPONSE possible in Java DII

  • Key: I2JAV11-51
  • Legacy Issue Number: 1381
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is no Flags argument in the create_request operations
    as mapped from PIDL to Java. This means that there is no
    way to create a request with INV_NO_RESPONSE. Therefore,
    you cannot do oneway invocations in Java DII without the ORB
    having to consult the Interface Repository (clearly
    unnacceptable).

  • Reported: I2JAV 1.0b1 — Mon, 18 May 1998 04:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed/resolved

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

Reserved names

  • Key: I2JAV11-50
  • Legacy Issue Number: 1090
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The list of java keywords provided is an old one.
    > Should this be updated to the following list?
    > abstract boolean break
    > byte byvalue case cast catch char
    > class const continue default do double
    > else extends final finally float for
    > future generic goto if implements import
    > inner instanceof int interface long native
    > new null operator outer package private
    > protected public rest return short static
    > super switch synchronized this throw throws
    > transient try var void volatile while

  • Reported: I2JAV 1.0b1 — Fri, 20 Mar 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

Problem with IDL --> Java mapping for Unions

  • Key: I2JAV11-49
  • Legacy Issue Number: 919
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I have found what appears to be a short coming of the IDL to Java
    mapping for unions.
    Reading the CORBA V2.0 (July 1995) on pages 3-23 and 3-24 it indicates
    unions can have a value of the discriminator where there is not a case
    that matches the discriminator. The Trader Service specification has a
    great example of when this may be needed (in fact we are following this
    pattern in PIDS). The Java mapping for unions does not have a method or constructor for
    setting the discriminator when the discriminator does not correspond to
    at least one case label.

  • Reported: I2JAV 1.0b1 — Fri, 23 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

IDL/Java language mapping, section 5.14, 6.11

  • Key: I2JAV11-48
  • Legacy Issue Number: 909
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: In the class definition for Any there is only
    insert_Streamable(...), but no
    extract_Streamable(...). How do you extract
    streamables?

  • Reported: I2JAV 1.0b1 — Wed, 7 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

Clarify the use of return_value() before invoke() in DII

  • Key: I2JAV11-44
  • Legacy Issue Number: 898
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Clarify the use of return_value() before invoke() in DII.
    When using dii in Java (in portable stubs), it should be possible
    to call return_value() before invoke() in order to get the Any
    that will be associated with the return. It is then possible
    to insert a streamable, which when combined with fixing copy
    semantics for any"s, will enable a big performance improvement.

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed

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

Fix any"s to have implement copy semantics

  • Key: I2JAV11-43
  • Legacy Issue Number: 897
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: Issue: Fix any"s to have implement copy semantics, similar to C++

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed

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

input/output streams should extend java.io.streams

  • Key: I2JAV11-40
  • Legacy Issue Number: 894
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue, resolved

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

delegate field in ObjectImpl should be transient

  • Key: I2JAV11-39
  • Legacy Issue Number: 893
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue

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

create_list semantics not well defined

  • Key: I2JAV11-38
  • Legacy Issue Number: 892
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: create_list semantics are not well-defined in CORE and hence Java
    Language Mapping

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    resolved/closed

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

Make all basic Holders implement Streamable

  • Key: I2JAV11-42
  • Legacy Issue Number: 896
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    proposal approved, issue closed

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

_orb() is missing from ObjectImpl

  • Key: I2JAV11-41
  • Legacy Issue Number: 895
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary:

  • Reported: I2JAV 1.0b1 — Mon, 12 Jan 1998 05:00 GMT
  • Disposition: Resolved — I2JAV 1.0
  • Disposition Summary:

    closed issue, resolved

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

Mapping for Character and String Types

  • Key: I2JAV12-10
  • Legacy Issue Number: 4710
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    Sections 1.4.3 and 1.4.5 of the IDL to Java spec state that
    character and string range and bounds checking should be performed
    at marshal time. Since it is possible to receive IDL characters,
    e.g UTF16 surrogate pairs, that cannot, at present, be mapped to
    Java characters, could we clarify that this checking should be
    performed at both marshaling and demarshaling time, per section
    4.11.3.25 DATA_CONVERSION of the CORBA 2.5 spec which states:-
    This exception is raised if an ORB cannot convert the
    representation of data as marshaled into its native
    representation or vice-versa.

    Also, could anyone please comment on the meaning of the term
    "character set" in the sentence beginning "If the char falls
    outside the range defined by the character set,..." in section
    1.4.3. Does this refer to the TCS, NCS or both?

  • Reported: I2JAV 1.1 — Wed, 21 Nov 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate changes and close issue

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

Anys obtained using the singleton ORB

  • Key: I2JAV12-13
  • Legacy Issue Number: 5468
  • Status: closed  
  • Source: International Business Machines ( Ann Collins)
  • Summary:

    The IDL to Java spec is very clear about what methods can (and by
    implication what methods can't) be used with the singleton ORB and
    one of those is create_any(), however it does not mention any
    restrictions on the use of Anys obtained in this way. I think this
    leads to some inconsistencies and potential problems, for example:

    1. You cannot use create_output_stream() on the singleton ORB but
    you can use create_output_stream() on an Any obtained from the
    singleton. Where has this OutputStream come from? Presumably from
    the Any's singleton ORB (calling the orb() method on that OutputStream
    would return the ORB). At best this seems inconsistent.

    2. The problem is worse if you now marshal an object reference into
    that OutputStream then call create_input_stream() and try to read back
    the object reference using a read_Object() call. If the read_Object()
    is to return an object reference it needs to have an ORB to associate
    it with, but the only ORB available to it is the original Any's
    singleton ORB, which cannot support object references. Should this
    read_Object() succeed or fail? If it should succeed what ORB should
    it be using?

    There may be similar problems writing and reading other types to these
    streams.

    I feel the spec should state explicitly that operations on an Any
    created using the singleton ORB will be limited by the restrictions
    applicable to the singleton ORB.

    I don't think this would affect the intended use of Anys from the
    singleton, which is stated as being to describe union labels when
    creating a union TypeCode.

    Proposed resolution:

    Add the following sentence to the end of the subsection "Default
    initialization" in section 1.21.9.3 ORB Initialization Methods in
    the IDL to Java spec:

    Operations on an Any created using the singleton ORB will be
    limited by the restrictions applicable to the singleton ORB;
    those which require the use of a fully functional ORB will result
    in a NO_IMPLEMENT system exception.

  • Reported: I2JAV 1.1 — Tue, 9 Jul 2002 04:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    resolved

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

Default UnknownException behavior

  • Key: I2JAV12-12
  • Legacy Issue Number: 5465
  • Status: closed  
  • Source: Oracle ( Andrew Piper)
  • Summary:

    On page 133, bullet 3 reads:

    • If the CORBA system exception org.omg.CORBA.portable.UnknownException
    is thrown, then the stub does one of the following:
    • Translates it to org.omg.CORBA.UNKNOWN.
    • Translates it to the nested exception that the UnknownException contains.
    • Passes it on directly to the user.

    It is unfortunate that there is no recommended default since for RMI-IIOP at least, option (2) is by far to be preferred. I would like to change it therefore to add the text:

    "In order to preserve RMI semantics ORBs implementing the RMI-IIOP protocol should always translate it to the nested exception that the UnknownException contains"

  • Reported: I2JAV 1.1 — Fri, 12 Jul 2002 04:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate revised text and close issue

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

Should a holder class for ProtectingEntity get generated

  • Key: I2JAV12-11
  • Legacy Issue Number: 4802
  • Status: closed  
  • Source: Anonymous
  • Summary:

    >There is something that is unclear in your CORBA spec that I think is causing
    incompatibility problems between various IDL compilers.
    >> >
    >> >Given the following IDL:
    >> >
    >> >-------------------------------------------------
    >> >struct Protection
    >> >

    { >> > string str; >> >}

    ;
    >> >
    >> >typedef Protection ProtectedEntity;
    >> >
    >> >typedef sequence<ProtectedEntity> ProtectedEntityList;
    >> >
    >> >typedef ProtectedEntityList ProtectingEntity;
    >> >-------------------------------------------------
    >> >
    >> >Should a holder class for ProtectingEntity get generated? I ask this because some IDL
    compilers generate it and others do not (very frustrating!).
    >> >
    >> >In section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 spec I found this:
    "Holder classes are generated for sequence and array typedefs only. The "unwound" type's
    Holder class is used for the other cases.".
    >> >
    >> >Since this is a typedef of a typedef, but the original item was a sequence, should the
    ProtectingEntityHolder.java file get generated or not?

  • Reported: I2JAV 1.1 — Wed, 9 Jan 2002 05:00 GMT
  • Disposition: Resolved — I2JAV 1.2
  • Disposition Summary:

    Incorporate change and close issue

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

response_expected value for colocated invocations

  • Key: I2JAV13-10
  • Legacy Issue Number: 5806
  • Status: closed  
  • Source: Anonymous
  • Summary:

    For optimized (SII) colocated invocations, how is it possible for the
    ORB to determine the value of "response_expected" flag (so as to pass it
    to the client/server request interceptor). Is there a portable way to
    get this info? This is specially a problem when a oneway method is
    invoked and sync scope policy is not set; since both oneway and two-way
    void methods have a void return type. At the moment, I think such
    information can only be passed to the ORB through the stub.

  • Reported: I2JAV 1.2 — Tue, 5 Nov 2002 05:00 GMT
  • Disposition: Resolved — I2JAV 1.3
  • Disposition Summary:

    see above

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

When to honor the servant delegate in POA?

  • Key: I2JAV11-28
  • Legacy Issue Number: 4059
  • Status: closed  
  • Source: Borland Software Corporation ( Vishy Kasar)
  • Summary:

    Java language mapping gives the user ability to set the delegate on a
    servant through:

    abstract public class Servant {
    public void _set_delegate(org.omg.PortableServer.portable.Delegate
    delegate)

    { _delegate = delegate; }

    }

    POA implementation must also set this delegate in many instances where
    user provides POA with a servant. activate_object, set_servant etc. In
    normal cases user does not set any delegate of his own. In special cases
    user may set his delegate on a servant before passing the servant to
    POA.

    There are also cases where user written servant manager may return the
    same servant over and over again.

    It is unclear from the language spec if POA is supposed to honor the
    already set delegate or set its own Delegate no matter what. It seems
    beneficial to me to look at the existing servant to see if this already
    has a Delegate and set it only if it has none. Comments? If that is a
    good idea shall we change the language spec to state that explicitly? If
    we do not state this explicitly, user code may behave differently when
    moved from one ORB implementation to the other.

  • Reported: I2JAV 1.0 — Fri, 17 Nov 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see above

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

Displaying SystemExceptions

  • Key: I2JAV11-27
  • Legacy Issue Number: 4057
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The definition of org.omg.CORBA.SystemException in section 1.15.2 of the
    IDL to Java mapping spec has no code to format and display system exceptions
    in string form. It would be useful to display the minor code as a hexadecimal
    number and the completion status as a string.

    The current implementation in the JDK contains a toString() method that
    displays the minor code as a decimal number and the completion status as a
    string. Displaying the minor code as a decimal number is a readability issue
    for both OMG standard minor codes and vendor-specific minor codes. For example,
    the OMG standard minor code 0x4f4d0001 would be formatted as 1330446337 and a
    vendor proprietary minor code 0xc9c25401 would be formatted as 3384955905
    (or -910011391 if using signed 32-bit arithmetic). Displaying the minor code
    in hexadecimal form solves this problem.

    Proposed resolution:

    Add the following implementation of org.omg.CORBA.SystemException.toString()
    to section 1.15.2 of the IDL to Java mapping spec and to the zip file:

    public String toString() {

    String completedString;
    String superString = super.toString();
    String minorString = " minor code: 0x" + Integer.toHexString(minor).toUpperCase();
    switch (completed.value())

    { case CompletionStatus._COMPLETED_YES: completedString = " completed: Yes"; break; case CompletionStatus._COMPLETED_NO: completedString = " completed: No"; break; case CompletionStatus._COMPLETED_MAYBE: default: completedString = " completed: Maybe"; break; }

    return superString + minorString + completedString;
    }

  • Reported: I2JAV 1.0 — Thu, 16 Nov 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate change and close issue

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

Clarification of serialization of Anys and Typecodes

  • Key: I2JAV11-33
  • Legacy Issue Number: 4286
  • Status: closed  
  • Source: IONA ( John Cosgrove)
  • Summary:

    I have a request for clarification of the IDL to Java language mapping
    concerning the serialization of Anys and Typecodes. Both classes implement
    IDLEntity and so would be expected to be serializable. Is this the intention
    of the mapping?

    I would also expect that TCKind should also implement IDLEntity and have a
    readResolve() method as suggested in the recent discussions of Issue 1752
    revising the mapping for enums. Is this correct?

  • Reported: I2JAV 1.0 — Thu, 26 Apr 2001 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

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

IDL/Java issue, Mapping for IDL enum

  • Key: I2JAV11-32
  • Legacy Issue Number: 4271
  • Status: closed  
  • Source: Anonymous
  • Summary:

    an earlier issue (#1752) described the problem that the singleton
    assumption for Java enum objects does not hold if these Java
    objects are serialized, i.e. stored in a file.

    The issue was closed without any comments, it seems
    (http://cgi.omg.org/issues/issue1752.txt.) However, the problem
    remains and is aggravated by the fact that in the more recent documents
    mappend Java enum classes are required to transitively implement
    java.io.Serializable! This means that the "singleton assumption"
    is broken as soon as an enum object is read in from a file, and
    equality tests fail, e.g. in generated code of unions that have
    enum switch types!

    I would thus ask for the same thing as Bruce Schuchardt did back
    then (quoted from the original mail for issue #1752):

    > Please consider revising the mapping of enums to require generation
    > of equality and hash methods that are class and value based.
    > Application developers should then be advised to use equals()
    > when comparing enum objects.

    This is the only way to reconcile enums with Java serialization!

    Regards, Gerald Brose.

  • Reported: I2JAV 1.0 — Sat, 14 Apr 2001 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate the revised text and close issue

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

Any extract operations for tk_abstract_interface

  • Key: I2JAV11-29
  • Legacy Issue Number: 4064
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    It is not clear from the IDL to Java language mapping spec whether a
    valuetype or object reference can be inserted into an "any" whose TypeCode is
    tk_abstract_interface. Neither is it clear whether a valuetype or object
    reference that has been passed across the wire inside an "any" with a
    tk_abstract_interface TypeCode can be extracted using the normal extract
    operations for valuetype or object reference.

    Proposed resolution:

    Add the following text to section 1.16:

    An object reference can be inserted into an "any" that has a matching tk_objref
    TypeCode. If the object reference inherits from an abstract interface, then
    it can also be inserted into an "any" that has a matching tk_abstract_interface
    TypeCode. A nil object reference can be inserted into any "any" that has
    a tk_objref or tk_abstract_interface TypeCode.

    A valuetype can be inserted into an "any" that has a matching tk_value or
    tk_value_box TypeCode. If the valuetype supports an abstract interface, then
    it can also be inserted into an "any" that has a matching tk_abstract_interface
    TypeCode. A null valuetype can be inserted into any "any" that has a tk_value,
    tk_value_box, or tk_abstract_interface TypeCode.

    The extract_Object operation can be used to extract an object reference
    (including a nil object reference) from an "any" that has a TypeCode of tk_objref.
    It can also be used to extract an object reference (including a nil object
    reference) from an "any" that has a TypeCode of tk_abstract_interface and a
    boolean discriminator of true.

    The extract_Value operation can be used to extract a valuetype (including a
    null valuetype) from an "any" that has a TypeCode of tk_value or tk_value_box.
    It can also be used to extract a valuetype (including a null valuetype) from
    an "any" that has a TypeCode of tk_abstract_interface and a boolean discriminator
    of false.

  • Reported: I2JAV 1.0 — Sat, 18 Nov 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate changes from Simon's proposal and close issue

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

publication of messaging / unchecked_narrow

  • Key: I2JAV11-31
  • Legacy Issue Number: 4158
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    Incorporate Messaging changes relevant to the Java mapping, as shown in
    orbos/98-05-05 pages 115 and 116 together with any changes made to them
    by the Messaging RTF, into the IDL-Java mapping chapter.

  • Reported: I2JAV 1.0 — Fri, 19 Jan 2001 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

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

System Exceptions REBIND, TIMEOUT, BAD_QOS

  • Key: I2JAV11-30
  • Legacy Issue Number: 4076
  • Status: closed  
  • Source: Improv Technologies ( Mary Leland)
  • Summary:

    The mapping from IDL names to Java Class names provided in Page 1-56 Table
    1-2 should include the following exceptions.

    REBIND, TIMEOUT, BAD_QOS

    Proposed Resolution:

    Add the following at the end of Table 1.2 in Section 15.2
    CORBA::REBIND org.omg.CORBA.REBIND
    CORBA::TIMEOUT org.omg.CORBA.TIMEOUT
    CORBA::BAD_QOS org.omg.CORBA.BAD_QOS

    Add Source Code files for these, modeling them on the
    existing source code files for other System Exceptions.

  • Reported: I2JAV 1.0 — Wed, 22 Nov 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate the revised text and source code changes and close the issue

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

Usage of ExceptionDetailMessage service context

  • Key: I2JAV11-26
  • Legacy Issue Number: 4013
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The interop RTF resolved issue 3405 by adding a new service context called
    ExceptionDetailMessage. The usage of this service context was
    left to language mappings to define. We need to define this usage for Java.

    Writing the service context:

    There are a few possibilities that come to mind:
    1) The result of calling getMessage() on the exception.
    2) The result of calling toString() on the exception.
    3) The result of calling printStackTrace(PrintWriter) on the exception.

    I'm inclined to think that option 3 is best, since the callee's stack trace
    is often very valuable debugging information.

    Reading the service context:

    The wstring from the service context should become the Java error message
    in the unmarshalled exception object.

  • Reported: I2JAV 1.0 — Wed, 1 Nov 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    issue has been resolved, see ptc/01-10-20

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

Should valuetype helper insert/extract make copies?

  • Key: I2JAV11-25
  • Legacy Issue Number: 4010
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The adopted resolution for issue 2531 has clarified that the Any.insert_Value
    and Any.extract_Value methods don't make copies of the Serializable parameter
    passed to insert_Value. Should the same be true for the valuetype helper's
    insert and extract methods? The IDL to Java mapping spec does not say
    anything about the copying semantics of helper insert and extract methods.

  • Reported: I2JAV 1.0 — Wed, 1 Nov 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate change and close issue

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

Java language mapping: Tie classes for local interfaces.

  • Key: I2JAV11-19
  • Legacy Issue Number: 3320
  • Status: closed  
  • Source: ICL ( Chris Wood)
  • Summary:

    The new java mapping as specified in 99-10-10 for local classes generates a
    class which is subclassed much as previous implementations subclassed the
    POA class.

    ie:

    local interface Test

    { void call(); }

    ;

    maps to:

    class Test extends org.omg.CORBA.portable.LocalImpl implements
    TestOperations {}

    then implementers subclass Test to get desired functionality.

    I believe there is a need for a tie class similar to the POATie class:

    class TestTie extends Test {
    public TestTie(TestOperations delegate)

    { _delegate = delegate; }

    private TestOperations _delegate;

    public void call()

    { _delegate.call(); }

    }

    Also the implementation for _hash is not correct :

    public int _hash(int max)

    { // return hashCode(); // incorrect, return value exceeds max. return hashCode() % (max+1); }
  • Reported: I2JAV 1.0 — Wed, 16 Feb 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate revised text and close issue

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

How to create marshalel data of java.lang.Throwable instance?

  • Key: I2JAV11-18
  • Legacy Issue Number: 3267
  • Status: closed  
  • Source: Fujitsu ( Masayoshi Shimamura)
  • Summary:

    I don't understand that how to create marshaled data of
    java.lang.Throwable instance to set it to context_data in
    UnknownExceptionInfo.

    In CORBA 2.3.1, section "13.6.7 Object Service Context" on 13-25 page
    says:

    UnknownExceptionInfo identifies a CDR encapsulation of a marshaled instance
    of a java.lang.throwable or one of its subclasses as described in Java
    to IDL Language Mapping, Section 1.4.8.1, "Mapping of UnknownExceptionInfo
    Service Context," on page 1-32.

    In Java to IDL Language Mapping specification revised by RTF
    (ptc/99-03-09), section "28.4.8.1 Mapping of UnknownExceptionInfo
    Service Context" on page 28-32 says:

    CORBA UNKNOWN exceptions whose GIOP Reply message includes an
    UnknownExceptionInfo service context containing a marshaled
    instance of java.lang.Throwable or one of its subclasses are mapped
    to RMI exceptions according to the type of the object contained in
    the service context, as shown in follows:
    -------------------------------------------------------------------
    UnknownExceptionInfo RMI Exception
    -------------------------------------------------------------------
    java.lang.Error java.rmi.ServerError
    java.rmi.RemoteException java.rmi.ServerException
    java.lang.RuntimeException java.rmi.ServerRuntimeException(JDK 1.1)
    java.lang.RuntimeException(Java 2)
    -------------------------------------------------------------------

    It seems to me that these specifications above are not clear. How to
    create the context_data from java.lang.Throwable instance? I guess the
    context_data should be created by one of following two ways. Which way
    is correct? Or is there any other correct way?

    1. A instance of java.lang.Throwable or its subclasses should be
    serialized by Java language specific serialization function and then
    should be set to the context_data as sequence of octet.

    2. A instance of java.lang.Throwable or its subclasses should be
    marshaled as CORBA Value type data and then should be set to the
    context_data as sequence of octet.

  • Reported: I2JAV 1.0 — Tue, 1 Feb 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see revised text below

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

Copying boxed valuetypes on local calls

  • Key: I2JAV11-23
  • Legacy Issue Number: 3995
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    n section 1.12.2 of the IDL to Java mapping spec, the second bullet
    should be clarified to state that the copying it describes applies
    only to non-boxed valuetypes and not to boxed valuetypes.

    Valuetypes need to be copied (unlike structs, which aren't copied)
    because the methods of a valuetype can modify its state and it is
    not reasonable to require the callee to know whether or not calling
    a valuetype method has resulted in a change to the valuetype's state.

    This does not apply to boxed valuetypes, which cannot have methods.
    Therefore, with respect to this copying, they should be treated like
    IDL constructed types, which are not copied.

    Proposed resolution:

    In section 1.12.2, second bullet, change "For IDL in parameters that
    are valuetypes" to "For IDL in parameters that are non-boxed valuetypes:"

    In section 1.12.2, second bullet, change "With the exception of value
    types" to "With the exception of non-boxed value types".

    In section 1.12.2, add new third bullet:
    • For IDL in parameters that are boxed valuetypes:
    • Java objects passed for boxed valuetype IDL in parameters are created and owned
    by the caller. The callee must not modify boxed valuetype in parameters or retain
    a reference to the in parameter beyond the duration of the call. Violation of
    these rules can result in unpredictable behavior.

    In section 1.21.5.1, second paragraph, change "the stub copies all
    valuetypes" to "the stub copies all non-boxed valuetypes".

  • Reported: I2JAV 1.0 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    close no change

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

Valuetype unmarshalling

  • Key: I2JAV11-22
  • Legacy Issue Number: 3994
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The rules for valuetype unmarshalling in section 1.13.8 of the IDL to
    Java mapping spec need to be expanded. There are two issues with the
    algorithm currently described:

    1. The algorithm described is based purely on the repository ID,
    which may either be read off the wire or passed as an argument on
    the read_value() call. However, if the expected type is passed
    as an argument on the read_value() call, then this should be taken
    into account in the unmarshalling algorithm.
    2. In some cases, the unmarshaller does not have enough information
    to distinguish between a boxed valuetype (which is unmarshalled
    using a helper object) and a regular valuetype (which is unmarshalled
    using a value factory). An additional step in the unmarshalling
    algorithm is needed to cover these cases.

    Proposed resolution:

    In section 1.13.8, add a new bullet before the existing second bullet
    as follows:
    • If this is not successful and an expected type clz was passed on the
    read_value call, and if clz implements IDLEntity but not ValueBase, then
    unmarshal the valuetype as a boxed IDL type by calling the read method
    of <clz>Helper.

    In section 1.13.8, add a new bullet before the existing third bullet
    as follows:
    • If this is not successful and the RepositoryId is a standard repository id that starts
    with “IDL:”, then attempt to generate the boxed value helper class name to use by
    stripping off the “IDL:” header and “:<major>.<minor>” version information
    trailer, and replacing the “/”s that separate the module names with “.”s and
    appending “Helper.”

    In section 1.13.8, add a new bullet before the existing fourth bullet
    as follows:
    • If this is not successful and an expected type clz was passed on the
    read_value call, and if clz does not implement IDLEntity, then use the
    ValueHandler interface to read in the value (see the Java to IDL Language
    Mapping document, Section 1.5.1.3, “ValueHandler,” on page 1-40).

  • Reported: I2JAV 1.0 — Wed, 25 Oct 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Incorporate the revised text and close the issue

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

Request clarification for use of alias typecodes in typedef helper classes

  • Key: I2JAV11-21
  • Legacy Issue Number: 3633
  • Status: closed  
  • Source: Anonymous
  • Summary:

    I've noticed that there appears to be a lack of consistency between ORB vendors
    when it comes to the use of alias typecodes in Java helper classes generated for
    IDL typedefs.

    Specifically, both Visibroker 4 and Orbix 2000 return an appropriate alias
    typecode from the helper class's type () method. However, the Visibroker 4
    generated helper class does not use it in either the insert or extract methods,
    whilst the Orbix 2000 helper class uses it to set the typecode of the Any passed
    to the insert method and to check that the Any passed to the extract method is
    of the correct type.

    Would it be possible to clarify which of these approaches is correct? From the
    specification of the IDL to Java mapping, it appears that typdef types are
    intended to be 'unwound' to the first non-typedef type, which would suggest that
    the first approach is OK. However, if this is the case, for what purpose is the
    alias typecode produced, if not for the setting/checking of typecodes of Anys
    containing instances of the associated type?

  • Reported: I2JAV 1.0 — Fri, 19 May 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    close no change

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

Custom marshal does not work for certain valuetypes

  • Key: I2JAV11-20
  • Legacy Issue Number: 3575
  • Status: closed  
  • Source: Borland Software Corporation ( Vijaykumar Natarajan)
  • Summary:

    This was discussed in the core rtf in boston, and the consensus was that this
    would be a java only issue and could be fixed in the language mapping directly.

    The issue:
    Boxed valuetypes, abstract interfaces and regular valuetypes (these can be
    marshaled but not in optimized format) cannot be marshaled or unmarshaled when
    using custom marshaling. This is because the Data*Stream APIs do not provide the
    requisite interfaces.

    Proposal:

    Add two new interfaces in java defined as follows
    package org.omg.CORBA;

    public interface CustomOutputStream extends org.omg.CORBA.DataOutputStream

    { public void write_Value(java.io.Serializable value, java.lang.String repId); // optimized valuetype writes public void write_Value(java.io.Serializable value, org.omg.CORBA.portable.BoxedValueHelper helper); //boxed valuetypes public void write_Abstract(java.lang.Object obj); // abstract interfaces }

    public interface CustomInputStream extends org.omg.CORBA.DataInputStream

    { public java.io.Serializable read_value(java.lang.String repId); // optimized valuetype reads public java.io.Serializable read_value(java.lang.Class expected); // Is this needed??? public java.lang.Object read_abstract_interface(); // abstract interfaces public java.lang.Object read_abstract_interface(java.lang.Class expected); // Is this needed??? public java.io.Serializable read_value(org.omg.CORBA.portable.BoxedValueHelper helper); // boxed valuetypes }
  • Reported: I2JAV 1.0 — Thu, 20 Apr 2000 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    resolved, see below

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

Java SystemException should contain nested exception field

  • Key: I2JAV11-16
  • Legacy Issue Number: 2979
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Java org.omg.CORBA.SystemException class should contain a nested exception
    field. This would assist debugging when a Java exception occurs locally
    within the client ORB when marshalling a request or unmarshalling a reply.
    At present, when generic system exceptions such as COMM_FAILURE or BAD_PARAM
    are returned to the application by the client ORB, it can be difficult to
    identify the precise lower-level failure that caused the problem.

    This issue applies specifically to system exceptions arising locally within
    a Java client, not those returned by the server to the client.

  • Reported: I2JAV 1.0 — Thu, 4 Nov 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see above

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

Should Any.extract_string work for bounded strings?

  • Key: I2JAV11-15
  • Legacy Issue Number: 2889
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: It is not clear from the OMG specs or from looking at existing Java ORB
    products what behavior is intended for the following case:
    1. Create an Any with a TypeCode for a bounded string.
    2. Call extract_string on the Any object.

    I have tried this on two Java ORBs and it fails in both cases. It works
    when the Any"s TypeCode is for an unbounded string. The spec is silent on
    whether or not this should work. The only relevant statement in the spec is
    the following from section 1.16:

  • Reported: I2JAV 1.0 — Wed, 15 Sep 1999 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    close no change

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

Union exceptions

  • Key: I2JAV11-24
  • Legacy Issue Number: 4009
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • Summary:

    Given a union such as:

    union u switch (long)

    { case 2: case 3: case 4: string string_member; case 5: double double_member; }

    ;

    I get a modifier

    public void string_member(int d, string v);

    What should happen if I call string_member(99, "hello")?

    Clearly, this is meaningless, but the spec doesn't say what should happen.
    I would suggest to throw BAD_PARAM.

  • Reported: I2JAV 1.0 — Tue, 31 Oct 2000 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see below

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

DII and SystemException semantics

  • Key: I2JAV11-13
  • Legacy Issue Number: 2721
  • Status: closed  
  • Source: Anonymous
  • Summary:

    There needs to be a clarification of the expected semantics for DII
    Request objects when a system exception is received over-the-wire
    after a call to invoke().

  • Reported: I2JAV 1.0 — Wed, 9 Jun 1999 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close no change

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

Mapping of AbstractBase and abstract interfaces

  • Key: I2JAV11-12
  • Legacy Issue Number: 2532
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: There is a problem with current mapping of abstract interface types
    to Java. These do not implement org.omg.CORBA.portable.IDLEntity.
    Even if they did, it would not be possible for the Java to IDL mapping
    to distinguish them from abstract valuetypes, which also map to
    Java interfaces that implement org.omg.CORBA.portable.IDLEntity.

  • Reported: I2JAV 1.0 — Fri, 12 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close, no change

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

ORB Init problems

  • Key: I2JAV11-17
  • Legacy Issue Number: 3204
  • Status: closed  
  • Source: International Business Machines ( Russell Butek)
  • Summary:

    Being new to this game, what is the "Java ORB instance" problem that you
    > tried solving? There is another problem with the Java ORB that I'd also
    > like to bring up, but I don't know the proper place to do it. Would the
    > Java RTF address it?
    >
    > The problem: the spec talks about an ORB ID. The Java mapping, for some
    > reason, chose to ignore the ID. I'd like to understand the reason why.
    > Could you enlighten us?

  • Reported: I2JAV 1.0 — Mon, 6 Dec 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    see above

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

Mapping Messaging sendc_ (and sendp_) methods to Java

  • Key: I2JAV11-11
  • Legacy Issue Number: 2528
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: I am having a hard time determining just where the sendc_ methods should be declared when the AMI spec is mapped to Java (this issue is evident on sendp_"s as well, but I don"t care right now. I am sure that someone has determined this, but it is not obvious in the spec.

  • Reported: I2JAV 1.0 — Thu, 11 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close no change

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

Java substitutability issue: value instance -> interface type

  • Key: I2JAV11-14
  • Legacy Issue Number: 2770
  • Status: closed  
  • Source: UBS ( Hans Kneubuehl)
  • Summary:

    How is it possible to substitute an instance of a value type, that supports
    an interface, to a parameter whose formal type is the interface?

  • Reported: I2JAV 1.0 — Fri, 25 Jun 1999 04:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close no change.

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

Standard properties should include initial host and port

  • Key: I2JAV11-10
  • Legacy Issue Number: 2520
  • Status: closed  
  • Source: Anonymous
  • Summary:

    Summary: The standard properties listed in section 25.21.7.1 allow the ORB
    class and ORB singleton class to be set. There should also be
    standard properties to allow the initial host and port for the naming
    service to be set.

  • Reported: I2JAV 1.0 — Mon, 8 Mar 1999 05:00 GMT
  • Disposition: Resolved — I2JAV 1.1
  • Disposition Summary:

    Close no change.

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