Summary: Placing generated stub classes in the package in which the interface is defined
is flawed for a few reasons:

1) It can violate license agreements (e.g., Jini uses remote interfaces, and
if an RMI-IIOP stub is generated from one of the core Jini interfaces
the license agreement will be violated since a new public class
will be added to the core).

2) Placing generated classes in the same package as the remote interface
definition will not be possible if the package is sealed.

If an interface is public, such generated classes could be placed in a
sub-package of a CORBA-specific package, for example,
org.omg.CORBA.stub.java.rmi._Remote_Stub.

Summary: We have a security hole in the reverse mapping that can be fixed by a
straight forward spec change.

The Java-to-IDL mapping spec 99-03-09 defines in paragraph 28.4.9.5 that
rmi-iiop offer a method

> Util.loadClass(String className, String remoteCodebase, Class
loadingContext)
> throws ClassNotFoundException

>

so that the caller has to perform the necessary
loadingContext.getClassLoader() call before calling this method. This
way the callers security permissions are checked properly by the
getClassLoader mechanism.

So code that uses this API right now has to change from

Util.loadClass(className, remoteCodebase, loadingContext)

to

Util.loadClass(className, remoteCodebase,
loadingContext.getClassLoader())

after this spec change.

No Data Available

resolved in XMI 1.1 RTF

closed is XMI 1.1 RTF

resolved in XMI 1.1 RTF

Summary: I took another look at 28.3.7.1, and I think that the current
special-case mapping of java.lang.Exception is odd and unnecessary.
It seems to me that the right thing to do is to simply remove this
special case, and map it the same as any other exception. So,
java.lang.Exception should map to a valuetype that has
::java::lang::Throwable as a superclass and no data fields, and to an
IDL exception of ::java::lang::Ex (note that this exception is used in
an example in 28.3.4.6). java.lang.Throwable should map to a valuetype
that has no superclass and a private data field named detailMessage, and
to an IDL exception of ::java::lang::ThrowableEx.

Closed, accepted

Summary: RMI remote interface types are currently mapped to IDL interfaces without
a #pragma ID, which means they have IDL-style repository IDs. This causes
problems when trying to locate a "best match" RMI stub for an IOR that
contains this format of repository ID. Because of the non-reversible
manglings from Java interface names to IDL interface names (inner classes,
leading underscores, and Unicode characters), there is no reliable
demangling from the IDL-style repid in an IOR to an RMI stub class name.

This can be fixed by using the RMI style of repid instead of the IDL style
of repid when mapping RMI remote interfaces to IDL, just as we currently
do for value types.

Closed, accepted

Summary: The ::java::lang::Exception type specified by the Java to IDL mapping
is wrong. It should be ::java::lang::_Exception, since exception is
an IDL keyword.

Closed, accepted

Summary: The wording of section 28.5.1.4 is misleading. It says that
writeRemoteObject and writeAbstractObject can allocate ties. This
is not incorrect, but it could be misinterpreted. In some
implementations, a tie is allocated when an implementation object
is exported, so this wording could be taken to imply that these
methods do an "auto export" if an unexported object is passed in
to these methods.

Closed, accepted

Summary: The javax.rmi.CORBA.Tie interface has a setTarget method but no getTarget.
It is sometimes necessary to be able to obtain the target object for a tie.
POA ties provide this facility, and it should be added to RMI/IDL ties.

Closed, accepted

Summary: This issue was raised by Vijay Natarajan of Inprise.

It appears that we need to do the same trick we used to distinguish
between Anys, java.lang.Objects, Serializable etc

We need to map java.rmi.Remote to be an alias of Object as in
module java {
module rmi

;
};

This is to allow us to distinguish in IDL mapping between

public interface hello implements java.rmi.Remote

w/o the aliasing, these methods cannot be mapped.

Closed, accepted

Summary: It is possible for an RMI/IDL value class to contain an IDLEntity type
that was mapped from an IDL valuetype. In this case, the GIOP
encoding of the IDLEntity type sent by an IDL/Java or C++ application
to an RMI-IIOP appplication may not contain type information (if the
actual type is the same as the declared type).

In order to allow the ValueHandler to demarshal these IDLEntity types,
an additional API call such as read_Value(Class clz) in needed on the
org.omg.CORBA.portable.InputStream class. This allows the ValueHandler
to pass the expected class (which it knows) to the InputStream.

