Java to IDL Language Mapping Avatar
  1. OMG Specification

Java to IDL Language Mapping — All Issues

  • Acronym: JAV2I
  • Issues Count: 12
  • Description: All Issues
Closed All
All Issues

Issues Descriptions

Behavior of Java writeUTF/readUTF

  • Key: JAV2I12-99
  • Legacy Issue Number: 4319
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    Java Serializable classes can define their own readObject/writeObject
    methods which take java.io.ObjectInputStream and
    java.io.ObjectOutputStream parameters, respectively.

    What is the proper behavior of the readUTF and writeUTF methods on these
    streams in RMI-IIOP? The Java to IDL specification doesn't mention
    these methods.

    Proposed resolution:

    In RMI-IIOP, java.io.ObjectOutputStream's writeUTF method should write a
    CORBA wstring. Similarly, readUTF should read a CORBA wstring.

    Discussion:

    One must override these methods to avoid using the internal java.io
    implementations. Looking at the JDK 1.3 code, the behavior is specific
    to Java serialization. If one doesn't override writeUTF and readUTF,
    Java serialization mechanisms such as blocks (similar to chunks) may be
    introduced on the wire in RMI-IIOP.

  • Reported: JAV2I 1.1 — Mon, 21 May 2001 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    See revised text below

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

