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?

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

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