Issue 4748: Naming issues for new ORB methods (java-rtf) Source: Oracle (Mr. Ken Cavanaugh, nobody) Nature: Uncategorized Issue Severity: Summary: 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 Resolution: Incorporate joint resolution changes and close issue Revised Text: In section 1.19.10, add the following to the pseudo interface ORB: After the list_initial_services declaration: void register_initial_reference( in ObjectId id, in Object obj ) raises (InvalidName) ; After the create_abstract_interface_tc declaration: TypeCode create_local_interface_tc( in RepositoryId id, in Identifier name ) ; After the typedef for ObjectIdList: ORBId id() ; In section 1.19.10, delete the paragraph that begins "All types defined in this chapter are either part of the CORBA or ...". All of the IDL level definitions are in the pseudo interface ORB, which has nothing to do with Java packages. In section 1.19.10, add the following to the Java abstract class org.omg.CORBA.ORB: After the list_initial_services method: public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } After the create_abstract_interface_tc method: public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } Also, fix the implementation of the create_abstract_interface_tc method to throw new org.omg.CORBA.NO_IMPLEMENT (it was missing the new). At the beginning, add: public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } At the end, add: public org.omg.CORBA.Object get_value_def( String repid ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory register_value_factory( String id, org.omg.CORBA.portable.ValueFactory factory ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void unregister_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public org.omg.CORBA.portable.ValueFactory lookup_value_factory( String id ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void set_delegate( java.lang.Object wrapper ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } In section 1.19.10, add the following Java definition to the very end: package org.omg.CORBA_2_5 ; public abstract class ORB extends org.omg.CORBA_2_3.ORB { public String id() { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public void register_initial_reference( String object_name, org.omg.CORBA.Object object ) throws org.omg.CORBA.ORBPackage.InvalidName { throw new org.omg.CORBA.NO_IMPLEMENT() ; } public TypeCode create_local_interface_tc( String id, String name ) { throw new org.omg.CORBA.NO_IMPLEMENT() ; } } Actions taken: December 14, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Date: Thu, 13 Dec 2001 15:21:57 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Naming issues for new ORB methods To: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: cxhJxXgxegftE+ruXAfvTQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: @f_!!CI=e9Q]~e9&nkd9 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 I think this solves all of our problems. If everyone is agreeable, I'll start writing the proposals to make this happen. I also welcome contributions for any proposals, of course :-). Thanks, Ken. Date: Fri, 14 Dec 2001 13:25:06 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Ken Cavanaugh CC: java-rtf@omg.org Subject: Re: Naming issues for new ORB methods References: <200112132321.fBDNLv709356@ha1sca-mail1.SFBay.Sun.COM> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: EBTd90@G!!P_\d9%V*e9 Ken, This sounds good to me. A couple of comments inline below. Simon Ken Cavanaugh wrote: > > 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 discussed this with Graham Hamilton and he said there is no requirement for JDK level n to pass JCK level n-1. > 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. > Alternatively, the vendor can add the CORBA_2_5 package. This is a vendor choice. > 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 > > I think this solves all of our problems. If everyone is agreeable, > I'll start writing the proposals to make this happen. I also > welcome contributions for any proposals, of course :-). > > Thanks, > > Ken. -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 18 Dec 2001 15:00:20 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Joint resolution for issues 4741, 4549, 4750, 4748 To: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: 8fpTAYJ3/E2Sjji2C7Oplg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: