Issue 2804: stub classes can violate licensing and package sealing (java2idl-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: Placing generated stub classes in the package in which the interface is defined is flawed for a few reasons: 1) It can violate license agreements (e.g., Jini uses remote interfaces, and if an RMI-IIOP stub is generated from one of the core Jini interfaces the license agreement will be violated since a new public class will be added to the core). 2) Placing generated classes in the same package as the remote interface definition will not be possible if the package is sealed. If an interface is public, such generated classes could be placed in a sub-package of a CORBA-specific package, for example, org.omg.CORBA.stub.java.rmi._Remote_Stub. Resolution: Revised Text: Actions taken: July 15, 1999: received issue September 16, 1999: closed issue Discussion: End of Annotations:===== Date: Thu, 15 Jul 1999 12:14:17 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: stub classes can violate licensing and package sealing To: issues@omg.org Cc: java2idl-rtf@omg.org, ann.wollrath@East.Sun.COM X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc >From Ann Wollrath: Placing generated stub classes in the package in which the interface is defined is flawed for a few reasons: 1) It can violate license agreements (e.g., Jini uses remote interfaces, and if an RMI-IIOP stub is generated from one of the core Jini interfaces the license agreement will be violated since a new public class will be added to the core). 2) Placing generated classes in the same package as the remote interface definition will not be possible if the package is sealed. If an interface is public, such generated classes could be placed in a sub-package of a CORBA-specific package, for example, org.omg.CORBA.stub.java.rmi._Remote_Stub. Date: Thu, 15 Jul 1999 20:30:29 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: Bob Scheifler - SMI Software Development CC: java2idl-rtf@omg.org, ann.wollrath@east.sun.com, java-rtf@omg.org Subject: Re: stub classes can violate licensing and package sealing Bob, I believe this is an issue for the IDL to Java mapping as well, since IDL/Java stubs are also placed in the same package as the remote interface. If we make a change, it should be consistent for both types of stub. The org.omg.CORBA package is reserved for classes defined in the CORBA specifications, so your specific suggestion is not appropriate. However, we could use a package org.omg.stub which is analogous to the modules ::org::omg::boxedIDL and ::org::org::boxedRMI that are currently defined by the Java to IDL mapping. Alternatively we could use a sub-package of the interface package such as myPackage.stub._MyInterface_Stub for myPackage.MyInterface. However, my preference would be to do neither of these, but to add a stub class registration mechanism so that the default name could be replaced by any name of the implementer's choosing. Simon Bob Scheifler - SMI Software Development wrote: > > >From Ann Wollrath: > > Placing generated stub classes in the package in which the interface is defined > is flawed for a few reasons: > > 1) It can violate license agreements (e.g., Jini uses remote interfaces, and > if an RMI-IIOP stub is generated from one of the core Jini interfaces > the license agreement will be violated since a new public class > will be added to the core). > > 2) Placing generated classes in the same package as the remote interface > definition will not be possible if the package is sealed. > > If an interface is public, such generated classes could be placed in a > sub-package of a CORBA-specific package, for example, > org.omg.CORBA.stub.java.rmi._Remote_Stub. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 15 Jul 1999 16:19:53 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: stub classes can violate licensing and package sealing To: nash@hursley.ibm.com Cc: java2idl-rtf@omg.org, ann.wollrath@East.Sun.COM, java-rtf@omg.org X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc > Alternatively we could use a sub-package of the interface package such as > myPackage.stub._MyInterface_Stub for myPackage.MyInterface. This has the same license violation problems. License restrictions generally cover entire namespaces, not specific packages. - Bob X-Sender: juergen@emerald.omg.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 16 Jul 1999 15:54:48 -0400 To: issues, java2idl-rtf From: Juergen Boldt Subject: issue 2804 -- Java to IDL RTF Issue This is issue # 2804 stub classes can violate licensing and package sealing Placing generated stub classes in the package in which the interface is defined is flawed for a few reasons: 1) It can violate license agreements (e.g., Jini uses remote interfaces, and if an RMI-IIOP stub is generated from one of the core Jini interfaces the license agreement will be violated since a new public class will be added to the core). 2) Placing generated classes in the same package as the remote interface definition will not be possible if the package is sealed. If an interface is public, such generated classes could be placed in a sub-package of a CORBA-specific package, for example, org.omg.CORBA.stub.java.rmi._Remote_Stub. Date: Sat, 17 Jul 1999 00:18:22 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: Bob Scheifler - SMI Software Development CC: java2idl-rtf@omg.org, ann.wollrath@east.sun.com, java-rtf@omg.org Subject: Re: stub classes can violate licensing and package sealing Bob, We would add an API call to load a stub given a remote interface. Generated stub and tie code would no longer have hard-wired references to other stub classes, but would use the new API or some higher-level API that calls it under the covers. For example, we could make it legal to call read_Object(interfaceclass) as well as read_Object(stubclass) and the former would trigger the new stub loading mechanism. There are two problems with the org.omg.stub approach: 1. It's an upward incompatible change. 2. It still hardwires the stub name, so there is no flexibility for user code to control which stub gets used. As stubs evolve, this will be a problem. It already is a problem for the IDL stubs used by the CosNaming classes in JDK 1.2. Simon Bob Scheifler - SMI Software Development wrote: > > > However, my preference would be to do neither of these, but to add a > > stub class registration mechanism so that the default name could be > > replaced by any name of the implementer's choosing. > > I'm not sure I understand the proposal. How do you mix and match > stubs generated by different tools with such an approach? It seems > a lot simpler to me to just use org.omg.stub for all public interfaces. > > - Bob -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Bob.Scheifler@East.Sun.COM (Bob Scheifler - SMI Software Development) Date: Fri, 16 Jul 1999 21:36:43 -0400 To: "Simon Nash" Cc: , , , Reply-To: Subject: Re: stub classes can violate licensing and package sealing X-Mailer: Sun NetMail 2.2.5 >We would add an API call to load a stub given a remote interface. >Generated stub and tie code would no longer have hard-wired references to >other stub classes, but would use the new API or some higher-level API >that calls it under the covers. That part I understood. What I don't understand is, how does the implementation of that new API know where to find the stub? Does someone have to manually configure the ORB with an interface->stub mapping? >There are two problems with the org.omg.stub approach: >1. It's an upward incompatible change. The current spec seems untenable, so this doesn't seem like much of a problem to me. As there is considerable urgency for resolving this issue, I counter-propose that we simple delete the words from the spec (for the java2idl mapping) that specify the stub and tie class name and package, and leave it implementation-dependent for now. We can then work on a portability solution. - Bob Date: Mon, 19 Jul 1999 15:55:48 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: rws@East.Sun.COM CC: java-rtf@omg.org, ann.wollrath@East.Sun.COM, java2idl-rtf@omg.org, masood.mortazavi@sun.com Subject: Re: stub classes can violate licensing and package sealing Bob, Bob Scheifler - SMI Software Development wrote: > > >We would add an API call to load a stub given a remote interface. > >Generated stub and tie code would no longer have hard-wired references to > >other stub classes, but would use the new API or some higher-level API > >that calls it under the covers. > > That part I understood. What I don't understand is, how does the > implementation of that new API know where to find the stub? Does > someone have to manually configure the ORB with an interface->stub > mapping? > Yes. An application that wants to use a non-default stub name would have to register the interface to stub mapping before the first use of the non-default stub. I believe there should be two registration APIs: 1. An interface->stub mapping that is managed by the javax.rmi.CORBA.* classes and is not ORB-specific. 2. An ORB-specific interface->stub mapping. RMI stubs could use either of these. IDL stubs could use only the second. RMI stub lookup would search the ORB mapping table followed by the javax.rmi.CORBA.* mapping table. IDL stub lookup would search the ORB mapping table only. > >There are two problems with the org.omg.stub approach: > >1. It's an upward incompatible change. > > The current spec seems untenable, so this doesn't seem like much of > a problem to me. > It's only untenable in certain cases. It's fine when delivering a package that contains pregenerated stub classes, or when delivering a package that is not subject to licensing or sealing. In these cases, the current naming algorithm is fine and we should not require it to be changed. > As there is considerable urgency for resolving this issue, I > counter-propose that we simple delete the words from the spec > (for the java2idl mapping) that specify the stub and tie class name > and package, and leave it implementation-dependent for now. We > can then work on a portability solution. > I strongly disagree with this. If we are going to make a change, let's put the correct fix in place, not move to some undefined broken state. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 19 Jul 1999 11:13:25 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: stub classes can violate licensing and package sealing To: nash@hursley.ibm.com Cc: java-rtf@omg.org, ann.wollrath@East.Sun.COM, java2idl-rtf@omg.org, masood.mortazavi@sun.com X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc > > Does someone have to manually configure the ORB with an interface->stub > > mapping? > > > Yes. An application that wants to use a non-default stub name would > have to register the interface to stub mapping before the first use of > the non-default stub. This doesn't seem sufficient to support downloadable stub classes. How does PortableRemoteObject.narrow know what stub class name to use? > > The current spec seems untenable, so this doesn't seem like much of > > a problem to me. > > > It's only untenable in certain cases. That's precisely why the current spec is untenable. :-) > > As there is considerable urgency for resolving this issue, I > > counter-propose that we simple delete the words from the spec > > (for the java2idl mapping) that specify the stub and tie class name > > and package, and leave it implementation-dependent for now. We > > can then work on a portability solution. > > > I strongly disagree with this. If we are going to make a change, let's > put the correct fix in place, not move to some undefined broken state. Are you willing to accept the removal of java.rmi._Remote_Stub in the interim? - Bob Date: Mon, 19 Jul 1999 19:11:09 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: Bob Scheifler - SMI Software Development CC: java-rtf@omg.org, ann.wollrath@east.sun.com, java2idl-rtf@omg.org, masood.mortazavi@sun.com Subject: Re: stub classes can violate licensing and package sealing Bob, Bob Scheifler - SMI Software Development wrote: > > > > Does someone have to manually configure the ORB with an interface->stub > > > mapping? > > > > > Yes. An application that wants to use a non-default stub name would > > have to register the interface to stub mapping before the first use of > > the non-default stub. > > This doesn't seem sufficient to support downloadable stub classes. > How does PortableRemoteObject.narrow know what stub class name to use? > Good point. I think the local registry would have to map from interfaces to stub class names, rather than interfaces to stub classes. > > > The current spec seems untenable, so this doesn't seem like much of > > > a problem to me. > > > > > It's only untenable in certain cases. > > That's precisely why the current spec is untenable. :-) > > > > As there is considerable urgency for resolving this issue, I > > > counter-propose that we simple delete the words from the spec > > > (for the java2idl mapping) that specify the stub and tie class name > > > and package, and leave it implementation-dependent for now. We > > > can then work on a portability solution. > > > > > I strongly disagree with this. If we are going to make a change, let's > > put the correct fix in place, not move to some undefined broken state. > > Are you willing to accept the removal of java.rmi._Remote_Stub in the interim? > No, because this breaks existing functionality (the ability to use Remote as a parameter or return type) without solving either of the problems described in the issue. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 19 Jul 1999 15:04:05 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: stub classes can violate licensing and package sealing To: nash@hursley.ibm.com Cc: java-rtf@omg.org, ann.wollrath@East.Sun.COM, java2idl-rtf@omg.org, masood.mortazavi@sun.com X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc > > This doesn't seem sufficient to support downloadable stub classes. > > How does PortableRemoteObject.narrow know what stub class name to use? > > > Good point. I think the local registry would have to map from interfaces to > stub class names, rather than interfaces to stub classes. You may have missed the implication. When A is narrowing a stub from B, it would be unacceptable to require that A have a priori knowledge of the stub class names that B was configured to download. So, it would no longer be sufficient for PortableRemoteObject.narrow to just use _is_a, it would either be necessary to include the stub class name in the IOR, or else ask the remote object what stub class name to use. I suspect that neither of these will be palatable within the OMG. > > Are you willing to accept the removal of java.rmi._Remote_Stub in the > > interim? > > > No, because this breaks existing functionality (the ability to use Remote > as a parameter or return type) without solving either of the problems > described in the issue. I think we need an immediate solution to the problem that the current spec implies that it is OK to generate stub classes for 30 interfaces in java and javax packages, in violation of JRE licensing. I do not believe that designing new APIs will result in an immediate solution. - Bob Date: Tue, 20 Jul 1999 10:39:50 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: Bob Scheifler - SMI Software Development CC: java-rtf@omg.org, ann.wollrath@east.sun.com, java2idl-rtf@omg.org, masood.mortazavi@sun.com Subject: Re: stub classes can violate licensing and package sealing Bob, Bob Scheifler - SMI Software Development wrote: > > > > This doesn't seem sufficient to support downloadable stub classes. > > > How does PortableRemoteObject.narrow know what stub class name to use? > > > > > Good point. I think the local registry would have to map from interfaces to > > stub class names, rather than interfaces to stub classes. > > You may have missed the implication. When A is narrowing a stub from B, > it would be unacceptable to require that A have a priori knowledge of the > stub class names that B was configured to download. So, it would no longer > be sufficient for PortableRemoteObject.narrow to just use _is_a, it would > either be necessary to include the stub class name in the IOR, or else ask > the remote object what stub class name to use. I suspect that neither of > these will be palatable within the OMG. > I agree that requiring these name mappings to be preconfigured and known by all clients is not ideal. The IOR currently contains a tagged component for the Java codebase, and it would be simple to extend this to include an optional stub class name. > > > Are you willing to accept the removal of java.rmi._Remote_Stub in the > > > interim? > > > > > No, because this breaks existing functionality (the ability to use Remote > > as a parameter or return type) without solving either of the problems > > described in the issue. > > I think we need an immediate solution to the problem that the current spec > implies that it is OK to generate stub classes for 30 interfaces in java and > javax packages, in violation of JRE licensing. I do not believe that > designing new APIs will result in an immediate solution. > Then there's no point in trying to fix one of these licensing problems by making a change that causes a severe functional regression, while leaving the remaining 29 unfixed. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Tue, 20 Jul 1999 09:46:00 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: stub classes can violate licensing and package sealing To: nash@hursley.ibm.com Cc: java-rtf@omg.org, ann.wollrath@East.Sun.COM, java2idl-rtf@omg.org, masood.mortazavi@sun.com X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc > The IOR currently contains a tagged component > for the Java codebase, and it would be simple to extend this to include an > optional stub class name. (I'm skeptical that anything is simple when an OMG process is involved.) I would be happy to hear the rest of the RTF (and Jeff) agree with that. Are you also proposing to add a _get_stub_classname to ObjectImpl, so that third-party intermediaries can prefer locally available stubs without losing the original stub classname information? > > I think we need an immediate solution to the problem that the current spec > > implies that it is OK to generate stub classes for 30 interfaces in java and > > javax packages, in violation of JRE licensing. I do not believe that > > designing new APIs will result in an immediate solution. > > > Then there's no point in trying to fix one of these licensing problems by > making a change that causes a severe functional regression, while leaving the > remaining 29 unfixed. I see no connection between these two statements. It seems to me there are three possible immediate solutions: 1. Live without stubs for all J2SE interfaces for now 2. Change the spec to put stubs in org.omg.stub 3. Change the spec to make stub placement unspecified I accept that you don't want any of these. If there's another option, propose it. I'd like to see the RTF vote on something this week. (Anything to avoid having to get involved in the "deciding what's urgent" discussion that's going on elsewhere...) - Bob Date: Tue, 20 Jul 1999 19:38:32 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: Max Mortazavi CC: Bob Scheifler - SMI Software Development , java-rtf@omg.org, ann.wollrath@east.sun.com, java2idl-rtf@omg.org, masood.mortazavi@sun.com Subject: Re: stub classes can violate licensing and package sealing Max, I think any solution would require this section to be rewritten. Could you be a little more specific on what you think the rewritten section should say? Simon Max Mortazavi wrote: > > Simon, > > Simon Nash wrote: > > > Bob, > > > > Bob Scheifler - SMI Software Development wrote: > > > > > > > The IOR currently contains a tagged component > > > > for the Java codebase, and it would be simple to extend this to include an > > > > optional stub class name. > > > > > > (I'm skeptical that anything is simple when an OMG process is involved.) > > > I would be happy to hear the rest of the RTF (and Jeff) agree with that. > > > Are you also proposing to add a _get_stub_classname to ObjectImpl, so > > > that third-party intermediaries can prefer locally available stubs without > > > losing the original stub classname information? > > > > > I agree that it would be good to hear from the rest of the RTF. Adding > > another method to ObjectImpl to get the stub class name seems reasonable, > > assuming that the RTF agrees with this approach of supporting flexibility > > for the stub class name. > > > > One possible problem with adding this method is deciding which ObjectImpl > > class to put it in. The most convenient place is > > org.omg.CORBA_2_3.portable.ObjectImpl, but the CORBA 2.3 spec has already > > been published, so this could cause some mild surprise. > > Wouldn't it be simpler and more elegant to rewrite 28.4.6 ["Locating Stubs and > Ties"] in the java to idl mapping? This section appears to be the real core of the > current problem. > > Max -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 2 Aug 1999 17:40:44 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Proposal for issue 2804 (stub names) To: java2idl-rtf@omg.org, nash@hursley.ibm.com Cc: java-rtf@omg.org, masood.mortazavi@Eng.Sun.COM X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc > 3. The semantics of the read_Object method are extended to allow an > RMI/IDL remote interface class to be passed instead of a stub class. > It will continue to be valid to pass a stub class. Semantically, > is.read_Object() > is equivalent to > PortableRemoteObject.narrow(is.read_Object(),) > except that the latter can be implemented more efficiently. If you really meant "latter" and not "former", could you explain why? - Bob Date: Tue, 03 Aug 1999 09:34:03 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: Bob Scheifler - SMI Software Development CC: java2idl-rtf@omg.org, java-rtf@omg.org, masood.mortazavi@Eng.Sun.COM Subject: Re: Proposal for issue 2804 (stub names) Bob, You are correct. I meant "former". Pardon me. Simon Bob Scheifler - SMI Software Development wrote: > > > 3. The semantics of the read_Object method are extended to allow an > > RMI/IDL remote interface class to be passed instead of a stub class. > > It will continue to be valid to pass a stub class. Semantically, > > is.read_Object() > > is equivalent to > > PortableRemoteObject.narrow(is.read_Object(),) > > except that the latter can be implemented more efficiently. > > If you really meant "latter" and not "former", could you explain why? > > - Bob -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Sat, 28 Aug 1999 01:21:26 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en To: java2idl-rtf@omg.org CC: java-rtf@omg.org, masood.mortazavi@Eng.Sun.COM Subject: VOTE on proposal for issue 2804 Here are proposed spec edits for my proposal, relative to base documents ptc/99-03-09 and formal/99-07-53. I would like to schedule a Java to IDL RTF vote on this proposal to complete by 5.00 pm PDT on September 3. I think this is reasonable given the history of discussion of this topic and the lack of any objection to or comment on the proposal that I sent out some time ago. However, if any RTF voting member feels they need more time to consider this proposal, I will consider requests for an extension of the voting deadline. 1. In section 28.4.6 of ptc/99-03-09, replace the second paragraph by the following: The stub class corresponding to an RMI/IDL interface or implementation class may either be in the same package as its associated interface or class, or may be further qualified by the org.omg.stub package prefix. For example, the stub class for an RMI/IDL interface class a.b.Fred, would be named either a.b._Fred_Stub or org.omg.stub.a.b._Fred_Stub. For an RMI/IDL implementation class x.y.Z, the tie class would be named x.y._Z_Tie. When loading a stub class corresponding to an interface or class ., the class .__Stub shall be used if it exists; otherwise, the class org.omg.stub..__Stub shall be used. 2. In section 28.4.9.5 of ptc/99-03-09, replace the third last paragraph by the following: For stubs created by InputStream.read_Object(clz), remoteCodebase is the same as for InputStream.read_Object(). If clz is a stub class, then the implementation of read_Object(clz) may either use the actual parameter clz to create a stub or may attempt to create a stub by loading a stub class whose name is derived from the RepositoryId in the IOR. If clz is an RMI/IDL remote interface, then the implementation of read_Object(clz) creates a stub whose class name is derived from either the name of the interface type clz or the RepositoryId in the IOR. loadingContext is clz. 3. In section 1.21.4.1 of formal/99-07-53, replace the description of read_Object by the following: For read_Object, the clz argument is one of the following: . the Class object for the stub class which corresponds to the type that is statically expected. Typically, the ORB runtime will allocate and return a stub object of this stub class. . the Class object for the RMI/IDL interface type that is statically expected. The ORB runtime must allocate and return a stub object that conforms to this interface. Simon Simon Nash wrote: > > Here is a proposal to resolve issue 2804: > > 1. For any RMI/IDL remote interface x.y, the stub class may either be named > x._y_Stub or org.omg.stub.x._y_Stub. The latter may be useful to avoid > problems with sealed packages or licensing restrictions (for example, in > the namespaces java, javax, com.sun, net.jini, and jini). > 2. The toStub and narrow methods of PortableRemoteObject look for a > stub class in the interface package first, then in the org.omg.stub > namespace. > 3. The semantics of the read_Object method are extended to allow an > RMI/IDL remote interface class to be passed instead of a stub class. > It will continue to be valid to pass a stub class. Semantically, > is.read_Object() > is equivalent to > PortableRemoteObject.narrow(is.read_Object(),) > except that the latter can be implemented more efficiently. > > Please would all Java to IDL RTF voting members comment on the acceptability > of the above proposal. > > Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb From: Jeffrey Mischkinsky Subject: Re: VOTE on proposal for issue 2804 To: nash@hursley.ibm.com (Simon Nash) Date: Fri, 27 Aug 1999 18:08:21 -0700 (PDT) Cc: java2idl-rtf@omg.org, java-rtf@omg.org, masood.mortazavi@Eng.Sun.COM X-Mailer: ELM [version 2.4 PL25] 'Simon Nash' writes: > > Here are proposed spec edits for my proposal, relative to base documents > ptc/99-03-09 and formal/99-07-53. > > I would like to schedule a Java to IDL RTF vote on this proposal to complete > by 5.00 pm PDT on September 3. I think this is reasonable given the history > of discussion of this topic and the lack of any objection to or comment on > the proposal that I sent out some time ago. However, if any RTF voting > member feels they need more time to consider this proposal, I will consider > requests for an extension of the voting deadline. Simon, I need to find out when vijay will be back from vacation in India. I think it's either next mon or the following week. If he's back next week , then friday the third is fine, if not, then i'd like to delay until he's back. jeff > > 1. In section 28.4.6 of ptc/99-03-09, replace the second paragraph by the following: > > The stub class corresponding to an RMI/IDL interface or implementation class > may either be in the same package as its associated interface or class, or > may be further qualified by the org.omg.stub package prefix. For example, > the stub class for an RMI/IDL interface class a.b.Fred, would be named either > a.b._Fred_Stub or org.omg.stub.a.b._Fred_Stub. For an RMI/IDL implementation > class x.y.Z, the tie class would be named x.y._Z_Tie. > > When loading a stub class corresponding to an interface or class > ., the class .__Stub shall be used > if it exists; otherwise, the class org.omg.stub..__Stub > shall be used. > > 2. In section 28.4.9.5 of ptc/99-03-09, replace the third last paragraph by the > following: > > For stubs created by InputStream.read_Object(clz), remoteCodebase is > the same as for InputStream.read_Object(). If clz is a stub class, then > the implementation of read_Object(clz) may either use the actual parameter > clz to create a stub or may attempt to create a stub by loading a stub class > whose name is derived from the RepositoryId in the IOR. If clz is an RMI/IDL > remote interface, then the implementation of read_Object(clz) creates a stub > whose class name is derived from either the name of the interface type clz or > the RepositoryId in the IOR. loadingContext is clz. > > 3. In section 1.21.4.1 of formal/99-07-53, replace the description of read_Object > by the following: > > For read_Object, the clz argument is one of the following: > . the Class object for the stub class which corresponds to the type that is > statically expected. Typically, the ORB runtime will allocate and return > a stub object of this stub class. > . the Class object for the RMI/IDL interface type that is statically > expected. The ORB runtime must allocate and return a stub object that > conforms to this interface. > > Simon > > Simon Nash wrote: > > > > Here is a proposal to resolve issue 2804: > > > > 1. For any RMI/IDL remote interface x.y, the stub class may either be named > > x._y_Stub or org.omg.stub.x._y_Stub. The latter may be useful to avoid > > problems with sealed packages or licensing restrictions (for example, in > > the namespaces java, javax, com.sun, net.jini, and jini). > > 2. The toStub and narrow methods of PortableRemoteObject look for a > > stub class in the interface package first, then in the org.omg.stub > > namespace. > > 3. The semantics of the read_Object method are extended to allow an > > RMI/IDL remote interface class to be passed instead of a stub class. > > It will continue to be valid to pass a stub class. Semantically, > > is.read_Object() > > is equivalent to > > PortableRemoteObject.narrow(is.read_Object(),) > > except that the latter can be implemented more efficiently. > > > > Please would all Java to IDL RTF voting members comment on the acceptability > > of the above proposal. > > > > Simon > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > 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 jeffm@inprise.com +1 650-358-3049 Date: Mon, 30 Aug 1999 12:19:40 -0700 From: David Heisser Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en To: Simon Nash CC: java2idl-rtf@omg.org, java-rtf@omg.org, masood.mortazavi@Eng.Sun.COM Subject: Re: VOTE on proposal for issue 2804 Simon Nash wrote: > Here are proposed spec edits for my proposal, relative to base documents > ptc/99-03-09 and formal/99-07-53. > > I would like to schedule a Java to IDL RTF vote on this proposal to complete > by 5.00 pm PDT on September 3. I think this is reasonable given the history > of discussion of this topic and the lack of any objection to or comment on > the proposal that I sent out some time ago. However, if any RTF voting > member feels they need more time to consider this proposal, I will consider > requests for an extension of the voting deadline. > > 1. In section 28.4.6 of ptc/99-03-09, replace the second paragraph by the following: > > The stub class corresponding to an RMI/IDL interface or implementation class > may either be in the same package as its associated interface or class, or > may be further qualified by the org.omg.stub package prefix. For example, > the stub class for an RMI/IDL interface class a.b.Fred, would be named either > a.b._Fred_Stub or org.omg.stub.a.b._Fred_Stub. For an RMI/IDL implementation > class x.y.Z, the tie class would be named x.y._Z_Tie. > > When loading a stub class corresponding to an interface or class > ., the class .__Stub shall be used > if it exists; otherwise, the class org.omg.stub..__Stub > shall be used. > > 2. In section 28.4.9.5 of ptc/99-03-09, replace the third last paragraph by the > following: > > For stubs created by InputStream.read_Object(clz), remoteCodebase is > the same as for InputStream.read_Object(). If clz is a stub class, then > the implementation of read_Object(clz) may either use the actual parameter > clz to create a stub or may attempt to create a stub by loading a stub class > whose name is derived from the RepositoryId in the IOR. If clz is an RMI/IDL > remote interface, then the implementation of read_Object(clz) creates a stub > whose class name is derived from either the name of the interface type clz or > the RepositoryId in the IOR. loadingContext is clz. > > 3. In section 1.21.4.1 of formal/99-07-53, replace the description of read_Object > by the following: > > For read_Object, the clz argument is one of the following: > . the Class object for the stub class which corresponds to the type that is > statically expected. Typically, the ORB runtime will allocate and return > a stub object of this stub class. > . the Class object for the RMI/IDL interface type that is statically > expected. The ORB runtime must allocate and return a stub object that > conforms to this interface. > > Simon > > Simon Nash wrote: > > > > Here is a proposal to resolve issue 2804: > > > > 1. For any RMI/IDL remote interface x.y, the stub class may either be named > > x._y_Stub or org.omg.stub.x._y_Stub. The latter may be useful to avoid > > problems with sealed packages or licensing restrictions (for example, in > > the namespaces java, javax, com.sun, net.jini, and jini). > > 2. The toStub and narrow methods of PortableRemoteObject look for a > > stub class in the interface package first, then in the org.omg.stub > > namespace. > > 3. The semantics of the read_Object method are extended to allow an > > RMI/IDL remote interface class to be passed instead of a stub class. > > It will continue to be valid to pass a stub class. Semantically, > > is.read_Object() > > is equivalent to > > PortableRemoteObject.narrow(is.read_Object(),) > > except that the latter can be implemented more efficiently. > > > > Please would all Java to IDL RTF voting members comment on the acceptability > > of the above proposal. > > > > Simon > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Mon, 30 Aug 1999 12:20:02 -0700 From: David Heisser Organization: Sun Microsystems Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en To: Simon Nash CC: java2idl-rtf@omg.org, java-rtf@omg.org, masood.mortazavi@Eng.Sun.COM Subject: Re: VOTE on proposal for issue 2804 Sun votes yes. Simon Nash wrote: > Here are proposed spec edits for my proposal, relative to base documents > ptc/99-03-09 and formal/99-07-53. > > I would like to schedule a Java to IDL RTF vote on this proposal to complete > by 5.00 pm PDT on September 3. I think this is reasonable given the history > of discussion of this topic and the lack of any objection to or comment on > the proposal that I sent out some time ago. However, if any RTF voting > member feels they need more time to consider this proposal, I will consider > requests for an extension of the voting deadline. > > 1. In section 28.4.6 of ptc/99-03-09, replace the second paragraph by the following: > > The stub class corresponding to an RMI/IDL interface or implementation class > may either be in the same package as its associated interface or class, or > may be further qualified by the org.omg.stub package prefix. For example, > the stub class for an RMI/IDL interface class a.b.Fred, would be named either > a.b._Fred_Stub or org.omg.stub.a.b._Fred_Stub. For an RMI/IDL implementation > class x.y.Z, the tie class would be named x.y._Z_Tie. > > When loading a stub class corresponding to an interface or class > ., the class .__Stub shall be used > if it exists; otherwise, the class org.omg.stub..__Stub > shall be used. > > 2. In section 28.4.9.5 of ptc/99-03-09, replace the third last paragraph by the > following: > > For stubs created by InputStream.read_Object(clz), remoteCodebase is > the same as for InputStream.read_Object(). If clz is a stub class, then > the implementation of read_Object(clz) may either use the actual parameter > clz to create a stub or may attempt to create a stub by loading a stub class > whose name is derived from the RepositoryId in the IOR. If clz is an RMI/IDL > remote interface, then the implementation of read_Object(clz) creates a stub > whose class name is derived from either the name of the interface type clz or > the RepositoryId in the IOR. loadingContext is clz. > > 3. In section 1.21.4.1 of formal/99-07-53, replace the description of read_Object > by the following: > > For read_Object, the clz argument is one of the following: > . the Class object for the stub class which corresponds to the type that is > statically expected. Typically, the ORB runtime will allocate and return > a stub object of this stub class. > . the Class object for the RMI/IDL interface type that is statically > expected. The ORB runtime must allocate and return a stub object that > conforms to this interface. > > Simon > > Simon Nash wrote: > > > > Here is a proposal to resolve issue 2804: > > > > 1. For any RMI/IDL remote interface x.y, the stub class may either be named > > x._y_Stub or org.omg.stub.x._y_Stub. The latter may be useful to avoid > > problems with sealed packages or licensing restrictions (for example, in > > the namespaces java, javax, com.sun, net.jini, and jini). > > 2. The toStub and narrow methods of PortableRemoteObject look for a > > stub class in the interface package first, then in the org.omg.stub > > namespace. > > 3. The semantics of the read_Object method are extended to allow an > > RMI/IDL remote interface class to be passed instead of a stub class. > > It will continue to be valid to pass a stub class. Semantically, > > is.read_Object() > > is equivalent to > > PortableRemoteObject.narrow(is.read_Object(),) > > except that the latter can be implemented more efficiently. > > > > Please would all Java to IDL RTF voting members comment on the acceptability > > of the above proposal. > > > > Simon > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Thu, 02 Sep 1999 14:49:46 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: java2idl-rtf@omg.org CC: java-rtf@omg.org, masood.mortazavi@Eng.Sun.COM Subject: Re: VOTE on proposal for issue 2804 References: <37A604E0.BFBE10BD@hursley.ibm.com> <37C72B86.B0AD5E2A@hursley.ibm.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 7f387999e481a8b0d7a7859c8194573b Jeff has requested a delay in the completion date for this vote so that Vijay can participate. The new deadline will be 5.00 pm PDT on September 10. Simon Simon Nash wrote: > > Here are proposed spec edits for my proposal, relative to base > documents > ptc/99-03-09 and formal/99-07-53. > > I would like to schedule a Java to IDL RTF vote on this proposal to > complete > by 5.00 pm PDT on September 3. I think this is reasonable given the > history > of discussion of this topic and the lack of any objection to or > comment on > the proposal that I sent out some time ago. However, if any RTF > voting > member feels they need more time to consider this proposal, I will > consider > requests for an extension of the voting deadline. > > 1. In section 28.4.6 of ptc/99-03-09, replace the second paragraph > by the following: > > The stub class corresponding to an RMI/IDL interface or > implementation class > may either be in the same package as its associated interface or > class, or > may be further qualified by the org.omg.stub package prefix. For > example, > the stub class for an RMI/IDL interface class a.b.Fred, would be > named either > a.b._Fred_Stub or org.omg.stub.a.b._Fred_Stub. For an RMI/IDL > implementation > class x.y.Z, the tie class would be named x.y._Z_Tie. > > When loading a stub class corresponding to an interface or class > ., the class > .__Stub shall be used > if it exists; otherwise, the class > org.omg.stub..__Stub > shall be used. > > 2. In section 28.4.9.5 of ptc/99-03-09, replace the third last > paragraph by the > following: > > For stubs created by InputStream.read_Object(clz), remoteCodebase > is > the same as for InputStream.read_Object(). If clz is a stub > class, then > the implementation of read_Object(clz) may either use the actual > parameter > clz to create a stub or may attempt to create a stub by loading a > stub class > whose name is derived from the RepositoryId in the IOR. If clz > is an RMI/IDL > remote interface, then the implementation of read_Object(clz) > creates a stub > whose class name is derived from either the name of the interface > type clz or > the RepositoryId in the IOR. loadingContext is clz. > > 3. In section 1.21.4.1 of formal/99-07-53, replace the description > of read_Object > by the following: > > For read_Object, the clz argument is one of the following: > . the Class object for the stub class which corresponds to the > type that is > statically expected. Typically, the ORB runtime will allocate > and return > a stub object of this stub class. > . the Class object for the RMI/IDL interface type that is > statically > expected. The ORB runtime must allocate and return a stub > object that > conforms to this interface. > > Simon > > Simon Nash wrote: > > > > Here is a proposal to resolve issue 2804: > > > > 1. For any RMI/IDL remote interface x.y, the stub class may either > be named > > x._y_Stub or org.omg.stub.x._y_Stub. The latter may be useful > to avoid > > problems with sealed packages or licensing restrictions (for > example, in > > the namespaces java, javax, com.sun, net.jini, and jini). > > 2. The toStub and narrow methods of PortableRemoteObject look for > a > > stub class in the interface package first, then in the > org.omg.stub > > namespace. > > 3. The semantics of the read_Object method are extended to allow > an > > RMI/IDL remote interface class to be passed instead of a stub > class. > > It will continue to be valid to pass a stub class. > Semantically, > > is.read_Object() > > is equivalent to > > > PortableRemoteObject.narrow(is.read_Object(),) > > except that the latter can be implemented more efficiently. > > > > Please would all Java to IDL RTF voting members comment on the > acceptability > > of the above proposal. > > > > Simon > > -- > Simon C Nash, Technology Architect, IBM Java Technology Centre > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Sender: mleland@fpk.hp.com Message-ID: <37CEB86B.42CD@fpk.hp.com> Date: Thu, 02 Sep 1999 13:48:27 -0400 From: Mary Leland Organization: Hewlett-Packard X-Mailer: Mozilla 3.01Gold (X11; I; HP-UX B.11.00 9000/889) MIME-Version: 1.0 To: Simon Nash , Jeffrey Mischkinsky CC: java2idl-rtf@omg.org, java-rtf@omg.org, masood.mortazavi@Eng.Sun.COM Subject: Re: VOTE on proposal for issue 2804 References: <199908280108.SAA21198@wheel.dcn.davis.ca.us> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: b783e7ffd177a7baa86cce05aaa2b26b So, what's the status? Does the vote close Sept. 3rd or is it delayed at Jeff's request? If we must vote by the 3rd, HP votes yes. But I reserve the right to change that vote if someone puts forth strong objections to the proposal. -- Mary Jeffrey Mischkinsky wrote: > > 'Simon Nash' writes: > > > > Here are proposed spec edits for my proposal, relative to base > documents > > ptc/99-03-09 and formal/99-07-53. > > > > I would like to schedule a Java to IDL RTF vote on this proposal > to complete > > by 5.00 pm PDT on September 3. I think this is reasonable given > the history > > of discussion of this topic and the lack of any objection to or > comment on > > the proposal that I sent out some time ago. However, if any RTF > voting > > member feels they need more time to consider this proposal, I will > consider > > requests for an extension of the voting deadline. > Simon, > I need to find out when vijay will be back from vacation in > India. > I think it's either next mon or the following week. > If he's back next week , then friday the third is fine, if not, > then i'd like > to delay until he's back. > > jeff > > > > 1. In section 28.4.6 of ptc/99-03-09, replace the second paragraph > by the following: > > > > The stub class corresponding to an RMI/IDL interface or > implementation class > > may either be in the same package as its associated interface > or class, or > > may be further qualified by the org.omg.stub package prefix. > For example, > > the stub class for an RMI/IDL interface class a.b.Fred, would > be named either > > a.b._Fred_Stub or org.omg.stub.a.b._Fred_Stub. For an RMI/IDL > implementation > > class x.y.Z, the tie class would be named x.y._Z_Tie. > > > > When loading a stub class corresponding to an interface or > class > > ., the class > .__Stub shall be used > > if it exists; otherwise, the class > org.omg.stub..__Stub > > shall be used. > > > > 2. In section 28.4.9.5 of ptc/99-03-09, replace the third last > paragraph by the > > following: > > > > For stubs created by InputStream.read_Object(clz), > remoteCodebase is > > the same as for InputStream.read_Object(). If clz is a stub > class, then > > the implementation of read_Object(clz) may either use the > actual parameter > > clz to create a stub or may attempt to create a stub by loading > a stub class > > whose name is derived from the RepositoryId in the IOR. If clz > is an RMI/IDL > > remote interface, then the implementation of read_Object(clz) > creates a stub > > whose class name is derived from either the name of the > interface type clz or > > the RepositoryId in the IOR. loadingContext is clz. > > > > 3. In section 1.21.4.1 of formal/99-07-53, replace the description > of read_Object > > by the following: > > > > For read_Object, the clz argument is one of the following: > > . the Class object for the stub class which corresponds to the > type that is > > statically expected. Typically, the ORB runtime will > allocate and return > > a stub object of this stub class. > > . the Class object for the RMI/IDL interface type that is > statically > > expected. The ORB runtime must allocate and return a stub > object that > > conforms to this interface. > > > > Simon > > > > Simon Nash wrote: > > > > > > Here is a proposal to resolve issue 2804: > > > > > > 1. For any RMI/IDL remote interface x.y, the stub class may > either be named > > > x._y_Stub or org.omg.stub.x._y_Stub. The latter may be > useful to avoid > > > problems with sealed packages or licensing restrictions (for > example, in > > > the namespaces java, javax, com.sun, net.jini, and jini). > > > 2. The toStub and narrow methods of PortableRemoteObject look > for a > > > stub class in the interface package first, then in the > org.omg.stub > > > namespace. > > > 3. The semantics of the read_Object method are extended to allow > an > > > RMI/IDL remote interface class to be passed instead of a stub > class. > > > It will continue to be valid to pass a stub class. > Semantically, > > > is.read_Object() > > > is equivalent to > > > > PortableRemoteObject.narrow(is.read_Object(),) > > > except that the latter can be implemented more efficiently. > > > > > > Please would all Java to IDL RTF voting members comment on the > acceptability > > > of the above proposal. > > > > > > Simon > > > > -- > > Simon C Nash, Technology Architect, IBM Java Technology Centre > > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb v> > > > > > -- > Jeff Mischkinsky > jmischki@dcn.davis.ca.us +1 530-758-9850 > jeffm@inprise.com +1 650-358-3049 Date: Thu, 02 Sep 1999 18:57:38 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Mary Leland CC: Jeffrey Mischkinsky , java2idl-rtf@omg.org, java-rtf@omg.org, masood.mortazavi@Eng.Sun.COM Subject: Re: VOTE on proposal for issue 2804 References: <199908280108.SAA21198@wheel.dcn.davis.ca.us> <37CEB86B.42CD@fpk.hp.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 704c050f19ca5c2183c1d13fd80a8376 Mary, I sent out a note about the delay but my first attempt bounced from OMG and it appears my second never made it either. The vote is delayed until the 10th at Jeff's request, so that Vijay can participate. Simon Mary Leland wrote: > > So, what's the status? Does the vote close Sept. 3rd or > is it delayed at Jeff's request? > > If we must vote by the 3rd, HP votes yes. But I reserve > the right to change that vote if someone puts forth strong > objections to the proposal. > > -- Mary > > Jeffrey Mischkinsky wrote: > > > > 'Simon Nash' writes: > > > > > > Here are proposed spec edits for my proposal, relative to base > documents > > > ptc/99-03-09 and formal/99-07-53. > > > > > > I would like to schedule a Java to IDL RTF vote on this proposal > to complete > > > by 5.00 pm PDT on September 3. I think this is reasonable given > the history > > > of discussion of this topic and the lack of any objection to or > comment on > > > the proposal that I sent out some time ago. However, if any RTF > voting > > > member feels they need more time to consider this proposal, I > will consider > > > requests for an extension of the voting deadline. > > Simon, > > I need to find out when vijay will be back from vacation in > India. > > I think it's either next mon or the following week. > > If he's back next week , then friday the third is fine, if not, > then i'd like > > to delay until he's back. > > > > jeff > > > > > > 1. In section 28.4.6 of ptc/99-03-09, replace the second > paragraph by the following: > > > > > > The stub class corresponding to an RMI/IDL interface or > implementation class > > > may either be in the same package as its associated interface > or class, or > > > may be further qualified by the org.omg.stub package prefix. > For example, > > > the stub class for an RMI/IDL interface class a.b.Fred, would > be named either > > > a.b._Fred_Stub or org.omg.stub.a.b._Fred_Stub. For an > RMI/IDL implementation > > > class x.y.Z, the tie class would be named x.y._Z_Tie. > > > > > > When loading a stub class corresponding to an interface or > class > > > ., the class > .__Stub shall be used > > > if it exists; otherwise, the class > org.omg.stub..__Stub > > > shall be used. > > > > > > 2. In section 28.4.9.5 of ptc/99-03-09, replace the third last > paragraph by the > > > following: > > > > > > For stubs created by InputStream.read_Object(clz), > remoteCodebase is > > > the same as for InputStream.read_Object(). If clz is a stub > class, then > > > the implementation of read_Object(clz) may either use the > actual parameter > > > clz to create a stub or may attempt to create a stub by > loading a stub class > > > whose name is derived from the RepositoryId in the IOR. If > clz is an RMI/IDL > > > remote interface, then the implementation of read_Object(clz) > creates a stub > > > whose class name is derived from either the name of the > interface type clz or > > > the RepositoryId in the IOR. loadingContext is clz. > > > > > > 3. In section 1.21.4.1 of formal/99-07-53, replace the > description of read_Object > > > by the following: > > > > > > For read_Object, the clz argument is one of the following: > > > . the Class object for the stub class which corresponds to > the type that is > > > statically expected. Typically, the ORB runtime will > allocate and return > > > a stub object of this stub class. > > > . the Class object for the RMI/IDL interface type that is > statically > > > expected. The ORB runtime must allocate and return a stub > object that > > > conforms to this interface. > > > > > > Simon > > > > > > Simon Nash wrote: > > > > > > > > Here is a proposal to resolve issue 2804: > > > > > > > > 1. For any RMI/IDL remote interface x.y, the stub class may > either be named > > > > x._y_Stub or org.omg.stub.x._y_Stub. The latter may be > useful to avoid > > > > problems with sealed packages or licensing restrictions > (for example, in > > > > the namespaces java, javax, com.sun, net.jini, and jini). > > > > 2. The toStub and narrow methods of PortableRemoteObject look > for a > > > > stub class in the interface package first, then in the > org.omg.stub > > > > namespace. > > > > 3. The semantics of the read_Object method are extended to > allow an > > > > RMI/IDL remote interface class to be passed instead of a > stub class. > > > > It will continue to be valid to pass a stub class. > Semantically, > > > > is.read_Object() > > > > is equivalent to > > > > > PortableRemoteObject.narrow(is.read_Object(),) > > > > except that the latter can be implemented more efficiently. > > > > > > > > Please would all Java to IDL RTF voting members comment on the > acceptability > > > > of the above proposal. > > > > > > > > Simon > > > > > > -- > > > Simon C Nash, Technology Architect, IBM Java Technology Centre > > > 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 > > jeffm@inprise.com +1 650-358-3049 -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Wed, 19 Jan 2000 16:08:17 +0000 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Mischkinsky CC: Mary Leland , java-rtf@omg.org, java2idl-rtf@omg.org, butek@us.ibm.com Subject: Issue 2804 revised text Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: gBOd9"CGe9'&\d9R))e9 Status: U Jeff, The resolution to issue 2804 approved by the Java to IDL RTF contains the following revised text for the IDL to Java mapping spec: 3. In section 1.21.4.1 of formal/99-07-53, replace the description of read_Object by the following: For read_Object, the clz argument is one of the following: . the Class object for the stub class which corresponds to the type that is statically expected. Typically, the ORB runtime will allocate and return a stub object of this stub class. . the Class object for the RMI/IDL interface type that is statically expected. The ORB runtime must allocate and return a stub object that conforms to this interface. 4. In section 1.21.4.1 of formal/99-07-53, replace the first paragraph of the description of read_abstract_interface by the following: For read_abstract_interface, the ORB runtime will return either a value object or a suitable stub object. The specified clz argument is one of the following: . the Class object for the stub class which corresponds to the type that is statically expected. . the Class object for the RMI/IDL interface type that is statically expected. If a stub object is returned, it must conform to this interface. Please make these changes as part of your current round of editing. Thanks. Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb X-Sender: jeff@mailhost.persistence.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Jan 2000 14:58:35 -0800 To: Simon Nash From: Jeff Mischkinsky Subject: Re: Issue 2804 revised text Cc: Mary Leland , java-rtf@omg.org, java2idl-rtf@omg.org, butek@us.ibm.com In-Reply-To: <3885E171.910B8EC0@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-UIDL: :+pd9SLL!!'oKe9Ql~e9 Status: U will do. I've already updated it for the IDL/Java RTF changes. I'll have it out tomorrow. jeff At 08:08 AM 1/19/00 , Simon Nash wrote: >Jeff, >The resolution to issue 2804 approved by the Java to IDL RTF contains >the following revised text for the IDL to Java mapping spec: > >3. In section 1.21.4.1 of formal/99-07-53, replace the description of >read_Object > by the following: > > For read_Object, the clz argument is one of the following: > . the Class object for the stub class which corresponds to the > type > that is > statically expected. Typically, the ORB runtime will allocate > and > return > a stub object of this stub class. > . the Class object for the RMI/IDL interface type that is > statically > expected. The ORB runtime must allocate and return a stub > object that > conforms to this interface. > >4. In section 1.21.4.1 of formal/99-07-53, replace the first > paragraph of the > description of read_abstract_interface by the following: > > For read_abstract_interface, the ORB runtime will return either a > > value object > or a suitable stub object. The specified clz argument is one of > the > following: > . the Class object for the stub class which corresponds to the > type > that is > statically expected. > . the Class object for the RMI/IDL interface type that is > statically > expected. If a stub object is returned, it must conform to > this > interface. > >Please make these changes as part of your current round of editing. > Thanks. > > Simon >-- >Simon C Nash, Technology Architect, IBM Java Technology Centre >Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England >Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb > Jeff Mischkinsky email: jeff@persistence.com Senior Software Architect voice: +1(650)372-3604 Persistence Software - The Engine for E-Commerce 1720 S. Amphlett Blvd. fax: +1(650)341-8432 San Mateo, CA 94402 web: http://www.persistence.com