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

Summary: PortableRemoteObject.toStub should throw NoSuchObjectException if object
has not been exported.

No Data Available

Summary: The Java to IDL mapping spec says that a Java name that is an IDL
keyword is mapped to a mangled name consisting of the IDL keyword
followed by a trailing underscore. Now that the Objects By Value
RTF has adopted escaped identifiers with keading underscores, we
should revise this mapping to use escaped identifiers.
I propose that section 5.2.2 of the Java to IDL mapping spec be
changed to state that Java names that collide with IDL keywords
are mapped to IDL by adding a leading underscore, so that typedef
would be mapped to _typedef.

No Data Available

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.

See revised text below

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.

See revised text below

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)

Summary: The spec should mandate codebase annotation when marshalling in Java,
and should specify how the annotation is selected.

The spec should mandate code downloading using the codebase annotation
when demarshalling in Java, and should specify the classloader semantics.

Closed, accepted

Summary: An RMI-JRMP server creates and exports server objects and then
returns. A non-daemon thread created by the JRMP runtime keeps the
server process alive until there are no more objects exported.
For code portability, an RMI-IIOP server needs to work in a similar
way. It is not acceptable to require a call to ORB.run() or the
use of application "wait" code to keep the server process alive.

I propose that the specification of PortableRemoteObject.exportObject
be updated to say that the first call to this creates a non-daemon
thread which keeps the JVM alive until all exported objects have
been unexported by calls to PortableRemoteObject.unexportObject.

No Data Available

Summary: The ORB should be responsible for marshalling all value headers and
other protocol specific data. The RMI runtime should only marshal
the state of the object. In other words, we exepect the contract
between the ORB and RMI to be the similar to that of the ORB and
an IDL generated ValueHelper.

• The APIs should allow all RMI types supported by the IDL-Java mapping
  to be marshalled completely and correctly.

• The APIs should be flexible enough to allow for some change in either
  RMI/Serialization semantics or changes to OBV wire protocol.

Closed, accepted

Summary: The proposal here is to map Object, Serializable and Externalizable
to distinct entities, rather than just to an any.

These entities are
module java {
module lang

;
module io

;
};

and so
java.lang.Object will map to ::java::lang::_Object,
java.io.Serializable will map to ::java::io::Serializable, and
java.io.Externalizable will map to ::java::io.Externalizable

No Data Available

Summary: The full wire format produced by ObjectOutputStream really needs
to be specified. E.g., I would assume that anything written with
writeObject gets marshalled as an Any. In normal Java
serialization, consecutive primitive writes (writeByte, writeInt,
etc.) are aggregated into chunks with size lengths, and tagged
to distinguish it from other data. In this way, ObjectInputStream
can ensure that major stream corruption never occurs: it can
make sure that a primitive read never eats into object data,
and vice versa. Is a similar format used for IIOP?

Closed, accepted

Summary: The mapping of java.lang.Class to IDL is not specified. An
interesting subquestion is whether it"s possible to transmit a
Class that has not previously been mapped to IDL.

No Data Available

Summary: If a Java method explictly declares that it throws RuntimeException or
some subclass, the current spec says that these should be retained in
the mapping to IDL. I think this is wrong; they should be dropped
when mapping to IDL. The reasoning is along the same lines as dropping
subclasses of RemoteException.

No Data Available

Summary: Generated names in the ::org::omg::sequences module can clash.
For example, a Java array of type foo[][] and a Java array of type
seq_foo[] both map to ::org::omg::sequences::seq_seq_foo.

I propose that instead of using repeated "seq_" prefixes for the
array dimensions, a single prefix "seq<n>_", where <n> is the
number of dimensions, should be used. This ensures no clashes.
In the example above, these Java types would map to seq2_foo and
seq1_seq_foo.

No Data Available

Summary: There is an issue with the currently specified mapping for Java
remote and abstract interfaces containing methods that throw
superclasses of java.rmi.RemoteException but do not throw
java.rmi.RemoteException. In Java 1.1, these are not recognized
as RMI remote interfaces. In Java 1.2, these are recognized as
RMI remote interfaces.

I propose that throwing these superclass exceptions be treated by
the Java to IDL mapping as semantically equivalent to throwing
both RemoteException and the superclass exception. This means
that the section 4.3 rules for RMI/IDL remote interfaces would
be changed to include this case (in point 3), with similar changes
elsewhere in the spec.

No Data Available

Summary: The spec needs to say what happens if a Java public RMI/IDL
value class has data members whose types are not public.

Options: Either a) restrict all uses of non-public types, or
b) map all non-public types to public in IDL.

