Java serialization supports the serialization of proxy classes explicitly. It does this by essentially marshaling into the stream the list of interfaces that the proxy implements and on the other end calling Proxy.getProxyClass() with those interfaces. In RMI-IIOP the proxy class ends up coming across the wire with a repository ID of RMI:\U0024Proxy0:2D4A76C198E9D8DA:0000000000000000 (i.e. $Proxy) which is not a real class and cannot be loaded by the client.

I think we probably need to mandate specific behaviour for proxy classes along the lines of the java serialization spec. A simple approach might be to mandate that the valuetype contain a list of repids, the first being the pseudo-repid for the proxy itself and the other being the repids of the interfaces the proxy supports. The actual data would be that of the proxy itself which is basically the InvocationHandler.

Section 1.6.1 states:

"A call to exportObject with no objects exported creates a non-daemon thread that
keeps the Java virtual machine alive until all exported objects have been unexported by
calling unexportObject."

However, there is no implicit way to unexport objects and so this places the burden on the users to do so. It may be that users are not exporting objects themselves but using some layered product that does so - in this case they would have to call a shutdown API in order for their program to exit. All of these solutions are non-intuitive and not helpful to the user who forgets to call the requied API - their program just does not exit.

I would like to suggest that this behavior be configurable in some way, either via exportObject or via properties so that users and implementors can choose whether or not a particular exported object should cause the VM to stay alive.

Consider the following Java classes:

public class A implements java.io.Serializable

public class B extends A {
// B's data – omitted here
// B's cobstructors – omitted here

// This is a custom class
private void writeObject(java.io.ObjectOutputStream s)

// Other methods omitted
}

Here we have a class inheritance hierarchy as D:C:B:A with A and C as non-custom classes, B and D as custom classes. What is the rmi-iiop data layout on the wire when an instance of D is marshaled in terms of customer header and data w.r.t. to each of the super classes? Which one of the following layout is correct?

-----------------------------------------------------------------------------------------
a. | A-Data | B-FV B-DWO B-Data | CData | FV-D DWO-D DData |
-----------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------------
b. | A-FV A-DWO A-Data | B-FV B-DWO B-Data | C-FV C-DWO C-Data | D-FV D- DWO DData |
-------------------------------------------------------------------------------------------------------------------------------

----------------------------------------------------------------------------
c. | A-FV A-DWO A-Data | B-Data | C-Data | DData |
---------------------------------------------------------------------------

Terms used for illustration purpose here:

A-FV ------ means the Format version octet for class A
A-DWO ------ means the defaultWriteObject boolean flag for class A
A-Data ----- means the data fields of class A.

B-FV ------ means the Format version octet for class B
B-DWO ------ means the defaultWriteObject boolean flag for class B
B-Data ----- means the data fields of class B

C-FV ------ means the Format version octet for class C
C-DWO ------ means the defaultWriteObject boolean flag for class C
C-Data ----- means the data fields of class C.

D-FV ------ means the Format version octet for class D
D-DWO ------ means the defaultWriteObject boolean flag for class D
D-Data ----- means the data fields of class D.

I have noticed that the Sun ORB generates RepositoryIds for primitive types when generating a FullValueDescription that looks like this:

RMI:int:000000000000000000

Now you could argue that the type of int is Integer.TYPE and the function getName() on this class does indeed return "int" however there are explicit mappings for primitive types (int -> IDL long) and this just seems wrong to me.

Should the repid be null or something else? Does it matter?

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

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

The javax.rmi.CORBA.Stub class defined in the Java to IDL
specification does not explicitly define its serialVersionUID, yet
this value is crucial for interoperability. The sender's Stub
repository ID must be compatible with that of the receiver.

Without a standard value, even compiler differences can affect the
serialVersionUID.

