Issue 4323: local interface mapping underspecified (java-rtf) Source: Oracle (Dr. Harold Carr, Ph.D., nobody) Nature: Uncategorized Issue Severity: Summary: The IDL-to-Java ptc/00-11-03 specification says that an implementation of a local interface would extend org.omg.CORBA.LocalObject instead of org.omg.CORBA.Object. This is underspecified. It does not say anything about the generated classes for a local interface, their relationships, nor which one should be implemented by an implementation. This MUST be specified for local interface implementations to be portable. I suggest for local interface X the following generated classes: interface X extends XOperations, org.omg.CORBA.Object This is similar to a non-local mapping except that it does not extend org.omg.CORBA.portable.IDLEntity. Although that would not hurt anything it is not necessary since a local interface cannot be marshaled. I suggest the following specification for implementations of local interfaces: class XImpl extends org.omg.CORBA.LocalObject implements X An instance would be create using the usual language construct: XImpl x = new XImpl(...); The above must be specified just like the current spec says what to do with a POA-based implementation of a non-local interface, e.g.,: class YImpl extends YPOA Resolution: see below Revised Text: In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local Interfaces", on page 1-29: ------------------------- BEGIN EXISTING TEXT Local Interfaces An IDL local interface is mapped in a fashion similar to that of a non-local interface. However because it may not be marshaled the implementation extends a special base interface, org.omg.CORBA.LocalObject, (see Section 1.20.2.1, "Mapping for Local Interface", on page 1-88) instead of org.omg.CORBA.Object. Issue Does it extend org.omg.CORBA.portable.IDLEntity since it can't be marshaled? Issue The CCM submission did not precisely define whether local interfaces have signature and operation interfaces. This assumes that theydo. 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. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. END EXISTING TEXT ------------------------- with: BEGIN REPLACEMENT TEXT Local Interfaces A new interface in org.omg.CORBA called LocalInterface is defined as: public interface LocalInterface extends org.omg.CORBA.Object { } A local interface <typename> is mapped to the the following java classes: interface <typename> extends <typename>Operations, org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity where interface <typename> and <typename>Operations are identical to the mapping for a non-local interface. An implementation of <typename> may then be specified as: class <typename>Impl extends org.omg.CORBA.LocalObject implements <typename> and an instance would be created using the usual Java language construct: <typename>Impl ti = new <typename>Impl(...); 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. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. END REPLACEMENT TEXT Actions taken: May 25, 2001: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== Date: Fri, 25 May 2001 12:08:51 -0700 (PDT) Message-Id: <200105251908.MAA28289@shorter.eng.sun.com> From: Harold Carr To: java-rtf@omg.org, issues@omg.org Subject: local interface mapping underspecified Content-Type: text X-UIDL: &f%e93i$e9-oS!!,WJe9 The IDL-to-Java ptc/00-11-03 specification says that an implementation of a local interface would extend org.omg.CORBA.LocalObject instead of org.omg.CORBA.Object. This is underspecified. It does not say anything about the generated classes for a local interface, their relationships, nor which one should be implemented by an implementation. This MUST be specified for local interface implementations to be portable. I suggest for local interface X the following generated classes: interface X extends XOperations, org.omg.CORBA.Object This is similar to a non-local mapping except that it does not extend org.omg.CORBA.portable.IDLEntity. Although that would not hurt anything it is not necessary since a local interface cannot be marshaled. I suggest the following specification for implementations of local interfaces: class XImpl extends org.omg.CORBA.LocalObject implements X An instance would be create using the usual language construct: XImpl x = new XImpl(...); The above must be specified just like the current spec says what to do with a POA-based implementation of a non-local interface, e.g.,: class YImpl extends YPOA Cheers, Harold Date: Mon, 11 Jun 2001 17:17:43 -0700 (PDT) Message-Id: <200106120017.RAA15082@shorter.eng.sun.com> From: Harold Carr To: java-rtf@omg.org Subject: Proposed resolution for issue 4323: local interface mapping underspecified Content-Type: text X-UIDL: $F[d9C_Le96/Vd988p!! In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local Interfaces", on page 1-29: ------------------------- BEGIN EXISTING TEXT Local Interfaces An IDL local interface is mapped in a fashion similar to that of a non-local interface. However because it may not be marshaled the implementation extends a special base interface, org.omg.CORBA.LocalObject, (see Section 1.20.2.1, "Mapping for Local Interface", on page 1-88) instead of org.omg.CORBA.Object. Issue Does it extend org.omg.CORBA.portable.IDLEntity since it can't be marshaled? Issue The CCM submission did not precisely define whether local interfaces have signature and operation interfaces. This assumes that theydo. 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. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. END EXISTING TEXT ------------------------- with: BEGIN REPLACEMENT TEXT Local Interfaces A local interface is mapped to the the following java classes: interface extends Operations, org.omg.CORBA.Object where interface and Operations are identical to the mapping for a non-local interface except that Java interface does not extend org.omg.CORBA.portable.IDLEntity. An implemenation of may then be specified as: class Impl extends org.omg.CORBA.LocalObject implements and an instance would be create using the usual Java language construct: Impl ti = new Impl(...); A holder class is generated as for non-local interfaces. For any user defined, local interface IDL type, , the following is the Java code generated for the type. public class Helper { public static String id() {...} public static narrow(java.lang.Object obj) {...} public static narrow(org.omg.CORBA.Object obj) {...} } ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. END REPLACEMENT TEXT Cheers, Harold Date: Tue, 12 Jun 2001 13:14:46 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Java RTF Cc: czhao@borland.com Subject: VOTE: IDL to Java RTF Issue 4323, Due June 18, 2001 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ap8!!g-'!!cadd9IVP!! Issue 4323: local interface mapping underspecified The IDL-to-Java ptc/00-11-03 specification says that an implementation of a local interface would extend org.omg.CORBA.LocalObject instead of org.omg.CORBA.Object. This is underspecified. It does not say anything about the generated classes for a local interface, their relationships, nor which one should be implemented by an implementation. This MUST be specified for local interface implementations to be portable. --------------------------------------------------------------------------- Votes Due: NOON EDT (US), June 18, 2001 ---------------------------------------------------------------------------- Proposal: [This is Harold's proposal from June 11, with one minor typo corrected (create changed to created)] In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local Interfaces", on page 1-29: ------------------------- BEGIN EXISTING TEXT Local Interfaces An IDL local interface is mapped in a fashion similar to that of a non-local interface. However because it may not be marshaled the implementation extends a special base interface, org.omg.CORBA.LocalObject, (see Section 1.20.2.1, "Mapping for Local Interface", on page 1-88) instead of org.omg.CORBA.Object. Issue Does it extend org.omg.CORBA.portable.IDLEntity since it can't be marshaled? Issue The CCM submission did not precisely define whether local interfaces have signature and operation interfaces. This assumes that theydo. 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. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. END EXISTING TEXT ------------------------- with: BEGIN REPLACEMENT TEXT Local Interfaces A local interface is mapped to the the following java classes: interface extends Operations, org.omg.CORBA.Object where interface and Operations are identical to the mapping for a non-local interface except that Java interface does not extend org.omg.CORBA.portable.IDLEntity. An implemenation of may then be specified as: class Impl extends org.omg.CORBA.LocalObject implements and an instance would be create using the usual Java language construct: Impl ti = new Impl(...); A holder class is generated as for non-local interfaces. For any user defined, local interface IDL type, , the following is the Java code generated for the type. public class Helper { public static String id() {...} public static narrow(java.lang.Object obj) {...} public static narrow(org.omg.CORBA.Object obj) {...} } ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. END REPLACEMENT TEXT Date: Wed, 13 Jun 2001 14:24:22 +0800 From: Vijaykumar Natarajan Subject: Re: Proposed resolution for issue 4323: local interface mappingunderspecified To: Harold Carr Cc: java-rtf@omg.org Message-id: <3B270716.9C02B25B@borland.com> MIME-version: 1.0 X-Mailer: Mozilla 4.74 [en] (Windows NT 5.0; U) Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200106120017.RAA15082@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: k6^!!#`Pd9A'D!!Fb&"! Hi all, I have an addition to this proposal. The problem I see, is that we expect the user to follow certain rules to allow us to detect that a given interface is a local interface. I would like to change that so, from the generated code hierarchy alone, we are able to detect local interfaces. To this end, I propose to add the following: Add a new interface in org.omg.CORBA called Local (or LocalInterface) defined as: public interface LocalInterface extends org.omg.CORBA.Object { } Modifications to the rest of the proposal is trivial: Change the following line in hte replacement text for this proposal from: A local interface is mapped to the the following java classes: interface extends Operations, org.omg.CORBA.Object to A local interface is mapped to the the following java classes: interface extends Operations, org.omg.CORBA.LocalInterface This allows the ORBs to detect local interfaces even if the user fails to extend LocalObject. We can go one step further and make this compile time by adding a method to LocalInterface (which would be implemented by LocalObject) thus detecting extending ObjectImpl vs. LocalObject. But I can't think of a real useful method for local interfaces and such an addition in the absence of a usecase would be gratuitous. Thoughts? Thanks, Vijay Harold Carr wrote: > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29: > > ------------------------- > BEGIN EXISTING TEXT > > Local Interfaces > > An IDL local interface is mapped in a fashion similar to that of a > non-local interface. However because it may not be marshaled the > implementation extends a special base interface, > org.omg.CORBA.LocalObject, (see Section 1.20.2.1, "Mapping for Local > Interface", on page 1-88) instead of org.omg.CORBA.Object. > > Issue > > Does it extend org.omg.CORBA.portable.IDLEntity since it can't be > marshaled? > > Issue > > The CCM submission did not precisely define whether > local interfaces have signature and operation interfaces. This > assumes > that theydo. > > 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. > > ORB implementations > shall detect attempts to marshal local objects and throw a > CORBA::MARSHAL exception. > > Issue An example for local interface should > be added. > > END EXISTING TEXT > ------------------------- > > with: > > BEGIN REPLACEMENT TEXT > > Local Interfaces > > A local interface is mapped to the the following java > classes: > > interface extends Operations, > org.omg.CORBA.Object > > where interface and Operations are identical to > the mapping for a non-local interface except that Java interface > does not extend org.omg.CORBA.portable.IDLEntity. > > An implemenation of may then be specified as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be create using the usual Java language > construct: > > Impl ti = new Impl(...); > > A holder class is generated as for non-local interfaces. > > For any user defined, local interface IDL type, , the > following is the Java code generated for the type. > > public class Helper { > public static String id() {...} > public static narrow(java.lang.Object obj) {...} > public static narrow(org.omg.CORBA.Object obj) {...} > } > > ORB implementations shall detect attempts to marshal local objects > and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > END REPLACEMENT TEXT > > Cheers, > Harold Date: Wed, 13 Jun 2001 19:58:49 +0100 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: Mary Leland CC: Java RTF , czhao@borland.com Subject: Re: VOTE: IDL to Java RTF Issue 4323, Due June 18, 2001 References: <3B264E06.D3025B8C@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Qc>e9d+Ce9^Cgd99TQd9 Mary, I have some concerns with this proposal. See below. Simon Mary Leland wrote: > > Issue 4323: local interface mapping underspecified > > The IDL-to-Java ptc/00-11-03 specification says that an implementation > of a local interface would extend org.omg.CORBA.LocalObject instead of > org.omg.CORBA.Object. This is underspecified. It does not say > anything about the generated classes for a local interface, their > relationships, nor which one should be implemented by an > implementation. This MUST be specified for local interface > implementations to be portable. > > --------------------------------------------------------------------------- > > Votes Due: NOON EDT (US), June 18, 2001 > > ---------------------------------------------------------------------------- > > Proposal: [This is Harold's proposal from June 11, with one minor typo > corrected (create changed to created)] > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29: > > ------------------------- > BEGIN EXISTING TEXT > > Local Interfaces > > An IDL local interface is mapped in a fashion similar to that of a > non-local interface. However because it may not be marshaled the > implementation extends a special base interface, > org.omg.CORBA.LocalObject, (see Section 1.20.2.1, "Mapping for Local > Interface", on page 1-88) instead of org.omg.CORBA.Object. > > Issue > > Does it extend org.omg.CORBA.portable.IDLEntity since it can't be > marshaled? > > Issue > > The CCM submission did not precisely define whether > local interfaces have signature and operation interfaces. This assumes > that theydo. > > 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. > > ORB implementations > shall detect attempts to marshal local objects and throw a > CORBA::MARSHAL exception. > > Issue An example for local interface should > be added. > > END EXISTING TEXT > ------------------------- > > with: > > BEGIN REPLACEMENT TEXT > > Local Interfaces > > A local interface is mapped to the the following java classes: > > interface extends Operations, org.omg.CORBA.Object > > where interface and Operations are identical to > the mapping for a non-local interface except that Java interface > does not extend org.omg.CORBA.portable.IDLEntity. > I don't think this is correct. The IDLEntity interface is a marker type for use by the Java to IDL mapping when it encounters Java types that were originally generated by applying the IDL to Java mapping. If an IDL local interface type foo is mapped to Java type foo which does not extend IDLEntity, and if some other Java interface bar that uses Java type foo is mapped to IDL, then the Java to IDL mapping will attempt to map Java type foo back to a new IDL abstract valuetype foo, which doesn't seem correct. If the generated Java type foo were specified as extending IDLEntity, then the Java to IDL mapping would generate the original IDL local interface type foo, which seems correct. > An implemenation of may then be specified as: > typo: implementation > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be create using the usual Java language > construct: > typo: created > Impl ti = new Impl(...); > > A holder class is generated as for non-local interfaces. > > For any user defined, local interface IDL type, , the > following is the Java code generated for the type. > > public class Helper { > public static String id() {...} > public static narrow(java.lang.Object obj) {...} > public static narrow(org.omg.CORBA.Object obj) {...} > } > The first of these narrow methods should be removed. It is only > present for helper classes for abstract interfaces and non-abstract interfaces > that have at least one abstract base interface. It is not applicable to > local interfaces that don't have abstract base interfaces. This raises the interesting question of whether there is such a thing as an abstract local interface. I'm inclined to think that there isn't. However, a local interface should be able to support an abstract interface. In this case, the narrow(java.lang.Object) method should be included in the helper. These rules are exactly the same as for helpers for non-local interfaces. > ORB implementations shall detect attempts to marshal local objects and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > END REPLACEMENT TEXT -- 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: Thu, 14 Jun 2001 13:32:11 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Java RTF , Harold Carr , Vijaykumar Natarajan , Simon Nash Subject: Issue 4323 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: G#I!!Q#Z!!4HIe9R_$!! Harold, Vijay, Simon, Can you (and whoever else wants to help) come up with a compromise proposal for 4323? The deadline for the interim report is June 18th (Monday). Of course, we could just wait on this issue, but it would be nice to get it resolved so that we have a consistent mapping for local interfaces. To summarize the 2 contentious points (details in the email archive at http://cgi.omg.org/issues/issue4323.txt - my apologies if I oversimplify): 1. For a local interface X, what should the mapped Java interface extend? Vijay would like a LocalInterface marker interface for a local interface. Simon would like the local interface to inherit from IDLEntity (the marker interface for use in the Java to IDL mapping to identify types originally mapped from IDL to Java). 2. The Helper class: Simon also has suggestions about the narrow methods in the helper class. Suggestions for resolution: For 1: A couple of (probably flawed) possibilities: A. Have LocalInterface extend IDLEntity, and otherwise take Vijay's suggestion. This gives both Simon and Vijay their desired marker interfaces, but deepens the inheritance tree. Also, IDLEntity extends java.io.Serializable, which seems strange for a local interface. B. Take Vijay's suggestion as is, and have the Java to IDL mapping also recognize LocalInterface as a marker for types mapped from IDL. Of course, that would add work to the Java to IDL mapping. [I hope these will inspire someone to come up with something better] For 2: Can we just go with Simon's last sentence "These rules are exactly the same as for helpers for non-local interfaces." and just say something like "A Helper class is generated as for non-local interfaces" ? Thanks, Mary Date: Thu, 14 Jun 2001 22:01:32 +0100 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: Mary Leland CC: Java RTF , Harold Carr , Vijaykumar Natarajan Subject: Re: Issue 4323 References: <3B28F51B.4218D92D@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: I+)!!QT`d9OYm!!-W*e9 Mary, Thanks for trying to broker a compromise. I think both your options for point 1 have problems, as you say, and I am trying to get a consensus view in IBM as to which is the lesser of the evils. Option B would also require a vote in the Java to IDL RTF to approve the necessary changes to the Java to IDL mapping, and I believe it is too late in the current RTF cycle to schedule this vote and give it the consideration it deserves. It may be better to defer this issue until the next RTF voting period so that we do not adopt a resolution in haste which we might regret later. Simon Mary Leland wrote: > > Harold, Vijay, Simon, > > Can you (and whoever else wants to help) come up with a > compromise proposal for 4323? The deadline for the interim > report is June 18th (Monday). Of course, we could just > wait on this issue, but it would be nice to get it resolved > so that we have a consistent mapping for local interfaces. > > To summarize the 2 contentious points > (details in the email archive at > http://cgi.omg.org/issues/issue4323.txt > - my apologies if I oversimplify): > > 1. For a local interface X, what should the mapped > Java interface extend? > > Vijay would like a LocalInterface marker interface > for a local interface. > > Simon would like the local interface to inherit from > IDLEntity (the marker interface for use in the Java to > IDL mapping to identify types originally mapped from > IDL to Java). > > 2. The Helper class: > Simon also has suggestions about the narrow methods in the > helper class. > > Suggestions for resolution: > > For 1: > A couple of (probably flawed) possibilities: > > A. Have LocalInterface extend IDLEntity, and otherwise take > Vijay's suggestion. This gives both Simon and Vijay their > desired marker interfaces, but deepens the inheritance > tree. Also, IDLEntity extends java.io.Serializable, which > seems strange for a local interface. > > B. Take Vijay's suggestion as is, and have the Java to IDL > mapping also recognize LocalInterface as a marker for types > mapped from IDL. Of course, that would add work to the > Java to IDL mapping. > > [I hope these will inspire someone to come up with something better] > > For 2: > Can we just go with Simon's last sentence "These rules > are exactly the same as for helpers for non-local interfaces." > and just say something like > "A Helper class is generated as for non-local interfaces" ? > > Thanks, > Mary -- 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: Thu, 14 Jun 2001 15:39:10 -0700 (PDT) Message-Id: <200106142239.PAA11825@shorter.eng.sun.com> From: Harold Carr To: java-rtf@omg.org Subject: Re: Issue 4323 Content-Type: text X-UIDL: -kad97K*e9*NNe9o5Ke9 Vijay and Simon and all: Viyay, I think your idea is well-motivated but I would suggest that we do not go down that path for the following reasons: 1. I think some vendors are already shipping support for local interfaces. Since the hierarchy you propose depends on a marker type that doesn't exist I imagine that most (if not all) are already doing something close to my original proposal and the new updated proposal below. 2. Our product schedule is such that we need to resolve this ASAP (i.e., June 18) with as little change as possible. 3. If a user follows the proposed specification then attempts to marshal local interfaces can be caught and handled correctly. Simon, I do not know the intricacies of IDLEntity. However, assuming you are right, I have no problem with including it in the derivation. Thanks for pointing out that the rules for generating a helper class for a local interface are the same as already stated elsewhere in the spec. That simplies the proposal. Here is a slightly modified version of my original proposal changed according to Simon's observations. Cheers, Harold BEGIN REPLACEMENT TEXT Local Interfaces A local interface is mapped identically to a non-local interface. An implementation of may then be specified as: class Impl extends org.omg.CORBA.LocalObject implements and an instance would be created using the usual Java language construct: Impl ti = new Impl(...); 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. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. END REPLACEMENT TEXT Date: Fri, 15 Jun 2001 18:02:17 +0800 From: Cuie Zhao Subject: Re: Issue 4323 To: Harold Carr Cc: java-rtf@omg.org Message-id: <3B29DD29.D8404BDA@borland.com> MIME-version: 1.0 X-Mailer: Mozilla 4.74 [en] (WinNT; U) Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200106142239.PAA11825@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: ^)X!!Z_,!!Bon!!m$fd9 Hi Harold, Harold Carr wrote: > Vijay and Simon and all: > > Viyay, I think your idea is well-motivated but I would suggest that >we > do not go down that path for the following reasons: > > 1. I think some vendors are already shipping support for local >interfaces. > Since the hierarchy you propose depends on a marker type that >doesn't > exist I imagine that most (if not all) are already doing >something > close to my original proposal and the new updated proposal below. I am afraid that's not a great argument. First, the only support for local interfaces that any vendor now supports is the presence of the LocalObject class in the package, and the absence of the marker interface in the generated code. So, let's say you ship w/o that support? what happens when you have to update your product to conform to a new spec (the one w/ my proposal, say). You change the code generation to include Local. Your user's code doesn't change (user still implements LocalObject). If the user didn't do that in the implementation, bad things happen both in your old product and in your new product. Everything still works. So I don't see a problem. Further, the current spec says only that the implementation is required to extend org.omg.CORBA.LocalObject, which is still the case. > 2. Our product schedule is such that we need to resolve this ASAP > (i.e., June 18) with as little change as possible. See above. Also, I don't see how this is a big change. All you have to do is add one interface and change code generation to replace four words. Given that the IDLEntity interface hierarchy change is acceptable to you, I don't see how this is different. > 3. If a user follows the proposed specification then attempts to marshal > local interfaces can be caught and handled correctly. Up until now, I don't see any part of the specification that requires the user to do something specific so the ORB can maintain IDL semantics. I agree with all of Simon's changes. The IDLEntity inheritance must exist. Also, I too think that we are trying to rush this issue and given the contention would prefer to defer the issue rather than adopt something that we may regret. Thanks, Vijay > > Here is a slightly modified version of my original proposal changed > according to Simon's observations. > > Cheers, > Harold > > BEGIN REPLACEMENT TEXT > > Local Interfaces > > A local interface is mapped identically to a non-local > interface. An implementation of may then be specified >as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be created using the usual Java language >construct: > > Impl ti = new Impl(...); > > 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. > > ORB implementations shall detect attempts to marshal local objects >and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > END REPLACEMENT TEXT -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Date: Fri, 15 Jun 2001 11:13:27 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Mary Leland Cc: Java RTF , Harold Carr , Vijaykumar Natarajan , Simon Nash Subject: Re: Issue 4323 References: <3B28F51B.4218D92D@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;H:!!J\@e9le&e9VZed9 Please resolve this issue ASAP, even if it takes one more week beyond the 18th. This one is exteremely important, and I am sure I will be able to lean on the AB to be a bit lenient. The reason for the urgency is that we are in the process of specifying that most POA objects are local objects. Without a resolution for this issue, local object java mappings will potentially become non-portable, thus rendering POA implemented servers non-portable, not a good thing IMHO. Thanks, Jishnu. Mary Leland wrote: > > Harold, Vijay, Simon, > > Can you (and whoever else wants to help) come up with a > compromise proposal for 4323? The deadline for the interim > report is June 18th (Monday). Of course, we could just > wait on this issue, but it would be nice to get it resolved > so that we have a consistent mapping for local interfaces. > > To summarize the 2 contentious points > (details in the email archive at > http://cgi.omg.org/issues/issue4323.txt > - my apologies if I oversimplify): > > 1. For a local interface X, what should the mapped > Java interface extend? > > Vijay would like a LocalInterface marker interface > for a local interface. > > Simon would like the local interface to inherit from > IDLEntity (the marker interface for use in the Java to > IDL mapping to identify types originally mapped from > IDL to Java). > > 2. The Helper class: > Simon also has suggestions about the narrow methods in the > helper class. > > Suggestions for resolution: > > For 1: > A couple of (probably flawed) possibilities: > > A. Have LocalInterface extend IDLEntity, and otherwise take > Vijay's suggestion. This gives both Simon and Vijay their > desired marker interfaces, but deepens the inheritance > tree. Also, IDLEntity extends java.io.Serializable, which > seems strange for a local interface. > > B. Take Vijay's suggestion as is, and have the Java to IDL > mapping also recognize LocalInterface as a marker for types > mapped from IDL. Of course, that would add work to the > Java to IDL mapping. > > [I hope these will inspire someone to come up with something better] > > For 2: > Can we just go with Simon's last sentence "These rules > are exactly the same as for helpers for non-local interfaces." > and just say something like > "A Helper class is generated as for non-local interfaces" ? > > Thanks, > Mary -- Jishnu Mukerji Senior Systems Architect EIAL, Hewlett-Packard Company 300 Campus Drive, MS 2E-62 Florham Park NJ 07932, USA +1 973 443 7528 jishnu_mukerji@hp.com Date: Fri, 15 Jun 2001 08:32:11 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cuie Zhao CC: Harold Carr , java-rtf@omg.org Subject: Re: Issue 4323 References: <200106142239.PAA11825@shorter.eng.sun.com> <3B29DD29.D8404BDA@borland.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: MX4e9S9L!!gofd9C~&!! Hello Vijay (who is Cuie Zhao?): > I am afraid that's not a great argument. First, the only support for local > interfaces that any vendor now supports is the presence of the LocalObject > class in the package, and the absence of the marker interface in the generated > code. So, let's say you ship w/o that support? what happens when you have to We can't ship without that support because we have PortableInterceptors which relies on local objects. > update your product to conform to a new spec (the one w/ my proposal, say). > You change the code generation to include Local. Your user's code doesn't > change (user still implements LocalObject). If the user didn't do that in the > implementation, bad things happen both in your old product and in your new > product. Everything still works. So I don't see a problem. Further, the > current spec says only that the implementation is required to extend > org.omg.CORBA.LocalObject, which is still the case. That sounds reasonable, however... > > > 2. Our product schedule is such that we need to resolve this ASAP > > > (i.e., June 18) with as little change as possible. > > See above. Also, I don't see how this is a big change. All you have to do is > add one interface and change code generation to replace four words. Given that > the IDLEntity interface hierarchy change is acceptable to you, I don't see how > this is different. The time for adding new APIs in our current schedule has long past. Yes, the IDLEntity change is fine. > > > 3. If a user follows the proposed specification then attempts to marshal > > local interfaces can be caught and handled correctly. > > Up until now, I don't see any part of the specification that requires the user > to do something specific so the ORB can maintain IDL semantics. > > I agree with all of Simon's changes. The IDLEntity inheritance must exist. Yes, my modified proposal did agree with all Simon's changes too. > > Also, I too think that we are trying to rush this issue and given > the > contention would prefer to defer the issue rather than adopt > something that we > may regret. I think Jishnu pointed out that this should be resolved. > > Thanks, > Vijay After applying Simon's changes all my modified proposal does is resolve two of the issues in the existing ptc/00-11-03 text (i.e., IDLEntity and signature and operation interfaces). It seems we could get agreement on this since my proposal doesn't change the existing spec, it just makes it less ambiguous. Thanks, Harold > > > > > Here is a slightly modified version of my original proposal changed > > according to Simon's observations. > > > > Cheers, > > Harold > > > > BEGIN REPLACEMENT TEXT > > > > Local Interfaces > > > > A local interface is mapped identically to a non-local > > interface. An implementation of may then be specified as: > > > > class Impl > > extends org.omg.CORBA.LocalObject > > implements > > > > and an instance would be created using the usual Java language construct: > > > > Impl ti = new Impl(...); > > > > 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. > > > > ORB implementations shall detect attempts to marshal local objects and > > throw a CORBA::MARSHAL exception. > > > > Issue > > > > An example for local interface should be added. > > > > END REPLACEMENT TEXT Date: Mon, 18 Jun 2001 09:20:26 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Java RTF , Harold Carr , Simon Nash , Vijaykumar Natarajan , Cuie Zhao Cc: Juergen Boldt Subject: Revised Vote: Issue 4323 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: FQp!!?:&e9*3U!!"11!! I'm going to go along with Jishnu's assurance that the AB will forgive us if we get the IDL to Java report in a week late, and try to get this issue resolved for the report. For this vote, please choose one of A. Accept Harold's revised proposal (see below for the text). B. Add in Vijay's proposal for a marker interface (see below for proposed text - any amendment from Vijay will be considered friendly) C. Leave the issue open for now. We'll go with whichever receives the most votes. Please vote as soon as practical; the absolute deadline is 9 am, US EDT, Monday, June 25. (Juergen: I'll get the report to you sometime on the 25th) -------------------------------------------------------------- Harold's revised proposal (Option A): In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local Interfaces", on page 1-29, with Local Interfaces A local interface is mapped identically to a non-local interface. An implementation of may then be specified as: class Impl extends org.omg.CORBA.LocalObject implements and an instance would be created using the usual Java language construct: Impl ti = new Impl(...); 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. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. ------------------------------------------------------------------------ Vijay's proposal (Option B): In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local Interfaces", on page 1-29, with Local Interfaces A new interface in org.omg.CORBA called LocalInterface is defined as: public interface LocalInterface extends org.omg.CORBA.Object { } A local interface is mapped to the the following java classes: interface extends Operations, org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity where interface and Operations are identical to the mapping for a non-local interface. An implementation of may then be specified as: class Impl extends org.omg.CORBA.LocalObject implements and an instance would be created using the usual Java language construct: Impl ti = new Impl(...); 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. ORB implementations shall detect attempts to marshal local objects and throw a CORBA::MARSHAL exception. Issue An example for local interface should be added. --------------------------------------------------------------------------- Date: Mon, 18 Jun 2001 16:19:11 +0100 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: Mary Leland CC: Java RTF , Harold Carr , Vijaykumar Natarajan , Cuie Zhao , Juergen Boldt Subject: Re: Revised Vote: Issue 4323 References: <3B2E001A.B7593FFE@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: =oTd9`T]!!\F > I'm going to go along with Jishnu's assurance that the AB will > forgive us if we get the IDL to Java report in a week late, and > try to get this issue resolved for the report. > > For this vote, please choose one of > A. Accept Harold's revised proposal (see below for the text). > B. Add in Vijay's proposal for a marker interface (see below > for proposed text - any amendment from Vijay will be considered > friendly) > C. Leave the issue open for now. > > We'll go with whichever receives the most votes. > > Please vote as soon as practical; the absolute deadline is > 9 am, US EDT, Monday, June 25. > (Juergen: I'll get the report to you sometime on the 25th) > > -------------------------------------------------------------- > Harold's revised proposal (Option A): > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29, with > > Local Interfaces > > A local interface is mapped identically to a non-local > interface. An implementation of may then be specified as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be created using the usual Java language construct: > > Impl ti = new Impl(...); > > 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. > > ORB implementations shall detect attempts to marshal local objects and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > ------------------------------------------------------------------------ > Vijay's proposal (Option B): > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29, with > > Local Interfaces > > A new interface in org.omg.CORBA called LocalInterface is defined as: > > public interface LocalInterface extends org.omg.CORBA.Object { > } > > A local interface is mapped to the the following java classes: > > interface extends Operations, org.omg.CORBA.LocalInterface, > org.omg.CORBA.portable.IDLEntity > > where interface and Operations are identical to > the mapping for a non-local interface. > > An implementation of may then be specified as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be created using the usual Java language construct: > > Impl ti = new Impl(...); > > 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. > > ORB implementations shall detect attempts to marshal local objects and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > --------------------------------------------------------------------------- -- 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 From: Jeffrey Mischkinsky Message-Id: <200106181526.IAA10430@wheel.dcn.davis.ca.us> Subject: Re: Revised Vote: Issue 4323 To: nash@hursley.ibm.com (Simon Nash) Date: Mon, 18 Jun 2001 08:26:55 -0700 (PDT) Cc: mleland@fpk.hp.com (Mary Leland), java-rtf@omg.org (Java RTF), harold.carr@Eng.Sun.COM (Harold Carr), vnatarajan@borland.com (Vijaykumar Natarajan), czhao@borland.com (Cuie Zhao), juergen@omg.org (Juergen Boldt) In-Reply-To: <3B2E1BEF.15EBEE56@hursley.ibm.com> from "Simon Nash" at Jun 18, 2001 04:19:11 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: CgFe91W > Mary, > I think we need a vote to select one of these options, followed by a vote > on whether to adopt the selected option (if A or B is selected by the first > vote). If we only have one vote, then either A or B could get the largest > number of votes in a 3-way split but may not have an overall majority of > all those voting. > > Simon > > Mary Leland wrote: > > > > I'm going to go along with Jishnu's assurance that the AB will > > forgive us if we get the IDL to Java report in a week late, and > > try to get this issue resolved for the report. > > > > For this vote, please choose one of > > A. Accept Harold's revised proposal (see below for the text). > > B. Add in Vijay's proposal for a marker interface (see below > > for proposed text - any amendment from Vijay will be considered > > friendly) > > C. Leave the issue open for now. > > > > We'll go with whichever receives the most votes. > > > > Please vote as soon as practical; the absolute deadline is > > 9 am, US EDT, Monday, June 25. > > (Juergen: I'll get the report to you sometime on the 25th) > > > > -------------------------------------------------------------- > > Harold's revised proposal (Option A): > > > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > > Interfaces", on page 1-29, with > > > > Local Interfaces > > > > A local interface is mapped identically to a non-local > > interface. An implementation of may then be specified as: > > > > class Impl > > extends org.omg.CORBA.LocalObject > > implements > > > > and an instance would be created using the usual Java language construct: > > > > Impl ti = new Impl(...); > > > > 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. > > > > ORB implementations shall detect attempts to marshal local objects and > > throw a CORBA::MARSHAL exception. > > > > Issue > > > > An example for local interface should be added. > > > > ------------------------------------------------------------------------ > > Vijay's proposal (Option B): > > > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > > Interfaces", on page 1-29, with > > > > Local Interfaces > > > > A new interface in org.omg.CORBA called LocalInterface is defined as: > > > > public interface LocalInterface extends org.omg.CORBA.Object { > > } > > > > A local interface is mapped to the the following java classes: > > > > interface extends Operations, org.omg.CORBA.LocalInterface, > > org.omg.CORBA.portable.IDLEntity > > > > where interface and Operations are identical to > > the mapping for a non-local interface. > > > > An implementation of may then be specified as: > > > > class Impl > > extends org.omg.CORBA.LocalObject > > implements > > > > and an instance would be created using the usual Java language construct: > > > > Impl ti = new Impl(...); > > > > 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. > > > > ORB implementations shall detect attempts to marshal local objects and > > throw a CORBA::MARSHAL exception. > > > > Issue > > > > An example for local interface should be added. > > > > --------------------------------------------------------------------------- > > -- > 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 > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* Date: Mon, 18 Jun 2001 12:55:12 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeffrey Mischkinsky Cc: Simon Nash , Java RTF , Harold Carr , Vijaykumar Natarajan , Cuie Zhao , Juergen Boldt Subject: Re: Revised Vote: Issue 4323 References: <200106181526.IAA10430@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 0!R!!~!He91*J!!;P>e9 Okay. How's this sound: If one of the alternative proposals A or B gets a majority of the votes cast, we'll adopt that one. If A or B gets a plurality but not a majority we'll have a second vote on whether to adopt the winner. This second vote will have a very quick deadline. In fact, voters should feel free to vote "in advance" on how they feel about alternatives A and B - would you vote in favor of it if it gets a plurality, even if it isn't your first choice? If C (do nothing) gets a majority or a plurality, we won't get this issue resolved in time for the interim report. We should try for a resolution early in the next cycle. Mary Jeffrey Mischkinsky wrote: > > Hi, > I was going to say something similar, but Simon took the words out of > fingers. > > You could try Single Transferable Voting (the way the AB elections are > run) if you could get Andrew to agree. Then we'd only need to vote once. > Let's see if he's listening:-) > > jeff > > 'Simon Nash' writes: > > > > Mary, > > I think we need a vote to select one of these options, followed by a vote > > on whether to adopt the selected option (if A or B is selected by the first > > vote). If we only have one vote, then either A or B could get the largest > > number of votes in a 3-way split but may not have an overall majority of > > all those voting. > > > > Simon > > > > Mary Leland wrote: > > > > > > I'm going to go along with Jishnu's assurance that the AB will > > > forgive us if we get the IDL to Java report in a week late, and > > > try to get this issue resolved for the report. > > > > > > For this vote, please choose one of > > > A. Accept Harold's revised proposal (see below for the text). > > > B. Add in Vijay's proposal for a marker interface (see below > > > for proposed text - any amendment from Vijay will be considered > > > friendly) > > > C. Leave the issue open for now. > > > > > > We'll go with whichever receives the most votes. > > > > > > Please vote as soon as practical; the absolute deadline is > > > 9 am, US EDT, Monday, June 25. > > > (Juergen: I'll get the report to you sometime on the 25th) > > > > > > -------------------------------------------------------------- > > > Harold's revised proposal (Option A): > > > > > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > > > Interfaces", on page 1-29, with > > > > > > Local Interfaces > > > > > > A local interface is mapped identically to a non-local > > > interface. An implementation of may then be specified as: > > > > > > class Impl > > > extends org.omg.CORBA.LocalObject > > > implements > > > > > > and an instance would be created using the usual Java language construct: > > > > > > Impl ti = new Impl(...); > > > > > > 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. > > > > > > ORB implementations shall detect attempts to marshal local objects and > > > throw a CORBA::MARSHAL exception. > > > > > > Issue > > > > > > An example for local interface should be added. > > > > > > ------------------------------------------------------------------------ > > > Vijay's proposal (Option B): > > > > > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > > > Interfaces", on page 1-29, with > > > > > > Local Interfaces > > > > > > A new interface in org.omg.CORBA called LocalInterface is defined as: > > > > > > public interface LocalInterface extends org.omg.CORBA.Object { > > > } > > > > > > A local interface is mapped to the the following java classes: > > > > > > interface extends Operations, org.omg.CORBA.LocalInterface, > > > org.omg.CORBA.portable.IDLEntity > > > > > > where interface and Operations are identical to > > > the mapping for a non-local interface. > > > > > > An implementation of may then be specified as: > > > > > > class Impl > > > extends org.omg.CORBA.LocalObject > > > implements > > > > > > and an instance would be created using the usual Java language construct: > > > > > > Impl ti = new Impl(...); > > > > > > 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. > > > > > > ORB implementations shall detect attempts to marshal local objects and > > > throw a CORBA::MARSHAL exception. > > > > > > Issue > > > > > > An example for local interface should be added. > > > > > > --------------------------------------------------------------------------- > > > > -- > > 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 > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* Date: Sun, 17 Jun 2001 22:00:03 +0100 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: Harold Carr CC: Cuie Zhao , Harold Carr , java-rtf@omg.org Subject: Re: Issue 4323 References: <200106142239.PAA11825@shorter.eng.sun.com> <3B29DD29.D8404BDA@borland.com> <3B2A2A7A.A810C882@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Y<[d9QQ!e9X(Z!!?(@e9 Harold, Harold Carr wrote: > > Hello Vijay (who is Cuie Zhao?): > > > I am afraid that's not a great argument. First, the only support for local > > interfaces that any vendor now supports is the presence of the LocalObject > > class in the package, and the absence of the marker interface in the generated > > code. So, let's say you ship w/o that support? what happens when you have to > > We can't ship without that support because we have PortableInterceptors > which relies on local objects. > > > update your product to conform to a new spec (the one w/ my proposal, say). > > You change the code generation to include Local. Your user's code doesn't > > change (user still implements LocalObject). If the user didn't do that in the > > implementation, bad things happen both in your old product and in your new > > product. Everything still works. So I don't see a problem. Further, the > > current spec says only that the implementation is required to extend > > org.omg.CORBA.LocalObject, which is still the case. > > That sounds reasonable, however... > > > > > > 2. Our product schedule is such that we need to resolve this ASAP > > > > > (i.e., June 18) with as little change as possible. > > > > See above. Also, I don't see how this is a big change. All you have to do is > > add one interface and change code generation to replace four words. Given that > > the IDLEntity interface hierarchy change is acceptable to you, I don't see how > > this is different. > > The time for adding new APIs in our current schedule has long past. > > Yes, the IDLEntity change is fine. > > > > > > 3. If a user follows the proposed specification then attempts to marshal > > > local interfaces can be caught and handled correctly. > > > > Up until now, I don't see any part of the specification that requires the user > > to do something specific so the ORB can maintain IDL semantics. > > > > I agree with all of Simon's changes. The IDLEntity inheritance must exist. > > Yes, my modified proposal did agree with all Simon's changes too. > > > > > Also, I too think that we are trying to rush this issue and given the > > contention would prefer to defer the issue rather than adopt something that we > > may regret. > > I think Jishnu pointed out that this should be resolved. > > > > Thanks, > > Vijay > > After applying Simon's changes all my modified proposal does is resolve > two of the issues in the existing ptc/00-11-03 text (i.e., IDLEntity and > signature and operation interfaces). It seems we could get agreement on > this since my proposal doesn't change the existing spec, it just makes > it less ambiguous. > I agree that your latest proposal is an incremental improvement on what appears in the spec currently. My only concern is that it requires all local objects to be serializable, but I can't see any way round this, given that IDLEntity extends java.io.Serializable. Simon -- 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: Mon, 18 Jun 2001 15:01:27 -0700 (PDT) Message-Id: <200106182201.PAA21086@shorter.eng.sun.com> From: Harold Carr To: java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 Content-Type: text X-UIDL: iRHe9j`ld95;3e9;TM!! Hello all, Proposal A is a simple incremental change. Proposal B is attempting to solve another problem (programmer error). However, proposal B has other implications which I detail below. I need to say again that it is TOO LATE to add or change APIs in J2SE 1.4. The J2SE 1.4 APIs are FROZEN. Proposal B has the following problem with respect to frozen APIs: J2SE 1.4 includes the POA. Generated code for the POA looks like: package org.omg.PortableServer; public interface POA extends POAOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity { } When the POA changes to be a local interface (rather than locality constrained, CORBA 2.4?) and if proposal B were to be adopted then the above would need to change to: public interface POA extends POAOperations, org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity { } But, it is TOO LATE to change APIs in J2SE 1.4. Proposal A, which just clears up ambiguities in the current spec, states that generated code for local interfaces is identical to code generated for non-local interfaces. Therefore there will be no problems with existing code, nor when the POA changes to local interface. I am trying to point out that proposal B has implications reaching further than the technical problem it is solving (catching a programmer error) whereas proposal A is an incremental improvement to the existing spec which is compatible with existing code and future code. Although Sun is shipping the POA for the first time, any other vendor products that have already shipped the POA would also be impacted by proposal B. Compatibility needs to be the main point of the resolution at this time. Thanks, Harold Date: Tue, 19 Jun 2001 11:42:26 +0800 From: Cuie Zhao Subject: Re: Revised Vote: Issue 4323 To: Harold Carr Cc: java-rtf@omg.org Message-id: <3B2ECA22.53AF25B9@borland.com> MIME-version: 1.0 X-Mailer: Mozilla 4.74 [en] (WinNT; U) Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200106182201.PAA21086@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: 8"]!!FAa!!SVOe9D58e9 Hi Harold & all, I am Cuie Zhao, proxy of Vijay. See my comments inline. > Hello all, > > Proposal A is a simple incremental change. I agree it's a simple incremental change and I do not object that. But it does not solve the other problem as you mentioned while proposal B solves it. A & B do not conflict. They compliment each other. > Proposal B is attempting > to solve another problem (programmer error). However, proposal B > has > other implications which I detail below. > > I need to say again that it is TOO LATE to add or change APIs in > J2SE > 1.4. The J2SE 1.4 APIs are FROZEN. > J2SE 1.4 release date is early next year? Besides, the effort you need to make it compliant with Vijay's proposal is minimal: all you need to do is to have the compiler regenerate the code. You do not have to modify any of your other codes. With this minimal effort, what you gain is a clean and graceful way in detection of user's error. > > But, it is TOO LATE to change APIs in J2SE 1.4. > > Proposal A, which just clears up ambiguities in the current spec, > states that generated code for local interfaces is identical to code > generated for non-local interfaces. Therefore there will be no > problems with existing code, nor when the POA changes to local > interface. > > I am trying to point out that proposal B has implications reaching > further than the technical problem it is solving (catching a > programmer error) whereas proposal A is an incremental improvement >to > the existing spec which is compatible with existing code and future > code. > > Although Sun is shipping the POA for the first time, any other >vendor > products that have already shipped the POA would also be impacted by > proposal B. I would have to say that this does not mean that the spec should not evolve just because of some products being frozen or shipped. > > Compatibility needs to be the main point of the resolution at this >time. I agree compatibility is important. But I don't see how compatibility is a big issue here? All one needs to do is to recompile once the compiler does the right job. Moreover, if you put Vijay's proposal into J2SE 1.4 now (a couple of minutes to implement it?), you won't have the compatibility issue at all. As for other vendors, why don't we let themselves decide? Cheers, Cuie -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from unknown (207.105.72.220) by hobbit.omg.org asmtp(1.0) id 22663; Tue, 19 Jun 2001 01:39:07 -0400 (EDT) Received: from singaporemail2.inprise.com (singaporemail2.inprise.com [143.186.139.187]) by sv-mta2.inprise.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GF500A36WL0K4@sv-mta2.inprise.com> for java-rtf@omg.org; Mon, 18 Jun 2001 22:29:25 -0700 (PDT) Received: from borland.com ([143.186.139.72]) by singaporemail2.inprise.com (iPlanet Messaging Server 5.1 (built May 8 2001)) with ESMTP id for java-rtf@omg.org; Tue, 19 Jun 2001 14:35:09 -0700 (Pacific Daylight Time) Date: Tue, 19 Jun 2001 13:26:31 +0800 From: Cuie Zhao Subject: Re: Revised Vote: Issue 4323 To: Harold Carr , java-rtf@omg.org Message-id: <3B2EE287.D3AD750A@borland.com> MIME-version: 1.0 X-Mailer: Mozilla 4.74 [en] (WinNT; U) Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200106182201.PAA21086@shorter.eng.sun.com> <3B2ECA22.53AF25B9@borland.com> Content-Type: text/plain; charset=us-ascii X-UIDL: WcW!!bG2e9ejP!!1fl!! Hi all, Cuie Zhao wrote: > Hi Harold & all, > > I am Cuie Zhao, proxy of Vijay. See my comments inline. > > > Hello all, > > > > Proposal A is a simple incremental change. > > I agree it's a simple incremental change and I do not object >that. But it > does not solve the other problem as you mentioned while proposal B >solves > it. A & B do not conflict. They compliment each other. > > > Proposal B is attempting > > to solve another problem (programmer error). However, proposal B >has > > other implications which I detail below. > > > > I need to say again that it is TOO LATE to add or change APIs in >J2SE > > 1.4. The J2SE 1.4 APIs are FROZEN. > > > > J2SE 1.4 release date is early next year? Besides, the effort you >need to > make it compliant with Vijay's proposal is minimal: all you need to >do is to > have the compiler regenerate the code. You do not have to modify any >of your > other codes. With this minimal effort, what you gain is a clean and >graceful > way in detection of user's error. > > > > > But, it is TOO LATE to change APIs in J2SE 1.4. > > > > Proposal A, which just clears up ambiguities in the current spec, > > states that generated code for local interfaces is identical to >code > > generated for non-local interfaces. Therefore there will be no > > problems with existing code, nor when the POA changes to local > > interface. > > > > I am trying to point out that proposal B has implications reaching > > further than the technical problem it is solving (catching a > > programmer error) whereas proposal A is an incremental improvement >to > > the existing spec which is compatible with existing code and >future > > code. > > > > Although Sun is shipping the POA for the first time, any other >vendor > > products that have already shipped the POA would also be impacted >by > > proposal B. > > I would have to say that this does not mean that the spec should not >evolve > just because of some products being frozen or shipped. > > > > > Compatibility needs to be the main point of the resolution at this >time. > > I agree compatibility is important. But I don't see how >compatibility is a > big issue here? All one needs to do is to recompile once the >compiler does > the right job. Moreover, if you put Vijay's proposal into J2SE 1.4 >now (a > couple of minutes to implement it?), you won't have the >compatibility issue > at all. > just to make myself clear and avoid miscommunication: what I meant is that I believe at this stage, the number of products shipped and deployed with local support is limited. So the number of customers that would require code regeneration are very limited. (And even if I am wrong, voters on the voting list will naturely voice on their own behalf as they kown their own products and customers better than anybody else, isn't it?). > > As for other vendors, why don't we let themselves decide? > > Cheers, > > Cuie > > -- > > This e-mail, and any attachments thereto, is intended only for use >by > the addressee(s) named herein and may contain legally privileged > and/or confidential information. If you are not the intended >recipient > of this e-mail, you are hereby notified that any dissemination, >distribution > > or copying of this e-mail, and any attachments thereto, is strictly > prohibited. > If you have received this e-mail in error, please immediately and > permanently > delete the original and any copy of any e-mail and any printout >thereof. -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Date: Tue, 19 Jun 2001 08:40:19 -0700 (PDT) Message-Id: <200106191540.IAA14845@shorter.eng.sun.com> From: Harold Carr To: java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 Content-Type: text X-UIDL: EDSd9`~pd9[\o!!'!0!! Hello Cuie, Vijay and java-rtf, The problem I pointed out with Proposal B (adding a marker interface and changing generated code to derive from it) has nothing to do with customer code. It applies to APIs that are frozen in J2SE 1.4. For instance, the J2SE 1.4 APIs include the interfaces in org.omg.PortableServer, org.omg.PortableInterceptor, and more. For example: >From PortableServer: AdapterActivator, LifespanPolicy, POA, etc >From PortableInterceptor: ClientRequestInfo, IORInterceptor, ORBInitializer, etc. They all have code that looks like: public interface ORBInitializer extends ORBInitializerOperations, org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity It is TOO LATE to change this. J2SE 1.4 is a rich platform (i.e., large). The CORBA part is only a small part of that platform. The entire platform APIs have been frozen quite a while ago. Many parts of the organization have now proceeded to work with those APIs (e.g., CTS, doc, etc.). Another problem with Proposal B. In officially adopted OMG specifications the POA interfaces are still locality constrained. Therefore, even if proposal B were adopted the POA interfaces could not be changed until after the POA officially switches to local interfaces. Therefore, besides being frozen, the POA must be shipped with the current official mapping. When the interfaces become local interfaces the mapping stays the same in the current spec and in proposal A. The CORBA portion of J2SE 1.4 was written to comply with the local interface specification in In ptc/2000-11-03. I raised this issue to remove those ambiguities. Can we just fix the ambiguities and be done with it? Thanks, Harold Date: Tue, 19 Jun 2001 16:19:20 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Java RTF , Harold Carr , Simon Nash , Vijaykumar Natarajan , Cuie Zhao Subject: Re: Revised Vote: Issue 4323 References: <3B2E001A.B7593FFE@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: D8Q!!HgMd9dYcd9b&\!! HP votes for alternative A. Mary Leland HP Advanced Development Florham Park, NJ 07922 Mary Leland wrote: > > I'm going to go along with Jishnu's assurance that the AB will > forgive us if we get the IDL to Java report in a week late, and > try to get this issue resolved for the report. > > For this vote, please choose one of > A. Accept Harold's revised proposal (see below for the text). > B. Add in Vijay's proposal for a marker interface (see below > for proposed text - any amendment from Vijay will be considered > friendly) > C. Leave the issue open for now. > > We'll go with whichever receives the most votes. > > Please vote as soon as practical; the absolute deadline is > 9 am, US EDT, Monday, June 25. > (Juergen: I'll get the report to you sometime on the 25th) > > -------------------------------------------------------------- > Harold's revised proposal (Option A): > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29, with > > Local Interfaces > > A local interface is mapped identically to a non-local > interface. An implementation of may then be specified as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be created using the usual Java language construct: > > Impl ti = new Impl(...); > > 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. > > ORB implementations shall detect attempts to marshal local objects and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > ------------------------------------------------------------------------ > Vijay's proposal (Option B): > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29, with > > Local Interfaces > > A new interface in org.omg.CORBA called LocalInterface is defined as: > > public interface LocalInterface extends org.omg.CORBA.Object { > } > > A local interface is mapped to the the following java classes: > > interface extends Operations, org.omg.CORBA.LocalInterface, > org.omg.CORBA.portable.IDLEntity > > where interface and Operations are identical to > the mapping for a non-local interface. > > An implementation of may then be specified as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be created using the usual Java language construct: > > Impl ti = new Impl(...); > > 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. > > ORB implementations shall detect attempts to marshal local objects and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > --------------------------------------------------------------------------- Date: Wed, 20 Jun 2001 12:22:28 +0800 From: Cuie Zhao Subject: Re: Revised Vote: Issue 4323 To: Harold Carr Cc: java-rtf@omg.org Message-id: <3B302504.CEB8C37B@borland.com> MIME-version: 1.0 X-Mailer: Mozilla 4.74 [en] (WinNT; U) Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200106191540.IAA14845@shorter.eng.sun.com> Content-Type: text/plain; charset=us-ascii X-UIDL: R'+!!=l(e9"0g!!hiLe9 Hi Harold, I can understand your insisting on not changing the J2SE 1.4 APIs. But I do not understand why you have problem with Proposal B that augments Proposal A from a standard spec perspective. Sun can always ship J2SE 1.4 as it is w.r.t. this issue (which is A compliant) but have its future releases Proposal B complaint. There isn't any product back-compat issue here as everything we are talking about here are local objects. I have no problem with the majority wins criteria as Mary/Simon/Jeff have proposed. Cheers, // Cuie Harold Carr wrote: > Hello Cuie, Vijay and java-rtf, > > The problem I pointed out with Proposal B (adding a marker interface > and changing generated code to derive from it) has nothing to do >with > customer code. It applies to APIs that are frozen in J2SE 1.4. For > instance, the J2SE 1.4 APIs include the interfaces in > org.omg.PortableServer, org.omg.PortableInterceptor, and more. For >example: > > From PortableServer: > > AdapterActivator, LifespanPolicy, POA, etc > > From PortableInterceptor: > > ClientRequestInfo, IORInterceptor, ORBInitializer, etc. > > They all have code that looks like: > > public interface ORBInitializer > extends ORBInitializerOperations, > org.omg.CORBA.Object, > org.omg.CORBA.portable.IDLEntity > > It is TOO LATE to change this. J2SE 1.4 is a rich platform (i.e., > large). The CORBA part is only a small part of that platform. The > entire platform APIs have been frozen quite a while ago. Many parts > of the organization have now proceeded to work with those APIs >(e.g., > CTS, doc, etc.). > > Another problem with Proposal B. In officially adopted OMG > specifications the POA interfaces are still locality constrained. > Therefore, even if proposal B were adopted the POA interfaces could > not be changed until after the POA officially switches to local > interfaces. Therefore, besides being frozen, the POA must be >shipped > with the current official mapping. When the interfaces become local > interfaces the mapping stays the same in the current spec and in > proposal A. > > The CORBA portion of J2SE 1.4 was written to comply with the local > interface specification in In ptc/2000-11-03. I raised this issue >to > remove those ambiguities. > > Can we just fix the ambiguities and be done with it? > > Thanks, > Harold -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Date: Wed, 20 Jun 2001 12:58:22 +0800 From: Cuie Zhao Subject: Re: Revised Vote: Issue 4323 To: Mary Leland Cc: Jeffrey Mischkinsky , Simon Nash , Java RTF , Harold Carr , Vijaykumar Natarajan , Juergen Boldt Message-id: <3B302D6E.BB422BED@borland.com> MIME-version: 1.0 X-Mailer: Mozilla 4.74 [en] (WinNT; U) Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200106181526.IAA10430@wheel.dcn.davis.ca.us> <3B2E3270.11778904@fpk.hp.com> Content-Type: text/plain; charset=us-ascii X-UIDL: & Okay. How's this sound: > > If one of the alternative proposals A or B gets a majority of the >votes cast, > we'll adopt that one. > > If A or B gets a plurality but not a majority we'll have a second >vote on > whether to adopt the winner. This second vote will have a very >quick deadline. > In fact, voters should feel free to vote "in advance" on how they >feel about > alternatives A and B - would you vote in favor of it if it gets a >plurality, > even if it isn't your first choice? > > If C (do nothing) gets a majority or a plurality, we won't get this > issue resolved in time for the interim report. We should try for a > resolution early in the next cycle. > > Mary > > Jeffrey Mischkinsky wrote: > > > > Hi, > > I was going to say something similar, but Simon took the words >out of > > fingers. > > > > You could try Single Transferable Voting (the way the AB >elections are > > run) if you could get Andrew to agree. Then we'd only need to >vote once. > > Let's see if he's listening:-) > > > > jeff > > > > 'Simon Nash' writes: > > > > > > Mary, > > > I think we need a vote to select one of these options, followed >by a vote > > > on whether to adopt the selected option (if A or B is selected >by the first > > > vote). If we only have one vote, then either A or B could get >the largest > > > number of votes in a 3-way split but may not have an overall >majority of > > > all those voting. > > > > > > Simon > > > > > > Mary Leland wrote: > > > > > > > > I'm going to go along with Jishnu's assurance that the AB will > > > > forgive us if we get the IDL to Java report in a week late, >and > > > > try to get this issue resolved for the report. > > > > > > > > For this vote, please choose one of > > > > A. Accept Harold's revised proposal (see below for the text). > > > > B. Add in Vijay's proposal for a marker interface (see below > > > > for proposed text - any amendment from Vijay will be >considered > > > > friendly) > > > > C. Leave the issue open for now. > > > > > > > > We'll go with whichever receives the most votes. > > > > > > > > Please vote as soon as practical; the absolute deadline is > > > > 9 am, US EDT, Monday, June 25. > > > > (Juergen: I'll get the report to you sometime on the 25th) > > > > > > > > -------------------------------------------------------------- > > > > Harold's revised proposal (Option A): > > > > > > > > In ptc/2000-11-03, replace the existing Section 1.12.1 , >"Local > > > > Interfaces", on page 1-29, with > > > > > > > > Local Interfaces > > > > > > > > A local interface is mapped identically to a >non-local > > > > interface. An implementation of may then be >specified as: > > > > > > > > class Impl > > > > extends org.omg.CORBA.LocalObject > > > > implements > > > > > > > > and an instance would be created using the usual Java language >construct: > > > > > > > > Impl ti = new Impl(...); > > > > > > > > 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. > > > > > > > > ORB implementations shall detect attempts to marshal local >objects and > > > > throw a CORBA::MARSHAL exception. > > > > > > > > Issue > > > > > > > > An example for local interface should be added. > > > > > > > > >------------------------------------------------------------------------ > > > > Vijay's proposal (Option B): > > > > > > > > In ptc/2000-11-03, replace the existing Section 1.12.1 , >"Local > > > > Interfaces", on page 1-29, with > > > > > > > > Local Interfaces > > > > > > > > A new interface in org.omg.CORBA called LocalInterface is >defined as: > > > > > > > > public interface LocalInterface extends org.omg.CORBA.Object { > > > > } > > > > > > > > A local interface is mapped to the the following >java classes: > > > > > > > > interface extends Operations, >org.omg.CORBA.LocalInterface, > > > > org.omg.CORBA.portable.IDLEntity > > > > > > > > where interface and Operations are >identical to > > > > the mapping for a non-local interface. > > > > > > > > An implementation of may then be specified as: > > > > > > > > class Impl > > > > extends org.omg.CORBA.LocalObject > > > > implements > > > > > > > > and an instance would be created using the usual Java language >construct: > > > > > > > > Impl ti = new Impl(...); > > > > > > > > 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. > > > > > > > > ORB implementations shall detect attempts to marshal local >objects and > > > > throw a CORBA::MARSHAL exception. > > > > > > > > Issue > > > > > > > > An example for local interface should be added. > > > > > > > > >--------------------------------------------------------------------------- > > > > > > -- > > > 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 > > > > > > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Date: Wed, 20 Jun 2001 00:11:34 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Cuie Zhao CC: Harold Carr , java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 References: <200106191540.IAA14845@shorter.eng.sun.com> <3B302504.CEB8C37B@borland.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b%O!!3Ck!!fD>e9"8=!! Hello again, > I can understand your insisting on not changing the J2SE 1.4 APIs. But I do not > understand why you have problem with Proposal B that augments Proposal A from a > standard spec perspective. Sun can always ship J2SE 1.4 as it is w.r.t. this > issue (which is A compliant) but have its future releases Proposal B complaint. > There isn't any product back-compat issue here as everything we are talking > about here are local objects. Once an API is shipped in a J2SE version that API cannot change. It can be deprecated and replaced, but it cannot change. Therefore, it is impossible to ship a POA class, for example, that will change its derivation in a future release. Proposal B is just not possible at this date. Proposal A does not change any APIs, it just resolves two issues noted in the spec. Cheers, Harold Date: Wed, 20 Jun 2001 11:22:20 +0100 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: Harold Carr CC: Cuie Zhao , Harold Carr , java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 References: <200106191540.IAA14845@shorter.eng.sun.com> <3B302504.CEB8C37B@borland.com> <3B304CA6.B9587103@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 5!Qd9O(=e9YHi!!c^Ee9 Harold, J2SE APIs do change in "single dot" releases. For example, in J2SE 1.4, the java.sql.Connection interface is being changed to add a number of new methods. I see no difference between adding new methods and a new interface derivation. Simon Harold Carr wrote: > > Hello again, > > > I can understand your insisting on not changing the J2SE 1.4 APIs. But I do not > > understand why you have problem with Proposal B that augments Proposal A from a > > standard spec perspective. Sun can always ship J2SE 1.4 as it is w.r.t. this > > issue (which is A compliant) but have its future releases Proposal B complaint. > > There isn't any product back-compat issue here as everything we are talking > > about here are local objects. > > Once an API is shipped in a J2SE version that API cannot change. It can > be deprecated and replaced, but it cannot change. Therefore, it is > impossible to ship a POA class, for example, that will change its > derivation in a future release. Proposal B is just not possible at this > date. Proposal A does not change any APIs, it just resolves two issues > noted in the spec. > > Cheers, > Harold -- 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: Wed, 20 Jun 2001 12:51:55 +0100 From: Eoghan Glynn X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Mary Leland CC: Java RTF , Harold Carr , Simon Nash , Vijaykumar Natarajan , Cuie Zhao , Juergen Boldt Subject: Re: Revised Vote: Issue 4323 References: <3B2E001A.B7593FFE@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: CQ+!!]ckd9K3Od9Rk%e9 IONA votes for option A. /Eoghan. Mary Leland wrote: > > I'm going to go along with Jishnu's assurance that the AB will > forgive us if we get the IDL to Java report in a week late, and > try to get this issue resolved for the report. > > For this vote, please choose one of > A. Accept Harold's revised proposal (see below for the text). > B. Add in Vijay's proposal for a marker interface (see below > for proposed text - any amendment from Vijay will be considered > friendly) > C. Leave the issue open for now. > > We'll go with whichever receives the most votes. > > Please vote as soon as practical; the absolute deadline is > 9 am, US EDT, Monday, June 25. > (Juergen: I'll get the report to you sometime on the 25th) > > -------------------------------------------------------------- > Harold's revised proposal (Option A): > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29, with > > Local Interfaces > > A local interface is mapped identically to a non-local > interface. An implementation of may then be specified as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be created using the usual Java language construct: > > Impl ti = new Impl(...); > > 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. > > ORB implementations shall detect attempts to marshal local objects and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > ------------------------------------------------------------------------ > Vijay's proposal (Option B): > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29, with > > Local Interfaces > > A new interface in org.omg.CORBA called LocalInterface is defined as: > > public interface LocalInterface extends org.omg.CORBA.Object { > } > > A local interface is mapped to the the following java classes: > > interface extends Operations, org.omg.CORBA.LocalInterface, > org.omg.CORBA.portable.IDLEntity > > where interface and Operations are identical to > the mapping for a non-local interface. > > An implementation of may then be specified as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be created using the usual Java language construct: > > Impl ti = new Impl(...); > > 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. > > ORB implementations shall detect attempts to marshal local objects and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > --------------------------------------------------------------------------- Date: Wed, 20 Jun 2001 14:42:33 +0100 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: Mary Leland CC: Java RTF , Harold Carr , Vijaykumar Natarajan , Cuie Zhao , Juergen Boldt Subject: Re: Revised Vote: Issue 4323 References: <3B2E001A.B7593FFE@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: C;%!!!88e9%mad9LN+e9 Mary, IBM votes as follows for issue 4323: B. This permits the Java to IDL mapping to diagnose an attempt to pass an IDL local interface type across a remote RMI-IIOP interface with a compile-time error, instead of the error being discovered at runtime. Simon Mary Leland wrote: > > I'm going to go along with Jishnu's assurance that the AB will > forgive us if we get the IDL to Java report in a week late, and > try to get this issue resolved for the report. > > For this vote, please choose one of > A. Accept Harold's revised proposal (see below for the text). > B. Add in Vijay's proposal for a marker interface (see below > for proposed text - any amendment from Vijay will be considered > friendly) > C. Leave the issue open for now. > > We'll go with whichever receives the most votes. > > Please vote as soon as practical; the absolute deadline is > 9 am, US EDT, Monday, June 25. > (Juergen: I'll get the report to you sometime on the 25th) > > -------------------------------------------------------------- > Harold's revised proposal (Option A): > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29, with > > Local Interfaces > > A local interface is mapped identically to a non-local > interface. An implementation of may then be specified as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be created using the usual Java language construct: > > Impl ti = new Impl(...); > > 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. > > ORB implementations shall detect attempts to marshal local objects and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > ------------------------------------------------------------------------ > Vijay's proposal (Option B): > > In ptc/2000-11-03, replace the existing Section 1.12.1 , "Local > Interfaces", on page 1-29, with > > Local Interfaces > > A new interface in org.omg.CORBA called LocalInterface is defined as: > > public interface LocalInterface extends org.omg.CORBA.Object { > } > > A local interface is mapped to the the following java classes: > > interface extends Operations, org.omg.CORBA.LocalInterface, > org.omg.CORBA.portable.IDLEntity > > where interface and Operations are identical to > the mapping for a non-local interface. > > An implementation of may then be specified as: > > class Impl > extends org.omg.CORBA.LocalObject > implements > > and an instance would be created using the usual Java language construct: > > Impl ti = new Impl(...); > > 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. > > ORB implementations shall detect attempts to marshal local objects and > throw a CORBA::MARSHAL exception. > > Issue > > An example for local interface should be added. > > --------------------------------------------------------------------------- -- 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: Wed, 20 Jun 2001 11:53:45 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 CC: Harold Carr , java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 References: <200106191540.IAA14845@shorter.eng.sun.com> <3B302504.CEB8C37B@borland.com> <3B304CA6.B9587103@sun.com> <3B30795C.680DD5B0@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: !;m!!+65e94nVd9d22e9 Hello Simon, The Java Language Specification (JLS) 13.4.5 indicates that it is possible to add new METHODS without breaking binary compatibility. However, JLS 13.4.4 states: "If a change to the direct superclass or the set of direct superinterfaces results in any class or interface no longer being a superclass or superinterface, respectively, then link-time errors may result if pre-existing binaries are loaded with the binary of the modified class. Such changes are not recommended for widely distributed classes." Therefore, as I have been saying, it is too late to change J2SE 1.4 APIs so proposal B is just not possible. Cheers, Harold > > Harold, > J2SE APIs do change in "single dot" releases. For example, in J2SE > 1.4, the > java.sql.Connection interface is being changed to add a number of > new methods. > I see no difference between adding new methods and a new interface > derivation. > > Simon > > Harold Carr wrote: > > Once an API is shipped in a J2SE version that API cannot change. It can > > be deprecated and replaced, but it cannot change. Therefore, it is > > impossible to ship a POA class, for example, that will change its > > derivation in a future release. Proposal B is just not possible at this > > date. Proposal A does not change any APIs, it just resolves two issues > > noted in the spec. Date: Wed, 20 Jun 2001 15:38:31 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash Cc: Harold Carr , Cuie Zhao , Harold Carr , java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 References: <200106191540.IAA14845@shorter.eng.sun.com> <3B302504.CEB8C37B@borland.com> <3B304CA6.B9587103@sun.com> <3B30795C.680DD5B0@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 1G&!!:-Z!!"Y6!!!GAe9 Simon Nash wrote: > > Harold, > J2SE APIs do change in "single dot" releases. For example, in J2SE 1.4, the > java.sql.Connection interface is being changed to add a number of new methods. > I see no difference between adding new methods and a new interface derivation. > > Simon Simon, Are you saying that there is no difference from the perspective of binary compatibility between adding a few methods to an interface on the one hand and changing a derivation hierarchy on the other? That sounds a bit odd to me, which leads me to believe I may be missing something or misinterpreting something that you are saying. Could you please explain a bit more? Thanks, Jishnu. Date: Wed, 20 Jun 2001 12:57:22 -0700 From: Harold Carr X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Harold Carr , java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 References: <200106191540.IAA14845@shorter.eng.sun.com> <3B302504.CEB8C37B@borland.com> <3B304CA6.B9587103@sun.com> <3B30795C.680DD5B0@hursley.ibm.com> <3B30F139.1962ACFF@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: )i'e99eG!!L8%e9"-,!! Hello all, Proposal B would break binary compatibility of any existing applications/products which already use/provide the POA interfaces or any local interfaces (e.g., PortableInterceptors). It would break existing local interfaces since the derivation tree would change. Later, when the POA becomes a local interface rather than locality constrained, changing its derivation tree would break binary compatibility. Proposal A does not have these problems. It is binary compatible with existing code now. In the future, when the POA becomes a local interface, existing POA interfaces will continue to be binary compatible. Cheers, Harold Harold Carr wrote: > > Hello Simon, > > The Java Language Specification (JLS) 13.4.5 indicates that it is > possible to add new METHODS without breaking binary compatibility. > However, JLS 13.4.4 states: > > "If a change to the direct superclass or the set of direct > superinterfaces results in any class or interface no longer being a > superclass or superinterface, respectively, then link-time errors may > result if pre-existing binaries are loaded with the binary of the > modified class. Such changes are not recommended for widely distributed > classes." Date: Wed, 20 Jun 2001 22:50:42 +0100 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: Harold Carr CC: Harold Carr , java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 References: <200106191540.IAA14845@shorter.eng.sun.com> <3B302504.CEB8C37B@borland.com> <3B304CA6.B9587103@sun.com> <3B30795C.680DD5B0@hursley.ibm.com> <3B30F139.1962ACFF@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: )bC!!Xbb!!"c?!!;S7!! Harold, This refers to removing superinterfaces, not adding them. Removing a superinterface from the POA would not be a binary compatible change, but adding a new superinterface LocalInterface is binary compatible. This is stated in section 13.4.4 of the JLS: "Changing the direct superclass or the set of direct superinterfaces of a class type will not break compatibility with pre-existing binaries, provided that the total set of superclasses or superinterfaces, respectively, of the class type loses no members." Simon Harold Carr wrote: > > Hello Simon, > > The Java Language Specification (JLS) 13.4.5 indicates that it is > possible to add new METHODS without breaking binary compatibility. > However, JLS 13.4.4 states: > > "If a change to the direct superclass or the set of direct > superinterfaces results in any class or interface no longer being a > superclass or superinterface, respectively, then link-time errors may > result if pre-existing binaries are loaded with the binary of the > modified class. Such changes are not recommended for widely distributed > classes." > > Therefore, as I have been saying, it is too late to change J2SE 1.4 APIs > so proposal B is just not possible. > > Cheers, > Harold > > > > > Harold, > > J2SE APIs do change in "single dot" releases. For example, in J2SE 1.4, the > > java.sql.Connection interface is being changed to add a number of new methods. > > I see no difference between adding new methods and a new interface derivation. > > > > Simon > > > > Harold Carr wrote: > > > > Once an API is shipped in a J2SE version that API cannot change. It can > > > be deprecated and replaced, but it cannot change. Therefore, it is > > > impossible to ship a POA class, for example, that will change its > > > derivation in a future release. Proposal B is just not possible at this > > > date. Proposal A does not change any APIs, it just resolves two issues > > > noted in the spec. -- 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: Wed, 20 Jun 2001 22:54:14 +0100 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: jishnu_mukerji@hp.com CC: Harold Carr , Cuie Zhao , Harold Carr , java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 References: <200106191540.IAA14845@shorter.eng.sun.com> <3B302504.CEB8C37B@borland.com> <3B304CA6.B9587103@sun.com> <3B30795C.680DD5B0@hursley.ibm.com> <3B30FBB7.F5456B53@hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: M3hd90eD!!6Ejd9ig/!! Jishnu, Some changes to the inheritance hierarchy are not binary compatible, but some are. Adding a new superinterface is a compatible change. Removing a superclass or superinterface would not be a compatible change. See section 13.4.4 of the Java Language Specification. Simon Jishnu Mukerji wrote: > > Simon Nash wrote: > > > > Harold, > > J2SE APIs do change in "single dot" releases. For example, in J2SE 1.4, the > > java.sql.Connection interface is being changed to add a number of new methods. > > I see no difference between adding new methods and a new interface derivation. > > > > Simon > > Simon, > > Are you saying that there is no difference from the perspective of > binary compatibility between adding a few methods to an interface on the > one hand and changing a derivation hierarchy on the other? That sounds a > bit odd to me, which leads me to believe I may be missing something or > misinterpreting something that you are saying. Could you please explain > a bit more? > > Thanks, > > Jishnu. -- 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: Wed, 20 Jun 2001 22:57:36 +0100 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: Harold Carr CC: Harold Carr , java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 References: <200106191540.IAA14845@shorter.eng.sun.com> <3B302504.CEB8C37B@borland.com> <3B304CA6.B9587103@sun.com> <3B30795C.680DD5B0@hursley.ibm.com> <3B30F139.1962ACFF@sun.com> <3B310022.F4E95A70@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: o&G!!Rk-e90j=!!TU+e9 Harold, I just sent a quote from section 13.4.4 of the Java Language Specification that makes it clear that simply adding a new superinterface (as option B proposes) does not break binary compatibility. Note: The option B up for vote is not the same as the option B that Mary originally proposed. Mary's original option B would have broken binary compatibility because it removed the IDLEntity superinterface. Simon Harold Carr wrote: > > Hello all, > > Proposal B would break binary compatibility of any existing > applications/products which already use/provide the POA interfaces or > any local interfaces (e.g., PortableInterceptors). It would break > existing local interfaces since the derivation tree would change. > Later, when the POA becomes a local interface rather than locality > constrained, changing its derivation tree would break binary > compatibility. > > Proposal A does not have these problems. It is binary compatible with > existing code now. In the future, when the POA becomes a local > interface, existing POA interfaces will continue to be binary > compatible. > > Cheers, > Harold > > Harold Carr wrote: > > > > Hello Simon, > > > > The Java Language Specification (JLS) 13.4.5 indicates that it is > > possible to add new METHODS without breaking binary compatibility. > > However, JLS 13.4.4 states: > > > > "If a change to the direct superclass or the set of direct > > superinterfaces results in any class or interface no longer being a > > superclass or superinterface, respectively, then link-time errors may > > result if pre-existing binaries are loaded with the binary of the > > modified class. Such changes are not recommended for widely distributed > > classes." -- 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: Wed, 20 Jun 2001 19:08:15 -0400 From: Jishnu Mukerji Reply-To: jishnu_mukerji@hp.com Organization: Hewlett-Packard EIAL, Florham Park NJ, USA X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Simon Nash Cc: Harold Carr , Cuie Zhao , java-rtf@omg.org Subject: Re: Revised Vote: Issue 4323 References: <200106191540.IAA14845@shorter.eng.sun.com> <3B302504.CEB8C37B@borland.com> <3B304CA6.B9587103@sun.com> <3B30795C.680DD5B0@hursley.ibm.com> <3B30FBB7.F5456B53@hp.com> <3B311B86.A0C5C70D@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 2/;e9 > Jishnu, > Some changes to the inheritance hierarchy are not binary compatible, but some are. > Adding a new superinterface is a compatible change. Removing a superclass or > superinterface would not be a compatible change. See section 13.4.4 of the Java > Language Specification. > > Simon Yes, that clarification helps a lot. Now I understand what you were saying. In effect when you add a bunch of methods, whether you add them individually, or you add them clumped together in a superinterface the effect is the same. Given that, now I would like to understand the argument what Harold is trying to make. So as long as the change introduced by the addition of a superinterface is a binary compatible change, why is this sort of change not permissible? The current frozen API can happily remain frozen if it so desires, and things will work just fine with those that deploy the new stuff. The net net will be that in the product from Sun, the marker interface will be absent until Sun gets around to incorporating it, and that change will be a backward compatible change when it happens. I don't see any reasonable reason why Sun would be unable to make this backward compatible change before 1.4 finally ships, without causing any harm to any implementations of local interfaces that have already been distributed without the marker interface. So what am I missing in this picture here? Thanks, Jishnu. Date: Thu, 21 Jun 2001 16:48:48 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Revised Vote: Issue 4323 To: java-rtf@omg.org Cc: harold.carr@sun.com, czhao@borland.com, jishnu_mukerji@hp.com, pwalker@Eng.Sun.COM, Anita.Jindal@sun.com MIME-Version: 1.0 Content-MD5: NFazIHrDDTPDDQGzkgTlnA== 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: @POe97(S!!a:1e99nbd9 In discussing issue 4323, what is most important to all of us is to look at the underlying technical arguments for the proposals. What I want to explore is exactly what proposal B gives us that proposal A does not. An assumption: A compliant IDL compiler with the resolution of 4323 will NOT generate any form of stubs or skeletons for local interfaces. Proposal A is wrong in this area, as it implies that stubs and skeletons are generated. Proposal B is better, but still does not definitely say that stubs and skeletons are not generated for local interfaces. The main question then is: How can a user create a local object reference? I see 4 possibilities: 1. They correctly extend LocalObject and implement the generated local interface as needed. Everything works correctly in this case, and all errors can be detected. 2. They attempt to create a servant for a POA, using either the inheritance or Tie models: This requires either an XXXPOA or an XXXPOATie class, which does not exist, leading to a compile-time error. 3. They directly implement the local interface: This requires implementing all of the org.omg.CORBA.Object methods directly. Failing to do this results in "class XXX should be abstract" errors at compile time. The 13 or so methods defined in CORBA.Object include lots of methods that CORBA users never see, so this should be a strong clue to the user that they are doing something wrong. In any case, even if the user creates something that compiles, it cannot be marshalled. The problem is that the incorrect object reference implements org.omg.CORBA.Object, but it does not extend org.omg.CORBA.portable.ObjectImpl. Any implementation of org.omg.CORBA.portable.OutputStream.write_Object will need access to internal data in the delegate in order to marshall the object. This will lead to an exception, such as a class cast exception in the ORB. An ORB can catch this exception and produce a more useful exception as required by the local interface spec. This should take care of all possible methods that could be used to marshal the local object in this case (as an any, cast to unconstrained base class and write, or object_to_string). 4. They get really clever and create: class FooImpl extends org.omg.CORBA.portable.ObjectImpl implements Foo { ... } and then they discover that they need to set the delegate in ObjectImpl. Perhaps they create a non-local object and assign its delegate to a FooImpl instance. This would result in interesting behavior, either invoking on the wrong operations, or invoking on the wrong object. So, what happens when the user attempts to marshal the object in this case? Let's look at the cases: 4.1. Static Stubs This is to some extent ORB dependent, but one possible implementation detects this error even without proposal B: if the generated stub code calls FooHelper.write instead of just calling outputStream.write_Object directly, the helper write method should throw a MARSHAL exception, since it is a local interface helper. 4.2. Any or narrow to unconstrained base class/write: Both of these will eventually end up calling OutputStream.write_Object (or an equivalent internal implementation method). Proposal B does detect this, while proposal A does not. However, this example is fairly unlikely. Also, as Simon points out, proposal B does allow a Java to IDL compiler to detect at compile time that an attempt is being made to marshal a local interface type, while proposal A does not. I am not convinced that either of these use cases justifies adding a new marker interface to the IDL to Java language mapping. Ken. From: Jeffrey Mischkinsky Message-Id: <200106222022.NAA06106@wheel.dcn.davis.ca.us> Subject: Re: Revised Vote: Issue 4323 To: Ken.Cavanaugh@sun.com Date: Fri, 22 Jun 2001 13:22:31 -0700 (PDT) Cc: java-rtf@omg.org, harold.carr@sun.com, czhao@borland.com, jishnu_mukerji@hp.com, pwalker@Eng.Sun.COM, Anita.Jindal@sun.com, gentwo@yahoo.com In-Reply-To: <200106212348.QAA16011@taller.eng.sun.com> from "Ken Cavanaugh" at Jun 21, 2001 04:48:48 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: GN0!!:o,e9^MC!!VRCe9 Ken, Thanks so much for the discussion. Unfortunately I'm now much more confused. One implication that I seem to be drawn to is that the 10 second summary/conclusion is that "B is superior to A, but not enough." I just don't see the relationship between the 4 cases, the existence or non-existence of a marker interface, and your final conclusion. BTW, I assume that the binary incompatibility argument has become moot. One other (minor) issue: i was under the (possibly mistaken) impression it didn't make sense to marshal a local object reference. Or do mean marshal it (into a buffer) which then gets passed around within the same process/JVM/capsule/pick-the right-term? signed, confused in CA P.S. In case anyone is wondering, the cc: to gentwo@yahoo.com is Vijay 'Ken Cavanaugh' writes: > > In discussing issue 4323, what is most important to all of us is to look at > the underlying technical arguments for the proposals. What I want to explore > is exactly what proposal B gives us that proposal A does not. > > An assumption: > > A compliant IDL compiler with the resolution of 4323 will NOT generate > any form of stubs or skeletons for local interfaces. Proposal A > is wrong in this area, as it implies that stubs and skeletons are > generated. Proposal B is better, but still does not definitely > say that stubs and skeletons are not generated for local interfaces. > > The main question then is: > > How can a user create a local object reference? > > I see 4 possibilities: > > 1. They correctly extend LocalObject and implement the generated local > interface as needed. Everything works correctly in this case, and > all errors can be detected. > > 2. They attempt to create a servant for a POA, using either the inheritance > or Tie models: > > This requires either an XXXPOA or an XXXPOATie class, > which does not exist, leading to a compile-time error. > > 3. They directly implement the local interface: > > This requires implementing > all of the org.omg.CORBA.Object methods directly. Failing to do this > results in "class XXX should be abstract" errors at compile time. > The 13 or so methods defined in CORBA.Object include lots of methods > that CORBA users never see, so this should be a strong clue to the user > that they are doing something wrong. > > In any case, even if the user creates something that compiles, it cannot > be marshalled. The problem is that the incorrect object reference > implements org.omg.CORBA.Object, but it does not extend > org.omg.CORBA.portable.ObjectImpl. Any implementation of > org.omg.CORBA.portable.OutputStream.write_Object will need access to > internal data in the delegate in order to marshall the object. > This will lead to an exception, such as a class cast exception in > the ORB. An ORB can catch this exception and produce > a more useful exception as required by the local interface spec. > > This should take care of all possible methods that could be used to > marshal the local object in this case (as an any, cast to unconstrained > base class and write, or object_to_string). > > 4. They get really clever and create: > > class FooImpl extends org.omg.CORBA.portable.ObjectImpl > implements Foo { ... } > > and then they discover that they need to set the delegate in ObjectImpl. > Perhaps they create a non-local object and assign its delegate to a > FooImpl instance. This would result in interesting behavior, either > invoking on the wrong operations, or invoking on the wrong object. > > So, what happens when the user attempts to marshal the object in this case? > Let's look at the cases: > > 4.1. Static Stubs > > This is to some extent ORB dependent, but one possible implementation > detects this error even without proposal B: if the generated stub > code calls FooHelper.write instead of just calling outputStream.write_Object > directly, the helper write method should throw a MARSHAL exception, since > it is a local interface helper. > > 4.2. Any or narrow to unconstrained base class/write: > > Both of these will eventually end up calling OutputStream.write_Object > (or an equivalent internal implementation method). Proposal B does > detect this, while proposal A does not. However, this example is > fairly unlikely. > > Also, as Simon points out, proposal B does allow a Java to IDL compiler > to detect at compile time that an attempt is being made to marshal a local > interface type, while proposal A does not. I am not convinced that > either of these use cases justifies adding a new marker interface to the > IDL to Java language mapping. > > Ken. > > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* Date: Fri, 22 Jun 2001 13:34:16 -0700 (PDT) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Revised Vote: Issue 4323 To: Ken.Cavanaugh@sun.com, jmischki@wheel.dcn.davis.ca.us Cc: java-rtf@omg.org, harold.carr@sun.com, czhao@borland.com, jishnu_mukerji@hp.com, pwalker@Eng.Sun.COM, Anita.Jindal@sun.com, gentwo@yahoo.com MIME-Version: 1.0 Content-MD5: M7g+AMTVUJoUF1R11x/KDA== 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: Ih?!!R)!"!oXj!!m7#!! >From: Jeffrey Mischkinsky >Subject: Re: Revised Vote: Issue 4323 >To: Ken.Cavanaugh@sun.com >Cc: java-rtf@omg.org, harold.carr@sun.com, czhao@borland.com, jishnu_mukerji@hp.com, pwalker@eng.sun.com, Anita.Jindal@sun.com, gentwo@yahoo.com >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit > >Ken, > Thanks so much for the discussion. Unfortunately I'm now much more >confused. > > One implication that I seem to be drawn to is that the 10 second > summary/conclusion is that "B is superior to A, but not enough." > That is my conclusion. > I just don't see the relationship between the 4 cases, the existence > or non-existence of a marker interface, and your final conclusion. > I was enumerating all of the possibilities that I could find (I think I found all of them) for creating an object that implements a local interface. In most cases, the mapping will already either prevent the user from implementing the local interface incorrectly, or allow an ORB to detect errors in its usage at runtime. > BTW, I assume that the binary incompatibility argument has become > moot. It has. > > One other (minor) issue: i was under the (possibly mistaken) >impression > it didn't make sense to marshal a local object reference. It does not. The entire argument is about when errors in the use of local interfaces are detected, and whether we require a new LocalInterface type to detect the errors. In most cases, I believe that we do not require it. It comes down to this: if a user creates an implementation of a local interface by inheriting from org.omg.CORBA.portable.ObjectImpl, and then somehow sets the delegate so that the implementation "looks" like a real object, proposal B does detect an error that A does not. I believe that this is a sufficiently contrived case as to be unimportant in practice. In the RMI-IIOP case, the marshalling error can be detected at compile time by the Java-IDL compiler for proposal B, while it is detected at run time by proposal A. > Or do mean > marshal it (into a buffer) I suppose this could happen, since IDLEntity extends Serializable, but I don't think we are trying to address this question. > which then gets passed around within the > same process/JVM/capsule/pick-the right-term? > > signed, > confused in CA > Ken. Date: Fri, 22 Jun 2001 21:59:34 +0100 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: Jeffrey Mischkinsky CC: Ken.Cavanaugh@sun.com, java-rtf@omg.org, harold.carr@sun.com, czhao@borland.com, jishnu_mukerji@hp.com, pwalker@Eng.Sun.COM, Anita.Jindal@sun.com, gentwo@yahoo.com Subject: Re: Revised Vote: Issue 4323 References: <200106222022.NAA06106@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: _P~!!`k4!!RGid9)ka!! Jeff, I share your confusion. Since B has some advantages over A and no drawbacks, I didn't follow why Ken thought A was better. And if A is wrong (as Ken says), perhaps the right thing to do is adopt neither A nor B, but a yet-to-be-proposed D. Simon Jeffrey Mischkinsky wrote: > > Ken, > Thanks so much for the discussion. Unfortunately I'm now much more confused. > > One implication that I seem to be drawn to is that the 10 second > summary/conclusion is that "B is superior to A, but not enough." > > I just don't see the relationship between the 4 cases, the existence > or non-existence of a marker interface, and your final conclusion. > > BTW, I assume that the binary incompatibility argument has become > moot. > > One other (minor) issue: i was under the (possibly mistaken) impression > it didn't make sense to marshal a local object reference. Or do mean > marshal it (into a buffer) which then gets passed around within the > same process/JVM/capsule/pick-the right-term? > > signed, > confused in CA > > P.S. In case anyone is wondering, the cc: to gentwo@yahoo.com is Vijay > > 'Ken Cavanaugh' writes: > > > > In discussing issue 4323, what is most important to all of us is to look at > > the underlying technical arguments for the proposals. What I want to explore > > is exactly what proposal B gives us that proposal A does not. > > > > An assumption: > > > > A compliant IDL compiler with the resolution of 4323 will NOT generate > > any form of stubs or skeletons for local interfaces. Proposal A > > is wrong in this area, as it implies that stubs and skeletons are > > generated. Proposal B is better, but still does not definitely > > say that stubs and skeletons are not generated for local interfaces. > > > > The main question then is: > > > > How can a user create a local object reference? > > > > I see 4 possibilities: > > > > 1. They correctly extend LocalObject and implement the generated local > > interface as needed. Everything works correctly in this case, and > > all errors can be detected. > > > > 2. They attempt to create a servant for a POA, using either the inheritance > > or Tie models: > > > > This requires either an XXXPOA or an XXXPOATie class, > > which does not exist, leading to a compile-time error. > > > > 3. They directly implement the local interface: > > > > This requires implementing > > all of the org.omg.CORBA.Object methods directly. Failing to do this > > results in "class XXX should be abstract" errors at compile time. > > The 13 or so methods defined in CORBA.Object include lots of methods > > that CORBA users never see, so this should be a strong clue to the user > > that they are doing something wrong. > > > > In any case, even if the user creates something that compiles, it cannot > > be marshalled. The problem is that the incorrect object reference > > implements org.omg.CORBA.Object, but it does not extend > > org.omg.CORBA.portable.ObjectImpl. Any implementation of > > org.omg.CORBA.portable.OutputStream.write_Object will need access to > > internal data in the delegate in order to marshall the object. > > This will lead to an exception, such as a class cast exception in > > the ORB. An ORB can catch this exception and produce > > a more useful exception as required by the local interface spec. > > > > This should take care of all possible methods that could be used to > > marshal the local object in this case (as an any, cast to unconstrained > > base class and write, or object_to_string). > > > > 4. They get really clever and create: > > > > class FooImpl extends org.omg.CORBA.portable.ObjectImpl > > implements Foo { ... } > > > > and then they discover that they need to set the delegate in ObjectImpl. > > Perhaps they create a non-local object and assign its delegate to a > > FooImpl instance. This would result in interesting behavior, either > > invoking on the wrong operations, or invoking on the wrong object. > > > > So, what happens when the user attempts to marshal the object in this case? > > Let's look at the cases: > > > > 4.1. Static Stubs > > > > This is to some extent ORB dependent, but one possible implementation > > detects this error even without proposal B: if the generated stub > > code calls FooHelper.write instead of just calling outputStream.write_Object > > directly, the helper write method should throw a MARSHAL exception, since > > it is a local interface helper. > > > > 4.2. Any or narrow to unconstrained base class/write: > > > > Both of these will eventually end up calling OutputStream.write_Object > > (or an equivalent internal implementation method). Proposal B does > > detect this, while proposal A does not. However, this example is > > fairly unlikely. > > > > Also, as Simon points out, proposal B does allow a Java to IDL compiler > > to detect at compile time that an attempt is being made to marshal a local > > interface type, while proposal A does not. I am not convinced that > > either of these use cases justifies adding a new marker interface to the > > IDL to Java language mapping. > > > > Ken. > > > > > > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* -- 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: Fri, 22 Jun 2001 22:03:10 +0100 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: jmischki@wheel.dcn.davis.ca.us, java-rtf@omg.org, harold.carr@sun.com, czhao@borland.com, jishnu_mukerji@hp.com, pwalker@Eng.Sun.COM, Anita.Jindal@sun.com, gentwo@yahoo.com Subject: Re: Revised Vote: Issue 4323 References: <200106222034.NAA12395@taller.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: PmK!!fl > > > > One other (minor) issue: i was under the (possibly mistaken) impression > > it didn't make sense to marshal a local object reference. > > It does not. The entire argument is about when errors in the use of local > interfaces are detected, and whether we require a new LocalInterface type > to detect the errors. In most cases, I believe that we do not require it. > > It comes down to this: if a user creates an implementation of a local interface > by inheriting from org.omg.CORBA.portable.ObjectImpl, and then somehow > sets the delegate so that the implementation "looks" like a real object, > proposal B does detect an error that A does not. I believe that this is > a sufficiently contrived case as to be unimportant in practice. > > In the RMI-IIOP case, the marshalling error can be detected at compile time > by the Java-IDL compiler for proposal B, while it is detected at run time > by proposal A. > It is always better to detect errors at compile time where possible. This is a clear usability advantage of B over A. Simon -- 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 From: Jeffrey Mischkinsky Message-Id: <200106230130.SAA00558@wheel.dcn.davis.ca.us> Subject: Re: Revised Vote: Issue 4323 To: nash@hursley.ibm.com (Simon Nash) Date: Fri, 22 Jun 2001 18:30:33 -0700 (PDT) Cc: Ken.Cavanaugh@sun.com (Ken Cavanaugh), java-rtf@omg.org, harold.carr@sun.com, czhao@borland.com, jishnu_mukerji@hp.com, pwalker@Eng.Sun.COM, Anita.Jindal@sun.com, gentwo@yahoo.com In-Reply-To: <3B33B28E.3EF33BB7@hursley.ibm.com> from "Simon Nash" at Jun 22, 2001 10:03:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ;Ld!!H`L!!'+E!!Z(O!! 'Simon Nash' writes: > > It is always better to detect errors at compile time where possible. This is a > clear usability advantage of B over A. > seems like a good principle to follow to me. jeff > Simon > -- > 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 > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 ***** NEW ******* Date: Fri, 29 Jun 2001 12:11:53 +0800 From: Cuie Zhao Subject: Re: IDL to Java Chapter ptc/2001-06-04 To: Mary Leland Cc: linda@omg.org, Juergen Boldt , Java RTF Message-id: <3B3C0009.F4685EC2@borland.com> MIME-version: 1.0 X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en References: <3B3B250C.C8E0BFE8@fpk.hp.com> <3B3B2651.399D7890@fpk.hp.com> Content-Type: multipart/alternative; boundary="Boundary_(ID_dULg7W9ZlN1I5QGLUdAawg)" X-UIDL: =BU!!T;&!!2V+!!9L=!! Hi Mary, I think we need to make minor wording corrections to the doc w.r.t. issue 4323. Section 1.21.1 on Local Interface paragraph: "A local interface is mapped to the the following java classes: interface extends Operations, org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity where interface and Operations are identical to the mapping for a non-local interface." The last sentence of the above paragraph needs to be changed to: "where Operations is identical to the mapping for a non-local interface." The interface is actually no longer identical to the maping for a non-local interface after adding the marker interface. Hope it's not to late to rectify the wordings ... Cheers, // Cuie Mary Leland wrote: Oops, this time it's really attached. Mary Leland wrote: > > The updated chapter is attached. > Linda/Juergen: please put it on the server as ptc/2001-06-04 > > Thanks, > Mary Leland > Chair, IDL to Java RTF ------------------------------------------------------------------------ Name: 2001-06-04.pdf 2001-06-04.pdf Type: Acrobat (application/pdf) Encoding: base64 Download Status: Not downloaded with message -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Date: Fri, 29 Jun 2001 13:24:24 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cuie Zhao Cc: Java RTF Subject: Re: IDL to Java Chapter ptc/2001-06-04 References: <3B3B250C.C8E0BFE8@fpk.hp.com> <3B3B2651.399D7890@fpk.hp.com> <3B3C0009.F4685EC2@borland.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Lcf!!GeV!!7^m!!g:n!! Hi Cuie, Unfortunately, it's too late to make any changes in the interim report or updated chapter. Sorry, but any significant wording changes need to be resolved during the vote on the issue. (I think this change is too big to be considered editorial.) The only option now is for you to file an issue (issues@omg.org) with the proposed resolution of the wording change. Mary Cuie Zhao wrote: > > Hi Mary, > > I think we need to make minor wording corrections to the doc w.r.t. issue 4323. Section 1.21.1 on > Local Interface paragraph: > > "A local interface is mapped to the the following java classes: > interface > extends Operations, > org.omg.CORBA.LocalInterface, > org.omg.CORBA.portable.IDLEntity > where interface and Operations are identical to the mapping for a non-local > interface." > > The last sentence of the above paragraph needs to be changed to: > "where Operations is identical to the mapping for a non-local interface." > > The interface is actually no longer identical to the maping for a non-local interface > after adding the marker interface. > > Hope it's not to late to rectify the wordings ... > > Cheers, > > // Cuie > > Mary Leland wrote: > > > Oops, this time it's really attached. > > > > Mary Leland wrote: > > > > > > The updated chapter is attached. > > > Linda/Juergen: please put it on the server as ptc/2001-06-04 > > > > > > Thanks, > > > Mary Leland > > > Chair, IDL to Java RTF > > > > ------------------------------------------------------------------------ > > Name: 2001-06-04.pdf > > 2001-06-04.pdf Type: Acrobat (application/pdf) > > Encoding: base64 > > Download Status: Not downloaded with message > > -- > > > This e-mail, and any attachments thereto, is intended only for use by > the addressee(s) named herein and may contain legally privileged > and/or confidential information. If you are not the intended recipient > of this e-mail, you are hereby notified that any dissemination, distribution > or copying of this e-mail, and any attachments thereto, is strictly prohibited. > If you have received this e-mail in error, please immediately and permanently > delete the original and any copy of any e-mail and any printout thereof. > Date: Fri, 29 Jun 2001 20:41:03 +0100 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: Mary Leland CC: Cuie Zhao , Java RTF Subject: Re: IDL to Java Chapter ptc/2001-06-04 References: <3B3B250C.C8E0BFE8@fpk.hp.com> <3B3B2651.399D7890@fpk.hp.com> <3B3C0009.F4685EC2@borland.com> <3B3CB9C8.A8100732@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 3\Ie990#"!F9p!!j/a!! Mary, I believe the intent of these words was to say that the members of both the and Operations interfaces are identical to those of a non-local interface. Clearly (as Cuie points out), the inheritance is not identical. Would it be possible to make the following as an editorial clarification, if no-one in the RTF objects? "A local interface is mapped to the the following java classes: interface extends Operations, org.omg.CORBA.LocalInterface, org.omg.CORBA.portable.IDLEntity where the members of interface and Operations are identical to the mapping for a non-local interface." Simon Mary Leland wrote: > > Hi Cuie, > > Unfortunately, it's too late to make any changes in the interim > report or updated chapter. Sorry, but any significant wording > changes need to be resolved during the vote on the issue. (I think > this change is too big to be considered editorial.) > > The only option now is for you to file an issue (issues@omg.org) > with the proposed resolution of the wording change. > > Mary > > Cuie Zhao wrote: > > > > Hi Mary, > > > > I think we need to make minor wording corrections to the doc w.r.t. issue 4323. Section 1.21.1 on > > Local Interface paragraph: > > > > "A local interface is mapped to the the following java classes: > > interface > > extends Operations, > > org.omg.CORBA.LocalInterface, > > org.omg.CORBA.portable.IDLEntity > > where interface and Operations are identical to the mapping for a non-local > > interface." > > > > The last sentence of the above paragraph needs to be changed to: > > "where Operations is identical to the mapping for a non-local interface." > > > > The interface is actually no longer identical to the maping for a non-local interface > > after adding the marker interface. > > > > Hope it's not to late to rectify the wordings ... > > > > Cheers, > > > > // Cuie > > > > Mary Leland wrote: > > > > > Oops, this time it's really attached. > > > > > > Mary Leland wrote: > > > > > > > > The updated chapter is attached. > > > > Linda/Juergen: please put it on the server as ptc/2001-06-04 > > > > > > > > Thanks, > > > > Mary Leland > > > > Chair, IDL to Java RTF > > > > > > ------------------------------------------------------------------------ > > > Name: 2001-06-04.pdf > > > 2001-06-04.pdf Type: Acrobat (application/pdf) > > > Encoding: base64 > > > Download Status: Not downloaded with message > > > > -- > > > > > > This e-mail, and any attachments thereto, is intended only for use by > > the addressee(s) named herein and may contain legally privileged > > and/or confidential information. If you are not the intended recipient > > of this e-mail, you are hereby notified that any dissemination, distribution > > or copying of this e-mail, and any attachments thereto, is strictly prohibited. > > If you have received this e-mail in error, please immediately and permanently > > delete the original and any copy of any e-mail and any printout thereof. > > -- 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 From: Jeffrey Mischkinsky Message-Id: <200106292006.NAA06857@wheel.dcn.davis.ca.us> Subject: Re: IDL to Java Chapter ptc/2001-06-04 To: nash@hursley.ibm.com (Simon Nash) Date: Fri, 29 Jun 2001 13:06:23 -0700 (PDT) Cc: mleland@fpk.hp.com (Mary Leland), czhao@borland.com (Cuie Zhao), java-rtf@omg.org (Java RTF) In-Reply-To: <3B3CD9CF.5B7BD424@hursley.ibm.com> from "Simon Nash" at Jun 29, 2001 08:41:03 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ^&Z!!)->!!Fh:e9[GI!! 'Simon Nash' writes: > > Mary, > I believe the intent of these words was to say that the members of both the > and Operations interfaces are identical to those of a > non-local interface. Clearly (as Cuie points out), the inheritance is not > identical. > > Would it be possible to make the following as an editorial clarification, > if no-one in the RTF objects? > > "A local interface is mapped to the the following java classes: > interface > extends Operations, > org.omg.CORBA.LocalInterface, > org.omg.CORBA.portable.IDLEntity > where the members of interface and Operations are > identical to the mapping for a non-local interface." or just add to the existing, > > > where interface and Operations are identical to the mapping for a non-local *** except for the inheritance relationship *** In any event, this was clearly the intent, and I'm happy to treat as editorial getting the exact wordsmithing correct. And I'm also happy to leave it to the able editor to editorially fix this up however it seems best to her. jeff > > Simon > > Mary Leland wrote: > > > > Hi Cuie, > > > > Unfortunately, it's too late to make any changes in the interim > > report or updated chapter. Sorry, but any significant wording > > changes need to be resolved during the vote on the issue. (I think > > this change is too big to be considered editorial.) > > > > The only option now is for you to file an issue (issues@omg.org) > > with the proposed resolution of the wording change. > > > > Mary > > > > Cuie Zhao wrote: > > > > > > Hi Mary, > > > > > > I think we need to make minor wording corrections to the doc > w.r.t. issue 4323. Section 1.21.1 on > > > Local Interface paragraph: > > > > > > "A local interface is mapped to the the following > java classes: > > > interface > > > extends Operations, > > > org.omg.CORBA.LocalInterface, > > > org.omg.CORBA.portable.IDLEntity > > > where interface and Operations are > identical to the mapping for a non-local > > > interface." > > > > > > The last sentence of the above paragraph needs to be changed to: > > > "where Operations is identical to the mapping for a > non-local interface." > > > > > > The interface is actually no longer identical to the > maping for a non-local interface > > > after adding the marker interface. > > > > > > Hope it's not to late to rectify the wordings ... > > > > > > Cheers, > > > > > > // Cuie > > > > > > Mary Leland wrote: > > > > > > > Oops, this time it's really attached. > > > > > > > > Mary Leland wrote: > > > > > > > > > > The updated chapter is attached. > > > > > Linda/Juergen: please put it on the server as ptc/2001-06-04 > > > > > > > > > > Thanks, > > > > > Mary Leland > > > > > Chair, IDL to Java RTF > > > > > > > > > ------------------------------------------------------------------------ > > > > Name: 2001-06-04.pdf > > > > 2001-06-04.pdf Type: Acrobat (application/pdf) > > > > Encoding: base64 > > > > Download Status: Not downloaded with message > > > > > > -- > > > > > > > > > This e-mail, and any attachments thereto, is intended only for > use by > > > the addressee(s) named herein and may contain legally privileged > > > and/or confidential information. If you are not the intended > recipient > > > of this e-mail, you are hereby notified that any dissemination, > distribution > > > or copying of this e-mail, and any attachments thereto, is > strictly prohibited. > > > If you have received this e-mail in error, please immediately > and permanently > > > delete the original and any copy of any e-mail and any printout > thereof. > > > > > -- > 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 > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975 Date: Mon, 02 Jul 2001 10:23:50 +0800 From: Cuie Zhao Subject: Re: IDL to Java Chapter ptc/2001-06-04 To: Jeffrey Mischkinsky Cc: Simon Nash , Mary Leland , Java RTF Message-id: <3B3FDB36.69F923AA@borland.com> MIME-version: 1.0 X-Mailer: Mozilla 4.74 [en] (WinNT; U) Content-transfer-encoding: 7BIT X-Accept-Language: en References: <200106292006.NAA06857@wheel.dcn.davis.ca.us> Content-Type: text/plain; charset=us-ascii X-UIDL: C(m!!k8?!!0T3e9~(6!! Jeffrey Mischkinsky wrote: > 'Simon Nash' writes: > > > > Mary, > > I believe the intent of these words was to say that the members of both the > > and Operations interfaces are identical to those of a > > non-local interface. Clearly (as Cuie points out), the inheritance is not > > identical. > > > > Would it be possible to make the following as an editorial clarification, > > if no-one in the RTF objects? > > > > "A local interface is mapped to the the following java classes: > > interface > > extends Operations, > > org.omg.CORBA.LocalInterface, > > org.omg.CORBA.portable.IDLEntity > > where the members of interface and Operations are > > identical to the mapping for a non-local interface." > > or just add to the existing, > > > > where interface and Operations are identical to the mapping for a non-local > interface > *** except for the inheritance relationship *** > or to be more accurate: **** except for the inheritance relationship of interface **** Cheers, // Cuie > > In any event, this was clearly the intent, and I'm happy to treat as >editorial > getting the exact wordsmithing correct. And I'm also happy to leave >it to > the able editor to editorially fix this up however it seems best to >her. > > jeff > > > > > Simon > > > > Mary Leland wrote: > > > > > > Hi Cuie, > > > > > > Unfortunately, it's too late to make any changes in the interim > > > report or updated chapter. Sorry, but any significant wording > > > changes need to be resolved during the vote on the issue. (I >think > > > this change is too big to be considered editorial.) > > > > > > The only option now is for you to file an issue (issues@omg.org) > > > with the proposed resolution of the wording change. > > > > > > Mary > > > > > > Cuie Zhao wrote: > > > > > > > > Hi Mary, > > > > > > > > I think we need to make minor wording corrections to the doc >w.r.t. issue 4323. Section 1.21.1 on > > > > Local Interface paragraph: > > > > > > > > "A local interface is mapped to the the following >java classes: > > > > interface > > > > extends Operations, > > > > org.omg.CORBA.LocalInterface, > > > > org.omg.CORBA.portable.IDLEntity > > > > where interface and Operations are >identical to the mapping for a non-local > > > > interface." > > > > > > > > The last sentence of the above paragraph needs to be changed >to: > > > > "where Operations is identical to the mapping for a >non-local interface." > > > > > > > > The interface is actually no longer identical to >the maping for a non-local interface > > > > after adding the marker interface. > > > > > > > > Hope it's not to late to rectify the wordings ... > > > > > > > > Cheers, > > > > > > > > // Cuie > > > > > > > > Mary Leland wrote: > > > > > > > > > Oops, this time it's really attached. > > > > > > > > > > Mary Leland wrote: > > > > > > > > > > > > The updated chapter is attached. > > > > > > Linda/Juergen: please put it on the server as >ptc/2001-06-04 > > > > > > > > > > > > Thanks, > > > > > > Mary Leland > > > > > > Chair, IDL to Java RTF > > > > > > > > > > >------------------------------------------------------------------------ > > > > > Name: 2001-06-04.pdf > > > > > 2001-06-04.pdf Type: Acrobat (application/pdf) > > > > > Encoding: base64 > > > > > Download Status: Not downloaded with >message > > > > > > > > -- > > > > > > > > > > > > This e-mail, and any attachments thereto, is intended only for >use by > > > > the addressee(s) named herein and may contain legally >privileged > > > > and/or confidential information. If you are not the intended >recipient > > > > of this e-mail, you are hereby notified that any >dissemination, distribution > > > > or copying of this e-mail, and any attachments thereto, is >strictly prohibited. > > > > If you have received this e-mail in error, please immediately >and permanently > > > > delete the original and any copy of any e-mail and any >printout thereof. > > > > > > > > -- > > 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 > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeff.mischkinsky@oracle.com +1 650-506-1975 -- This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. Date: Thu, 05 Jul 2001 11:53:13 -0400 From: Mary Leland X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Cuie Zhao , Java RTF Cc: Jeffrey Mischkinsky , Simon Nash Subject: Re: IDL to Java Chapter ptc/2001-06-04 (Issue 4323) References: <200106292006.NAA06857@wheel.dcn.davis.ca.us> <3B3FDB36.69F923AA@borland.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: Va[!!(Upd9pgbd9aGEe9 Okay, if Jeff & Simon agree that it's an editorial change, who am I to argue. Unless I hear objections by 5pm US EDT on Monday, July 9, I will take Cuie's wording suggestion, and change the phrase in question to read "where interface and Operations are identical to the mapping for a non-local interface, except for the inheritance relationship of interface ." This change will appear in the version that I send to the OMG editor, and will be propogated in future revisions. Thanks, Mary Cuie Zhao wrote: > > Jeffrey Mischkinsky wrote: > > > 'Simon Nash' writes: > > > > > > Mary, > > > I believe the intent of these words was to say that the members of both the > > > and Operations interfaces are identical to those of a > > > non-local interface. Clearly (as Cuie points out), the inheritance is not > > > identical. > > > > > > Would it be possible to make the following as an editorial clarification, > > > if no-one in the RTF objects? > > > > > > "A local interface is mapped to the the following java classes: > > > interface > > > extends Operations, > > > org.omg.CORBA.LocalInterface, > > > org.omg.CORBA.portable.IDLEntity > > > where the members of interface and Operations are > > > identical to the mapping for a non-local interface." > > > > or just add to the existing, > > > > > where interface and Operations are identical to the mapping for a non-local > > interface > > *** except for the inheritance relationship *** > > > > or to be more accurate: > > **** except for the inheritance relationship of interface **** > > Cheers, > > // Cuie > > > > > In any event, this was clearly the intent, and I'm happy to treat as editorial > > getting the exact wordsmithing correct. And I'm also happy to leave it to > > the able editor to editorially fix this up however it seems best to her. > > > > jeff > > > > > > > > Simon > > > > > > Mary Leland wrote: > > > > > > > > Hi Cuie, > > > > > > > > Unfortunately, it's too late to make any changes in the interim > > > > report or updated chapter. Sorry, but any significant wording > > > > changes need to be resolved during the vote on the issue. (I think > > > > this change is too big to be considered editorial.) > > > > > > > > The only option now is for you to file an issue (issues@omg.org) > > > > with the proposed resolution of the wording change. > > > > > > > > Mary > > > > > > > > Cuie Zhao wrote: > > > > > > > > > > Hi Mary, > > > > > > > > > > I think we need to make minor wording corrections to the doc w.r.t. issue 4323. Section 1.21.1 on > > > > > Local Interface paragraph: > > > > > > > > > > "A local interface is mapped to the the following java classes: > > > > > interface > > > > > extends Operations, > > > > > org.omg.CORBA.LocalInterface, > > > > > org.omg.CORBA.portable.IDLEntity > > > > > where interface and Operations are identical to the mapping for a non-local > > > > > interface." > > > > > > > > > > The last sentence of the above paragraph needs to be changed to: > > > > > "where Operations is identical to the mapping for a non-local interface." > > > > > > > > > > The interface is actually no longer identical to the maping for a non-local interface > > > > > after adding the marker interface. > > > > > > > > > > Hope it's not to late to rectify the wordings ... > > > > > > > > > > Cheers, > > > > > > > > > > // Cuie > > > > > > > > > > Mary Leland wrote: > > > > > > > > > > > Oops, this time it's really attached. > > > > > > > > > > > > Mary Leland wrote: > > > > > > > > > > > > > > The updated chapter is attached. > > > > > > > Linda/Juergen: please put it on the server as ptc/2001-06-04 > > > > > > > > > > > > > > Thanks, > > > > > > > Mary Leland > > > > > > > Chair, IDL to Java RTF > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > Name: 2001-06-04.pdf > > > > > > 2001-06-04.pdf Type: Acrobat (application/pdf) > > > > > > Encoding: base64 > > > > > > Download Status: Not downloaded with message > > > > > > > > > > -- > > > > > > > > > > > > > > > This e-mail, and any attachments thereto, is intended only for use by > > > > > the addressee(s) named herein and may contain legally privileged > > > > > and/or confidential information. If you are not the intended recipient > > > > > of this e-mail, you are hereby notified that any dissemination, distribution > > > > > or copying of this e-mail, and any attachments thereto, is strictly prohibited. > > > > > If you have received this e-mail in error, please immediately and permanently > > > > > delete the original and any copy of any e-mail and any printout thereof. > > > > > > > > > > > -- > > > 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 > > > > > > > -- > > Jeff Mischkinsky > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > jeff.mischkinsky@oracle.com +1 650-506-1975 > > -- > > This e-mail, and any attachments thereto, is intended only for use by > the addressee(s) named herein and may contain legally privileged > and/or confidential information. If you are not the intended recipient > of this e-mail, you are hereby notified that any dissemination, distribution > or copying of this e-mail, and any attachments thereto, is strictly prohibited. > If you have received this e-mail in error, please immediately and permanently > delete the original and any copy of any e-mail and any printout thereof. \ From: Jeffrey Mischkinsky Message-Id: <200107051637.JAA06455@wheel.dcn.davis.ca.us> Subject: Re: IDL to Java Chapter ptc/2001-06-04 (Issue 4323) To: mleland@fpk.hp.com (Mary Leland) Date: Thu, 5 Jul 2001 09:37:50 -0700 (PDT) Cc: czhao@borland.com (Cuie Zhao), java-rtf@omg.org (Java RTF), nash@hursley.ibm.com (Simon Nash) In-Reply-To: <3B448D69.A7B255E2@fpk.hp.com> from "Mary Leland" at Jul 05, 2001 11:53:13 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: pB+e9W,'!!jjB!!GJ*!! 'Mary Leland' writes: > > Okay, if Jeff & Simon agree that it's an editorial change, > who am I to argue. Only the grand poobah of this activity. :-) > Unless I hear objections by 5pm US EDT on Monday, July 9, No objections. thanks, jeff > I will take Cuie's wording suggestion, and change the phrase > in question to read > > "where interface and Operations are > identical to the mapping for a non-local interface, except > for the inheritance relationship of interface ." > > This change will appear in the version that I send to the OMG > editor, and will be propogated in future revisions. > > Thanks, > Mary > > Cuie Zhao wrote: > > > > Jeffrey Mischkinsky wrote: > > > > > 'Simon Nash' writes: > > > > > > > > Mary, > > > > I believe the intent of these words was to say that the > members of both the > > > > and Operations interfaces are identical > to those of a > > > > non-local interface. Clearly (as Cuie points out), the > inheritance is not > > > > identical. > > > > > > > > Would it be possible to make the following as an editorial > clarification, > > > > if no-one in the RTF objects? > > > > > > > > "A local interface is mapped to the the following > java classes: > > > > interface > > > > extends Operations, > > > > org.omg.CORBA.LocalInterface, > > > > org.omg.CORBA.portable.IDLEntity > > > > where the members of interface and > Operations are > > > > identical to the mapping for a non-local interface." > > > > > > or just add to the existing, > > > > > > where interface and Operations are > identical to the mapping for a non-local > > > interface > > > *** except for the inheritance relationship *** > > > > > > > or to be more accurate: > > > > **** except for the inheritance relationship of interface > **** > > > > Cheers, > > > > // Cuie > > > > > > > > In any event, this was clearly the intent, and I'm happy to > treat as editorial > > > getting the exact wordsmithing correct. And I'm also happy to > leave it to > > > the able editor to editorially fix this up however it seems best > to her. > > > > > > jeff > > > > > > > > > > > Simon > > > > > > > > Mary Leland wrote: > > > > > > > > > > Hi Cuie, > > > > > > > > > > Unfortunately, it's too late to make any changes in the > interim > > > > > report or updated chapter. Sorry, but any significant > wording > > > > > changes need to be resolved during the vote on the issue. (I > think > > > > > this change is too big to be considered editorial.) > > > > > > > > > > The only option now is for you to file an issue > (issues@omg.org) > > > > > with the proposed resolution of the wording change. > > > > > > > > > > Mary > > > > > > > > > > Cuie Zhao wrote: > > > > > > > > > > > > Hi Mary, > > > > > > > > > > > > I think we need to make minor wording corrections to the > doc w.r.t. issue 4323. Section 1.21.1 on > > > > > > Local Interface paragraph: > > > > > > > > > > > > "A local interface is mapped to the the > following java classes: > > > > > > interface > > > > > > extends Operations, > > > > > > org.omg.CORBA.LocalInterface, > > > > > > org.omg.CORBA.portable.IDLEntity > > > > > > where interface and Operations are > identical to the mapping for a non-local > > > > > > interface." > > > > > > > > > > > > The last sentence of the above paragraph needs to be > changed to: > > > > > > "where Operations is identical to the mapping > for a non-local interface." > > > > > > > > > > > > The interface is actually no longer identical > to the maping for a non-local interface > > > > > > after adding the marker interface. > > > > > > > > > > > > Hope it's not to late to rectify the wordings ... > > > > > > > > > > > > Cheers, > > > > > > > > > > > > // Cuie > > > > > > > > > > > > Mary Leland wrote: > > > > > > > > > > > > > Oops, this time it's really attached. > > > > > > > > > > > > > > Mary Leland wrote: > > > > > > > > > > > > > > > > The updated chapter is attached. > > > > > > > > Linda/Juergen: please put it on the server as > ptc/2001-06-04 > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Mary Leland > > > > > > > > Chair, IDL to Java RTF > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > > Name: 2001-06-04.pdf > > > > > > > 2001-06-04.pdf Type: Acrobat > (application/pdf) > > > > > > > Encoding: base64 > > > > > > > Download Status: Not downloaded with > message > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > This e-mail, and any attachments thereto, is intended only > for use by > > > > > > the addressee(s) named herein and may contain legally > privileged > > > > > > and/or confidential information. If you are not the > intended recipient > > > > > > of this e-mail, you are hereby notified that any > dissemination, distribution > > > > > > or copying of this e-mail, and any attachments thereto, is > strictly prohibited. > > > > > > If you have received this e-mail in error, please > immediately and permanently > > > > > > delete the original and any copy of any e-mail and any > printout thereof. > > > > > > > > > > > > > > -- > > > > 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 > > > > > > > > > > -- > > > Jeff Mischkinsky > > > jmischki@dcn.davis.ca.us +1 530-758-9850 > > > jeff.mischkinsky@oracle.com +1 650-506-1975 > > > > -- > > > > This e-mail, and any attachments thereto, is intended only for use > by > > the addressee(s) named herein and may contain legally privileged > > and/or confidential information. If you are not the intended > recipient > > of this e-mail, you are hereby notified that any dissemination, > distribution > > or copying of this e-mail, and any attachments thereto, is > strictly prohibited. > > If you have received this e-mail in error, please immediately and > permanently > > delete the original and any copy of any e-mail and any printout > thereof. > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeff.mischkinsky@oracle.com +1 650-506-1975