Inprise have proposed that we adopt option b). Comments?

No Data Available

Summary: Suppose we are passing an array of declared type Animal[] and
runtime type Wombat[] but whose elements are all of runtime type
Wombat, where Wombat is a subtype of Animal. This array is mapped
to a boxed valuetype in the org.omg.sequences module. In the
RMI-IIOP stub, we need to write this array by making a write_Value
call (so that sharing can be handled correctly). The repository ID
that we need to write is for a type seq_Animal, based on a static
mapping from the declared type of the array (see section 5.6 of the
Java-to-IDL spec). However, if the stub used the normal write_Value
call that takes a single argument of the object to be written, the
runtime will not be able to put the correct repository ID on the
wire because it only knows about the runtime type of the array, not
the declared type. For the IDL case, this is taken care of by
having the stub generate the form of write_Value that takes a
ValueHelper object for the declared type, but in RMI-IIOP there are
no ValueHelper objects.

closed, accepted

Summary: The Java to IDL mapping spec specifies rules for how value
methods are mapped to IDL. However, none of the examples
shows any of these methods actually being mapped. Although
this is legal according to the spec, it has led to some
confusion as to which methods would normally be expected to
be mapped, such as the writeObject method in section 5.5.9.

No Data Available

Summary: The example in section A.2 of the Java-to-IDL spec uses the
type ::CORBA::WStringValue but does not define this type.
By CORBA convention, the definition will be in the file
orb.idl, which should be #included in the example IDL code.
I propose that this example be changed to #include orb.idl.
l

:CORBA::WStringValue but does not define this type.

Summary: The Java-to-IDL spec says in section 6.6.1 that certain CORBA system
exceptions are mapped to the Java exceptions
javax.jts.TransactionRequiredException
javax.jts.TransactionRolledBackException
javax.jts.InvalidTransactionException

The names above are obsolete (since Sun revised the JTS/JTA specs),
so the Java-to-IDL spec needs to be changed. Possible mappings are:
1. javax.transaction.<the_same_names_as_above>
(as listed in the JTA spec)
2. java.rmi.RemoteException
3. No mapping (leave them as CORBA system exceptions)

Option 1 implies a dependency of the RMI-IIOP runtime on these
JTA exception classes.

No Data Available

Summary: It has concerned me for a while the use of the javax.rmi package in the Java
to IDL mapping. I think that PortableRemoteObject and other classes should be
placed in a subpackage. We may in the future put subpackages in javax.rmi and
would like it organized much better than it is currently. The
PortableRemoteObject class should be put in a subpackage "portable" or
something else. I"d like to raise this as an issue to discuss at the RTF.
There are still other issues that are being ironed out, and I think that this
one can be addressed along with the others.

Closed, no change

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.

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.

see 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.

Summary: There is currently no standard support for local RMI/IDL stubs.
In contrast, the IDL/Java mapping specifies how support for local
stubs is to be provided. The Java to IDL mapping should also
specify standard APIs for local stubs which are compatible with
the POA and the mechanisms used by IDL/Java local stubs.

closed, accepted

Summary: In section 7.1.2, there is a method called read_AbstractObject(clz).
I propose that we change its name to read_Abstract to bring it
into line with the read_Abstract() method introduced in section
8.7.1 of the OBV spec. This is consistent with having methods
called read_Object() and read_Object(clz).

There"s also a typo in section 7.2.6. It says that
Util.write_AbstractObject calls OutputStream.write_AbstractObject.
This should say OutputStream.write_Abstract.

No Data Available

Summary: orbos/98-02-01 says:

We have provided name manglings to work around [the limitations],
but we recommend that OMG consider extending the definitions of
IDL identifiers so that a wider range of unicode characters can
be supported and so that case is significant in distinguishing
identifiers.

I would suggest to remove this recommendation because it is pragmatically
unimplementable for implementation languages that do not support
extended character sets. If the OMG were to take this step, it would
effectively alienate CORBA from all such implementation languages, which
I believe would be detrimental to the success of CORBA.

Because overloaded methods are a popular feature in object-oriented
programming languages we recommend that OMG considers extending
IDL to allow overloaded methods.

Again, I suggest to remove the recommendation because it is pragmatically
unimplementable. Steve Vinoski recently posted an interesting article
on this topic in comp.object.corba – I have attached a copy below.

No Data Available

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.