For symmetry, a write_Value(java.io.Serializable obj, Class clz) method
should be added to org.omg.CORBA.portable.OutputStream. This would
allow RMI-IIOP marshalling to use the same optimized encoding for this
case as is possible for C++ and IDL/Java.

Closed, accepted

Summary: If a user passes a non-remote and non-serializable object to a remote
method whose signature type is an abstract interface, the IBM/Sun
implementation of RMI-IIOP currently returns a ClassCastException.

It is not very obvious to the user what is causing this error.
RMI-JRMP returns a NotSerializableException in this case, which is
much easier for the user to interpret.

Closed, accepted

Summary: The Java to IDL mapping specifies a number of names in the IDL
module "java". Examples are ::java::lang::Exception and
::java::lang::_Object. This can cause problems when mapping
Java to IDL and then remapping the resulting IDL back to Java.

Closed, no change

Summary: The javax.* APIs in the Java to IDL mapping spec have not been
designed to separate interface from implementation. For the RMI-IIOP
standard extension, this is not a problem since the whole standard
extension can be replaced by other vendors if necessary. However,
when RMI-IIOP becomes part of the core, it may be necessary to permit
other vendors to replace these implementations without replacing the
APIs (as is currently the case for the ORB APIs and implementation).

Closed, accepted

Summary: For the scoped name component, it is far simpler to use the actual class
name of the java class with all the invalid IDL characters unicode escaped.

Closed, accepted

Summary: The RemoteException returned by mapSystemException should preserve
the original CORBA system exception as the detail field.

Closed, accepted

Summary: The text describing PortableRemoteObject does not describe the
possible error cases very completely or precisely. 1. Change the paragraph:

It is an error to call exportObject more than once for the same object.

to the paragraph:

It is an error to call exportObject on an object that is already
exported.

2. Change the sentence in the description of toStub:

The argument object must either be a subclass of PortableRemoteObject
or have been previously the target of a call on
PortableRemoteObject.exportObject.

to the sentences:

The argument object must currently be exported, either because it is
a subclass of PortableRemoteObject or by virtue of a previous call
to PortableRemoteObject.exportObject. If the object is not currently
exported, a NoSuchObjectException is thrown.

3. Change the sentence:

The unexportObject method is used a deregister a server object from
the ORB runtimes, allowing the object to become available for
garbage collection.

to the sentences:

The unexportObject method is used a deregister a currently exported
server object from the ORB runtimes, allowing the object to become
available for garbage collection. If the object is not currently
exported, a NoSuchObjectException is thrown.

Closed, accepted

Summary: When IDLEntity types are mapped from Java to IDL, they need to be
mapped as valuetypes to preserve RMI null and sharing semantics.
For most IDLEntity types, this will require the generation of
boxed valuetypes in IDL, similarly to the mapping of Java arrays to
IDL boxed sequences.

Closed, accepted

Summary: The definition of the equals method of javax.rmi.CORBA.Stub should
say that this method returns false when used to compare stubs that
do not represent the same remote object.

Closed, accepted (see summary for text)

Summary: The mapping of a non-conforming class should be abstract valuetype,
not valuetype. This is because instances of this type are not
serializable, but instances of its subtypes are serializable.

Closed, accepted (see summary for text)

Summary: The mapping for methods and constants in non-conforming types
should be specified (by cross-reference to the words for value types).

Closed, accepted (see summary for text)

Summary: The Java to IDL mapping rules for remote interfaces and value types
should be consistent except where there is clear need for differences.

Closed, accepted

Summary: The following changes will improve the code generated for RMI/IDL Ties:

a) RMI/IDL Tie classes shall catch org.omg.CORBA.SystemException and
rethrow it (unwrapped by UnknownException).

b) Change the signature of Util.mapSystemException to
public static java.rmi.RemoteException
mapSystemException(org.omg.CORBA.SystemException ex);

c) RMI/IDL Tie classes shall throw the result from mapSystemException.

d) mapSystemException shall return the mapped exception if it is an
instance of RemoteException or a subclass, and shall throw the
mapped exception in all other cases.

This has been agreed by the RTF, but an OMG issue number is needed.

Closed, accepted (see summary for text)

Summary: The mapping of CORBA system exceptions to Java remote exceptions
omits the completion status information. This should be preserved
in the detail string.

Closed, accepted

Summary: In the javax.rmi.CORBA.Util class, the following names should be
changed for consistency with the naming convention used in this package:
write_RemoteObject to writeRemoteObject
write_AbstractObject to writeAbstractObject
This has been agreed by the RTF, but an OMG issue number is needed.

Closed, accepted (see summary for text)

Summary: The specified Java to IDL mapping for IDLEntity exception types does
not work for method parameters and results, because IDL exception
types cannot be passed as method parameters and results.

Closed, accepted (see summary for text)

Summary: The names of generated stub classes can be the same in some cases for
IIOP and JRMP. This is a source of user error and confusion.

Closed, accepted (see summary for text)

Summary: The overloaded method name mangling for the Java long type is not
specified in the spec. My suggestion is to use "long_long".

Closed, accepted

Summary: Java private methods and constructors should not be mapped to IDL.
This has been agreed by the RTF, but an OMG issue number is needed.

Closed, accepted (see summary for text)

The javax.rmi.CORBA.Tie.deactivate() method does not declare any exceptions.
However, when using a POA servant, the following exceptions can be thrown by
the RMI/IDL tie's implementation of deactivate():

org.omg.PortableServer.POAPackage.ServantNotActive
org.omg.PortableServer.POAPackage.WrongPolicy
(by the servant_to_id() method)

org.omg.PortableServer.POAPackage.ObjectNotActive
org.omg.PortableServer.POAPackage.WrongPolicy
(by the deactivate_object() method)

How should these exceptions be handled by Tie.deactivate()? If they should
be rethrown by Tie.deactivate(), what exception(s) should be used?

(This issue was raised by Max Mortazavi of Sun.)

See revised text below.

Say I have a class octet in the global scope and I have an interface

interface foo extends java.rmi.Remote

;

The operationsin IDL will now be

op_octet (octet x) and op_octet(::_octet);

which is incorrect.

closed, no change

Summary: Are we trying to support sending JRMP stubs over IIOP? If so, then
it would seem that the IDL mapping of java.rmi.Remote to CORBA::Object
works against that; it would need to be changed to Any.

See revised text below.

The Java to IDL mapping does not specify how the Java classes produced
by the forward mapping from the CORBA "any" and "TypeCode" types should
be mapped back to IDL.

Since org.omg.CORBA.Any and org.omg.CORBA.TypeCode both inherit from
IDLEntity, section 1.3.9 implies that these types should be "boxed" in
the same way as other IDLEntity types. This would imply the following
mapping to IDL:

module org {
module omg {
module boxedIDL {
module CORBA

;
};
};
};

module org {
module omg {
module boxedIDL {
module CORBA

;
};
};
};

The above raises a number of questions:

1. What is the correct IDL name for the boxed valuetype enclosing the Java "Any"
type? Is it ::org::omg::boxedIDL::CORBA::_Any or ::org::omg::boxedIDL::_any?

2. How should the hashcodes and SUIDs be computed in the above repid pragmas?
For other boxed IDLEntity Java types, these are computed from the actual
implementation classes. However, for these two types, the actual
implementation classes are ORB-specific and it seems meaningless to send
their hashcodes or SUIDs on the wire. We could either do what we do for
object references and send zeros for the hashcode and SUID, or we could
use IDL-style repids instead or RMI-style repids for these types.

3. Is it better to make these types an exception to the general rule as defined
in section 1.3.9? An alternative non-boxed mapping would be to simply map
them to the IDL/PIDL types "any" and "::CORBA::TypeCode". This would have
the drawback that RMI semantics of being able to pass nulls and maintaining
referential integrity for shared references to "by value" Java objects would
not apply to these Java types.

See revised text below.

The Java to IDL mapping spec does not explictly specify the package for the
PortableRemoteObjectDelegate interface.

The correct fully-qualified name of this interface is
javax.rmi.CORBA.PotableRemoteObjectDelegate. This is stated explictly in
Harold Carr's final proposal for issue 2478, which contained the text:

> The implementation delegate classes for PortableRemoteObject and Util must
> implement the following new interfaces:
>
> javax.rmi.CORBA.PortableRemoteObjectDelegate (per-class delegation)
> javax.rmi.CORBA.UtilDelegate (per-class delegation)

and is also implied by the text that was voted on for issue 2478, which
contained the following:

> The implementation delegate classes for PortableRemoteObject and Util must
> implement the following new interfaces for per-class delegation:
>
> package javax.rmi.CORBA;
>
> public interface UtilDelegate

