[omniORB] Interoperability problems with JacORB 1.4beta4

[Duncan Grisby]

On Thursday 15 August, Mike Mascari wrote:

[...]
> Unfortunately, Java's BigDecimal class knows its own scale, but not the
> number of digits. So a Java ORB conforming to the 2.3 OutputStream
> interface will generate:
> 
> 455000c
> 
> for "45.5000", not
> 
> 0000000000455000c
> 
> even though the IDL for the type is fixed<16,4>. Of course, unless the
> server ORB picks through the bytes until it arrives at either 0xc or
> 0xd, and then works its way backwards assuming the appropriate scale,
> there is no way for it to determine the number of digits in the data. Do
> you want to do this, Duncan? ;-)

Thanks for picking through the marshalled data -- saved me doing it.
I don't want to do what you suggest, because I've been here before.
See:

  http://cgi.omg.org/issues/interop.html#Issue4198

So JacORB is definitely wrong to behave the way it does.

This issue is relevant to the problem, too, covering the Java mapping
problem...

  http://cgi.omg.org/issues/interop.html#Issue3431

... resulting in the new write_fixed method:

> public void write_fixed(java.math.BigDecimal value, short digits, short
> scale);


Having said all that, it wouldn't be too hard to modify omniORB's
fixed point unmarshalling code to cope with the format JacORB sends,
so you might want to give that a go. In fact, I'll do it for you for a
suitable fee... :-)

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan@grisby.org     --
   -- http://www.grisby.org --