Three of the new portability APIs intorduced by the Java to IDL mapping
are declared as throwing org.omg.CORBA.SystemException. These are
the _invoke methods of ObjectImpl and Delegate and the _invoke method
of InvokeHandler. I don"t think this exception hould be declared
explicitly, since it is a subclass of java.lang.RuntimeException and so
is always implictly throwable whether it is declared or not. Also,
other portability APIs can throw this exception even though they do not
declare it explicitly. This inconsistency makes it very difficult for
the reader of the spec to determine which of the portability APIs can
throw CORBA system exceptions, and is likely to cause confusion.

I propose that org.omg.CORBA.SystemException be removed from the throws
clause of the above-mentioned APIs.

No Data Available

Summary: RMI/JRMP stubs provide overridden implementations for the
hashCode, equals, and toString methods of java.lang.Object.

The stub hashCode method returns the same hash code for
different stubs that refer to the same remote object.
The stub equals method returns true when stubs that refer
to the same remote object are compared. These methods allow
remote objects to be held in Java collections.

The stub toString method returns a string containing information
about the remote object, not the local stub.

RMI/IIOP stubs should provide equivalent methods. The easiest
way to do this is to add implementations of these three methods
to the javax.rmi.CORBA.Stub base class.

I propose that the definition of javax.rmi.CORBA.Stub in
section 7.2.5 be modified to add these methods.

No Data Available

Summary: The generated IDL in A2 needs to be changed.

In particular, forward declares for fred.Test2 and fred.Stuff must
appear before #includes, before sequence defs and before the module
definition. Their #includes must appear at the end. In fact, just follow
the file layout rules described at the beginning of the appendix.

If this is not done, there is a danger that circular references will
lead to undeclared types when the IDL is compiled.

Proposed resolution: fix example

No Data Available

Summary: 17. Need to clarify rules for mapping server-side errors and runtime
exceptions back to client exceptions.

Proposed resolution: use omg.omg.CORBA.UNKNOWN

No Data Available

Summary: In section 5.7.4 the mapped IDL for Thrower includes:
FruitbatException getLastException();
It should be
readonly attribute ::omega::FruitbatException lastException;

No Data Available

Summary: 12. Narrow signature does not allow use for abstract interfaces

Proposed resolution: return java.lang.Object

No Data Available

Summary: 25. Should exportObject throw exceptions?

No Data Available

Summary: Rules in section 7.4.4 for toStub IIOP/JRMP search aren"t quite correct.
If the object has been exported as IIOP (i.e., an IIOP Tie exists),
no attempt will be made to create a JRMP stub even if there is no IIOP
stub class.

Proposed resolution: clarify spec

No Data Available

Summary: The text in section 5.4.5 has no mention of String constants.
This seems to be an accidental omission. I propose replacing
the text in this section by the text in section 5.5.5, with
"value type" changed to "interface".

No Data Available

Summary: The current Java to IDL mapping spec does not fully address support
for abstract interfaces. There is support for these in the
Portability Interfaces chapter, but not in the RMI/IDL Subset or
IDL Mapping chapters.

No Data Available

Summary: Do we need to protect non-generated IDL files against multiple
inclusion?

Proposed resolution: no protection

No Data Available

Summary: Need to define a mangling rule for name clashes in IDL between
constant/method/attribute.

No Data Available

Summary: Lexigraphic sort for field names is before mangling

Proposed resolution: clarify section 5.5.6

No Data Available

Summary: 10. Need to emit ID pragmas after declarations

No Data Available

Summary: 15. does toStub return most derived stub, or iterate looking for one?

No Data Available

Summary: Can toStub take a stub?

Proposed resolution: yes, in which case it"s a no-op.

No Data Available

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.

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

catch (Throwable ex)

finally

}
}
}

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.

see below

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

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

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

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

Summary: mapping for nested sequences:

• error in section 5.6 sequence<seq_Y>
• no occurrence of >> so no need for white space

Proposed resolution: fix example in section 5.6

No Data Available

Summary: The Unicode example given in the spec (5.2.4) is x\u22aBy
javac diagnoses \u22aB as an invalid character in an identifier.

A Java identifier may only consist of Unicode characters that denote a
letter or a digit in a language. \u22aB (apparently) does not.

Try \u03bC instead. According to 8.2.1 it"s a Greek mu. javac is happy
with it.

Proposed resolution: fix example

No Data Available

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the Objects By Value RTF because it affects the Java
ORB implementation of Objects By Value.

The currently specified delegation relationship between
SerializationInputStream and SerializationOutputStream and their
underlying ORB stream classes is inefficient and awkward.
It is awkward because it requires the ORB implementation of the
underlying streams to know about their "wrapper" serialization
streams and to be careful to always pass out a reference to the
wrapper instead of a "this" pointer. It is inefficient because
all items (even primitives) that are written to these streams
need to go through an extra delegation step through the wrapper
class as the underlying stream does not know whether it can
safely bypass the wrapper method.

