Issue 1650: Boxed values need extension to write_Value call (obv-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: There"s a problem with the mapping to Java for boxed IDL values for non-primitive Java types, for example, a boxed string or a boxed sequence. The currently specified write_Value call doesn"t allow these to be marshalled correctly. Resolution: Revised Text: Actions taken: July 8, 1998: received issue July 30, 1998: closed issue Discussion: End of Annotations:===== Return-Path: Date: Wed, 08 Jul 1998 10:10:35 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: obv-rtf@omg.org Cc: issues@omg.org Subject: Boxed values need extension to write_Value call There's a problem with the mapping to Java for boxed IDL values for non-primitive Java types, for example, a boxed string or a boxed sequence. The currently specified write_Value call doesn't allow these to be marshalled correctly. First, let's review the mapping for the non-boxed case, i.e., a regular value containing a string. My IDL is: value valString { public string str; }; interface xx { void foo(in valString s); }; The stub code for foo calls write_Value passing s, which is an instance of valString. The OutputStream.write_Value code checks for possible sharing (there's none in this trivial example) then finds the helper for valString (valStringHelper) and calls its id() method to get the repository ID. The write_Value code writes this ID string to the stream, then calls the write method on the Helper class to marshal the contents of the value. In this case, the Helper's write method will just call write_String to write the string str. The Helper's write method returns to write_Value which will write the end tag for the value. In the skeleton, the process is reversed. The skeleton code for foo calls read_Value. The InputStream.read_Value code reads the repository ID from the stream, checks for a value factory (let's assume there's none), builds a Helper class name (valStringHelper) from the repository ID, then calls the Helper's read method. The Helper's read method creates an instance of valString, calls read_string to read the string, then assigns the string to the str field. The Helper's read method returns to read_Value which consumes the end tag for the value. Now suppose I have a boxed string. The mapping says that I get a Helper and Holder class for the boxed string but I do not get a "value" class. This is rather like how typedefs are handled by the Java mapping. So far so good. Now, let's look at how this boxed type is marshalled and demarshalled. My IDL is: value boxString string; interface yy { void foo(in boxString s); }; The stub code for foo calls write_Value passing s, which is an instance of java.lang.String (according to the mapping). The OutputStream.write_Value code checks for possible sharing (there's none) then needs to find the helper (boxStringHelper) so that it can call its id() method to get the repository ID. The problem is that there's no way to find the helper class from the information passed to write_Value (an instance of java.lang.String). The best approach seems to be to add a new overloaded write_Value method that takes a helper class object (which the stub can easily determine). The signature of this new method would be: public abstract void write_Value(java.io.Serializable obj, java.lang.Class helper); We could use this for the unboxed value case above, which would probably speed it up a little as it avoids the cost of finding the helper class based on the type of the value instance passed. In the skeleton, things work much as before. The skeleton code for foo calls read_Value. The InputStream.read_Value code reads the repository ID from the stream, checks for a value factory (let's assume there's none), builds a Helper class name (boxStringHelper) from the repository ID, then calls the Helper's read method. The Helper's read method just calls read_string and returns the result. The Helper's read method returns to read_Value which consumes the end tag for the value. Again it might be a useful optimization to add the Helper class object to the read_Value call rather than having read_Value compute it from the repID in the stream. It could check the repID to make sure this matches what's expected. Also, this would be necessary if we want to avoid the need for encoding the repID in the stream for every value, as we discussed last week. Simon -- Simon C Nash, IBM Java Technology Centre, Hursley, UK MailPoint 146, x245156 Tel. 01962 815156 or +44-1962-815156 Internet: nash@hursley.ibm.com Notes mail: Simon Nash@ibmgb