The above code clearly makes both interfaces part of the javax.rmi.CORBA package.
However, when these definitions were copied into the Java to IDL mapping spec,
the interfaces UtilDelegate and PortableRemoteObject were placed in separate
sections 1.5.3.2 and 1.5.3.3, and the package statement was copied to section
1.5.3.2 but was unfortunately not copied to 1.5.3.3. This creates an ambiguity
in the published spec document, since section 1.5.3.3 does not explicitly specify
the package for PortableRemoteObjectDelegate.

Proposed resolution:

Add the line
package javax.rmi.CORBA;
to section 1.5.3.3.

See revised text below

The descriptions of readAny and writeAny in section 1.5.1.4 of the Java to IDL
mapping spec are not very precise and don't say how null values should be handled.
These methods are currently described in section 1.5.1.4 as follows:

> The writeAny method writes the Java object obj to the output stream out in the
> form of a GIOP any. The readAny method reads a GIOP any from the input stream
> in and unmarshals it as a Java object, which is returned.

Proposed resolution:

Replace the above paragraph in section 1.5.1.4 by the following:

The writeAny method writes the Java object obj to the output stream out in the
form of a GIOP any. The contents of the GIOP any are determined by applying
the Java to IDL mapping rules to the actual runtime type of obj. If obj is null,
then it is written as follows: the TypeCode is tk_value, the repository ID is
"IDL:omg.org/CORBA/ValueBase:1.0", the name string is "", the ValueModifier is
VM_NONE, the concrete base is tk_null, the member count is 0, and the any's value
is a null valuetype (0x00000000).

The readAny method reads a GIOP any from the input stream in and unmarshals it
as a Java object, which is returned. The following TypeCodes are valid for
the GIOP any: tk_value, tk_value_box, and tk_objref. If the TypeCode is anything
other than these, a MARSHAL exception is thrown.

See revised text below.

In ptc/00-01-06.pdf, the ValueHandler Interface shows method
implementations. According to Java conventions, the methods
should not be implemented in interfaces. It is requested that
this interface be updated to remove the method implementations.

Remove method implementations from the definition of the ValueHandler interface.

When I have Java exceptions called

foo
fooException
fooError

they all get mapped to the exception fooEx causing collisions.

I am not sure what the fix should be so I'll dump my thoughts here...

The correct fix for this probably should be:

foo -> fooEx
fooException -> fooExcp
fooError -> fooEr

However, given that that would not be backward compatible, another solution
would be

All exceptions map to the Ex suffix. Each collision adds an _ (underscore) at
the end, if there is a collision.

However, this has problem with the name changing depending on which exception
gets processed first, and the resultant definitions are not deterministic.

Any other ideas?

See revised text below

In 1.4.9.5, #4 of the Java 2 case:

4. If a class was not successfully loaded by step 1, 2, or 3, and loader is
non-null, then call loader.loadClass(className)

Shouldn't that really be Class.forName(className, false, loader), so that
array types are handled properly?

ClassLoader.loadClass does not handle creating new array types (it
will only find previously created array types), Class.forName does.

See revised text below.

There appears to be no way to construct a javax.rmi.ClassDesc, since the
ClassDesc class has two private members and no constructor. This is required by
non-default implementations of ValueHandler.

There are many ways to solve this issue.
1. Add a public constructor to javax.rmi.ClassDesc (preferred)
2. Make members protected so other implementations can subclass and add
constructors
3. create a factory method in say Util that returns a ClassDesc which takes the
required parameters.

See revised text below

Since Java byte values are mapped bit-for-bit to IDL (see section 1.3.3),
the same should apply to byte constants. For example, -1 should map to 255.
However, section 1.3.4.5 says that these constants are mapped to the
same values.

Proposed resolution:

In section 1.3.4.5, change "are mapped to the same values" to "are mapped
to the same values, except for byte constants which are mapped bit-for-bit.
For example, -1 maps to 255."

resolved, see below

Section 1.4.8 of the Java to IDL mapping spec says that when mapping
CORBA system exceptions to RMI exceptions, the minor code is formatted
as a decimal number. This 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).

Proposed resolution:

In section 1.4.8, change the fourth bullet to:
• followed by the hexadecimal value of the system exception’s minor code

In the following paragraph, change the example detail string to:
“CORBA UNKNOWN 0x31 Maybe”

See revised text below.