If you send BigDecimal(new BigInteger("0")) over the wire, the receiving JacORB fails with Zero length BigInteger. Problem is at CDRInputStream.java:897 read_fixed_internal() For 0 the CDR representation is 0C so (outBuffer.length() > 0 || c != 0) is false || false and the 0 gets ignored. 47 49 4F 50 01 02 00 01 00 00 00 0D 00 00 00 04 GIOP .... .... .... 00 00 00 00 00 00 00 00 0C .... .... . FINE read GIOP message of size 25 from ClientGIOPConnection to 172.20.6.163:61759 (1010058) java.lang.NumberFormatException: Zero length BigInteger at java.math.BigInteger.<init>(BigInteger.java:276) at java.math.BigInteger.<init>(BigInteger.java:451) at org.jacorb.orb.CDRInputStream.read_fixed(CDRInputStream.java:838) at demo.hello.FixedStructHelper.read(FixedStructHelper.java:41) at demo.hello._GoodDayStub.testFixed(_GoodDayStub.java:102) at demo.hello.Client.main(Client.java:65) To reproduce: struct FixedStruct { fixed<1,0> fnull; }; interface GoodDay { ... FixedStruct testFixed(in FixedStruct fs); }; return with new BigDecimal(new BigInteger("0"))
Fixed with SHA de510ce7b913a3b681a194c4b1c4cbeae0497289
The code still fails if called from the deprecated read_fixed() (which is called from stubs generated with -generate_helper deprecated) If called from read_fixed() digits is -1 and the condition of the new code is false. I think the core problem is in if (outBuffer.length() > 0 || c != 0) { outBuffer.append(c); } which is equivalent to if (c == 0) if (outBuffer.length() == 0) skip the character; I do not understand why this code is there.
I think it relates to some changes from PrismTech - there are existing tests e.g. test/regression/src/org/jacorb/test/orb/dynany/DynAnyFixedTest.java Can you provide a patch that fixes your scenario and doesn't break and preexisting tests?
It seems to work if you change your fix to if ((digits == 1 || digits == -1) && outBuffer.length() == 0)
I propose to add the digits == -1 condition and close the bug.
Done : SHA 163ee981f523a858e6ea1d0efed586c8d52faec4