As we all know, naming things is the hardest part.
I am writing this as a general reply to the concerns that Simon Nash,
Ann Dalton, and Franz Hauck have raised about packaging of new APIs.
This is also relevant to the discussion Simon and I had about a
relevant JCK rule (I'm still waiting on details from the JCK team at
Sun on that one).

I want to focus on just the ORB methods here, which seems to be the
major problem, although the same ideas should apply elsewhere.

The APIs that we are talking about are:

New in CORBA_2_5.ORB (which extends CORBA_2_3.ORB) :
ORB.id
ORB.create_local_interface_tc
ORB.register_initial_references

In CORBA_2_3.ORB:
ORB.register_value_factory
ORB.unregister_value_factory
ORB.lookup_value_factory
ORB.get_value_def
ORB.set_delegate

This affects the following issues:
4741 (register_initial_reference)
4559 (create_local_interface_tc)
moving CORBA_2_3 APIs into CORBA (I have not yet filed this)
4699 (is_a support on local interfaces)
need support for ORB::id (no issue for this yet)

(4699 does not involved ORB methods, but it's the same issue, because
vendors have shipped PI implementations before is_a support became
necessary on local interfaces).

Here are the goals I would like to achieve:

1. Add new methods to the CORBA ORB so that users have a better API.

2. Make CORBA_2_3::ORB methods available in CORBA::ORB.

3. Still support user code using the CORBA_2_3::ORB methods.

4. Allow JDK 1.3 licensees to implement the new features legally.

5. Allow CORBA 2.3 ORB implementations to work unchanged with the
CORBA 2.5 APIs.

Proposal:

1. Add all the CORBA 2.5 methods to CORBA.ORB as concrete methods that
throw NO_IMPLEMENT.

2. Also add all the new methods to CORBA_2_5.ORB as concrete methods
that throw NO_IMPLEMENT.

3. Copy all of the CORBA_2_3 methods to CORBA.ORB (all of which are
currently concrete methods that throw NO_IMPLEMENT).

To evaluate my proposal, let's consider the different combinations of
JDK and CORBA versions:

• JDK:
  1.3: No endorsed classes mechanism, CORBA 2.3 ORB
  1.4: Endorsed classes mechanism, CORBA 2.3 ORB
  1.5: Endorsed classes mechanism, CORBA 2.5 ORB

• CORBA:
  2.3: the current standard in JDK 1.3, and also ptc/01-10-20
  2.5: the next version, probably aligned with the CORBA 3.0
  standards

Results:

CORBA 2.5 on JDK 1.5:
This is what Sun will ship in JDK 1.5.
Other vendors can use the files in JDK 1.5, or replace with a
later version if desired.
User writes new code to CORBA.ORB.
User code written to CORBA_2_3.ORB and CORBA_2_5.ORB still works.

CORBA 2.5 on JDK 1.4:
Vendor swaps in CORBA 2.5 files.
User writes new code to CORBA.ORB.
User code written to CORBA_2_3.ORB CORBA_2_5.ORB still works.

CORBA 2.5 on JDK 1.3:
Vendor adds new CORBA_2_5 package. CORBA.ORB is unchanged.
User codes to CORBA_2_5.ORB
User code written to CORBA_2_3.ORB still works.

CORBA 2.3 on JDK 1.5:
Vendor ORB works unchanged: new 2.5 features are not supported.

CORBA 2.3 on JDK 1.4:
This is what Sun ships in JDK 1.4.
Vendor ORB works unchanged.
User code works unchanged.

CORBA 2.3 on JDK 1.3:
This is the baseline that everyone has

Incorporate joint resolution changes and close issue

The portable interceptors specification added a new method to the
ORB for registering initial references. This method needs to
be added to the standard org.omg.CORBA.ORB class.

We should simply add the register_initial_reference method to
org.omg.CORBA.ORB and not create another version of the ORB
class for this purpose.

Proposed Resolution: Incorporate edits and close issue

Revised Text:

In section 1.19.10
in the PIDL section, add before resolve_initial_references:

void register_initial_reference( in ObjectId identifier,
in Object obj ) raises (InvalidName) ;

in the Java section, add before resolve_initial_references:

public void register_initial_reference( String id,
org.omg.CORBA.Object obj ) throws InvalidName ;

Also update the org.omg.CORBA.ORB class in the omg.zip file.

Incorporate joint resolution changes and close issue

