I2JAV11 — Possible problem with IDL to Java mapping of fixed-point decimal types

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?

see below