Issue 4280: In RMI rep Id, when is inclusion of SUID legal? (interop) Source: Oracle (Mr. Everett Anderson, ) Nature: Uncategorized Issue Severity: Summary: In formal 00-11-03 10.6.2 in the discussion of the serial version UID in the RMI hashed format, the spec defines the repository ID format as RMI: <class name> : <hash code> [ : <serialization version UID> ] and says "If the actual serialization version UID for the Java class differs from the hash code, a colon and the actual serialization version UID (transcribed as a 16 digit upper-case hex string) shall be appended to the RepositoryId after the hash code." The Java to IDL spec ptc-00-01-06 1.3.5.7 says "The syntax of the repository ID is the standard OMG RMI Hashed format, with an initial “RMI:” followed by the Java class name, followed by a hash code string, followed optionally by a serialization version UID string." Questions: 1) Is it legal to include the serial version UID in the repository ID even when it is equal to the hash code? (Alternatively: Is it legal for an ORB to throw an exception/fail if the hash code and serial version UID in the repository Id are the same?) 2) If it is not legal to include the serial Version UID in the repository ID when equal to the hash code, what should an ORB do? Discussion: Other than it not harming anything to include the SUID, there are rare cases that the same Java class compiled with different compilers can result in different default serial version UIDs, so it would be wise to explicitly specify the serialVersionUID field even in the first version of a class. If it is legal to always include the serial version UID part of the repository ID, ORBs with classes from two different compilers would still be able to interoperate. Resolution: see below Revised Text: Page 10-44, change the following text: If the actual serialization version UID for the Java class differs from the hash code, a colon and the actual serialization version UID (transcribed as a 16 digit upper-case hex string) shall be appended to the RepositoryId after the hash code. To r ead: For Serializable (including Externalizable) classes, the Java serialization version UID, transcribed as a 16 digit upper-case hex string, shall be appended to the RepositoryId following the hash code and a colon. The Java serialization version UID is defined in the Java Object Serialization Specification. Actions taken: April 23, 2001: received issue May 13, 2002: closed issue Discussion: End of Annotations:===== Subject: Re: In RMI rep Id, when is inclusion of SUID legal? Date: Tue, 24 Apr 2001 15:28:50 +0100 From: Simon Nash Organization: IBM To: Everett Anderson CC: interop@omg.org Everett, Everett Anderson wrote: > > In formal 00-11-03 10.6.2 in the discussion of the serial version UID in > the RMI hashed format, the spec defines the repository ID format as > > RMI: : [ : ] > > and says > > "If the actual serialization version UID for the Java class differs from > the hash code, a colon and the actual serialization version UID > (transcribed as a 16 digit upper-case hex string) shall be appended to > the RepositoryId after the hash code." > > The Java to IDL spec ptc-00-01-06 1.3.5.7 says > > "The syntax of the repository ID is the standard OMG RMI Hashed format, > with an ava class name, followed by a > hash code string, followed optionally by a serialization version UID > string." > > Questions: > > 1) Is it legal to include the serial version UID in the repository ID > even when it is equal to the hash code? (Alternatively: Is it legal > for an ORB to throw an exception/fail if the hash code and serial > version UID in the repository Id are the same?) > Yes, it is legal to include the actual SUID even when it is identical to the hash code, since there is nothing in the spec prohibiting this. Our ORB always includes the actual SUID for serializable classes, even when it happens to be the same as the hashcode, so it would cause interoperability problems if some other ORB threw an exception in this case. > 2) If it is not legal to include the serial Version UID in the > repository ID when equal to the hash code, what should an ORB do? > > Discussion: > > Other than it not harming anything to include the SUID, there are rare > cases that the same Java class compiled with different compilers can > result in different default serial version UIDs, so it would be wise to > explicitly specify the serialVersionUID field even in the first version > of a class. If it is legal to always include the serial version UID > part of the repository ID, ORBs with classes from two different > compilers would still be able to interoperate. > I don't quite follow this. Since the hashcode must always be included, and the SUID must always be included except where it happens to be the same as the hashcode, a repid of RMI:myClass:x is exactly equivalent to RMI:myClass:x:x. So an ORB receiving a repid RMI:myClass:x can be sure that the sender's computation of the SUID yielded the value x, even if the receiver's computation yields some other value. All this is true no matter whether class myClass includes an explicit SUID declaration or relies on the default computation. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Subject: RE: In RMI rep Id, when is inclusion of SUID legal? Date: Tue, 24 Apr 2001 10:43:37 -0700 From: "Everett Anderson" To: "Simon Nash" , "Everett Anderson" CC: > Yes, it is legal to include the actual SUID even when it is > identical to the > hash code, since there is nothing in the spec prohibiting this. Our > ORB > always includes the actual SUID for serializable classes, even when > it > happens to be the same as the hashcode, so it would cause > interoperability > problems if some other ORB threw an exception in this case. Okay, thanks! > I don't quite follow this. Since the hashcode must always be included, > and the SUID must always be included except where it happens to be the > same as the hashcode, a repid of RMI:myClass:x is exactly equivalent to Yes, you're absolutely right -- I'm sorry, my mind had wandered off to a different problem. :) Thanks, Everett Subject: RMI repository ID references to serial version UID Date: Wed, 25 Apr 2001 13:27:51 -0700 From: Everett Anderson To: issues@omg.org, interop@omg.org Hi, I have another request for clarifications about the RMI repository ID: CORBA formal 00-11-03 10.6.2 states "If the actual serialization version UID for the Java class differs from the hash code, a colon and the actual serialization version UID (transcribed as a 16 digit upper-case hex string) shall be appended to the RepositoryId after the hash code." Please comment on the following assertions. The CORBA spec is vague here, and it has resulted in incompatible interpretations which must be resolved quickly. 1) The "actual serialization version UID" mentioned is as defined in the Java Object Serialization specification. http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100 Based on this Java specification and its note that "If the SUID is not declared for a class, the value defaults to the hash for that class": 2) If a serialVersionUID field is defined in the class with the proper modifiers, its value is used as the "actual serialization version UID" mentioned in the CORBA spec 3) If a serialVersionUID field with the proper modifiers is not explicitly defined in a class, its value is computed as explained in the Java Object Serialization spec, and this computed value is used as the "actual serialization version UID" mentioned in the CORBA spec 4) It is required by the CORBA spec to always include the Java serialVersionUID (as computed in assertions 2 and 3 above) in the RMI repository ID if the value is different than the OMG hash code (for which the algorithm is defined in CORBA formal 00-11-03 10.6.2) 5) It is not acceptable to leave off the SUID portion of the RMI repository ID if the serialVersionUID field is merely absent from the Java class Thank you, Everett Subject: Re: RMI repository ID references to serial version UID Date: Wed, 25 Apr 2001 22:01:34 +0100 From: Simon Nash Organization: IBM To: Everett Anderson CC: interop@omg.org Everett, I agree with all your assertions. Simon Everett Anderson wrote: > > Hi, > > I have another request for clarifications about the RMI repository ID: > > CORBA formal 00-11-03 10.6.2 states > > "If the actual serialization version UID for the Java class differs from > the hash code, a colon and the actual serialization version UID > (transcribed as a 16 digit upper-case hex string) shall be appended to > the RepositoryId after the hash code." > > Please comment on the following assertions. The CORBA spec is vague > here, and it has resulted in incompatible interpretations which must be > resolved quickly. > > 1) The "actual serialization version UID" mentioned is as defined in > the Java Object Serialization specification. > > http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100 > > Based on this Java specification and its note that "If the SUID is not > declared for a class, the value defaults to the hash for that class": > > 2) If a serialVersionUID field is defined in the class with the proper > modifiers, its value is used as the "actual serialization version UID" > mentioned in the CORBA spec > > 3) If a serialVersionUID field with the proper modifiers is not > explicitly defined in a class, its value is computed as explained in the > Java Object Serialization spec, and this computed value is used as the > "actual serialization version UID" mentioned in the CORBA spec > > 4) It is required by the CORBA spec to always include the Java > serialVersionUID (as computed in assertions 2 and 3 above) in the RMI > repository ID if the value is different than the OMG hash code (for > which the algorithm is defined in CORBA formal 00-11-03 10.6.2) > > 5) It is not acceptable to leave off the SUID portion of the RMI > repository ID if the serialVersionUID field is merely absent from the > Java class > > Thank you, > Everett -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Subject: Re: In RMI rep Id, when is inclusion of SUID legal? Date: Tue, 01 May 2001 18:17:39 -0700 From: Vijaykumar Natarajan Organization: Borland Software Corporation To: Simon Nash CC: Everett Anderson , interop@omg.org Hi simon, Simon Nash wrote: > > Questions: > > > > 1) Is it legal to include the serial version UID in the repository ID > > even when it is equal to the hash code? (Alternatively: Is it legal > > for an ORB to throw an exception/fail if the hash code and serial > > version UID in the repository Id are the same?) > > > Yes, it is legal to include the actual SUID even when it is identical to the > hash code, since there is nothing in the spec prohibiting this. Our ORB > always includes the actual SUID for serializable classes, even when it > happens to be the same as the hashcode, so it would cause interoperability > problems if some other ORB threw an exception in this case. That worries me a lot. Since this is a repository ID, having two repids be essentially equivalent will cause a lot of problems. I can see IR issues, cross language interop issues etc. We should pick and agree on one choice and mandate it. Vijay > > Simon > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England > Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb -- ------- --------------------------------------------------------------------- Vijaykumar Natarajan Sr. Software Engineer Borland Software Corporation Enterprise Business Unit Vijaykumar Natarajan Sr. Software Engineer Borland Software Corporation HTML Mail Enterprise Business Unit 951 Mariner's Island Blvd, Suite #400 Work: (650) 358 2412 San Mateo CA 94404 USA Additional Information: Last Name Natarajan First Name Vijaykumar Version 2.1 Subject: Re: In RMI rep Id, when is inclusion of SUID legal? Date: Tue, 01 May 2001 18:28:46 -0700 From: Everett Anderson To: Vijaykumar Natarajan CC: Simon Nash , interop@omg.org > That worries me a lot. Since this is a repository ID, having two repids > be essentially equivalent will cause a lot of problems. I can see IR > issues, cross language interop issues etc. We should pick and agree on > one choice and mandate it. Since the two algorithms are so different, the values will only be the same by coincidence. Why bother checking to see if they're the same since one must compute them both, anyway? It seems like such a rare case to check to save a few bytes on the wire. (As you can see, I favor just putting them both all the time since the line in the spec about leaving the Java one off just causes confusion. :)) - Everett Subject: Re: In RMI rep Id, when is inclusion of SUID legal? Date: Wed, 02 May 2001 10:56:12 -0700 From: Vijaykumar Natarajan Organization: Borland Software Corporation To: Everett Anderson CC: Vijaykumar Natarajan , Simon Nash , interop@omg.org, czhao@borland.com I don't have a strong preference either way. As long as there is only one repId given a class. Vijay Everett Anderson wrote: > > > That worries me a lot. Since this is a repository ID, having two repids > > be essentially equivalent will cause a lot of problems. I can see IR > > issues, cross language interop issues etc. We should pick and agree on > > one choice and mandate it. > > Since the two algorithms are so different, the values will only be the > same by coincidence. Why bother checking to see if they're the same > since one must compute them both, anyway? It seems like such a rare > case to check to save a few bytes on the wire. > > (As you can see, I favor just putting them both all the time since the > line in the spec about leaving the Java one off just causes confusion. > :)) > > - Everett -- ------- Don't forget to vote in JDJ Readers' Choice Awards: http://www2.sys-con.com/java/readerschoice2001 or vote for all Borland's nominations in one go: http://www.borland.com/jdjvote.html This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately and permanently delete the original and any copy of any e-mail and any printout thereof. --------------------------------------------------------------------- Vijaykumar Natarajan Sr. Software Engineer Borland Software Corporation Enterprise Business Unit Vijaykumar Natarajan Sr. Software Engineer Borland Software Corporation HTML Mail Enterprise Business Unit 951 Mariner's Island Blvd, Suite #400 Work: (650) 358 2412 San Mateo CA 94404 USA Additional Information: Last Name Natarajan First Name Vijaykumar Version 2.1 Subject: Re: In RMI rep Id, when is inclusion of SUID legal? Date: Thu, 03 May 2001 10:08:11 +0100 From: Simon Nash Organization: IBM To: Vijaykumar Natarajan , Everett Anderson CC: interop@omg.org, czhao@borland.com Vijay and Everett, I'm OK with making the SUID field mandatory for RMI-style repids of serializable classes (including externalizable classes). However, for non-serializable classes and interfaces, the spec currently requires the SUID to be omitted (since the concept of SUID is only defined for serializable classes) and I would not want to change this. Simon Vijaykumar Natarajan wrote: > > I don't have a strong preference either way. As long as there is only > one repId given a class. > > Vijay > > Everett Anderson wrote: > > > > > That worries me a lot. Since this is a repository ID, having two repids > > > be essentially equivalent will cause a lot of problems. I can see IR > > > issues, cross language interop issues etc. We should pick and agree on > > > one choice and mandate it. > > > > Since the two algorithms are so different, the values will only be the > > same by coincidence. Why bother checking to see if they're the same > > since one must compute them both, anyway? It seems like such a rare > > case to check to save a few bytes on the wire. > > > > (As you can see, I favor just putting them both all the time since the > > line in the spec about leaving the Java one off just causes confusion. > > :)) > > > > - Everett > > -- > ------- > Don't forget to vote in JDJ Readers' Choice Awards: > http://www2.sys-con.com/java/readerschoice2001 > or vote for all Borland's nominations in one go: > http://www.borland.com/jdjvote.html > > This e-mail, and any attachments thereto, is intended only for use by > the addressee(s) named herein and may contain legally privileged > and/or > confidential information. If you are not the intended recipient of > this e-mail, you are hereby notified that any dissemination, > distribution or copying of this e-mail, and any attachments thereto, > is > strictly prohibited. If you have received this e-mail in error, > please > immediately and permanently delete the original and any copy of any > e-mail and any printout thereof. -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Subject: Re: In RMI rep Id, when is inclusion of SUID legal? Date: Thu, 03 May 2001 10:39:00 -0700 From: Everett Anderson To: Simon Nash CC: Vijaykumar Natarajan , interop@omg.org, czhao@borland.com Hi, > I'm OK with making the SUID field mandatory for RMI-style repids of serializable > classes (including externalizable classes). However, for non-serializable classes > and interfaces, the spec currently requires the SUID to be omitted (since the > concept of SUID is only defined for serializable classes) and I would not want > to change this. I'm fine with that. Just curious, though, do you know why the SUID was allowed to be left off if it happens to be the same as the OMG hash? Was it merely to save space on the wire, or were there other reasons, too? - Everett Subject: Re: In RMI rep Id, when is inclusion of SUID legal? Date: Thu, 03 May 2001 23:33:01 +0100 From: Simon Nash Organization: IBM To: Everett Anderson CC: Vijaykumar Natarajan , interop@omg.org, czhao@borland.com Everett, Back in the mists of time, the hash algorithm was defined to be the same as the SUID algorithm. This meant that having the two numbers be the same was a very common occurrence, and it seemed worthwhile to optimize this to save space on the wire. Then later we discovered that the SUID algorithm was unsuitable as a hash because it doesn't include any superclass information. So we changed the hash algorithm to fix this but we didn't change the rule about the SUID being optional. Simon Everett Anderson wrote: > > Hi, > > > I'm OK with making the SUID field mandatory for RMI-style repids of serializable > > classes (including externalizable classes). However, for non-serializable classes > > and interfaces, the spec currently requires the SUID to be omitted (since the > > concept of SUID is only defined for serializable classes) and I would not want > > to change this. > > I'm fine with that. > > Just curious, though, do you know why the SUID was allowed to be left > off if it happens to be the same as the OMG hash? Was it merely to save > space on the wire, or were there other reasons, too? > > - Everett -- Simon C Nash, Chief Technical Officer, IBM Java Technology Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 18 May 2001 12:59:17 -0700 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja MIME-Version: 1.0 To: Juergen Boldt Subject: Re: issue 4283 -- Interop RTF issue References: <4.3.2.7.2.20010516130943.02536670@emerald.omg.org> <4.3.2.7.2.20010518142301.00c51c00@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: DM:!!,/7!!-<^d9>)Pd9 Hi, > Everett...have a look now... I looked at http://cgi.omg.org/issues/interop.html#Issue4280 The issue archive has been updated, but if possible, I'd like to have the proposed resolution text I wrote below incorporated somehow. Is there a 'proposed resolution' section? Proposed resolution ------------------- Require the Java serial version UID field for RMI repository IDs of Serializable and Externalizable classes by changing the wording in 10.6.2 (CORBA formal 00-11-03) as follows: Old: "If the actual serialization version UID for the Java class differs from the hash code, a colon and the actual serialization version UID (transcribed as a 16 digit upper-case hex string) shall be appended to the RepositoryId after the hash code." New: "For Serializable (including Externalizable) classes, the Java serialization version UID, transcribed as a 16 digit upper-case hex string, shall be appended to the RepositoryId following the hash code and a colon. The Java serialization version UID is defined in the Java Object Serialization Specification." Date: Wed, 27 Mar 2002 10:58:22 -0500 From: Tom Rutt Reply-To: tom@coastin.com Organization: Coast Enterprises LLC X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: orb-revision@omg.org CC: tom@coastin.com Subject: Issue 4280 Proposed Revision Content-Type: multipart/mixed; boundary="------------FA56779FB5CD45FB6A85ED69" X-UIDL: 3?Ie9Ok'!!+JDe9D:#e9 attached is a draft proposed resolution for Issue 4280 This is not for vote but for discussion at this time. -- ---------------------------------------------------- Tom Rutt email: tom@coastin.com Tel: +1 732 801 5744 Fax: +1 732 774 5133 Fujitsu Issue 4820: Potential problem using BiDir GIOP and codeset conversion service context (corba-rtf) Click here for this issue's archive. Source: ICL (Mr. Chris Wood, ) Nature: Clarification Severity: Significant Summary: I've just noticed there's a potential problem when using BiDir GIOP and the codeset conversion service context, or in fact any service context that has connection rather than request scope. Take the following example: A opens connection to B A issues request 1 (R1) with bidir SC, not codeset SC B processes R1, marking connection as bidir B processes R1, marking the connection as bidirectional. B invokes a callback object with a request (R2), this request does contain the codeset conversion service context, since B has noticed A has not set one for the request. A simultaniously issues another request (R3), this one does contain the codeset service context, however the codesets it selects are different. So we have a problem, which codesets should be used for the connection? The obvious solution is to force each direction to negotiate it's own character encodings, however this is not stated anywhere in the spec AFAICS. This problem will also occur for any connection specific state as set up by service contexts. Suggested resolution: add to the BiDir part of chapter 15 the following: "For any connection level state negotiated by exchange of service contexts, each direction of abidirectional connection should be negotiated independently. For example, the codeset negotiation process shall produce independent transmission codesets for each direction" Resolution: Each direction has to use the same TCS-C and TCS-W. This follows from the new rule from Issue 3318 resolution. Revised Text: none, accomodated by resolution to issue 3318 Actions taken: February 1, 2002: received issue