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

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

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

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

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