Issue 5332: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID (java2idl-rtf) Source: Oracle (Mr. Everett Anderson, ) Nature: Uncategorized Issue Severity: Summary: I'd like to raise the following as an urgent issue for the Java to IDL RTF: The javax.rmi.CORBA.Stub class defined in the Java to IDL specification does not explicitly define its serialVersionUID, yet this value is crucial for interoperability. The sender's Stub repository ID must be compatible with that of the receiver. Without a standard value, even compiler differences can affect the serialVersionUID. In our case, we removed an unnecessary protected constructor before our J2SE 1.4.0 implementation shipped. Unfortunately, this broke interoperability with our (and others') previous implementations, and it is seriously affecting one of our customers. We would like to standardize the following (older) value so we can then patch our 1.4.0 implementation: Proposed resolution: Add the following serialVersionUID to the Stub class in Java to IDL (ptc-02-01-12) 1.5.1.2: // Java public abstract class Stub extends org.omg.CORBA_2_3.portable.ObjectImpl implements java.io.Serializable { private static final long serialVersionUID = 1087775603798577179L; ... } Resolution: Closed, accepted. See proposed revised text below Revised Text: Add the following serialVersionUID to the Stub class in Java to IDL (ptc-02-01-12) 1.5.1.2: // Java public abstract class Stub extends org.omg.CORBA_2_3.portable.ObjectImpl implements java.io.Serializable { private static final long serialVersionUID = 1087775603798577179L; ... } Actions taken: June 3, 2002: received issue December 11, 2002: closed issue Discussion: . End of Annotations:===== Date: Fri, 31 May 2002 14:44:18 -0700 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja To: andrew@omg.org, issues@omg.org, java2idl-rtf@omg.org Subject: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID Hi, I'd like to raise the following as an urgent issue for the Java to IDL RTF: The javax.rmi.CORBA.Stub class defined in the Java to IDL specification does not explicitly define its serialVersionUID, yet this value is crucial for interoperability. The sender's Stub repository ID must be compatible with that of the receiver. Without a standard value, even compiler differences can affect the serialVersionUID. In our case, we removed an unnecessary protected constructor before our J2SE 1.4.0 implementation shipped. Unfortunately, this broke interoperability with our (and others') previous implementations, and it is seriously affecting one of our customers. We would like to standardize the following (older) value so we can then patch our 1.4.0 implementation: Proposed resolution: Add the following serialVersionUID to the Stub class in Java to IDL (ptc-02-01-12) 1.5.1.2: // Java public abstract class Stub extends org.omg.CORBA_2_3.portable.ObjectImpl implements java.io.Serializable { private static final long serialVersionUID = 1087775603798577179L; ... } - Everett Date: Fri, 31 May 2002 23:55:21 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en To: Everett Anderson CC: andrew@omg.org, java2idl-rtf@omg.org Subject: Re: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID Everett, Since Stub is an abstract class, it is never serialized. Only instances of subclasses of Stub can be serialized. So how does adding a serialversionUID to this class help interoperability? Simon Everett Anderson wrote: > > Hi, > > I'd like to raise the following as an urgent issue for the Java to IDL > RTF: > > The javax.rmi.CORBA.Stub class defined in the Java to IDL > specification does not explicitly define its serialVersionUID, yet > this value is crucial for interoperability. The sender's Stub > repository ID must be compatible with that of the receiver. > > Without a standard value, even compiler differences can affect the > serialVersionUID. > > In our case, we removed an unnecessary protected constructor before > our J2SE 1.4.0 implementation shipped. Unfortunately, this broke > interoperability with our (and others') previous implementations, and > it is seriously affecting one of our customers. > > We would like to standardize the following (older) value so we can > then patch our 1.4.0 implementation: > > Proposed resolution: > > Add the following serialVersionUID to the Stub class in Java to IDL > (ptc-02-01-12) 1.5.1.2: > > // Java > public abstract class Stub > extends org.omg.CORBA_2_3.portable.ObjectImpl > implements java.io.Serializable { > > private static final long serialVersionUID = 1087775603798577179L; > > ... > } > > - 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, 31 May 2002 19:02:48 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID To: nash@hursley.ibm.com Cc: andrew@omg.org, java2idl-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc > Since Stub is an abstract class, it is never serialized. Only instances of > subclasses of Stub can be serialized. Stub implements Serializable, so it participates in serialization just like any other serializable superclass. It doesn't matter whether a serializable superclass is abstract or not. Note for example that Stub has readObject/writeObject methods. - Bob Date: Sat, 01 Jun 2002 00:09:27 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en To: Bob Scheifler - SMI Software Development CC: andrew@omg.org, java2idl-rtf@omg.org Subject: Re: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID Bob, I understand that, but the SUID that is part of the serialized stream is computed from the class of the instance being serialized, not from its superclasses. How does the SUID of an abstract superclass come into play? Simon Bob Scheifler - SMI Software Development wrote: > > > Since Stub is an abstract class, it is never serialized. Only instances of > > subclasses of Stub can be serialized. > > Stub implements Serializable, so it participates in serialization just > like any other serializable superclass. It doesn't matter whether a > serializable superclass is abstract or not. Note for example that Stub > has readObject/writeObject methods. > > - Bob -- 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, 31 May 2002 18:35:05 -0700 From: Everett Anderson X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf,ja To: Simon Nash CC: andrew@omg.org, java2idl-rtf@omg.org Subject: Re: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID > Since Stub is an abstract class, it is never serialized. Only instances of > subclasses of Stub can be serialized. That's absolutely correct, and I'm afraid it means I failed to question the conclusion I was given. I retract the request for the issue and apologize for the trouble! I'll dig further into exactly how the problem is being encountered. - Everett Date: Mon, 3 Jun 2002 10:12:24 -0400 (EDT) From: Bob Scheifler - SMI Software Development Reply-To: Bob Scheifler - SMI Software Development Subject: Re: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID To: nash@hursley.ibm.com Cc: andrew@omg.org, java2idl-rtf@omg.org X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.6_06 SunOS 5.8 sun4u sparc > How does the SUID of an abstract superclass come into play? For Stub, it should rarely come into play for normal IIOP marshalling, since stubs should be marshalled as IORs. However, I believe it will appear in the repid field of a ClassDesc if you marshal Stub.class itself, and I believe it will also appear in the repid of the type code for Stub (e.g., if you query up the type code tree of a subclass of Stub). It will also appear if you serialize an instance of a subclass of Stub class using a vanilla (non-IIOP) serialization stream or a JRMP marshal stream, since class descriptors for serializable superclasses appear in the serialization stream in those cases. - Bob From: "Everett Anderson" To: "Simon Nash" Cc: Subject: RE: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID Date: Mon, 17 Jun 2002 13:48:19 -0700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal Hi, We did eventually get the scenario straightened out. > Since Stub is an abstract class, it is never serialized. > Only instances of > subclasses of Stub can be serialized. So how does adding a > serialversionUID > to this class help interoperability? When users serialize stubs to files using Java Object Serialization or over RMI-JRMP, the serialVersionUID for javax.rmi.CORBA.Stub is checked. Various implementations of javax.rmi.CORBA.Stub probably have different serialVersionUIDs. At a minimum, we have different ones from our J2SE 1.3 to JDK 1.4 implementations due to trying to remove non-private methods that weren't in the spec code. Thus I would like to keep this issue open. Thanks, Everett > Everett Anderson wrote: > > > > Hi, > > > > I'd like to raise the following as an urgent issue for > the Java to IDL > > RTF: > > > > The javax.rmi.CORBA.Stub class defined in the Java to IDL > > specification does not explicitly define its serialVersionUID, yet > > this value is crucial for interoperability. The sender's Stub > > repository ID must be compatible with that of the receiver. > > > > Without a standard value, even compiler differences can affect the > > serialVersionUID. > > > > In our case, we removed an unnecessary protected > constructor before > > our J2SE 1.4.0 implementation shipped. Unfortunately, this broke > > interoperability with our (and others') previous > implementations, and > > it is seriously affecting one of our customers. > > > > We would like to standardize the following (older) value so we can > > then patch our 1.4.0 implementation: > > > > Proposed resolution: > > > > Add the following serialVersionUID to the Stub class in > Java to IDL > > (ptc-02-01-12) 1.5.1.2: > > > > // Java > > public abstract class Stub > > extends org.omg.CORBA_2_3.portable.ObjectImpl > > implements java.io.Serializable { > > > > private static final long serialVersionUID = > 1087775603798577179L; > > > > ... > > } > > > > - 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: Mon, 17 Jun 2002 22:00:21 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en To: Bob Scheifler - SMI Software Development CC: andrew@omg.org, java2idl-rtf@omg.org Subject: Re: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID Bob, Bob Scheifler - SMI Software Development wrote: > > > How does the SUID of an abstract superclass come into play? > > For Stub, it should rarely come into play for normal IIOP marshalling, > since stubs should be marshalled as IORs. However, I believe it will > appear in the repid field of a ClassDesc if you marshal Stub.class > itself, > Yes, I agree that it will appear here. However, it seems unlikely that this is the customer's problem. > and I believe it will also appear in the repid of the type code > for Stub (e.g., if you query up the type code tree of a subclass of Stub). > Do you mean a CORBA TypeCode? If so, I don't think this is correct since subclasses of Stub represent remote objects which all have repids with a hash code of zero and no SUID. > It will also appear if you serialize an instance of a subclass of > Stub class using a vanilla (non-IIOP) serialization stream or a > JRMP marshal stream, since class descriptors for serializable > superclasses > appear in the serialization stream in those cases. > When deserializing/unmarshaling, are all these SUIDs checked, or just > the one for the most-derived class? If they are all checked, then this > could explain why the customer is seeing a problem. If all SUIDs in the hierarchy are checked for Java deserialization and JRMP unmarshaling, then this raises the question of whether they should all be checked for IIOP unmarshaling. The current IIOP stream format doesn't allow this since only the SUID for the most-derived class is placed in the stream. Simon -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 Date: Mon, 17 Jun 2002 22:50:14 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en To: Everett Anderson CC: java2idl-rtf@omg.org Subject: Re: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID Everett, I just saw Bob's message on this as well as yours. Do you want to run a short cycle vote this week on this? If so, I will send the vote out tomorrow. Do any RTF members object to this proposal? Simon Everett Anderson wrote: > > Hi, > > We did eventually get the scenario straightened out. > > > Since Stub is an abstract class, it is never serialized. > > Only instances of > > subclasses of Stub can be serialized. So how does adding a > > serialversionUID > > to this class help interoperability? > > When users serialize stubs to files using Java Object Serialization or > over RMI-JRMP, the serialVersionUID for javax.rmi.CORBA.Stub is > checked. Various implementations of javax.rmi.CORBA.Stub probably > have different serialVersionUIDs. At a minimum, we have different > ones from our J2SE 1.3 to JDK 1.4 implementations due to trying to > remove non-private methods that weren't in the spec code. > > Thus I would like to keep this issue open. > > Thanks, > Everett > > > Everett Anderson wrote: > > > > > > Hi, > > > > > > I'd like to raise the following as an urgent issue for > > the Java to IDL > > > RTF: > > > > > > The javax.rmi.CORBA.Stub class defined in the Java to IDL > > > specification does not explicitly define its serialVersionUID, yet > > > this value is crucial for interoperability. The sender's Stub > > > repository ID must be compatible with that of the receiver. > > > > > > Without a standard value, even compiler differences can affect the > > > serialVersionUID. > > > > > > In our case, we removed an unnecessary protected > > constructor before > > > our J2SE 1.4.0 implementation shipped. Unfortunately, this broke > > > interoperability with our (and others') previous > > implementations, and > > > it is seriously affecting one of our customers. > > > > > > We would like to standardize the following (older) value so we can > > > then patch our 1.4.0 implementation: > > > > > > Proposed resolution: > > > > > > Add the following serialVersionUID to the Stub class in > > Java to IDL > > > (ptc-02-01-12) 1.5.1.2: > > > > > > // Java > > > public abstract class Stub > > > extends org.omg.CORBA_2_3.portable.ObjectImpl > > > implements java.io.Serializable { > > > > > > private static final long serialVersionUID = > > 1087775603798577179L; > > > > > > ... > > > } > > > > > > - 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 > > -- Simon C Nash, Chief Technical Officer, IBM Java Technology Hursley Park, Winchester, UK nash@hursley.ibm.com Tel. +44-1962-815156 Fax +44-1962-818999 From: "Everett Anderson" To: "Simon Nash" Cc: Subject: RE: Urgent issue: javax.rmi.CORBA.Stub serialVersionUID Date: Mon, 17 Jun 2002 14:57:10 -0700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal Hi, > I just saw Bob's message on this as well as yours. Do you > want to run a > short cycle vote this week on this? If so, I will send the > vote out tomorrow. Yes, please do, with the current proposed resolution of adding a private static final long serialVersionUID = 1087775603798577179L; field. Thanks, Everett > Do any RTF members object to this proposal? > > Simon > > Everett Anderson wrote: > > > > Hi, > > > > We did eventually get the scenario straightened out. > > > > > Since Stub is an abstract class, it is never serialized. > > > Only instances of > > > subclasses of Stub can be serialized. So how does adding a > > > serialversionUID > > > to this class help interoperability? > > > > When users serialize stubs to files using Java Object > Serialization or > > over RMI-JRMP, the serialVersionUID for javax.rmi.CORBA.Stub is > > checked. Various implementations of javax.rmi.CORBA.Stub probably > > have different serialVersionUIDs. At a minimum, we have different > > ones from our J2SE 1.3 to JDK 1.4 implementations due to trying to > > remove non-private methods that weren't in the spec code. > > > > Thus I would like to keep this issue open. > > > > Thanks, > > Everett > > > > > Everett Anderson wrote: > > > > > > > > Hi, > > > > > > > > I'd like to raise the following as an urgent issue for > > > the Java to IDL > > > > RTF: > > > > > > > > The javax.rmi.CORBA.Stub class defined in the Java to IDL > > > > specification does not explicitly define its > serialVersionUID, yet > > > > this value is crucial for interoperability. The sender's Stub > > > > repository ID must be compatible with that of the receiver. > > > > > > > > Without a standard value, even compiler differences > can affect the > > > > serialVersionUID. > > > > > > > > In our case, we removed an unnecessary protected > > > constructor before > > > > our J2SE 1.4.0 implementation shipped. > Unfortunately, this broke > > > > interoperability with our (and others') previous > > > implementations, and > > > > it is seriously affecting one of our customers. > > > > > > > > We would like to standardize the following (older) > value so we can > > > > then patch our 1.4.0 implementation: > > > > > > > > Proposed resolution: > > > > > > > > Add the following serialVersionUID to the Stub class in > > > Java to IDL > > > > (ptc-02-01-12) 1.5.1.2: > > > > > > > > // Java > > > > public abstract class Stub > > > > extends org.omg.CORBA_2_3.portable.ObjectImpl > > > > implements java.io.Serializable { > > > > > > > > private static final long serialVersionUID = > > > 1087775603798577179L; > > > > > > > > ... > > > > } > > > > > > > > - 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 > > > > > -- > Simon C Nash, Chief Technical Officer, IBM Java Technology > Hursley Park, Winchester, UK nash@hursley.ibm.com > Tel. +44-1962-815156 Fax +44-1962-818999 >