Issue 2482: Mapping of java.rmi.Remote (java2idl-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: This issue was raised by Vijay Natarajan of Inprise. It appears that we need to do the same trick we used to distinguish between Anys, java.lang.Objects, Serializable etc We need to map java.rmi.Remote to be an alias of Object as in module java { module rmi { typedef Object Remote; }; }; This is to allow us to distinguish in IDL mapping between public interface hello implements java.rmi.Remote { void foo (java.rmi.Remote arg); void foo (org.omg.CORBA.Object arg); } w/o the aliasing, these methods cannot be mapped. Resolution: Closed, accepted Revised Text: When java.rmi.Remote appears as an RMI/IDL argument or result type, it is mapped to the following IDL type: module java { module rmi { typedef Object Remote; }; }; java.rmi.Remote as a java value member is also mapped this way In section 28.2.3, replace numbered item 1 by: The interface is or inherits from java.rmi.Remote either directly or indirectly. Actions taken: February 22, 1999: received issue June 4, 1999: closed issue Discussion: End of Annotations:===== Date: Mon, 22 Feb 1999 15:20:54 +0000 From: Simon Nash Organization: IBM To: issues CC: java2idl Subject: Mapping of java.rmi.Remote This issue was raised by Vijay Natarajan of Inprise. It appears that we need to do the same trick we used to distinguish between Anys, java.lang.Objects, Serializable etc We need to map java.rmi.Remote to be an alias of Object as in module java { module rmi { typedef Object Remote; }; }; This is to allow us to distinguish in IDL mapping between public interface hello implements java.rmi.Remote { void foo (java.rmi.Remote arg); void foo (org.omg.CORBA.Object arg); } w/o the aliasing, these methods cannot be mapped. So I propose that we adopt the above alias for java.rmi.Remote as the mapping of java.rmi.Remote to IDL. Date: Fri, 12 Mar 1999 19:56:07 +0000 From: Simon Nash Organization: IBM X-Accept-Language: en To: issues@omg.org CC: java2idl-rtf@omg.org, Bryan Atsatt , Steve Lewallen Subject: Mapping of java.rmi.Remote type The proposal for issue 2482 that we adopted has some problems. First consider the client side. If I have a declared type of java.rmi.Remote as a result of a remote method, I need to be able to demarshal the IOR that I receive as a generic remote stub if I cannot find a better stub based onthe actual type in the IOR. I propose that the following stub class should be used for this: package javax.rmi.CORBA; public class _Remote_Stub extends javax.rmi.CORBA.Stub implements java.rmi.Remote { } For consistency with our usual naming convention, this suggests that java.rmi.Remote should be mapped to the following IDL: module javax { module rmi { module CORBA { typedef Object Remote; }; }; }; Now consider the server side. Suppose I have an implementation class that implements java.rmi.Remote and no other remote interfaces. This works just fine in JRMP. What repid would be marshalled in the IOR for such an object? I think the correct answer based on the above IDL is "IDL:javax/rmi/CORBA/Remote:1.0" which is a typedef (alias) for Object. The other alternative is "IDL:omg.org/CORBA/Object:1.0" but I am not sure if it is legal to send this in an IOR, or if sending a null repid is legal and means the same thing. But there's a tiny wrinkle here. Since this is an OMG-published IDL definition, it is supposed to have the prefix "omg.org" and its repid would therefore be "IDL:omg.org/javax/rmi/CORBA/Remote:1.0" Does that mean the receiver has to strip off the omg.org prefix before trying to find an "exact match" stub class? An exact match will exist and will be called javax.rmi.CORBA._Remote_Stub (no omg.org or org.omg here). Of course this same wrinkle applies to other IDL types in our spec such as ::java::lang::Exception or whatever it ends up being called. But that one will be OK if we adopt amendment 1 to proposal 2092 (you did read that first, didn't you?). I'm inclined to go for "IDL:javax/rmi/CORBA/Remote:1.0" and if that means we have to change the IDL in the spec to #pragma prefix "" module javax { module rmi { module CORBA { typedef Object Remote; }; }; }; to make this absolutely unambiguous, I suppose that's OK. Any comments? 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, 16 Mar 1999 11:32:59 -0800 From: "Vijaykumar Natarajan" Reply-To: vijayn@inprise.com Organization: Inprise Corporation X-Accept-Language: en To: Simon Nash CC: issues@omg.org, java2idl-rtf@omg.org, Bryan Atsatt , Steve Lewallen Subject: Re: Mapping of java.rmi.Remote type References: <36E97157.54F70FB9@hursley.ibm.com> Hmmm.... Simon Nash wrote: > The proposal for issue 2482 that we adopted has some problems. > > First consider the client side. If I have a declared type of > java.rmi.Remote as a result of a remote method, I need to be able > to demarshal the IOR that I receive as a generic remote stub if > I cannot find a better stub based onthe actual type in the IOR. > > I propose that the following stub class should be used for this: > > package javax.rmi.CORBA; > public class _Remote_Stub extends javax.rmi.CORBA.Stub > implements java.rmi.Remote { > } > I still don't believe the adopted proposal is a problem. The solution is to simply state the repository Id for the alias definition to be RMI:java.rmi.Remote:1 (as in with a hash value of 1). On the client side, one could special case this and use the _Remote_Stub that you mentioned. I do believe that is implementation dependent and need not be specified though. > For consistency with our usual naming convention, this suggests that > java.rmi.Remote should be mapped to the following IDL: > > module javax { > module rmi { > module CORBA { > typedef Object Remote; > }; > }; > }; > Now consider the server side. Suppose I have an implementation > class that implements java.rmi.Remote and no other remote > interfaces. > This works just fine in JRMP. What repid would be marshalled in the > IOR for such an object? I think the correct answer based on the > above IDL is > "IDL:javax/rmi/CORBA/Remote:1.0" > which is a typedef (alias) for Object. The other alternative is > "IDL:omg.org/CORBA/Object:1.0" > but I am not sure if it is legal to send this in an IOR, or if > sending > a null repid is legal and means the same thing. And based on what I said above the resulting IOR in the server side would encode the repository id of "RMI:java.rmi.Remote:1". However, I think this is quite a wierd case, if an object just implements Remote (implying it has no methods to be remoted) what possible need would there be to pass such a thing around? I actually would prefer to make this an error (Would that be possible to do though?). Vijay