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

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