I2JAV12 — Naming issues for new ORB methods

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