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

[Jaikiran Pai]

(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