Issue 6410: Custom marshalled abstract interfaces and Java/IDL (java2idl-rtf) Source: Oracle (Dr. Andrew Piper, andyp(at)bea.com) Nature: Clarification Severity: Summary: We currently are having a problem implementing abstract interface behaviour in C++ for valuetypes marshaled according to the Java/IDL spec. For custom marshaled objects the spec says: "Other Java objects are marshaled in the form of an IDL abstract interface (i.e., a union with a boolean discriminator containing either an object reference if the discriminator is true or a value type if the discriminator is false)." However, the Java/IDL spec does not mandate that _all_ Java objects of this type be mapped to IDL that has an abstract interface as a supertype. Thus we are left in the position for IDL that objects marshaled as abstract interfaces are not truly abstract interfaces as defined in the CORBA spec section 6.2. Moreover the generated C++ for these types will not include inheritance from AbstractBase, so how should these types be handled? In particular should DataInputStream::read_Abstract() work at all for these types? You could imagine making this work by having read_Abstract() return some container class that held the actual object (valuetype or object reference), but its not clear that this is actual legal wrt 6.2. Clarification appreciated. Resolution: Revised Text: In section 1.4.10, paragraph starting "Primitive Java types ...", change last sentence to: Other Java objects are marshaled in the form of a union with a boolean discriminator containing either an object reference if the discriminator is true or a value type if the discriminator is false. [footnote: This marshaling format happens to be the same as that used for OMG IDL abstract interface types. Despite this similarity, these objects are not mapped to OMG IDL abstract interface types and they should not be treated as abstract interface types when they are unmarshaled.] Actions taken: November 3, 2003: received issue July 30, 2007: closed issue Discussion: Resolution: Closed, no change. See revised text below. End of Annotations:===== Date: Mon, 07 Jul 2003 14:29:10 -0700 From: KEN CAVANAUGH Subject: Request clarification on copyObject(s) semantics Sender: Ken.Cavanaugh@Sun.COM To: java2idl-rtf@omg.org Cc: corba-dev@Sun.COM, Sanjeev.Krishnan@Sun.COM Reply-to: Ken.Cavanaugh@Sun.COM Organization: Sun Microsystems X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Questions have come up recently about copyObject behavior, both within Sun and from customers. The main question is whether it is necessary to actually copy immutable objects, or can copyObject( obj ) simply return obj for immutable objects. The standard immutable objects in question are String and the primitive type wrappers (Integer etc.). Looking at ptc/02-01-12, the main part of the specification that is relevant is section 1.5.1.6, on the bottom of page 1-52. The statement is made here that "(copyObject and copyObjects) observe copy semantics for value objects that are equivalent to marshalling, ...". What exactly does equivalent mean here? It seems to me that the most important property here is that any sequence of method invocations made by the "client" do not affect the results of any sequence of method invocations made by the "server" (or vice-versa). This is normally the case for immutable objects that are copied by reference. However, locking of an object passed by reference is possibly observable. Normally, the "client" and the "server" in the colocated case are actually running on the same thread, but each role could pass object obj and copyObject(obj) to a different thread. Different results are then possible for the copy/non-copy case, depending on the locking behavior of the threads. There are old parts of the rmic -iiop code and the Sun ORB, dating from the days when Sun and IBM were jointly developing RMI-IIOP, that show evidence of both possible interpretations. For example, StubGenerator.mustCopy( TYPE_STRING ) returns false, so that a method that takes only one or more String arguments would not have a call to copyObject(s) generated in the stub. However, the implementation of Util.copyObject(s) always copies String instances. I would like to see the text clarified in the specification to explicitly state whether immutable objects need to be copied or not. Thanks, Ken. Subject: Re: Request clarification on copyObject(s) semantics To: Ken.Cavanaugh@sun.com Cc: java2idl-rtf@omg.org X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002 From: "Ann Collins" Date: Tue, 8 Jul 2003 12:07:42 +0100 X-MIMETrack: Serialize by Router on D06ML055/06/M/IBM(Release 5.0.9a |January 7, 2002) at 08/07/2003 12:10:09 Ken, I think the objective is to preserve remote/local transparency for locally optimized colocated method calls. The only reasons I know of for copying immutable objects are a. to preserve referential integrity when e.g Strings in the parameter list may be referenced from other objects that are copied b. because the spec section you cite suggests at least that all objects will be copied I would be happy to see the spec clarified to allow optimizations, within the constraints of the above. Ann A E Collins (formerly Dalton) KEN CAVANAUGH cc: corba-dev@Sun.COM, Sanjeev.Krishnan@Sun.COM Sent by: Subject: Request clarification on copyObject(s) semantics Ken.Cavanaugh@Sun .COM 07/07/2003 22:29 Please respond to Ken.Cavanaugh Questions have come up recently about copyObject behavior, both within Sun and from customers. The main question is whether it is necessary to actually copy immutable objects, or can copyObject( obj ) simply return obj for immutable objects. The standard immutable objects in question are String and the primitive type wrappers (Integer etc.). Looking at ptc/02-01-12, the main part of the specification that is relevant is section 1.5.1.6, on the bottom of page 1-52. The statement is made here that "(copyObject and copyObjects) observe copy semantics for value objects that are equivalent to marshalling, ...". What exactly does equivalent mean here? It seems to me that the most important property here is that any sequence of method invocations made by the "client" do not affect the results of any sequence of method invocations made by the "server" (or vice-versa). This is normally the case for immutable objects that are copied by reference. However, locking of an object passed by reference is possibly observable. Normally, the "client" and the "server" in the colocated case are actually running on the same thread, but each role could pass object obj and copyObject(obj) to a different thread. Different results are then possible for the copy/non-copy case, depending on the locking behavior of the threads. There are old parts of the rmic -iiop code and the Sun ORB, dating from the days when Sun and IBM were jointly developing RMI-IIOP, that show evidence of both possible interpretations. For example, StubGenerator.mustCopy( TYPE_STRING ) returns false, so that a method that takes only one or more String arguments would not have a call to copyObject(s) generated in the stub. However, the implementation of Util.copyObject(s) always copies String instances. I would like to see the text clarified in the specification to explicitly state whether immutable objects need to be copied or not. Thanks, Ken. Date: Tue, 08 Jul 2003 09:39:16 -0700 From: KEN CAVANAUGH Subject: Re: Request clarification on copyObject(s) semantics Sender: Ken.Cavanaugh@Sun.COM To: Ann Collins Cc: java2idl-rtf@omg.org, Sanjeev.Krishnan@Sun.COM Reply-to: Ken.Cavanaugh@Sun.COM Organization: Sun Microsystems X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Ann Collins wrote: > > Ken, > > I think the objective is to preserve remote/local transparency for > locally optimized colocated method calls. I agree. > The only reasons I know of for > copying immutable objects are > a. to preserve referential integrity when e.g Strings in the parameter > list may be referenced from other objects that are copied This just means that the string must be handled consistently. If a String is not copied (because Strings are immutable), then all references continue to be shared correctly. > b. because the spec section you cite suggests at least that all objects > will be copied I don't think the spec says that. It requires "equivalent semantics". I think the "copy" referred to in the spec is simply the result of copyObject( obj ), which could be obj if obj is immutable. It appears that such optimizations may already be common in a number of app server implementations. It would be useful to get clarification about what BEA and IBM (among others) are doing in this area. > I would be happy to see the spec clarified to allow optimizations, > within the constraints of the above. > My proposal would be simply to allow copyObject( obj ) == obj if obj is immutable. This would not be required, merely allowed. But in either case, the reference sharing semantics must be preserved. Thanks, Ken. > Ann > A E Collins (formerly Dalton) > > > KEN CAVANAUGH > n.COM> cc: corba-dev@Sun.COM, Sanjeev.Krishnan@Sun.COM > Sent by: Subject: Request clarification on copyObject(s) semantics > Ken.Cavanaugh@Sun > .COM > > > 07/07/2003 22:29 > Please respond to > Ken.Cavanaugh > > > > Questions have come up recently about copyObject behavior, both within Sun > and from customers. > The main question is whether it is necessary to actually copy immutable > objects, or can copyObject( obj ) > simply return obj for immutable objects. The standard immutable > objects in question are String and the primitive type wrappers (Integer > etc.). > > Looking at ptc/02-01-12, the main part of the specification that is > relevant is section 1.5.1.6, > on the bottom of page 1-52. The statement is made here that "(copyObject > and copyObjects) observe > copy semantics for value objects that are equivalent to marshalling, ...". > What exactly does > equivalent mean here? > > It seems to me that the most important property here is that any sequence > of method invocations > made by the "client" do not affect the results of any sequence of method > invocations made by > the "server" (or vice-versa). This is normally the case for immutable > objects that are copied by reference. > However, locking of an object passed by reference is possibly observable. > Normally, the > "client" and the "server" in the colocated case are actually running on the > same thread, but > each role could pass object obj and copyObject(obj) to a different thread. > Different results > are then possible for the copy/non-copy case, depending on the locking > behavior of the threads. > > There are old parts of the rmic -iiop code and the Sun ORB, dating from the > days when Sun and IBM > were jointly developing RMI-IIOP, that show evidence of both possible > interpretations. For > example, StubGenerator.mustCopy( TYPE_STRING ) returns false, so that a > method that takes > only one or more String arguments would not have a call to copyObject(s) > generated in the stub. > However, the implementation of Util.copyObject(s) always copies String > instances. > > I would like to see the text clarified in the specification to explicitly > state whether immutable > objects need to be copied or not. > > Thanks, > > Ken. X-Sender: andyp@san-francisco.beasys.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 08 Jul 2003 13:06:15 -0700 To: Ken.Cavanaugh@sun.com, Ann Collins From: Andy Piper Subject: Re: Request clarification on copyObject(s) semantics Cc: java2idl-rtf@omg.org, Sanjeev.Krishnan@sun.com At 09:39 AM 7/8/2003 -0700, KEN CAVANAUGH wrote: t appears that such optimizations may already be common in a number of app server implementations. It would be useful to get clarification about what BEA and IBM (among others) are doing in this area. We do precisely this in a number of situations (don't copy immutables). andy Date: Wed, 09 Jul 2003 02:16:06 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ken.Cavanaugh@sun.com CC: Ann Collins , java2idl-rtf@omg.org, Sanjeev.Krishnan@sun.com, andyp@bea.com Subject: Re: Request clarification on copyObject(s) semantics Ken, I agree that locking of immutable objects is potentially observable and could impact remote/local transparency if immutable objects are not copied. However, I think the performance gain from optimizing copyObject() for immutable objects outweighs the very small loss of full transparency in this unlikely case. So I would be OK with a spec clarification that immutable objects need not be copied if referential integrity is preserved. Simon KEN CAVANAUGH wrote: > > Ann Collins wrote: > > > > Ken, > > > > I think the objective is to preserve remote/local transparency for > > locally optimized colocated method calls. > > I agree. > > > The only reasons I know of for > > copying immutable objects are > > a. to preserve referential integrity when e.g Strings in the parameter > > list may be referenced from other objects that are copied > > This just means that the string must be handled consistently. If a > String is not copied (because Strings are immutable), > then all references continue to be shared correctly. > > > b. because the spec section you cite suggests at least that all objects > > will be copied > > I don't think the spec says that. It requires "equivalent semantics". > I think the "copy" referred to in the spec is simply the result of > copyObject( obj ), which could be obj if obj is immutable. > It appears that such optimizations may already be common in a number > of app server implementations. It would be useful to get clarification > about what BEA and IBM (among others) are doing in this area. > > > I would be happy to see the spec clarified to allow optimizations, > > within the constraints of the above. > > > > My proposal would be simply to allow copyObject( obj ) == obj if > obj is immutable. This would not be required, merely allowed. > But in either case, the reference sharing semantics must be preserved. > > Thanks, > > Ken. > > > Ann > > A E Collins (formerly Dalton) > > > > > > KEN CAVANAUGH > > > n.COM> cc: corba-dev@Sun.COM, Sanjeev.Krishnan@Sun.COM > > Sent by: Subject: Request clarification on copyObject(s) semantics > > Ken.Cavanaugh@Sun > > .COM > > > > > > 07/07/2003 22:29 > > Please respond to > > Ken.Cavanaugh > > > > > > > > Questions have come up recently about copyObject behavior, both within Sun > > and from customers. > > The main question is whether it is necessary to actually copy immutable > > objects, or can copyObject( obj ) > > simply return obj for immutable objects. The standard immutable > > objects in question are String and the primitive type wrappers (Integer > > etc.). > > > > Looking at ptc/02-01-12, the main part of the specification that is > > relevant is section 1.5.1.6, > > on the bottom of page 1-52. The statement is made here that "(copyObject > > and copyObjects) observe > > copy semantics for value objects that are equivalent to marshalling, ...". > > What exactly does > > equivalent mean here? > > > > It seems to me that the most important property here is that any sequence > > of method invocations > > made by the "client" do not affect the results of any sequence of method > > invocations made by > > the "server" (or vice-versa). This is normally the case for immutable > > objects that are copied by reference. > > However, locking of an object passed by reference is possibly observable. > > Normally, the > > "client" and the "server" in the colocated case are actually running on the > > same thread, but > > each role could pass object obj and copyObject(obj) to a different thread. > > Different results > > are then possible for the copy/non-copy case, depending on the locking > > behavior of the threads. > > > > There are old parts of the rmic -iiop code and the Sun ORB, dating from the > > days when Sun and IBM > > were jointly developing RMI-IIOP, that show evidence of both possible > > interpretations. For > > example, StubGenerator.mustCopy( TYPE_STRING ) returns false, so that a > > method that takes > > only one or more String arguments would not have a call to copyObject(s) > > generated in the stub. > > However, the implementation of Util.copyObject(s) always copies String > > instances. > > > > I would like to see the text clarified in the specification to explicitly > > state whether immutable > > objects need to be copied or not. > > > > Thanks, > > > > Ken. -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Tue, 08 Jul 2003 23:35:30 -0700 From: KEN CAVANAUGH Subject: Re: Request clarification on copyObject(s) semantics Sender: Ken.Cavanaugh@Sun.COM To: Simon Nash Cc: Ann Collins , java2idl-rtf@omg.org, Sanjeev.Krishnan@Sun.COM, andyp@bea.com Reply-to: Ken.Cavanaugh@Sun.COM Organization: Sun Microsystems X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Simon Nash wrote: > > Ken, > I agree that locking of immutable objects is potentially observable > and could impact remote/local transparency if immutable objects are > not copied. However, I think the performance gain from optimizing > copyObject() for immutable objects outweighs the very small loss of > full transparency in this unlikely case. So I would be OK with a > spec clarification that immutable objects need not be copied if > referential integrity is preserved. > This is my preference as well. I think the possible problems with locking are very unlikely in practice, especially since immutable objects would normally not be used for synchronization. I think a lot of J2EE vendors are making this optimization, so I would certainly like to see a clarification allowing copyObject( obj ) == obj if obj is immutable. Thanks, Ken. > Simon > > KEN CAVANAUGH wrote: > > > > Ann Collins wrote: > > > > > > Ken, > > > > > > I think the objective is to preserve remote/local transparency for > > > locally optimized colocated method calls. > > > > I agree. > > > > > The only reasons I know of for > > > copying immutable objects are > > > a. to preserve referential integrity when e.g Strings in the parameter > > > list may be referenced from other objects that are copied > > > > This just means that the string must be handled consistently. If a > > String is not copied (because Strings are immutable), > > then all references continue to be shared correctly. > > > > > b. because the spec section you cite suggests at least that all objects > > > will be copied > > > > I don't think the spec says that. It requires "equivalent semantics". > > I think the "copy" referred to in the spec is simply the result of > > copyObject( obj ), which could be obj if obj is immutable. > > It appears that such optimizations may already be common in a number > > of app server implementations. It would be useful to get clarification > > about what BEA and IBM (among others) are doing in this area. > > > > > I would be happy to see the spec clarified to allow optimizations, > > > within the constraints of the above. > > > > > > > My proposal would be simply to allow copyObject( obj ) == obj if > > obj is immutable. This would not be required, merely allowed. > > But in either case, the reference sharing semantics must be preserved. > > > > Thanks, > > > > Ken. > > > > > Ann > > > A E Collins (formerly Dalton) > > > > > > > > > KEN CAVANAUGH > > > > > n.COM> cc: corba-dev@Sun.COM, Sanjeev.Krishnan@Sun.COM > > > Sent by: Subject: Request clarification on copyObject(s) semantics > > > Ken.Cavanaugh@Sun > > > .COM > > > > > > > > > 07/07/2003 22:29 > > > Please respond to > > > Ken.Cavanaugh > > > > > > > > > > > > Questions have come up recently about copyObject behavior, both within Sun > > > and from customers. > > > The main question is whether it is necessary to actually copy immutable > > > objects, or can copyObject( obj ) > > > simply return obj for immutable objects. The standard immutable > > > objects in question are String and the primitive type wrappers (Integer > > > etc.). > > > > > > Looking at ptc/02-01-12, the main part of the specification that is > > > relevant is section 1.5.1.6, > > > on the bottom of page 1-52. The statement is made here that "(copyObject > > > and copyObjects) observe > > > copy semantics for value objects that are equivalent to marshalling, ...". > > > What exactly does > > > equivalent mean here? > > > > > > It seems to me that the most important property here is that any sequence > > > of method invocations > > > made by the "client" do not affect the results of any sequence of method > > > invocations made by > > > the "server" (or vice-versa). This is normally the case for immutable > > > objects that are copied by reference. > > > However, locking of an object passed by reference is possibly observable. > > > Normally, the > > > "client" and the "server" in the colocated case are actually running on the > > > same thread, but > > > each role could pass object obj and copyObject(obj) to a different thread. > > > Different results > > > are then possible for the copy/non-copy case, depending on the locking > > > behavior of the threads. > > > > > > There are old parts of the rmic -iiop code and the Sun ORB, dating from the > > > days when Sun and IBM > > > were jointly developing RMI-IIOP, that show evidence of both possible > > > interpretations. For > > > example, StubGenerator.mustCopy( TYPE_STRING ) returns false, so that a > > > method that takes > > > only one or more String arguments would not have a call to copyObject(s) > > > generated in the stub. > > > However, the implementation of Util.copyObject(s) always copies String > > > instances. > > > > > > I would like to see the text clarified in the specification to explicitly > > > state whether immutable > > > objects need to be copied or not. > > > > > > Thanks, > > > > > > Ken. > > -- > Simon C Nash IBM Distinguished Engineer > Hursley Park, Winchester, UK nash@hursley.ibm.com > Tel. +44-1962-815156 Fax +44-1962-818999 Date: Wed, 9 Jul 2003 12:41:48 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Request clarification on copyObject(s) semantics To: Ken.Cavanaugh@sun.com Cc: ann_collins@uk.ibm.com, java2idl-rtf@omg.org, Sanjeev.Krishnan@sun.com, andyp@bea.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc > I would certainly like to see a clarification > allowing copyObject( obj ) == obj if obj is immutable. Is there a precise definition of "immutable" that you have in mind? As an example, java.security.cert.Certificate instances are intended to be immutable, are you thinking it's OK to perform the optimization for any (subclass) instance of it? This is a particular case where serialization is non-trivial: copying an instance via serialization can result in a different CertificateFactory provider being used to create the new Certificate than was used in the original, so you can end up with a certificate instance of a different class than what you started with. Is the optimization allowed even if the class has read/writeObject methods that perform validation that might, under some circumstances, throw InvalidObjectException or some other ObjectStreamException? Or an "immutable" object whose class has a writeReplace or readResolve method that would return an instance of some completely different class? Are any/all Class objects immutable? The actual Class you get as a result of serializing (in a true remote call into the same VM) could be from a different class loader than the original Class. As an aside, it seems that the java2idl spec doesn't say anything about if/how the context class loader must be set when unmarshalling arguments for incoming remote calls, which seems like a problem, given that the spec says RMIClassLoader.loadClass is used and it has a fundamental dependence on the context class loader. - Bob Date: Wed, 09 Jul 2003 11:14:24 -0700 From: KEN CAVANAUGH Subject: Re: Request clarification on copyObject(s) semantics Sender: Ken.Cavanaugh@Sun.COM To: Bob Scheifler - SMI Software Development Cc: ann_collins@uk.ibm.com, java2idl-rtf@omg.org, Sanjeev.Krishnan@Sun.COM, andyp@bea.com, corba-dev@Sun.COM Reply-to: Ken.Cavanaugh@Sun.COM Organization: Sun Microsystems X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Bob Scheifler - SMI Software Development wrote: > > > I would certainly like to see a clarification > > allowing copyObject( obj ) == obj if obj is immutable. > > Is there a precise definition of "immutable" that you have in mind? Immutable is a bit hard to pin down precisely. The main classes that I am currently considering are String and the primitive type wrappers. There are probably others, and a user could possibly decide that certain classes they define are also immutable. One attempt at a definition is the following: Object obj is immutable if for every method m on obj that has a non-void return type, obj.m( args ) always returns the same result for the same sequence of arguments. "Same" probably can be either == or equals, but I'm not sure which is more appropriate here. I just want some statement that captures the idea that the externally visible state of an immutable object can't change. Of course, this says nothing about the actual state representation of an immutable object. All sorts of optimizations based on commonly occurring values on a method call are possible, and these would result in internal state changes that are not externally visible. In fact, this definition is not entirely adequate: in addition, an immutable object must not have any exposed mutable state. Certainly the class used in the result of Collections.unmodifiableList( List ) is an immutable, but the list passed as an argument may not be. This is another reason why immutable objects need to be defined manually. In any case, we will need to pin this down for the spec. I think the whole point of this question is to allow RMI-IIOP implementations to treat certain commonly occuring classes as immutable. We should not try to take advantage of every possible immutable class, and we should not try to automatically detect immutable classes. > > As an example, java.security.cert.Certificate instances are intended > to be immutable, are you thinking it's OK to perform the optimization > for any (subclass) instance of it? This is a particular case where > serialization is non-trivial: copying an instance via serialization > can result in a different CertificateFactory provider being used > to create the new Certificate than was used in the original, so > you can end up with a certificate instance of a different class > than what you started with. I would not expect that a subclass of an immutable object is automatically immutable. Of course, there is no way to automatically detect whether a class is immutable, so I would expect to rely on manual registration of all immutable classes. What determines which CertificateFactory provider is in use? Would the same provider always be used in the co-located case? If this is just the registered JCA provider, it appears that the same CertificateFactory would always be used in the co-located case. However, the actual implementation of Certificate is some provider-specific subclass that is probably unknown to the copyObject implementation, so it would not be treated as an immutable class. > > Is the optimization allowed even if the class has read/writeObject > methods that perform validation that might, under some circumstances, > throw InvalidObjectException or some other ObjectStreamException? > Or an "immutable" object whose class has a writeReplace or readResolve > method that would return an instance of some completely different class? > If this is a concern, then such a class should not be treated as being immutable. > Are any/all Class objects immutable? The actual Class you get as a > result of serializing (in a true remote call into the same VM) could > be from a different class loader than the original Class. > I wasn't planning to make java.lang.Class one of the immutables, as Class always requires special handling. However, it might not be a problem, as the co-located path (where copyObject is used) is only applicable if the invoker and the servant are loaded by the same class loader (at least, this is what normally happens. The actual requirement is the the interface type of the servant be in the same class loader as the invoker, but the Sun ORB actually requires the invoker and the Servant in the same class loader). In this case, I think we would have the same Class. > As an aside, it seems that the java2idl spec doesn't say > anything about if/how the context class loader must be set when > unmarshalling arguments for incomin Date: Wed, 9 Jul 2003 15:04:30 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Request clarification on copyObject(s) semantics To: Ken.Cavanaugh@sun.com Cc: ann_collins@uk.ibm.com, java2idl-rtf@omg.org, Sanjeev.Krishnan@sun.com, andyp@bea.com, corba-dev@sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc > Immutable is a bit hard to pin down precisely. I suspect it's very hard to pin down precisely. > The main classes > that I am currently considering are String and the primitive type wrappers. I could imagine a simple enumeration in the spec of classes for which the optimization was allowed. I'd be concerned that any semantic definition will be open to disagreement. > One attempt at a definition is the following: > > Object obj is immutable if for every method m on obj that has a non-void > return type, obj.m( args ) always returns the same result for the same > sequence of arguments. > > "Same" probably can be either == or equals, but I'm not sure which is > more appropriate here. The above is missing accessible modifiable fields. It also doesn't capture things like void methods that take callback arguments and expose mutating state to those callbacks. Or objects that spawn threads that reach out and touch someone. There's also details like which methods and fields (public, protected, package) to consider. And nasty little issues like immutable objects that are outer "this" instances for mutable objects of inner classes. And the kinds of read/write/resolve/replaceObject vagaries I mentioned before. > I would not expect that a subclass of an immutable object is automatically > immutable. True, but if "immutable" is open to interpretation, I could easily imagine somone deciding that it's intended semantically that all Certificate instances are immutable, and any subclass that violates that is broken, and decide choice of provider shouldn't in theory matter, so it's OK to optimize all of them. > Of course, there is no way to automatically detect > whether a class is immutable, so I would expect to rely on manual > registration of all immutable classes. I'm less concerned about manual registration than what copyObject is permitted to do absent any such registration. > What determines which CertificateFactory provider is in use? > Would the same provider always be used in the co-located case? > If this is just the registered JCA provider, it appears that the > same CertificateFactory would always be used in the co-located > case. The default serialization of a Certificate only encodes the cert type, not the provider name. There can be multiple providers for a given type, and it's possible to specify a particular provider name when directly calling CertificateFactory.getInstance, but the default deserialization of a Certificate will always use the default provider registered with JCA. So co-location doesn't guarantee the same provider. > The actual > requirement is the the interface type of the servant be in the > same class loader as the invoker Where is that specified? What I see in the 1.2 idljava spec is: "The _is_local() method returns true if the servant incarnating the object is located in the same process as the stub and they both share the same ORB instance." > but the Sun ORB actually requires the invoker and > the Servant in the same class loader). In this case, I think we > would have the same Class. According to the java2idl spec, I think it would still depend on the context class loader. And to push at another corner, it might depend on what you think a custom RMIClassLoaderSpi provider is obligated to do. - Bob Date: Wed, 09 Jul 2003 23:37:09 -0700 From: KEN CAVANAUGH Subject: Re: Request clarification on copyObject(s) semantics Sender: Ken.Cavanaugh@Sun.COM To: Bob Scheifler - SMI Software Development Cc: ann_collins@uk.ibm.com, java2idl-rtf@omg.org, Sanjeev.Krishnan@Sun.COM, andyp@bea.com, corba-dev@Sun.COM Reply-to: Ken.Cavanaugh@Sun.COM Organization: Sun Microsystems X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Bob Scheifler - SMI Software Development wrote: > > > Immutable is a bit hard to pin down precisely. > > I suspect it's very hard to pin down precisely. > Yes. It seems that there is lots of discussion about immutable objects and locking, and that String is immutable, but I have not seen any attempts to precisely pin down the meaning of immutable. > > The main classes > > that I am currently considering are String and the primitive type wrappers. > > I could imagine a simple enumeration in the spec of classes for which the > optimization was allowed. I'd be concerned that any semantic definition > will be open to disagreement. That is a potential problem. I'd be happy to go in either direction, depending on what the other RTF members want to do. > > > One attempt at a definition is the following: > > > > Object obj is immutable if for every method m on obj that has a non-void > > return type, obj.m( args ) always returns the same result for the same > > sequence of arguments. > > > > "Same" probably can be either == or equals, but I'm not sure which is > > more appropriate here. > > The above is missing accessible modifiable fields. True. I forgot that because I seldom use externally visible fields. An immutable object should not have any non-private non-final fields. > It also doesn't > capture things like void methods that take callback arguments and > expose mutating state to those callbacks. Actually, the definition also has a problem, in that many mutable objects that only have void setters would be allowed as well. The definition would probably need to include some idea that obj.m( args ) always produces the same result no matter what sequence of method invocations preceed the call. The callback problem is interesting. An object that generates events according to internal state changes that are not visible through the methods on the object would have observably different behavior depending on how it is copied. An immutable object either must not contain any mutating state, or it must never expose the mutating state. Here we have pushed the problem into another corner: how do we define exposing mutating state? > Or objects that spawn threads > that reach out and touch someone. Perhaps immutable objects should never spawn threads? Some uses would be safe, but thread spawning could be outlawed completely, if a class is allowed as immutable. > There's also details like which methods > and fields (public, protected, package) to consider. Any non-private methods must be considered. No non-private non-final fields should be allowed. > And nasty little > issues like immutable objects that are outer "this" instances for mutable > objects of inner classes. What is the problem here? I'm uncertain as to the exact case you're thinking of here. > And the kinds of read/write/resolve/replaceObject > vagaries I mentioned before. > > > I would not expect that a subclass of an immutable object is automatically > > immutable. > > True, but if "immutable" is open to interpretation, I could easily > imagine somone deciding that it's intended semantically that all Certificate > instances are immutable, and any subclass that violates that is broken, > and decide choice of provider shouldn't in theory matter, so it's OK to > optimize all of them. > > > Of course, there is no way to automatically detect > > whether a class is immutable, so I would expect to rely on manual > > registration of all immutable classes. > > I'm less concerned about manual registration than what copyObject > is permitted to do absent any such registration. I would say that copyObject must make a copy in a manner equivalent to serialization. We would only be allowing certain specific classes to be handled as immutable, and these classes must be explicitly registered with the copyObject implementation. I would leave it up to the implementation to decide how the registration takes place. I think we still need to decide whether to list all allowable immutable classes, or to attempt to define what immutable means. We could also leave the definition of immutable open, and list those JDK classes that we wish to guarantee are immutable. > > > What determines which CertificateFactory provider is in use? > > Would the same provider always be used in the co-located case? > > If this is just the registered JCA provider, it appears that the > > same CertificateFactory would always be used in the co-located > > case. > > The default serialization of a Certificate only encodes the cert type, > not the provider name. There can be multiple providers for a given type, > and it's possible to specify a particular provider name when directly > calling CertificateFactory.getInstance, but the default deserialization > of a Certificate will always use the default provider registered > with JCA. So co-location doesn't guarantee the same provider. > OK, I understand the problem better now. In any case, I don't think we would want to make Certificates immutables for copyObject. > > The actual > > requirement is the the interface type of the servant be in the > > same class loader as the invoker > > Where is that specified? What I see in the 1.2 idljava spec is: > "The _is_local() method returns true if the servant incarnating the object > is located in the same process as the stub and they both share the same ORB > instance." It's not, but the generated code in the co-located case in the stub needs to cast the untyped servant returned from the ORB to the interface type. The stub is loaded by the invoker's class loader, so the interface type is loaded in the stub by the invoker's class loader. If the interface type on the servant is loaded in a different class loader, and the resulting defining class loader for the interface type is different, the co-located call would fail with a ClassCastException. This is a common occurrence in the app server, and we take a lot of care to make this work correctly. > > > but the Sun ORB actually requires the invoker and > > the Servant in the same class loader). In this case, I think we > > would have the same Class. > > According to the java2idl spec, I think it would still depend on the > context class loader. Which part of the spec? The discussion about Codebase usage in 1.4.9.5 defines the actions that Util.loadClass must take, and this does not include the context class loader (but probably should). In any case, Class should probably not be one of the legal immutables for copyObject. > And to push at another corner, it might depend > on what you think a custom RMIClassLoaderSpi provider is obligated to do. > Well, since we won't treat Class instances as immutable, this shouldn't matter either. Ken. Date: Thu, 10 Jul 2003 13:14:17 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Request clarification on copyObject(s) semantics To: Ken.Cavanaugh@sun.com Cc: ann_collins@uk.ibm.com, java2idl-rtf@omg.org, Sanjeev.Krishnan@sun.com, andyp@bea.com, corba-dev@sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc > The definition > would probably need to include some idea that obj.m( args ) always produces > the same result no matter what sequence of method invocations preceed the > call. Well, I might argue that instances of the following class are immutable: public class Foo { public long now() { return System.currentTimeMillis(); } } > > And nasty little > > issues like immutable objects that are outer "this" instances for mutable > > objects of inner classes. > > What is the problem here? I'm uncertain as to the exact case you're thinking > of here. I was thinking about if you didn't copy the immutable object but did copy the mutable ones, but on second thought, the requirement to retain referential integrity would force you to copy the immutable one. > > > The actual > > > requirement is the the interface type of the servant be in the > > > same class loader as the invoker > > > > Where is that specified? What I see in the 1.2 idljava spec is: > > "The _is_local() method returns true if the servant incarnating the object > > is located in the same process as the stub and they both share the same ORB > > instance." > > It's not, but the generated code in the co-located case in the stub > needs to cast the untyped servant returned from the ORB to the interface > type. I'm not sure I really care about this point, but is there something in the spec that prohibits the stub from invoking the servant reflectively (thus avoiding the need for a shared interface type)? > > According to the java2idl spec, I think it would still depend on the > > context class loader. > > Which part of the spec? The discussion about Codebase usage in 1.4.9.5 > defines the actions that Util.loadClass must take, and this does not > include the context class loader (but probably should). It includes the context class loader indirectly, in that Util.loadClass specifies the use of RMIClassLoader.loadClass, and that method makes use of the context class loader. > > And to push at another corner, it might depend > > on what you think a custom RMIClassLoaderSpi provider is obligated to do. > > Well, since we won't treat Class instances as immutable, this shouldn't matter > either. Well, still pushing far into the corners, depending on how much latitude you think such a provider has in resolving class names, it might be argued that optimizing out the copy of any immutable object is ursurping a custom provider's ability to resolve that object's class as it sees fit. - Bob Date: Wed, 16 Jul 2003 20:33:50 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en To: Ken.Cavanaugh@sun.com CC: Bob Scheifler - SMI Software Development , ann_collins@uk.ibm.com, java2idl-rtf@omg.org, Sanjeev.Krishnan@sun.com, andyp@bea.com, corba-dev@sun.com Subject: Re: Request clarification on copyObject(s) semantics Ken et al, KEN CAVANAUGH wrote: > > Bob Scheifler - SMI Software Development wrote: > > > > > Immutable is a bit hard to pin down precisely. > > > > I suspect it's very hard to pin down precisely. > > > > Yes. It seems that there is lots of discussion about immutable objects and > locking, and that String is immutable, but I have not seen any attempts > to precisely pin down the meaning of immutable. > > > > The main classes > > > that I am currently considering are String and the primitive type wrappers. > > > > I could imagine a simple enumeration in the spec of classes for which the > > optimization was allowed. I'd be concerned that any semantic definition > > will be open to disagreement. > > That is a potential problem. I'd be happy to go in either direction, depending > on what the other RTF members want to do. > Here is a proposal for a semantic definition of immutable. An object is immutable if, after its constructor/initializer completes, it is impossible to modify the non-static fields of the object. In addition, for non-static fields that hold object references, each referenced object must also itself be immutable. What are the problems with this definition? Simon -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Wed, 16 Jul 2003 16:04:21 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Request clarification on copyObject(s) semantics To: nash@hursley.ibm.com Cc: ann_collins@uk.ibm.com, java2idl-rtf@omg.org, Sanjeev.Krishnan@sun.com, andyp@bea.com, corba-dev@sun.com X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc > An object is immutable if, after its constructor/initializer > completes, it is impossible to modify the non-static fields > of the object. In addition, for non-static fields that hold > object references, each referenced object must also itself > be immutable. > > What are the problems with this definition? If I understand your definition, (as but one example) BigInteger violates it, yet I would think BigInteger instances are semantically immutable. Your definition doesn't distinguish modifications that are not semantically visible from those that are. - Bob Date: Wed, 16 Jul 2003 13:34:17 -0700 From: KEN CAVANAUGH Subject: Re: Request clarification on copyObject(s) semantics Sender: Ken.Cavanaugh@Sun.COM To: Simon Nash Cc: Bob Scheifler - SMI Software Development , ann_collins@uk.ibm.com, java2idl-rtf@omg.org, Sanjeev.Krishnan@Sun.COM, andyp@bea.com, corba-dev@Sun.COM Reply-to: Ken.Cavanaugh@Sun.COM Organization: Sun Microsystems X-Mailer: Mozilla 4.79C-CCK-MCD [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en Simon Nash wrote: > > Ken et al, > > KEN CAVANAUGH wrote: > > > > Bob Scheifler - SMI Software Development wrote: > > > > > > > Immutable is a bit hard to pin down precisely. > > > > > > I suspect it's very hard to pin down precisely. > > > > > > > Yes. It seems that there is lots of discussion about immutable objects and > > locking, and that String is immutable, but I have not seen any attempts > > to precisely pin down the meaning of immutable. > > > > > > The main classes > > > > that I am currently considering are String and the primitive type wrappers. > > > > > > I could imagine a simple enumeration in the spec of classes for which the > > > optimization was allowed. I'd be concerned that any semantic definition > > > will be open to disagreement. > > > > That is a potential problem. I'd be happy to go in either direction, depending > > on what the other RTF members want to do. > > > Here is a proposal for a semantic definition of immutable. > > An object is immutable if, after its constructor/initializer > completes, it is impossible to modify the non-static fields > of the object. In addition, for non-static fields that hold > object references, each referenced object must also itself > be immutable. > > What are the problems with this definition? > Some thoughts: 1. String does not strictly comply with this definition for a trivial reason: The hash value for a String is cached. This sort of caching should not make an object fail to be immutable, as it is not externally observable. 2. A mutable static could be an issue too, if a static is used to count the number of instances. A method could be provided that returns the number of instances that have been constructed. This would give different results for Pass-by-referemce and pass-by-value. 3. Internal references to other objects can do fairly peculiar things. For example, I could have an immutable proxy whose state is a String, that dynamically looks up a mutable object in a JNDI context (so a reference to the context is obtained dynamically by calling new InitialContext()). This would meet the strict definition of immutable you defined above. One of the interesting things we could do with this is use System.identityHashCode to report which copy of the original object is performing some action. I think it may be more useful to focus on the externally visible behavior of an object, but this is also tricky to get right, as the discussion between Bob and me has pointed out. Date: Wed, 15 Nov 2006 23:07:24 +0000 From: Simon Nash Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en To: Jishnu Mukerji , Ken Cavanaugh , Jeffrey Mischkinsky , Yoshitaka Honishi , Andy Piper , Naveed Shaikh , Bill Beckwith , Eoghan Glynn CC: java2idl-rtf@omg.org Subject: Proposed resolution for Java to IDL issue 5991 Here is a proposed resolution for issue 5991. Issue title: Request clarification on copyObject(s) semantics Issue summary: Questions have come up recently about copyObject behavior, both within Sun and from customers. The main question is whether it is necessary to actually copy immutable objects, or can copyObject( obj ) simply return obj for immutable objects. The standard immutable objects in question are String and the primitive type wrappers (Integer etc.). Looking at ptc/02-01-12, the main part of the specification that is relevant is section 1.5.1.6, on the bottom of page 1-52. The statement is made here that "(copyObject and copyObjects) observe copy semantics for value objects that are equivalent to marshalling, ...". What exactly does equivalent mean here? It seems to me that the most important property here is that any sequence of method invocations made by the "client" do not affect the results of any sequence of method invocations made by the "server" (or vice-versa). This is normally the case for immutable objects that are copied by reference. However, locking of an object passed by reference is possibly observable. Normally, the "client" and the "server" in the colocated case are actually running on the same thread, but each role could pass object obj and copyObject(obj) to a different thread. Different results are then possible for the copy/non-copy case, depending on the locking behavior of the threads. There are old parts of the rmic -iiop code and the Sun ORB, dating from the days when Sun and IBM were jointly developing RMI-IIOP, that show evidence of both possible interpretations. For example, StubGenerator.mustCopy( TYPE_STRING ) returns false, so that a method that takes only one or more String arguments would not have a call to copyObject(s) generated in the stub. However, the implementation of Util.copyObject(s) always copies String instances. I would like to see the text clarified in the specification to explicitly state whether immutable objects need to be copied or not. Proposed resolution: The spec already states clearly in section 1.5.1.6 that these methods do make physical copies. Clarify the spec to say that if the stub wants to optimize out the copying (which is legal), then it should omit calls to these methods. In section 1.5.1.6, paragraph starting "The copyObject and ...", change the last sentence to: For non-immutable parameters, results and exceptions (including remote objects), stubs must either call these methods or generate inline code to provide equivalent semantics. In section 1.5.2.2, after the following paragraph: Local stubs are responsible for performing copying of method parameters, results and exceptions, and handling remote objects correctly in order to provide remote/local transparent RMI/IDL semantics. add the following: Local stubs are not required to copy immutable objects. Simon -- Simon C Nash IBM Distinguished Engineer Hursley Park, Winchester, UK nash@hursley.ibm.com Ken.