No Data Available

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.

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.

When adding support for idlToJava generated Stubs to
"InputStream.read_Object(java.lang.Class clz)" we ran into a small
problem while writing the code. Initially we used "clz.newInstance()"
to create an instance of the Stub object. The problem here is the
Stub does not have a default constructor, so newInstance throws an
exception. We added a default constructor to the stub and everything
worked fine. The question is: should we add a default constructor to
the stubs generated by idlToJava or should we use reflection(cost??) to
invoke the one constructor that is already a member of the stub class?

I propose that we state in the spec that a default constructor is
required on all generated Stubs.

No Data Available

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.

How do SerializationInputStream and SerializationOutputStream marshal
Any, Context, Principal, and TypeCode objects? Is the same mechanism
used as for user-defined IDL types, i.e., look for the IDLEntity
marker interface and call the implementation helper class"s write
or read method? If so, we need to clarify that vendor implementation
of these types must implement IDLEntity and provide a Helper class.

I propose that we state in the spec that vendor implementations of
these types must implement IDLEntity and provide a Helper class.

No Data Available

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.

There are two places in the Java to IDL mapping spec that imply
the use of a default ORB. One is the toStub method of the
PortableRemoteObject class, and the other is the readObject method
of the javax.rmi.CORBA.Stub class. It is not clear how we can
obtain a suitable default ORB for use in these APIs without either
excessive resource consumption (if we start a new ORB every time)
or violating applet isolation boundaries (if we use the same ORB
every time).

Closed, accepted

Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of
concern to the IDL-to-Java RTF because it affects the IDL-to-Java
mapping.

The Java to IDL mapping spec states that Java types produced by
the direct mapping should implement IDLEntity and be serializable.
This could be accomplished by having IDLEntity extend
Java.io.Serializable, or by having the generated types extend
both IDLEntity and java.io.Serializable. The spec should
specify which of these approaches is to be used.

No Data Available

Summary: This item affects the Java-to-IDL spec, but is also of concern to the
IDL-to-Java RTF because it relates to the new portability stub APIs.

Section 7.2.2 of the Java to IDL mapping specifies a new interface
ResponseHandler with methods createReply and createExceptionReply.
These methods are declared as public.

Section 9.4 of the Java Language Specification states that "Every
method declaration in the body of an interface is implicitly public.
It is permitted, but strongly discouraged as a matter of style, to
redundantly specify the public modifier for interface methods."

I propose that the public modifier be removed from these method
declarations.

No Data Available

Summary: This item affects the Java-to-IDL spec, but is also of concern to the
IDL-to-Java RTF because it relates to the new portability stub APIs.

An orb() method is needed on org.omg.CORBA.portable.InputStream for
SerializationInputStream to call to find which ORB to use for
lookup_value_factory during execution of read_Value.

I propose adding an orb() method to org.omg.CORBA.portable.InputStream.

No Data Available

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, ..."

see above

A Serializable or Externalizable can define methods which take
java.io.ObjectOutputStreams. There are four methods on that class
that are well defined in Java, but the mapping to CORBA may need to be
clarified:

writeByte(int)
writeChar(int)
writeBytes(String)
writeChars(String)

Please see the Java docs for these methods:

http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeByte(int)
http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeChar(int)
http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeBytes(java.lang.String)
http://java.sun.com/j2se/1.3/docs/api/java/io/DataOutput.html#writeChars(java.lang.String)

Based on those detailed definitions, I'd say the mapping would be:

writeByte(int)

• write_octet of the lower 8 bits of the int

writeChar(int)

• two write_octet calls in the order as shown in the java docs

writeBytes(String)

• For each char in the String, call charAt, take the lower 8 bits, and
  call write_octet

writeChars(String)

• For each char in the String, call charAt, split the char into two
  bytes, and make two write_octet calls in the order shown in the java
  docs

Another interpretation might be to use wstrings or wchar arrays for
writeChars. The problem I see there is that since there isn't a
readChars method, the user will be using the DataInput methods
readFully or multiple readChar calls to reconstruct the String. Since
the wire format of wstrings/wchars depends on the code set, he might
start to see code set specific bytes instead of the expected bytes
detailed in the java docs of writeChars and writeChar.

see below

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, ...

Closed, accepted. See revised text below

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

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) )

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

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

try

catch ( Throwable ex )

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();

Closed, accepted. See revised text below.

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.

see below

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.

Closed, accepted. See revised text below

"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 !

Closed, accepted. See revised text below