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

Jaikiran Pai jai.forums2013 at
Wed Jun 20 05:13:50 UTC 2018

(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");

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 

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.


More information about the jdk-dev mailing list