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

[David Holmes]

Thanks for that analysis Jaikiran! Very helpful.

I've added your mail in full as a comment on the JIRA issue. You need to 
be an OpenJDK Author (and so have an OpenJDK user name) to comment 
directly in bugs.openjdk.java.net

BTW the best email list to comment on JBS issues is the one that 
corresponds to the bug category in JBS. 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
> 
>