Issue 1594: SerializationInputStream and SerializationOutputStream (java2idl-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: Summary: This item arises from the Java-to-IDL Mapping RFP, but is also of concern to the Objects By Value RTF because it affects the Java ORB implementation of Objects By Value. The currently specified delegation relationship between SerializationInputStream and SerializationOutputStream and their underlying ORB stream classes is inefficient and awkward. It is awkward because it requires the ORB implementation of the underlying streams to know about their "wrapper" serialization streams and to be careful to always pass out a reference to the wrapper instead of a "this" pointer. It is inefficient because all items (even primitives) that are written to these streams need to go through an extra delegation step through the wrapper class as the underlying stream does not know whether it can safely bypass the wrapper method. Resolution: Revised Text: Actions taken: June 29, 1998: received issue February 23, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Date: Mon, 29 Jun 1998 15:28:11 +0100 From: Simon Nash Reply-To: nash@hursley.ibm.com Organization: IBM To: java2idl-rtf@omg.org Cc: obv-rtf@omg.org, issues@omg.org Subject: SerializationInputStream and SerializationOutputStream This item arises from the Java-to-IDL Mapping RFP, but is also of concern to the Objects By Value RTF because it affects the Java ORB implementation of Objects By Value. The currently specified delegation relationship between SerializationInputStream and SerializationOutputStream and their underlying ORB stream classes is inefficient and awkward. It is awkward because it requires the ORB implementation of the underlying streams to know about their "wrapper" serialization streams and to be careful to always pass out a reference to the wrapper instead of a "this" pointer. It is inefficient because all items (even primitives) that are written to these streams need to go through an extra delegation step through the wrapper class as the underlying stream does not know whether it can safely bypass the wrapper method. There are a number of possible solutions to this problem: 1. Make the serialization stream classes non-final, but all their methods final. This allows ORB implementations to make subclasses of these streams and to add but not replace method implementations in the subclasses. 2. As 1, but make only some (or none?) of their methods final. This allows ORB implementations to make more efficient subclasses of these streams. 3. Use "reverse delegation" between the ORB streams and the serialization streams. With this approach, the read_Value and write_Value methods of the ORB streams would call methods on the serialization streams to read and write Java types that do not implement IDLEntity. They would make these calls in place of calls to the read and write methods of the Helper class for IDLEntity types. With this approach, the read and write methods of the serialization streams effectively become utility functions, and there is no need for separate instances of serialization stream objects to exist. 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