In our case, we removed an unnecessary protected constructor before
our J2SE 1.4.0 implementation shipped. Unfortunately, this broke
interoperability with our (and others') previous implementations, and
it is seriously affecting one of our customers.

We would like to standardize the following (older) value so we can
then patch our 1.4.0 implementation:

Proposed resolution:

Add the following serialVersionUID to the Stub class in Java to IDL
(ptc-02-01-12) 1.5.1.2:

// Java
public abstract class Stub
extends org.omg.CORBA_2_3.portable.ObjectImpl
implements java.io.Serializable

Closed, accepted. See proposed revised text below

The resolution for issue 3151 does not make it clear how to encode a custom
valuetype that has no optional custom data. This includes custom types
whose writeObject() method calls defaultWriteObject() but writes no additional
data, and custom types that don't write any data at all.

Tihs case could be handled by always writing the org.omg.customRMI.* wrapper
even if there is no data inside of it. However, this is very wasteful of
space. A better approach would be to write a null valuetype (0x00000000) to
indicate the omission of the optional data. The optional data cannot be omitted
entirely, since the receiver would not be able to correctly parse the stream.

Proposed resolution:

Change paragraph "d" in section 1.4.10 from the following:

d. (optional) Additional data written by writeObject, encoded as specified below.
For format version 1, the data is written "as is". For format version 2, the
data is enclosed within a CDR custom valuetype with no codebase and repid
"RMI:org.omg.custom.<class>" where <class> is the fully-qualified name of the
class whose writeObject method is being invoked.

to the following:

d. Additional data written by writeObject, encoded as specified below. For format
version 1, this data is optional and if present must be written "as is". For
format version 2, if optional data is present then it must be enclosed within a
CDR custom valuetype with no codebase and repid "RMI:org.omg.custom.<class>"
where <class> is the fully-qualified name of the class whose writeObject method
is being invoked. For format version 2, if optional data is not present then a
null valuetype (0x00000000) must be written to indicate the absence of optional data.

Closed, accepted. See proposed revised text below

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

Thought I would raise this as a formal issue.

The spec is ambiguous about mapping boolean accessors when in the following cases

boolean isFoo ();
void setFoo(boolean x);

and

boolean getBar();
boolean isBar();
void setBar(boolean x);

According to the spec, both of the above get mapped to attributes. But, an attribute has only one getter and one setter.
So, the question is what is isBar represented as on the wire? And how is the distinction made between isBar and getBar?

Two ideas I can think of are
1. Drop isBar from being recognized as a getter for attribute bar.
2. Have isBar be represented on the wire as _get_bar. This has the effect of the two methods collapsing into
one on the receiving context, which is probably OK because they should semantically be equivalent anyway.

No Data Available

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

The spec does not define what happens when a null object reference is passed to
PortableRemoteObject.narrow(). For consistency with xxxHelper.narrow(), I think
it should return null.

No Data Available

Summary: The Java to IDL mapping specifies that Java constructors are
mapped to IDL initializers. Now that core RTF issue 1981 has
replaced IDL initializers by factory methods, this mapping is
broken and inconsistent with the core chapters.

No Data Available

There is a commonly occurring name collision that is not covered by the
current name mangling rules. This is demonstrated by the Java to IDL mapping
of java.util.Date. The IDL generated gives a custom valuetype "Date" which
contains an attribute "date", which is illegal in IDL. This problem is not
unique to java.util.Date.

More generally, this collision occurs whenever a Java interface or class
being mapped to IDL contains a method or data member with the same name
as the interface or class (using a case-insensitive comparison). For example,
the following Java definitions cause this problem:

No Data Available

Does the serialVersionUID field need to be private, static, and final,
or just static and final? The Java to IDL spec says private, static,
and final, but as far as I can tell, regular Java serialization just
uses static and final. This has been a source of confusion for a number
of users.

No Data Available

Summary: We should consider whether a Java class that has a writeReplace or a
readResolve method (with the appropriate signature for use by object
serialization) should map to a custom valuetype in IDL instead of
a normal valuetype. We should also think harder about the impact
of writeReplace/readResolve semantics on non-Java ORBs: can non-Java
implementations properly receive and send instances of such classes,
maintaining all the proper sharing, without running into type checking
problems, and without any additions to non-Java ORBs?

No Data Available

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: Moving forward to JDK 1.2, the IDL value type data mapping needs
to factor in the new serialPersistentFields declaration. And there"s
an interesting question whether the existence of a writeReplace method
should influence the decision to map to a custom value.

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

Java to IDL Language Mapping Specification doesn't cover the mapping for Java enum from JDK 1.5. We propose the following mapping to be included in the specification. Mapping for Enumeration: When used as a parameter, return type or member variable, Java enum in JDK 1.5 is mapped to the OMG IDL type ::javax::rmi::CORBA::EnumDesc. The corresponding representation in Java class is: package javax.rmi.CORBA; public class EnumDesc implements java.io.Serializable

The mapping in IDL will be: module javax { module rmi { module CORBA { valuetype EnumDesc

; #pragma ID EnumDesc "RMI:EnumDesc:aaaaaa:xxxxxxxxx" }; }; };

No Data Available

The CORBA activity specification (Additional Structuring Mechanisms for
the OTS, v1.0, OMG document formal/02-09-03) introduced three new system
exceptions (INVALID_ACTIVITY, ACTIVITY_COMPLETED, and ACTIVITY_REQUIRED)
that were incorporated into CORBA 3.0.

The JCP J2EE Activity Service for Extended Transactions (JSR 95) adds
three equivalent exceptions
javax.activity.InvalidActivityException
javax.activity.ActivityCompletedException
javax.activity.ActivityRequiredException
to the Java platform.

The Java to IDL mapping should be extended to map these CORBA exceptions
to the equivalent Java activity exceptions, just as the three CORBA
transaction system exceptions are currently mapped to the equivalent
JTA exceptions in the javax.transaction package.

Proposal:

In section 1.4.8, add the following rows to table 1-2:

CORBA Exception RMI Exception
--------------- -------------
INVALID_ACTIVITY javax.activity.InvalidActivityException
ACTIVITY_COMPLETED javax.activity.ActivityCompletedException
ACTIVITY_REQUIRED javax.activity.ActivityRequiredException

No Data Available

We have recently found an interop problem with another Vendor's orb and wanted some clarification on the customer marshaling format wrt defaultWriteObject. 1.4.10 says:

For serializable objects with a writeObject method:
b. boolean - True if defaultWriteObject was called, false otherwise.

However it is mute on the subject of writeFields and readFields. The Java serialization spec indicates that defaultWriteObject and writeFields are somewhat equivalent, so (a) one could argue that the boolean should be true if writeFields has been called. (b) One could also argue that the spec doesn't say this and so the boolean should be false. My feeling is that (a) is correct (and this is what the other orb does) but that it should be called out explicitly in the spec.

Comments appreciated

No Data Available

We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says:

"Other Java objects are marshaled in the form of an
IDL abstract interface (i.e., a union with a boolean discriminator containing either an
object reference if the discriminator is true or a value type if the discriminator is false)."

However, the Java/IDL spec does not mandate that all Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2.

Clarification appreciated

No Data Available

Section 1.3.2.4 of the Java to IDL Mapping spec describes name mapping rules
for illegal IDL identifier characters. The text implies that only non-Latin 1
characters are illegal, but in fact non-ASCII characters are illegal in IDL
identifiers (see section 3.2.3 of the CORBA spec).

Proposed resolution:

In section 1.3.2.4, change "outside of ISO Latin 1" to "outside of ASCII".

In section 1.3.2.4, change "outside of ISO Latin 1" to "outside of ASCII".

We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says:

"Other Java objects are marshaled in the form of an
IDL abstract interface (i.e., a union with a boolean discriminator containing either an
object reference if the discriminator is true or a value type if the discriminator is false)."

However, the Java/IDL spec does not mandate that all Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2.

Clarification appreciated.

No Data Available

Questions have come up recently about copyObject behavior, both within Sun and from customers.
The main question is whether it is necessary to actually copy immutable objects, or can copyObject( obj )
simply return obj for immutable objects. The standard immutable
objects in question are String and the primitive type wrappers (Integer etc.).

Looking at ptc/02-01-12, the main part of the specification that is relevant is section 1.5.1.6,
on the bottom of page 1-52. The statement is made here that "(copyObject and copyObjects) observe
copy semantics for value objects that are equivalent to marshalling, ...". What exactly does
equivalent mean here?

It seems to me that the most important property here is that any sequence of method invocations
made by the "client" do not affect the results of any sequence of method invocations made by
the "server" (or vice-versa). This is normally the case for immutable objects that are copied by reference.
However, locking of an object passed by reference is possibly observable. Normally, the
"client" and the "server" in the colocated case are actually running on the same thread, but
each role could pass object obj and copyObject(obj) to a different thread. Different results
are then possible for the copy/non-copy case, depending on the locking behavior of the threads.

There are old parts of the rmic -iiop code and the Sun ORB, dating from the days when Sun and IBM
were jointly developing RMI-IIOP, that show evidence of both possible interpretations. For
example, StubGenerator.mustCopy( TYPE_STRING ) returns false, so that a method that takes
only one or more String arguments would not have a call to copyObject(s) generated in the stub.
However, the implementation of Util.copyObject(s) always copies String instances.

I would like to see the text clarified in the specification to explicitly state whether immutable
objects need to be copied or not.

No Data Available

1. The Java to IDL mapping spec defines the ValueHandler.getRunTimeCodeBase() that returns an CORBA object reference of SendingContext::RunTime to be used to construct the SendingContextRunTime service context:

org.omg.SendingContext.RunTime getRunTimeCodeBase();

However, the ValueHandler is not ORB aware of, how should the object reference be constructed by the ValueHandler? More specifically, how should the ValueHandler get a handle of a POA and which POA to create the reference?

2. Similar issue exists in PortableRemoteObject.exportObject() and PRO constructor:

protected PortableRemoteObject() throws java.rmi.RemoteException;
public static void exportObject(java.rmi.Remote obj) throws java.rmi.RemoteException;

The spec says:

"Server side implementation objects may either inherit from javax.rmi.PortableRemoteObject or they may simply implement an RMI/IDL remote interface and then use the exportObject method to register themselves as a server object"

The PRO is again not ORB aware of, how should the remote object be exported and registered with a POA and with which POA?

3. The spec needs to clearly indicate on who owns the creation/initialization of the ORB. Should rmi-iiop implementation implicitly create/initialize an ORB instance at some point of time? Or should the RMI-IIOP application create/initialize an ORB instance and pass into the RMI-IIOP implementation via certain APIs?

Closed, accepted. See revised text below

The Java to IDL specification uses the IOR TaggedComponent
TAG_JAVA_CODEBASE to transmit a codebase string used to download stubs
and ties. Yet, at IOR creation time when using the POA, the ORB may
not know the implementing servant, so may not be able to determine the
correct codebase.

I propose solving this by the creationg of a standard POA Policy for
the Java codebase component. A POA using this policy will add the
given codebase string as the TAG_JAVA_CODEBASE component in the IORs
which it creates. (Someone using a single given POA for supporting
multiple servant types would of course have to include the codebases
for all of them.)

Proposed resolution:

1. Add a section in CORBA 11.3.7:

11.3.7.x Java Codebase Policy

Objects with the JavaCodebasePolicy interface are obtained using the
ORB::create_policy operation and passed to the POA::create_POA
operation to specify the TAG_JAVA_CODEBASE TaggedComponent's value
that should be used in this POA's IORs. The any passed to
ORB::create_policy should contain a string which is a space-separated
list of one or more URLs, as described in the Java to IDL mapping
(formal/01-06-07), Codebase Transmission.

2. Add the following to the IDL in CORBA 11.4:

const CORBA::PolicyType JAVA_CODEBASE_POLICY_ID = nn;
[note to editor: number to be assigned by OMG]

local interface JavaCodebasePolicy : CORBA::Policy

;

see above

You know, this scheme for mapping names is pretty byzantine. As far as I can tell, if you happen to name a java variable J_Fred, you've got problems. I'm sure you get plenty of suggestions. Here's mine:

1) Underscore is used consistently as an escape character. Thus: _ -> __ $ -> _S \u1234 -> _U1234 ( -> _P (parenthesis) [ -> _B (bracket) ; -> _C (semiColon) / -> _F (forward slash)

_U uppercases a single character doRecord -> DO_URECORD

A indicates that the entire name is in uppercase MAX_VALUE -> _AMAX_VALUE

2) inner classes - we replace the dot with a $, and use that as the name. This is how most java compilers produce inner classes.

3) Overloaded names - In the case of overloaded names, then rather than using the simple name of a method or variable, we use the converted name as it is defined in the java virtual machine specification, section 4.3. This is an already existing standard for uniquely identifying members in java classes. As methods are identified by parameters (ie: we don't need the return types to distinguish them), we can ignore the closing parenthesis and return type of a Method Descriptor.

However, we use lowercase for the characters in table 4.2 so that our underscore escaping doesn't expand out foo(I to foo_P_UI

thus: int FOO int foo void foo() Object foo(int) long foo(int[]) a.b.Boz foo(a.b.Bar.Baz)

become

FOO foo foo( foo(i foo([i foo(la/b/Bar$Baz;

which are encoded by the rules above to

_AFOO FOO FOO_P FOO_PI FOO_P_BI FOO_PLA_FA_F_UBAR_S_UBAZ_C

These are not very natural ... but there you go. Serves you right for attempting to use IDL for overloaded names.

If IDL had an name ailiasing facility (maybe it does), then all classes and methods could be generated as above and used as such in generated code, and an alias produced for those names which map unambiguously to a particular field or value.

Thus for doAThing(int), all generated code would use DO_UA__UTHING_PI, but an alias DOATHING would be generated and presumably used by coders.

see above