Comment about JDK-8204458 - BigDecimal toString() return different value when use idea run and debug
Jaikiran Pai
jai.forums2013 at gmail.com
Wed Jun 20 06:30:55 UTC 2018
On 20/06/18 11:49 AM, David Holmes wrote:
> Thanks for that analysis Jaikiran! Very helpful.
>
> I've added your mail in full as a comment on the JIRA issue.
Thanks David!
>
> BTW the best email list to comment on JBS issues is the one that
> corresponds to the bug category in JBS.
That's helpful, thank you!
-Jaikiran
> In this case core-libs-dev at openjdk.java.net
>
> Cheers,
> David
>
> On 20/06/2018 3:13 PM, Jaikiran Pai wrote:
>> (I don't have permissions to comment on the JIRA nor do I see a way
>> to submit a comment, as a casual observer, to a bug opened by someone
>> else through https://bugs.java.com/. So posting it here. I thought of
>> sending it to "discuss" list instead of this one, but this felt more
>> appropriate. I hope that's OK.)
>>
>> As noted in the JIRA https://bugs.openjdk.java.net/browse/JDK-8204458
>> the following simple code:
>>
>> public static void main(final String[] args) throws Exception {
>> final BigDecimal bd = new BigDecimal("1");
>> System.out.println(bd.toString());
>> }
>>
>> returns an "incorrect" output ("0") when run in debug mode with a
>> breakpoint in IntelliJ IDE. Apparently not reproducible in other
>> IDEs. I use IntelliJ, so gave it a quick try and indeed it does
>> return "0" in a specific scenario. What actually triggers this and
>> reproduces this, is the combination of 2 things:
>>
>> - The breakpoint has to be in the constructor of the BigDecimal class
>> (which is what the OP has done in that JIRA)
>> - The fact that the toString() implementation of this class uses a
>> "stringCache"
>>
>> What's really happening (in IntelliJ) is that when the IDE stops at
>> that breakpoint, i.e. when the class instance isn't yet fully
>> initialized, the IDE tries to render a IDE specific "Variables"
>> view/window, where it displays the object instance details. To do so,
>> it internally (in the background) appears to be triggering a
>> toString() call on that instance being displayed. Effectively, what's
>> happening is that the toString() implementation of this BigDecimal
>> class goes and builds up a "stringCache" using an
>> uninitialized/partially initialized state of this instance (which is
>> still not finished in its constructor) and ends up storing an
>> incorrect value of "0" to this "stringCache". As a result, the
>> subsequent calls to toString(), even after the object is fully
>> initialized return this incorrectly computed/cached value.
>>
>> This appears to be something the IntelliJ team might have to handle
>> better in their debug view/rendering, I guess. I see this as neither
>> specific to BigDecimal nor as a bug in this implementation. I believe
>> any similar class will run into similar problems for cases like these
>> where the instance isn't yet fully initialized to be presented in the
>> debug view.
>>
>> -Jaikiran
>>
>>
More information about the jdk-dev
mailing list