It would be much better for CORBA users if the methods are currently
in org.omg.CORBA_2_3.ORB were available in the org.omg.CORBA.ORB class.
The best approach seems to be simply to copy the method definitions
into the ORB class.

Incorporate joint resolution changes and close issue

The resolution to issue 4699 introduced a new method in
org.omg.CORBA.LocalObject as follows:

abstract public String[] _ids() ;

Unfortunately this causes a big problem for current users of
portable interceptors: any user of PI who implements a local
interface (for example ServerRequestInterceptor) according to the
CORBA 2.5 spec will have written code that will not function correctly
under the CORBA 3.0 revision, due to the addition of this new abstract
method.

The fix for this is simple: just change the _ids method to

public String[] _ids()

This causes the _is_a method to always return false for old implementations
of local interfaces, which is a reasonable result, since old implementations
were written before is_a support was available.

Incorporate revised text and closed issue

The CCM (ptc/01-11-03) has added exceptions to attributes.
The IDL to Java mapping needs to be updated to reflect this addition.
Also, the mapping currently says essentially nothing about the mapping of
exceptions
on operations or attributes in any context.

Proposed revised text:

In section 1.13.2, replace the paragraph

The mapped Java class contains abstract method definitions that correspond
to the operations and attributes defined on the value type in IDL.

with

The mapped Java class contains abstract method definitions that correspond
to the operations and attributes defined on the value type in IDL.
Attributes
are mapped in the same way as in interfaces, to modifer and accessor
methods.
Exceptions are mapped as follows:

1. If an operation raises exceptions, then the corresponding Java method
must throw
Java exceptions corresponding to the listed IDL exceptions.

2. If a readonly attribute raises exceptions, then the Java read accessor
method must throw
Java exceptions corresponding to the listed IDL exceptions.

3. If an attribute has a getRaises clause, the the Java accessor method must
throw Java exceptions corresponding to the listed IDL exceptions.

4. If an attribute has a setRaises clause, the the Java modifier method must
throw Java exceptions corresponding to the listed IDL exceptions.

In section 1.12.1, replace the third paragraph with the following two
paragraphs:

The Java operations interface contains the mapped operation signatures.
If an operation raises exceptions, then the corresponding Java method must
throw
Java exceptions corresponding to the listed IDL exceptions.

The Java signature interface extends the operations interface, the (mapped)
base org.omg.CORBA.Object, as well as org.omg.portable.IDLEntity.
Methods can be invoked on the signature interface. Interface inheritance
expressed in IDL is reflected in both the Java signature interface and
operations interface hierarchies.

In section 1.12.1, insert after the sixth paragraph:

Attribute exceptions are mapped as follows:

1. If a readonly attribute raises exceptions, then the Java read accessor
method must
throw Java exceptions corresponding to the listed IDL exceptions.

2. If an attribute has a getRaises clause, the the Java accessor method must
throw Java exceptions corresponding to the IDL exceptions listed in the
getRaises clause.

3. If an attribute has a setRaises clause, the the Java modifier method must
throw Java exceptions corresponding to the IDL exceptions listed in the
setRaises clause.

Incoporate the revised text and close the issue

The CORBA components updates to the Interface Repository defined in ptc/01-11-03
include the addition of exceptions on valuetype initializers. There is a
separate
issue that is required to change the IDL grammar and other text in chapter 3
to include this. For the purposes of discussion in this issue,
I am assuming that the appropriate syntax is:

<init_dcl> ::= "factory" <identifier> "(" [ <init_param_decls> ] ")" [
<raises_expr> ] ";"

Proposed revised text:

In section 1.13.2, replace the paragraph that begins "The value type's generated
value factory" with:

The value type's generated value factory interface extends
org.omg.CORBA.portable.ValueFactory and contains one method corresponding to
each
factory declared in the IDL. The name of the method is the same as the name
of
the factory, and the factory arguments are mapped in the same way as in
parameters
are for IDL operations. If the factory raises exceptions, then the
corresponding
Java method must throw Java exceptions corresponding to the listed IDL
exceptions.

Incorporate the revised text and close the issue

We here at Nortel Networks use CORBA extensively. However, we
have a question regarding the use of Java null, and the most
recent OMG spec seems to have some mixed messages.

Section 1.4.1.5 has been there for some time, and it is pretty
clear what is legal and what is illegal.

However, in section 1.4.1.4, it seems to say that in the Holder
class, the Java Strings are initialized to null rather than "".

