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

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

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

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

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

1.2.3 RMI/IDL Remote Interfaces 2. All methods in the interface are defined to throw java.rmi.RemoteException or a superclass of java.rmi.RemoteException.

Should this read " ... or a subclass of ..." as per point 4 and elsewhere?

see above