Comment about JDK-8204458 - BigDecimal toString() return different value when use idea run and debug

Jaikiran Pai jai.forums2013 at
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!


> In this case core-libs-dev at
> 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 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 
>> 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