We are asking this question because it is affecting one of
our software products. We are getting org.omg.CORBA.BAD_PARAM
exception once in a while.

We are using Sun's JRE ORB(JRE 1.3.1_01).

close issue no change

Note: this is NOT issue 3754, but it is related. A new issue is needed
as described below:
--------------------------------------------------------------------------
Issue 3754 (colocated call optimization and portable interceptors) was
raised some time ago by Harold Carr. This issue discusses the problems
of supporting portable interceptors for RMI-IIOP calls when the colocated
call optimization is used. The basic issue is that there is no way for the
ORB to detect whether a local dispatch to a servant completed normally or
completed by throwing an exception. This problem exists because the
current is_local/servant_preinvoke/servant_postinvoke mechanism has no
way to report normal or exceptional completion of a local dispatch.

The same problem arises in the IDL stub case as well.
Both Java mappings can share the same solution here, but a solution requires
changing part of the portable stub API which is shared by both mappings.

In the discussion of 3754, Simon Nash asked to reassign the issue from the
Java to IDL RTF to the Java mapping RTF. We really need two separate issues
here. I propose that we do the following:

1. Move 3754 back to the Java to IDL RTF since Harold wrote the issue with the
RMI-IIOP mapping in mind.

2. Create a new Java mapping issue for the same problem. The bulk of this message
should be the new issue.

Both RTFs will need to consider the issues. The new Java mapping issue will need
to propose extensions to the portable stub APIs and document the required changes
in the IDL based stubs, while the resolution to 3754 will need to adopt the
same new portable stub API and document the required changes in the RMI-IIOP stubs.

To start a discussion, here is my initial proposal for solving this problem in
the Java mapping RTF:

We need to add methods to report the result of the local dispatch. I propose that
we extend the portable definition of ServantObject as follows:

abstract public class ServantObjectExt extends ServantObject

Another alternative is to extend the Delegate class instead. I prefer the
ServantObject approach because the method signatures are simpler:
adding these methods on the Delegate would require passing ServantObject
as an argument, since multiple threads could be simultaneously invoking
methods on the same object reference, which would share the same delegate.

Making this change makes it necessary to consider what happens in
mixed versions.

Old stub, Old ServantObject:
no change

New stub, new ServantObject:
stub always invokes either normalCompletion or
exceptionalCompletion, so the ORB has enough information to correctly implement
portable interceptor behavior. Note that a location forward (e.g. from a
ServantManager) is not a problem today, since it happens inside of
_servant_preinvoke,
which allows the ORB to correctly handle that case.

New stub, old ServantObject:
If a new stub is written to do an instanceof check on
the ServantObject it gets from _servant_preinvoke, it can correctly determine
whether or not to call the new methods. There are a number of possibilities
for the check:

1. Just use (so instanceof ServantObjectExt) and rely on the ServantObjectExt
class to be defined somewhere in the environment. New stubs that wanted to
be compatible with old ORBs would need to be packaged somehow with this
class in their classpath. The stubs would need the ServantObjectExt class
both at compile time and at runtime.

2. A stub could be written to entirely use reflection for the instanceof check
and the method invocation. This would avoid the requirement to have
ServantObjectExt in the classpath, but would require more code in the stubs,
plus run a little slower (probably about 2X slower in JDK 1.4, but in
earlier JDKs the penalty could easily be 10-20X).

Old stub, new ServantObject:
In this case, neither method is ever invoked, so the
ORB can tell the difference between normal completion and an old stub.
The PI implementation in this case is free to do anything. However, probably the
best approach is to extend RequestInfo::reply_status with a new value
PortableInterceptor::UNKNOWN. Then the local case would always use the
interceptor points send_other and receive_other with a reply_status set to
UNKNOWN. This extension requires a new core issue.

It is worth noting here that the PI change makes it reasonable to consider simply
changing PI, and avoid changing the ServantObject API and 2 language mappings.
In this case, a user of PI cannot tell what is happening with colocated calls
in a very basic sense: did the operation complete successfully or not?
Many applications of PI (for example, transactions and security) often do not
require the use of PI in the colocated case. However, one important application
is best done this way: logging/tracing in a complex system. I believe this
argues strongly for extending the mapping, since a log entry that cannot distinguish
success from failure is of little use.

With the instanceof check, the local code for the sample stub then becomes
(from page 1-114 of ptc/01-06-04):

