Issue 3668: Possible problem with IDL to Java mapping of fixed-point decimal types (java-rtf) Source: SAP SE (Mr. Evan Ireland, eireland(at)sybase.com) Nature: Uncategorized Issue Severity: Summary: I'm wondering how other folks interpret the following section from CORBA 2.3.1 (for the CDR Transfer Syntax). 15.3.2.8 Fixed-Point Decimal Type The IDL fixed type has no alignment restrictions, and is represented as shown in Table 15-4 on page 15-13. Each octet contains (up to) two decimal digits. If the fixed type has an odd number of decimal digits, then the representation begins with the first (most significant) digit — d0 in the figure. Otherwise, this first half-octet is all zero, and the first digit is in the second half-octet — d1 in the figure. The sign configuration, in the last half-octet of the representation, is 0xD for negative numbers and 0xC for positive and zero values. I interpret this to mean that the encoded size of any given fixed-point decimal IDL type is determined statically according to the 'digits' and 'scale' in the fixed<digits,scale> IDL definition, rather than dynamically by the number of digits in the value to be encoded. Unfortunately if my interpretation is correct, there appears to be a problem in the IDL to Java mapping for fixed-point decimals, as we have in org.omg.CORBA.portable.OutputStream: public void write_fixed(java.math.BigDecimal value) ... Since a Java BigDecimal has a scale but no precision, I would think there would be a problem if the BigDecimal value "1.23" was to be encoded as a fixed<5,2>, since the write_fixed method has no 'digits' parameter, so it doesn't know the correct size for the CDR encoding. The 'read_fixed' method on the InputStream class has similar problems. Has anyone encountered this issue before, and if so what was the resolution? Resolution: see below Revised Text: In Section 21.4 and in the Source Code: Change org.omg.CORBA.portable.InputStream.read_fixed to /** @deprecated Deprecated by CORBA 2.4 */ java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed() { throw new org.omg.CORBA.NO_IMPLEMENT(); } java.math.BigDecimal org.omg.CORBA.portable.InputStream.read_fixed( short digits, short scale) { throw new org.omg.CORBA.NO_IMPLEMENT(); } Change org.omg.CORBA.portable.OutputStream.write_fixed to /** @deprecated Deprecated by CORBA 2.4 */ void org.omg.CORBA.portable.OutputStream.write_fixed(java.math.BigDecimal value) { throw new org.omg.CORBA.NO_IMPLEMENT(); } void org.omg.CORBA.portable.OutputStream.write_fixed( java.math.BigDecimal value, short digits, short scale) { throw new org.omg.CORBA.NO_IMPLEMENT(); } Add a new subsection at the end of Section 21.4.1: read_fixed The short parameters indicate the digits and scale of the fixed-point decimal. These parameters are needed because when the fixed is read off the stream, the BigDecimal can't be reconstructed to the original digits and scale without explicitly passing in the digits and scale. Add a new subsection at the end of Section 21.4.2: write_fixed The short parameters indicate the digits and scale of the fixed-point decimal. These parameters are needed because the information of the maximum number of digits and scale is lost when the IDL fixed is mapped to a BigDecimal for write_fixed. Actions taken: May 31, 2000: received issue February 27, 2001: closed issue Discussion: End of Annotations:===== Date: Wed, 31 May 2000 11:34:28 +1200 From: Evan Ireland Organization: Sybase, Inc. X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.object.corba CC: issues@omg.org Subject: Possible problem with IDL to Java mapping of fixed-point decimal types Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 X-UIDL: 1$-e9HH!!![d@!!o9k!! Hi, I'm wondering how other folks interpret the following section from CORBA 2.3.1 (for the CDR Transfer Syntax). 15.3.2.8 Fixed-Point Decimal Type The IDL fixed type has no alignment restrictions, and is represented as shown in Table 15-4 on page 15-13. Each octet contains (up to) two decimal digits. If the fixed type has an odd number of decimal digits, then the representation begins with the first (most significant) digit ration, in the last half-octet of the representation, is 0xD for negative numbers and 0xC for positive and zero values. I interpret this to mean that the encoded size of any given fixed-point decimal IDL type is determined statically according to the 'digits' and 'scale' in the fixed IDL definition, rather than dynamically by the number of digits in the value to be encoded. Unfortunately if my interpretation is correct, there appears to be a problem in the IDL to Java mapping for fixed-point decimals, as we have in org.omg.CORBA.portable.OutputStream: public void write_fixed(java.math.BigDecimal value) ... Since a Java BigDecimal has a scale but no precision, I would think there would be a problem if the BigDecimal value "1.23" was to be encoded as a fixed<5,2>, since the write_fixed method has no 'digits' parameter, so it doesn't know the correct size for the CDR encoding. The 'read_fixed' method on the InputStream class has similar problems. Has anyone encountered this issue before, and if so what was the resolution? ________________________________________________________________________________ Evan Ireland Sybase EAServer Engineering eireland@sybase.com Wellington, New Zealand +64 4 934-5856 Date: Fri, 03 Nov 2000 16:24:51 +0000 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: Ken Cavanaugh CC: java-rtf@omg.org Subject: Issue 3668 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: 'UDe93KJe9H(Td9h%&!! Ken, If there are any stubs calling the current APIs, aren't they already broken since the current APIs can't marshal the fixed value correctly? Simon -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb Date: Fri, 3 Nov 2000 09:59:29 -0800 (PST) From: Ken Cavanaugh Reply-To: Ken Cavanaugh Subject: Re: Issue 3668 To: nash@hursley.ibm.com Cc: java-rtf@omg.org MIME-Version: 1.0 Content-MD5: aPCiIBHWg/P63Z3oZRS3Ww== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.4p_5 SunOS 5.7 sun4u sparc Content-Type: TEXT/plain; charset=us-ascii X-UIDL: 6Y'e9)PQ!!l^*e9C3id9 >From: Simon Nash >X-Accept-Language: en >MIME-Version: 1.0 >To: Ken Cavanaugh >CC: java-rtf@omg.org >Subject: Issue 3668 >Content-Transfer-Encoding: 7bit > >Ken, >If there are any stubs calling the current APIs, aren't they already >broken >since the current APIs can't marshal the fixed value correctly? > Yes, that's true, but the problem is that we cannot remove such an API from the JDK. We can deprecate it, and add methods to fix the problem. The old deprecated methods still need to be present. This is really just another example of the discussion we have been having about get_interface (although there at least there is likely to be a small amount of code that cares about the old API). Ken. Date: Mon, 06 Nov 2000 21:26:02 +0000 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: Ken Cavanaugh CC: java-rtf@omg.org Subject: Re: Issue 3668 References: <200011031759.JAA16845@taller.eng.sun.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: ]>:!!*2*!!5@I!!I_k!! Ken, Whether or not the method is removed from the JDK seems a different issue from whether it is removed from the OMG specification. The issue is not quite the same as get_interface since at least the write_fixed method can be overloaded based on its parameter types to distinguish between the old and new versions. But I have no strong objection to retaining the old method in the OMG spec as deprecated and throwing NO_IMPLEMENT. Simon Ken Cavanaugh wrote: > > >From: Simon Nash > >X-Accept-Language: en > >MIME-Version: 1.0 > >To: Ken Cavanaugh > >CC: java-rtf@omg.org > >Subject: Issue 3668 > >Content-Transfer-Encoding: 7bit > > > >Ken, > >If there are any stubs calling the current APIs, aren't they already broken > >since the current APIs can't marshal the fixed value correctly? > > > > Yes, that's true, but the problem is that we cannot remove such an > API from the JDK. We can deprecate it, and add methods to fix the > problem. The old deprecated methods still need to be present. > This is really just another example of the discussion we have been > having about get_interface (although there at least there is likely > to be a small amount of code that cares about the old API). > > Ken. -- Simon C Nash, Technology Architect, IBM Java Technology Centre Tel. +44-1962-815156 Fax +44-1962-818999 Hursley, England Internet: nash@hursley.ibm.com Lotus Notes: Simon Nash@ibmgb