javax.rmi.CORBA.Util.isLocal RemoteException condition(s) not specified

  • Key: JAV2I12-98
  • Legacy Issue Number: 4296
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The Java to IDL spec
    (http://cgi.omg.org/cgi-bin/doc?ptc/00-01-06, section 1.5.1.4 page 47)
    says:

    "The isLocal method has the same semantics as the ObjectImpl._is_local
    method, except that it can throw a RemoteException."

    However, it does not specify under what conditions a remote exception
    is thrown.

    Either the exception condition(s) should be specified or the exception
    should be removed from the signature.

  • Reported: JAV2I 1.1 — Tue, 8 May 2001 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    See revised text below

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

Stream format problem for custom marshalled RMI types

  • Key: JAV2I12-14
  • Legacy Issue Number: 3151
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    There is a problem in the stream format for custom marshalled RMI types.
    The Java serialization spec requires that when a class with a writeObject
    method calls defaultWriteObject and then writes optional data, the receiver
    must be able to skip the optional data if the readObject does not consume
    it or the class is not in the receiver's hierarchy. So if the sender's
    hierarchy consists of serializable classes Base and Derived, both of which
    call defaultWriteObject and then write optional data, there must be a way
    for the unmarshaller to first skip to the end of the Base data, then skip
    to the end of the Derived data. With the current stream format, this is
    not possible.

  • Reported: JAV2I 1.0b1 — Mon, 20 Dec 1999 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    see below

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

Java reverse mapping local case cannot properly support Portable Intercepto

  • Key: JAV2I12-20
  • Legacy Issue Number: 3754
  • Status: closed  
  • Source: Oracle ( Harold Carr)
  • Summary:

    The local mapping makes it impossible to determine which ending point
    to call.

    ptc/00-01-06 says:

    BEGIN_QUOTE

    1.5.2.2 Local Stubs

    The stub class may provide an optimized call path for local server
    implementation objects. For a method echo(int x) of a remote interface
    Aardvark, the optimized path does the following:

    1. Find out if the servant is local by calling Util.isLocal()
    2. If the servant is local, call
    this._servant_preinvoke("echo",Aardvark.class)
    3. If _servant_preinvoke returned a non-null ServantObject so, call
    ((Aardvark)so.servant).echo
    4. If _servant_preinvoke returned a non-null ServantObject so, call
    this._servant_postinvoke(so)
    5. If _servant_preinvoke returned null, repeat step 1. The call to
    Util.isLocal() will return false, causing the non-optimized
    path to be followed.
    ...

    The following is an example of a stub class that provides this
    optimized call path.

    // Java
    public class _Aardvark_Stub extends javax.rmi.CORBA.Stub
    implements Aardvark
    {
    public int echo(int x)
    throws java.rmi.RemoteException, Boomerang
    {
    if (!javax.rmi.CORBA.Util.isLocal(this))

    { ... }

    else {
    // local call path
    org.omg.CORBA.portable.ServantObject so =
    _servant_preinvoke("echo", Aardvark.class);
    if (so == null)
    return echo;
    try

    { return ((Aardvark)so.servant).echo(x); }

    catch (Throwable ex)

    { Throwable ex2 = (Throwable) javax.rmi.CORBA.Util.copyObject(ex, _orb()); if (ex2 instanceof Boomerang) throw (Boomerang)ex2; else throw javax.CORBA.Util.wrapException(ex2); }

    finally

    { _servant_postinvoke(so); }

    }
    }
    }

    END_QUOTE

    ClientRequestInterceptor::send_request would need to be invoked by the
    ORB inside _servant_preinvoke.

    ClientRequestInterceptor::receive_reply or receive_exception would
    need to be called inside _servant_postinvoke.

    (Note that receive_other would not happen since, if a POA were
    involved inside _servant_preinvoke and a servant manager raised
    ForwardRequest, this should cause _servant_preinvoke to return null
    resulting in a recursive call to the method. In this case the ORB
    would not call send_request in the first place, or, if it did, it
    would handle the call to the receive_other internally inside of
    _servant_preinvoke.)

    One is tempted to say that the ORB could remember if
    javax.rmi.CORBA.Util.copyObject was called on behalf of this request.
    In that case, when _servant_postinvoke is called it would know there
    was an exception (and would have it hands on the exception object -
    which needs to be available via Portable Interceptors).

    However, this does not work. The example does not show it, but if the
    method returns values those values are filtered through
    javax.rmi.CORBA.Util.copyObject before being returned to the client.
    Exception objects are legal return values. So there is no way to
    determine if copyObject was called to copy return values or exception
    objects resulting from an actually exception. Therefore this trick
    will not work.

    Bottom line: there is no reliable way to determine which Portable
    Interceptor ending point to call in the Java reverse mapping local
    case.

  • Reported: JAV2I 1.0b1 — Fri, 21 Jul 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    see below

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

Java to IDL mapping contradictive to CORBA/IIOP 2.3.1

  • Key: JAV2I12-18
  • Legacy Issue Number: 3641
  • Status: closed  
  • Source: Anonymous
  • Summary:

    The Java to IDL Language Mapping (formal/99-07-59) seems to contradict the CORBA/IIOP 2.3.1 Specification (formal/99-10-07) over exceptions being raised by valuetype initialisers.

    Section 1.3.5.4 of 99-07-59, point 3 states that exceptions thrown by a constructor of an object-by-value class are mapped to the corresponding OMG IDL exception.

    On the other hand, section 2.8.1.5 of 99-10-07 does not allow initialisers to include a raises clause (contrast this with the syntax for an operation declaration in section 3.12).

    This is a significant inter-operability problem. In my case the IDL generated by the IBM/SUN RMI-IIOP Java-to-IDL compiler (which includes 'raises' clauses in valuetype initialisers) is rejected as syntactically invalid by the MICO IDL-to-C++ compiler.
    submit: Submit Issue Report

  • Reported: JAV2I 1.0b1 — Wed, 24 May 2000 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Close, no change. Core RTF issue 4785 has added exceptions to IDL valuetype initializers, which reso

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

Mapping of ExceptionDetailMessage service context

  • Key: JAV2I12-8
  • Legacy Issue Number: 4656
  • 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. This usage has been defined for the IDL to Java
    mapping (issue 4013) but not for the Java to IDL mapping.

    The resolution for issue 4013 defines how this service context shall be used
    when marshaling and unmarshaling system exceptions. However, an RMI-IIOP client
    never receives a system exception, but instead receives a mapped RemoteException
    or RuntimeException that was created by applying the rules specified in
    section 1.4.8. Currently these rules do not take account of any detail message
    that the system exception has acquired from the ExceptionDetailMessage service
    context by applying the mappings specified by the resolution of issue 4013.

    In order to ensure that this valuable diagnostic information is available on
    exceptions received by RMI-IIOP clients as well as IDL clients, I propose the
    following change to section 1.4.8 of the Java to IDL mapping spec.

    Proposed resolution:

    After table 1-2, replace

    "In all cases, ..."

    by

    "If the getMessage() method of the CORBA system exception returns a non-null
    and non-empty string, the RMI exception is created with this string as its
    detail string. In all other cases, ..."

  • Reported: JAV2I 1.1 — Thu, 1 Nov 2001 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    see above

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

New issue: Behavior of writeByte, writeChar, writeBytes, writeChars


Mapping subclasses of custom-marshaled Java classes to IDL

  • Key: JAV2I12-6
  • Legacy Issue Number: 4497
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    The Java to IDL mapping spec says that serializable Java classes that
    have a writeObject method are mapped to IDL custom valuetypes. This
    should also apply to any Java subclasses of these classes, since otherwise
    the generated IDL is illegal. (An IDL non-custom valuetype can't
    inherit from an IDL custom valuetype.)

    Proposed resolution:

    In section 1.3.5.6 of the Java to IDL mapping spec, change the first sentence
    of the second paragraph from

    If the class does not implement java.io.Externalizable but does have a
    writeObject method, ...

    to:

    If the class does not implement java.io.Externalizable but does have a
    writeObject method, or extends such a class directly or indirectly, ...

  • Reported: JAV2I 1.1 — Wed, 15 Aug 2001 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Closed, accepted. See revised text below

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

Issue with using the local stub with for example an EJB application

  • Key: JAV2I12-5
  • Legacy Issue Number: 4429
  • Status: closed  
  • Source: Anonymous
  • Summary:

    When using the local stub with for example an EJB application, we discovered the following critical issue.

    Let's take an simple example :

    public interface HelloWorld extends javax.rmi.EJBObject

    { void print( String message ); }

    The generated Stub according to the mapping rules contains the methods for the inherited interface as for example 'getEJBHome'.

    For a local invocation on 'getEJBHome' the following part of the stub will be used :

    public javax.ejb.EJBHome getEJBHome() throws java.rmi.RemoteException { while( true ) { if (!javax.rmi.CORBA.Util.isLocal(this) )

    { // non local use }

    else { org.omg.CORBA.portable.ServantObject _so = _servant_preinvoke("EJBHome", HelloWorld.class);

    if ( _so == null ) return getEJBHome();

    try

    {return ((javax.ejb.EJBObject)_so.servant).getEJBHome(); }

    catch ( Throwable ex )

    { Throwable ex2 = ( Throwable ) javax.rmi.CORBA.Util.copyObject(ex, _orb()); throw javax.rmi.CORBA.Util.wrapException(ex2); }

    finally {_servant_postinvoke(_so); } } } }

    The '_servant_preinvoke' method will return a servant class of type 'HelloWorld' that implements the 'getEJBHome' operation.

    Thus, the '_HelloWorld_Tie' servant is returned.

    Then, the cast to convert the returned servant to 'javax.ejb.EJBObject' will fail since the servant doesn't implement this interface ( it only inherits from org.omg.PortableServer.Servant and implements javax.rmi.CORBA.Tie ).

    Thus, by using the local stub, it is not possible to invoke an inherited operation.

    Solution :

    The returned servant is always implementing 'javax.rmi.CORBA.Tie'. To allow the correct cast to 'javax.ejb.EJBObject' we need to access the final target instead of the servant itself. So the following solution can be always applied :

    javax.rmi.CORBA.Tie tie = ((javax.rmi.CORBA.Tie)_so.servant);

    return ((javax.ejb.EJBObject)tie.getTarget()).getEJBHome();

  • Reported: JAV2I 1.1 — Wed, 25 Jul 2001 04:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Closed, accepted. See revised text below.

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

RMI-IIOP interop bet. J2SE 1.3 and 1.4

  • Key: JAV2I12-11
  • Legacy Issue Number: 4795
  • Status: closed  
  • Source: Oracle ( Everett Anderson)
  • Summary:

    I'd like to raise the following as an urgent issue for the Java to IDL
    RTF:

    RuntimeExceptions/Errors are broken in RMI-IIOP when interoperating
    between J2SE 1.3 and 1.4 (or "class evolution in service contexts is
    broken").

    When an unchecked exception (RuntimeException, Error) occurs in
    RMI-IIOP, it is translated into a CORBA UNKNOWN system exception, and
    the real Java exception is marshaled as a CDR encapsulation in the
    UnknownExceptionInfo service context. (Java to IDL formal 01-06-07
    1.4.7, 1.4.8.1)

    In J2SE 1.4, java.lang.Throwable has evolved to add several new
    non-transient fields including

    private Throwable cause;
    private StackTraceElement[] stackTrace;

    This means that when J2SE 1.3.x talks to 1.4 and an unchecked
    exception occurs, there is a class evolution scenario occurring inside
    of the UnknownExceptionInfo service context. Normally, class
    evolution is handled by using the SendingContextRunTime CodeBase to
    find out what the sender put on the wire. This service context is
    sent by the client on the first request on a connection and by the
    server on the first reply on a connection. (Java to IDL formal
    01-06-07 1.5.1)

    This presents two problems:

    1. Since the UnknownExceptionInfo service context has the Throwable
    in an encapsulation, technically it has no connection information.

    2. Even if we assumed that we use the connection on which this
    encapsulation is transmitted, we would need to make sure that the
    SendingContextRunTime service context is unmarshaled BEFORE the
    UnknownExceptionInfo service context so that the connection has the
    CodeBase to use to unmarshal the evolved Throwable class.

    Here are two possible solutions:

    1. Service context ordering proposal (strawman):

    Require that service context encapsulations use the connection on
    which they are sent if they need the CodeBase, and that the
    UnknownExceptionInfo service context must be unmarshaled after the
    SendingContextRunTime service context. Specifically, add this
    language to the Java to IDL spec in section 1.4.8.1.

    Note: We may need to be careful not to generalize to all service
    contexts. For instance, code sets for wstring/wchar inside of service
    context encapsulations should probably be explicitly stated when
    defining the service context at the spec level.

    2. New service context & backwards compatibility proposal:

    Add a new UnknownExceptionInfo service context called something like
    UnknownExceptionInfoPlusCodeBase service context. It contains the
    CodeBase IOR followed by the java.lang.Throwable. Thus, all necessary
    information is contained, and we can support evolution going forward
    in this particular service context. Older receivers would just
    disregard it.

    For backwards compatibility with J2SE 1.3 and before, we must still
    also send the original UnknownExceptionInfo service context containing
    something that looks like the J2SE 1.3 java.lang.Throwable class.
    Thus, we must define the format of this new structure and how to
    translate from J2SE 1.4 or later Throwables to it.

  • Reported: JAV2I 1.1 — Wed, 19 Dec 2001 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    see below

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

mapSystemException server mapping

  • Key: JAV2I12-10
  • Legacy Issue Number: 4698
  • Status: closed  
  • Source: hursley.ibm.com ( Simon Nash)
  • Summary:

    Ie RemoteException and subclasses are not RMI/IDL Exception types. (Note
    > > >however,
    > > >that the section refered to doesn't explicitly state that. That is a spec
    > > >problem). The spec provides these options:
    > > >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.
    > > >
    > > >This option is needed because, some userdefined runtime exception, say,
    > > >may not
    > > >have an equivalent implementation on the receiving end. If we fix remote
    > > >exception to always result in the "right" exception on the wire, this case
    > > >occurs
    > > >only when there is an unexpected exception (such as a null pointer), which
    > > >should
    > > >be OK. The intent here was to talk about base classes and not individual types, but I
    > > >agree this is not explicit. Ideally, only remote exceptions that don't
    > > >have the
    > > >explicit reverse (rmi-to-system) mapping should result in a ServerException.
    > >
    > > Right, your first point makes this not so bothersome.
    > >
    > > > > >2. What about C++ clients ? The server should have converted any Java
    > > > > >Exception into a CORBA SYSTEM/USER exception where this is possible,
    > > > so that
    > > > > >any non-Java clients can deal with the Exceptions. Especially for the
    > > > > >TRANSACTION exceptions where a one-to-one mapping is possible, so that C++
    > > > > >clients know about those events from an RMI-IIOP server. Unfortunately the
    > > > > >Table 1-2, CORBA and RMI Exceptions (p. 1-33), has no one-to-one
    > > > mapping, so
    > > > > >Then mapping into the other direction some information will get lost.
    > > > >
    > > > > The problem is actually worse than this. If the server throws an exception
    > > > > that is a subclass of a declared exception, the client will get the Java
    > > > > IDL mapped exception (e.g. FooException -> FooEx) but
    > > > > there_is_no_way_for_the_client_to_handle_it because the IDL does not
    > > > > declare FooEx - and IDL does not allow exception inheritance. I would like
    > > > > to propose therefore that in the "standard" exception mapping that only
    > > > > exceptions of the declared type are thrown and that any exception
    > > > > inheritance is represented in the detail which is the actual java
    > > > > exception. We are actually doing this already in our server because it is
    > > > > the only reasonable way to make C++ clients work with EJBs.

  • Reported: JAV2I 1.1 — Sun, 11 Nov 2001 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Closed, accepted. See revised text below

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

There is a typo on page 1-46.

  • Key: JAV2I12-9
  • Legacy Issue Number: 4690
  • Status: closed  
  • Source: Anonymous
  • Summary:

    "The mapSystemException method maps a CORBA system exception to a java.rmi.RemoteException or a java.rmi.RuntimeException."

    There is no java.rmi.RuntimeException, instead it should read: java.lang.RuntimeException !

  • Reported: JAV2I 1.1 — Thu, 8 Nov 2001 05:00 GMT
  • Disposition: Resolved — JAV2I 1.2
  • Disposition Summary:

    Closed, accepted. See revised text below

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