org.omg.CORBA.portable.ServantObject _so =
_servant_preinvoke( "length", _opsClass ) ;
if (_so == null)
continue ;

Example.AnInterfaceOperations _self =
(Example.AnInterfaceOperations)_so.servant ;

try

catch (Throwable thr)

finally

Note that the instanceof checks are quite fast in modern JVMs,
so I don't think this adds significantly to the overhead of the operation.
A reflective solution is also possible, but I am not including that here.
In any case, the precise code generation should be left to the implementation.
All that the spec should require is:

1. If the invocation on the servant completes without throwing an exception,
then the stub code must call servant.normalCompletion after the invocation
completes.

2. If the invocation on the servant throws exception exc, then the stub code
must call servant.exceptionalCompletion( exc ) after the invocation completes.

In either case, the servant completion call must occur before the
_servant_postinvoke call.

Incorporate the revised text, make corresponding changes in the standard source files, close

With the recent adoption of the resolution to issue 4623 (support
is_a on local interfaces), we need to answer the question of how
is_a is implemented in Java. I would like to create a new
Java RTF issue for this, and propose a solution to hopefully start
some discussion on this issue.

Proposed solution:

Change org.omg.CORBA.LocalObject to an abstract class as follows:

abstract public class LocalObject implements org.omg.CORBA.Object {

...

abstract public String[] _ids() ;

public _is_a( String repository_id)
{
String[] ids = _ids() ;
for (int i=0; i<ids.length; i++)

return false ;
}
}

Then the IDL compiler generates a local implementation base class as follows:

class <typename>LocalBase extends org.omg.CORBA.LocalObject
implements <typename> {

private String[] _type_ids() =

public String[] _ids()

}

where _type_ids contains a list of repository IDs of the local
interface and all of its superinterfaces in order from most derived
to org.omg.CORBA.Object.

The implementer of a local interface then simply writes

class MyImpl extends <typename>LocalBase

and instantiates the local interface by calling

new MyImpl( ... ).

Note: a full proposed resolution to this issue should include a static
delegate for LocalObject, so that the implementation of _is_a and any
other non-trivial methods can be made pluggable in the JDK. I will raise
another issue for get_interface_def after we have an issue number for
this issue.

Incorporate the revised text, make corresponding changes in the standard source files, close

The CORBA spec Section 3.7.6.1 includes the following:

• The usage of client side language mappings for local types shall be
  identical to
  those of equivalent unconstrained types.
• Language mappings shall specify server side mechanisms, including base
  classes
  and/or skeletons if necessary, for implementing local objects, so that
  invocation
  overhead is minimized.
• Invocations on local objects are not ORB mediated. Specifically,
  parameter copy
  semantics are not honored, interceptors are not invoked, and the execution
  context
  of a local object does not have ORB service Current object contexts that
  are
  distinct from those of the caller.

The IDL to Java spec section Section 1.12 Mapping for Interface,
subsection Local Interfaces states that:

• A local interface <typename> is mapped to interface <typename> which
  extends <typename>Operations, [... which an implementation can extend]
• A holder class is generated as for non-local interfaces.
• A helper class is also generated according to the normal rules, see
  Section 1.5,
  "Helpers", on page 1-13.
  No mention is made of Stubs, Ties or skeletons.

Section 1.20.2.1 Mapping for Local Interface states:
In the Java language mapping, the LocalObject class is used as a base class
for
implementations of a local interface.

I take it from the above that, quite reasonably, since "invocations on
local objects are
not ORB mediated", skeletons/Ties are not required for Java.

I can't see why Stubs should be required either, but
Section 1.21.6.1 Stub/Skeleton Architecture states:
Stubs support both local invocation and remote invocation, except in the
following
case: The stub is implementing an IDL interface that may only be invoked
locally (e.g.,
PortableServer::POA). In this case, the stub may choose to implement only
local
invocation.
which suggests that Stubs may be required (although the POA interface is
constrained
to be invoked locally, but not actually defined as local - is that the
difference?)

Incorporate revised text and close issue

In the latest spec of the idl-to-java mapping, I don't see a mapping for
create_local_interface_tc() on the ORB. Also missing is
tk_local_interface in TCKind. These need to be fixed quickly as this
leaves the local mapping incomplete in Java.

Proposal:

Section 1.19.9:

Add tk_local_interface to TCKind
enum TCKind

;

// java (add at the appropriate location)

public static final int _tk_local_interface = 33;
TCKind tk_local_interface = new TCKind(_tk_local_interface);

