This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Where the attribute trusteeId is a long and result.getTrusteeId() is a BigDecimal. The result object is a CocoBase object, and populated by a CocoBase select.
So, this line worked on the Solaris box, and now does not work on the Linux box. The jre version on both machines is 1.5.0_07-b03 so this is not a jre version issue. Then in the API documentation for toString in BigDecimal it says this "The string produced for a given number is always the same; it is not affected by locale".
Then to confuse me even further, on my dev box, which is also Linux, and using the same version JRE, this works.
So I put some logs in, and this is what gets returned on the 3 different machines.
<blockquote>code:<pre name="code" class="core">System.out.println(result.getTrusteeId().toString()</pre></blockquote> Solaris box and my dev machine --> 1 New Test Linux box --> 0E+127
So my question. Why does this print 0E+127. Where could that possibly come from? I just need to understand why this is happening. Can anyone help please? ;-)
I agree with you Piet, and long before this post I has already changed it to that. That wasn't my question however. I'm trying to understand how on earth on these 3 different machines, it worked on 2 of them, and the other one not.
They are all 3 32 bit operating systems and cpu's (that's the level that i'm getting into now...) so still no joy. Can anyone explain why BigDecimal.toString will return 0E+127 (for the number '1' by the way) and then on 2 other machines, the actual number. In principle it doesn't make any sense. But there must be a reason why.
I was also going down that alley, and assumed that i did. So there is obviously something wrong with the CocoBase ORM and how it's matching a normal database NUMBER type to the class. The generated class has a BigDecimal as the match.
That said, it still doesn't explain why BigDecimal.toString returns 0E+127 in the 1 environment, and "1" in the other 2 enviroments. That's actually the part that i was hoping to get an answer on.
Joined: Jun 11, 2002
I have found out why this was happening. Very very interesting indeed.
This is apparently an oracle bug, with java 1.5. See this website. The problem here is even more scary than mine but highlights the bug quite nicely.
Basically, what was going wrong with mine was that I had 2 oracle drivers in my classpath, and in the 2 environments the classloader was loading 1.2 first, but in the new test environment the classloader got hold of 1.4 first.
And the 1.4 driver has a problem with new jdk1.5 changes to the way BigDecimal stores numbers, in that it case have negative exponant values.
Thanks all for the replies, have a lekker weekend.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com