IDL to Java Language Mapping Avatar
  1. OMG Specification

IDL to Java Language Mapping — Closed Issues

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

Issues Descriptions

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

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

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