Section 1.19.10
Copy the new ORB PIDL from CORBA 2.4 spec (which basically adds)

TypeCode create_local_interface_tc(
in RepositoryId id,
in Identifier name
);

and add to the Java section:

package org.omg.CORBA_2_4;
import org.omg.CORBA.TypeCode;
public abstract class ORB extends org.omg.CORBA_2_3.ORB

Incorporate the revised text and close issue. Also make corresponding changes in the standard source

Sections 1.4.3 and 1.4.5 of the IDL to Java spec state that
character and string range and bounds checking should be performed
at marshal time. Since it is possible to receive IDL characters,
e.g UTF16 surrogate pairs, that cannot, at present, be mapped to
Java characters, could we clarify that this checking should be
performed at both marshaling and demarshaling time, per section
4.11.3.25 DATA_CONVERSION of the CORBA 2.5 spec which states:-
This exception is raised if an ORB cannot convert the
representation of data as marshaled into its native
representation or vice-versa.

Also, could anyone please comment on the meaning of the term
"character set" in the sentence beginning "If the char falls
outside the range defined by the character set,..." in section
1.4.3. Does this refer to the TCS, NCS or both?

Incorporate changes and close issue

The IDL to Java spec is very clear about what methods can (and by
implication what methods can't) be used with the singleton ORB and
one of those is create_any(), however it does not mention any
restrictions on the use of Anys obtained in this way. I think this
leads to some inconsistencies and potential problems, for example:

1. You cannot use create_output_stream() on the singleton ORB but
you can use create_output_stream() on an Any obtained from the
singleton. Where has this OutputStream come from? Presumably from
the Any's singleton ORB (calling the orb() method on that OutputStream
would return the ORB). At best this seems inconsistent.

2. The problem is worse if you now marshal an object reference into
that OutputStream then call create_input_stream() and try to read back
the object reference using a read_Object() call. If the read_Object()
is to return an object reference it needs to have an ORB to associate
it with, but the only ORB available to it is the original Any's
singleton ORB, which cannot support object references. Should this
read_Object() succeed or fail? If it should succeed what ORB should
it be using?

There may be similar problems writing and reading other types to these
streams.

I feel the spec should state explicitly that operations on an Any
created using the singleton ORB will be limited by the restrictions
applicable to the singleton ORB.

I don't think this would affect the intended use of Anys from the
singleton, which is stated as being to describe union labels when
creating a union TypeCode.

Proposed resolution:

Add the following sentence to the end of the subsection "Default
initialization" in section 1.21.9.3 ORB Initialization Methods in
the IDL to Java spec:

Operations on an Any created using the singleton ORB will be
limited by the restrictions applicable to the singleton ORB;
those which require the use of a fully functional ORB will result
in a NO_IMPLEMENT system exception.

resolved

On page 133, bullet 3 reads:

• If the CORBA system exception org.omg.CORBA.portable.UnknownException
is thrown, then the stub does one of the following:
• Translates it to org.omg.CORBA.UNKNOWN.
• Translates it to the nested exception that the UnknownException contains.
• Passes it on directly to the user.

It is unfortunate that there is no recommended default since for RMI-IIOP at least, option (2) is by far to be preferred. I would like to change it therefore to add the text:

"In order to preserve RMI semantics ORBs implementing the RMI-IIOP protocol should always translate it to the nested exception that the UnknownException contains"

Incorporate revised text and close issue

>There is something that is unclear in your CORBA spec that I think is causing
incompatibility problems between various IDL compilers.
>> >
>> >Given the following IDL:
>> >
>> >-------------------------------------------------
>> >struct Protection
>> >

;
>> >
>> >typedef Protection ProtectedEntity;
>> >
>> >typedef sequence<ProtectedEntity> ProtectedEntityList;
>> >
>> >typedef ProtectedEntityList ProtectingEntity;
>> >-------------------------------------------------
>> >
>> >Should a holder class for ProtectingEntity get generated? I ask this because some IDL
compilers generate it and others do not (very frustrating!).
>> >
>> >In section 1.18.2 of the OMG IDL mapping document ptc/00-01-08 spec I found this:
"Holder classes are generated for sequence and array typedefs only. The "unwound" type's
Holder class is used for the other cases.".
>> >
>> >Since this is a typedef of a typedef, but the original item was a sequence, should the
ProtectingEntityHolder.java file get generated or not?

Incorporate change and close issue