Issue 4319: Behavior of Java writeUTF/readUTF (java2idl-rtf) Source: Sun Microsystems (Mr. Everett Anderson, ) Nature: Uncategorized Issue Severity: Critical Summary: Java Serializable classes can define their own readObject/writeObject methods which take java.io.ObjectInputStream and java.io.ObjectOutputStream parameters, respectively. What is the proper behavior of the readUTF and writeUTF methods on these streams in RMI-IIOP? The Java to IDL specification doesn't mention these methods. Proposed resolution: In RMI-IIOP, java.io.ObjectOutputStream's writeUTF method should write a CORBA wstring. Similarly, readUTF should read a CORBA wstring. Discussion: One must override these methods to avoid using the internal java.io implementations. Looking at the JDK 1.3 code, the behavior is specific to Java serialization. If one doesn't override writeUTF and readUTF, Java serialization mechanisms such as blocks (similar to chunks) may be introduced on the wire in RMI-IIOP. Resolution: See revised text below Revised Text: In document ptc/00-12-03, replace the second last paragraph of section 1.4.10 as follows. Replace the existing text: Primitive Java types are marshaled as their corresponding IDL primitives (see Section 1.3.3, "Mappings for Primitive Types," on page 1-10). 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). by the new text: Primitive Java types are marshaled as their corresponding IDL primitives (see Section 1.3.3, “Mappings for Primitive Types,” on page 1-10). Java strings written by the java.io.ObjectOutputStream.writeUTF() method and read by the java.io.ObjectInputStream.readUTF() method are marshaled as IDL wstrings. 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). Actions taken: May 21, 2001: received issue October 3, 2001: closed issue Discussion: End of Annotations:===== X-Authentication-Warning: emerald.omg.org: hobbit.omg.org [192.67.184.3] didn't use HELO protocol Received: from patan.sun.com (192.18.98.43) by hobbit.omg.org asmtp(1.0) id 816; Fri, 18 May 2001 18:28:45 -0400 (EDT) Received: from taller.eng.sun.com ([129.144.251.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00482; Fri, 18 May 2001 16:23:50 -0600 (MDT) Received: from sun.com (d-ucup02-251-153 [129.144.251.153]) by taller.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22568; Fri, 18 May 2001 15:23:35 -0700 (PDT) Message-ID: <3B059FE6.37ABE11C@sun.com> Date: Fri, 18 May 2001 15:19:18 -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: java2idl-rtf@omg.org, issues@omg.org Subject: New Issue: Behavior of Java writeUTF/readUTF Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: WJ2e9TU$!!O%_!!E"Ae9 Hi, I'd like the following raised as an issue. Java Serializable classes can define their own readObject/writeObject methods which take java.io.ObjectInputStream and java.io.ObjectOutputStream parameters, respectively. What is the proper behavior of the readUTF and writeUTF methods on these streams in RMI-IIOP? The Java to IDL specification doesn't mention these methods. Proposed resolution: In RMI-IIOP, java.io.ObjectOutputStream's writeUTF method should write a CORBA wstring. Similarly, readUTF should read a CORBA wstring. Discussion: One must override these methods to avoid using the internal java.io implementations. Looking at the JDK 1.3 code, the behavior is specific to Java serialization. If one doesn't override writeUTF and readUTF, Java serialization mechanisms such as blocks (similar to chunks) may be introduced on the wire in RMI-IIOP. - Everett Date: Tue, 22 May 2001 10:21:28 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Juergen Boldt CC: issues@emerald.omg.org, java2idl-rtf@emerald.omg.org, ann_dalton@uk.ibm.com, caroline_maynard@uk.ibm.com, knutson@us.ibm.com, everett.anderson@sun.com Subject: Re: issue 4319 -- Java to IDL RTF issue References: <4.3.2.7.2.20010521153915.025c2100@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: cOL!!2AXd9e_m!!(d?e9 Juergen, I have received a request from Everett Anderson of Sun to clasify this issue as urgent because it impacts some forthcoming product releases from Sun. Since an urgent issue requires a default resolution, I'd like to use Everett's proposed resolution as the default resolution. Thanks. Simon Juergen Boldt wrote: > > This is issue # 4319 Everett Anderson > > Behavior of Java writeUTF/readUTF > > Java Serializable classes can define their own readObject/writeObject > methods which take java.io.ObjectInputStream and > java.io.ObjectOutputStream parameters, respectively. > > What is the proper behavior of the readUTF and writeUTF methods on these > streams in RMI-IIOP? The Java to IDL specification doesn't mention > these methods. > > Proposed resolution: > > In RMI-IIOP, java.io.ObjectOutputStream's writeUTF method should write a > CORBA wstring. Similarly, readUTF should read a CORBA wstring. > > Discussion: > > One must override these methods to avoid using the internal java.io > implementations. Looking at the JDK 1.3 code, the behavior is specific > to Java serialization. If one doesn't override writeUTF and readUTF, > Java serialization mechanisms such as blocks (similar to chunks) may be > introduced on the wire in RMI-IIOP. > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-781 444 0404 ext. 132 > 250 First Avenue, Suite 201 Fax: +1-781 444 0320 > Needham, MA 02494, USA Email: juergen@omg.org > URL: www.omg.org > > ================================================================ -- 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 X-Sender: andrew@192.67.184.65 Message-Id: In-Reply-To: <3B0A2F98.4A1D8BB9@hursley.ibm.com> References: <4.3.2.7.2.20010521153915.025c2100@emerald.omg.org> Mime-Version: 1.0 Date: Tue, 29 May 2001 18:25:06 +0100 To: Simon Nash From: Andrew Watson Subject: Re: issue 4319 -- Java to IDL RTF issue Cc: Juergen Boldt , java2idl-rtf@omg.org, ann_dalton@uk.ibm.com, caroline_maynard@uk.ibm.com, knutson@us.ibm.com, everett.anderson@sun.com Content-Type: text/plain; charset="us-ascii" X-UIDL: -:m!!9-]d9ZPd!!7!&!! Simon, You wrote: > I have received a request from Everett Anderson of Sun to clasify this > issue as urgent because it impacts some forthcoming product releases from > Sun. > > Since an urgent issue requires a default resolution, I'd like to use > Everett's proposed resolution as the default resolution. Sorry it's taken me so long to excavate down my mailbox to this issue. Yes, I'm happy to declare this issue as urgent. As you point out, we need a default resolution. Since the issue seems to be an omission to the specification, this resolution will presumably add new text to the spec, and not make any deletions. However, I do need the precise wording of this text, and the exact location and document where it should be added. Presumably the document is formal/99-07-59 (BTW, what's the status of applying the last RTF report (ptc/00-12-02) to create a new version of the spec)? So, assuming the text you need is some version of this: In RMI-IIOP, java.io.ObjectOutputStream's writeUTF method should write a CORBA wstring. Similarly, readUTF should read a CORBA wstring. ... please can you let me know exactly where it goes? If not, I'll suggest somewhere (and you don't want that :-). Thanks, Andrew Date: Tue, 29 May 2001 11:08:44 -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: Andrew Watson CC: Simon Nash , Juergen Boldt , java2idl-rtf@omg.org, ann_dalton@uk.ibm.com, caroline_maynard@uk.ibm.com, knutson@us.ibm.com Subject: Re: issue 4319 -- Java to IDL RTF issue References: <4.3.2.7.2.20010521153915.025c2100@emerald.omg.org> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: E24e9ZPXd9UZ!"!9\_!! Hi, > and not make any deletions. However, I do need the precise wording of this > text, and the exact location and document where it should be added. > Presumably the document is formal/99-07-59 (BTW, what's the status of > applying the last RTF report (ptc/00-12-02) to create a new version of the > spec)? I'm afraid I'm not quite familiar about the rules, here -- should text be added to the last formal document or the most recent ptc document? I'd say Java to IDL formal 99-07-63 if the former, or Java to IDL ptc 00-01-06 if the latter. Either way, I propose adding the following at the end of section 1.4.10, Custom Marshaling Format: --- The java.io.ObjectOutputStream writeUTF method should write a CORBA wstring. Similarly, the java.io.ObjectInputStream readUTF method should read a CORBA wstring. --- Unrelated note: At some point, I think the mapping needs to address ObjectInputStream.GetFields/ObjectOutputStream.PutFields, even though it does mention serialPersistentFields. I'm not sure if GetFields/PutFields were around when the spec was written, but it's vital that class evolution support is maintained. This becomes much more important beginning with Sun's J2SE 1.4 implementation since core classes such as java.math.BigInteger start using such features to maintain wire compatibility with older versions. We've updated our 1.4 RMI-IIOP implementation to handle these cases, but it might be good to explicitly mention it in the spec. In addition, we're going to try harder beginning later this year to make sure RMI-IIOP stays as compatible as possible with RMI/Java serialization. I believe some new features are being added on the Java side. - Everett Date: Tue, 29 May 2001 19:35:48 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Watson CC: Juergen Boldt , java2idl-rtf@omg.org, ann_dalton@uk.ibm.com, caroline_maynard@uk.ibm.com, knutson@us.ibm.com, everett.anderson@sun.com Subject: Re: issue 4319 -- Java to IDL RTF issue References: <4.3.2.7.2.20010521153915.025c2100@emerald.omg.org> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 0'!"!*'^!!([*e9-~2!! Andrew, The relevant document is ptc/00-12-03. I don't know when a formal document for the Java to IDL mapping will next be issued. Last time round, Linda Heaton did this. Is she still the person responsible for deciding the timing of formal document releases, or should I be initiating this process? For the default resolution, I'd like to propose replacing the second last paragraph of section 1.4.10 as follows. Replace the existing text: Primitive Java types are marshaled as their corresponding IDL primitives (see Section 1.3. type if the discriminator is false). by the new text: Primitive Java types are marshaled as their corresponding IDL primitives (see Section 1.3.3, 3 on page 1-10). Java strings written by the java.io.ObjectOutputStream.writeUTF() method and read by the java.io.ObjectInputStream.readUTF() method are marshaled as IDL wstrings. 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). Simon Andrew Watson wrote: > > Simon, > > You wrote: > > > I have received a request from Everett Anderson of Sun to clasify this > > issue as urgent because it impacts some forthcoming product releases from > > Sun. > > > > Since an urgent issue requires a default resolution, I'd like to use > > Everett's proposed resolution as the default resolution. > > Sorry it's taken me so long to excavate down my mailbox to this issue. > > Yes, I'm happy to declare this issue as urgent. As you point out, we need a > default resolution. Since the issue seems to be an omission to the > specification, this resolution will presumably add new text to the spec, > and not make any deletions. However, I do need the precise wording of this > text, and the exact location and document where it should be added. > Presumably the document is formal/99-07-59 (BTW, what's the status of > applying the last RTF report (ptc/00-12-02) to create a new version of the > spec)? > > So, assuming the text you need is some version of this: > > In RMI-IIOP, java.io.ObjectOutputStream's writeUTF method should write a > CORBA wstring. Similarly, readUTF should read a CORBA wstring. > > ... please can you let me know exactly where it goes? If not, I'll suggest > somewhere (and you don't want that :-). > > Thanks, > > Andrew -- 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: Tue, 29 May 2001 12:42: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: Simon Nash CC: Andrew Watson , Juergen Boldt , java2idl-rtf@omg.org, ann_dalton@uk.ibm.com, caroline_maynard@uk.ibm.com, knutson@us.ibm.com Subject: Re: issue 4319 -- Java to IDL RTF issue References: <4.3.2.7.2.20010521153915.025c2100@emerald.omg.org> <3B13EC04.50E74334@hursley.ibm.com> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: \Ne!!*ah!!^AJe9\^P!! Hi, I'm fine with Simon's proposed change. It fits the spec better. :) Please withdraw my proposed change in favor of his. Something else just occured to me -- if someone calls writeObject(Object) giving it a String instance, does that go to a IDL wstring or does it actually go into an abstract interface? - Everett > For the default resolution, I'd like to propose replacing the second last > paragraph of section 1.4.10 as follows. Replace the existing text: > > Primitive Java types are marshaled as their corresponding IDL primitives (see > Section 1.3.> 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). > > by the new text: > > Primitive Java types are marshaled as their corresponding IDL primitives (see > Section 1.3.3, 3 on page 1-10). Java strings > written by the java.io.ObjectOutputStream.writeUTF() method and read by the > java.io.ObjectInputStream.readUTF() method are marshaled as IDL wstrings. > 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). > > Simon > > Andrew Watson wrote: > > > > Simon, > > > > You wrote: > > > > > I have received a request from Everett Anderson of Sun to clasify this > > > issue as urgent because it impacts some forthcoming product releases from > > > Sun. > > > > > > Since an urgent issue requires a default resolution, I'd like to use > > > Everett's proposed resolution as the default resolution. > > > > Sorry it's taken me so long to excavate down my mailbox to this issue. > > > > Yes, I'm happy to declare this issue as urgent. As you point out, we need a > > default resolution. Since the issue seems to be an omission to the > > specification, this resolution will presumably add new text to the spec, > > and not make any deletions. However, I do need the precise wording of this > > text, and the exact location and document where it should be added. > > Presumably the document is formal/99-07-59 (BTW, what's the status of > > applying the last RTF report (ptc/00-12-02) to create a new version of the > > spec)? > > > > So, assuming the text you need is some version of this: > > > > In RMI-IIOP, java.io.ObjectOutputStream's writeUTF method should write a > > CORBA wstring. Similarly, readUTF should read a CORBA wstring. > > > > ... please can you let me know exactly where it goes? If not, I'll suggest > > somewhere (and you don't want that :-). > > > > Thanks, > > > > Andrew > > -- > 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: Tue, 29 May 2001 20:54:48 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Everett Anderson CC: Andrew Watson , Juergen Boldt , java2idl-rtf@omg.org, ann_dalton@uk.ibm.com, caroline_maynard@uk.ibm.com, knutson@us.ibm.com Subject: Re: issue 4319 -- Java to IDL RTF issue References: <4.3.2.7.2.20010521153915.025c2100@emerald.omg.org> <3B13EC04.50E74334@hursley.ibm.com> <3B13FB99.5F04CE11@sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ,NF!!9Ied9o?7!!?VZd9 Everett, Everett Anderson wrote: > > Hi, > > I'm fine with Simon's proposed change. It fits the spec better. :) > Please withdraw my proposed change in favor of his. > > Something else just occured to me -- if someone calls > writeObject(Object) giving it a String instance, does that go to a IDL > wstring or does it actually go into an abstract interface? > It goes to an abstract interface. The spec seems quite clear to me on this point. This is required so that RMI/serialization semantics for preserving sharing of String (and other) object instances is observed. 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 Date: Fri, 01 Jun 2001 12:31:42 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Watson CC: Juergen Boldt , java2idl-rtf@omg.org, ann_dalton@uk.ibm.com, caroline_maynard@uk.ibm.com, knutson@us.ibm.com, everett.anderson@sun.com, Mary Leland , vnatarajan@borland.com, Yoshitaka Honishi , jeff.mischkinsky@oracle.com, stefan.bauer@Eng.Sun.COM, Bob Scheifler Subject: Re: issue 4319 -- Java to IDL RTF issue References: <4.3.2.7.2.20010521153915.025c2100@emerald.omg.org> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: HYU!!=p>e9!]!!!dHhd9 Andrew, I assume that the reference below to the Interop RTF is a cut and paste error, since you also say that this issue will be voted on by the Java to IDL RTF. By copy to RTF members: I'd like to put forward Andrew's default resolution for vote by the Java to IDL RTF. If any member of the Java to IDL RTF objects to this or wants to propose amended wording, please let me know by close of business Monday. The current voting members of the Java to IDL RTF are: Simon Nash (IBM) Mary Leland (HP) Vijay Natarajan (Borland) Stefan Bauer (Sun) Yoshitaka Honishi (Fujitsu) Jeff Mischkinsky (Oracle) Simon Andrew Watson wrote: > > Simon, > > You wrote: > > > The relevant document is ptc/00-12-03. I don't know when a formal > > document for the Java to IDL mapping will next be issued. Last time > > round, Linda Heaton did this. Is she still the person responsible for > > deciding the timing of formal document releases, or should I be initiating > > this process? > > I'm checking with Juergen and Linda to see where we stand on this. > Meanwhile, we'll work from ptc/00-12-03. > > > For the default resolution, I'd like to propose replacing the second last > > paragraph of section 1.4.10 as follows. Replace the existing text: > > > > Primitive Java types are marshaled as their corresponding IDL primitives > > (see Section 1.3.3, "Mappings for Primitive Types," on page 1-10). 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). > > > > by the new text: > > > > Primitive Java types are marshaled as their corresponding IDL primitives > > (see Section 1.3.> > strings written by the java.io.ObjectOutputStream.writeUTF() method and > > read by the java.io.ObjectInputStream.readUTF() method are marshaled as > > IDL wstrings. 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). > > So be it. > > I am classifying Issue 4319 as Urgent, in accordance with procedure > described in section 4.4.1.5 of the P&P, available here: > > http://cgi.omg.org/cgi-bin/doc?pp > > You can find the thread of discussion on this issue here: > > http://www.omg.org/issues/issue4319.txt > > The issue will be voted on by the Java to IDL (December 2000) RTF. > > The default resolution will be the one quoted above. > > This default resolution will be applied to ptc/00-12-03 (the most recent > if and only if the Interop RTF fails to generate a resolution within 14 > days (i.e. by Thr 14th June). It is not necessarily the most desirable > resolution, and even if it is, the RTF should nevertheless vote on it > rather than allow it to be applied by default (so as to expedite the > process). > > As usual, I strongly recommend that any proposed resolutions aired on the > RTF mailing list continue to include the *EXACT* wording of proposed > amendments. > > Thanks, > > Andrew -- 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 3, Date: Fri, 01 Jun 2001 11:44:43 -0700 From: Vijaykumar Natarajan Subject: Re: issue 4319 -- Java to IDL RTF issue To: Simon Nash Cc: Andrew Watson , Juergen Boldt , java2idl-rtf@omg.org, vnatarajan@borland.com Message-id: <3B17E29B.AF676F4E@inprise.com> Organization: Borland Software Corporation MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en References: <4.3.2.7.2.20010521153915.025c2100@emerald.omg.org> <3B177D1E.80DC71A1@hursley.ibm.com> Content-Type: multipart/mixed; boundary="Boundary_(ID_Uxid9YgoL1CkTrBUYhZduw)" X-UIDL: ^Gdd9C/ > Andrew, > I assume that the reference below to the Interop RTF is a cut and paste error, > since you also say that this issue will be voted on by the Java to IDL RTF. > > By copy to RTF members: > > I'd like to put forward Andrew's default resolution for vote by the Java to IDL RTF. > If any member of the Java to IDL RTF objects to this or wants to propose amended > wording, please let me know by close of business Monday. > > The current voting members of the Java to IDL RTF are: > Simon Nash (IBM) > Mary Leland (HP) > Vijay Natarajan (Borland) > Stefan Bauer (Sun) > Yoshitaka Honishi (Fujitsu) > Jeff Mischkinsky (Oracle) > > Simon > > Andrew Watson wrote: > > > > Simon, > > > > You wrote: > > > > > The relevant document is ptc/00-12-03. I don't know when a formal > > > document for the Java to IDL mapping will next be issued. Last time > > > round, Linda Heaton did this. Is she still the person responsible for > > > deciding the timing of formal document releases, or should I be initiating > > > this process? > > > > I'm checking with Juergen and Linda to see where we stand on this. > > Meanwhile, we'll work from ptc/00-12-03. > > > > > For the default resolution, I'd like to propose replacing the second last > > > paragraph of section 1.4.10 as follows. Replace the existing text: > > > > > > Primitive Java types are marshaled as their corresponding IDL primitives > > > (see Section 1.3.3, "Mappings for Primitive Types," on page 1-10). 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). > > > > > > by the new text: > > > > > > Primitive Java types are marshaled as their corresponding IDL primitives > > > (see Section 1.3.> > > strings written by the java.io.ObjectOutputStream.writeUTF() method and > > > read by the java.io.ObjectInputStream.readUTF() method are marshaled as > > > IDL wstrings. 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). > > > > So be it. > > > > I am classifying Issue 4319 as Urgent, in accordance with procedure > > described in section 4.4.1.5 of the P&P, available here: > > > > http://cgi.omg.org/cgi-bin/doc?pp > > > > You can find the thread of discussion on this issue here: > > > > http://www.omg.org/issues/issue4319.txt > > > > The issue will be voted on by the Java to IDL (December 2000) RTF. > > > > The default resolution will be the one quoted above. > > > > This default resolution will be applied to ptc/00-12-03 (the most recent > > if and only if the Interop RTF fails to generate a resolution within 14 > > days (i.e. by Thr 14th June). It is not necessarily the most desirable > > resolution, and even if it is, the RTF should nevertheless vote on it > > rather than allow it to be applied by default (so as to expedite the > > process). > > > > As usual, I strongly recommend that any proposed resolutions aired on the > > RTF mailing list continue to include the *EXACT* wording of proposed > > amendments. > > > > Thanks, > > > > Andrew > > -- > 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 -- ------- 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. [] vnatarajan2.vcf 3, Date: Tue, 05 Jun 2001 17:19:39 +0100 From: Simon Nash Organization: IBM X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Mary Leland , vnatarajan@borland.com, Yoshitaka Honishi , jeff.mischkinsky@oracle.com, stefan.bauer@Eng.Sun.COM CC: java2idl-rtf@omg.org Subject: java2idl issue 4319 proposed resolution Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: (3a!!/kb!!*VY!!Yp+e9 The following proposed resolution for urgent issue 4319 will be in Java to IDL RTF vote 1 which I will send out shortly: In document ptc/00-12-03, replace the second last paragraph of section 1.4.10 as follows. Replace the existing text: Primitive Java types are marshaled as their corresponding IDL primitives (see Section 1.3.3, "Mappings for Primitive Types," on page 1-10). 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). by the new text: Primitive Java types are marshaled as their corresponding IDL primitives (see Section 1.3.strings written by the java.io.ObjectOutputStream.writeUTF() method and read by the java.io.ObjectInputStream.readUTF() method are marshaled as IDL wstrings. 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). 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