Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is a JVM bug, BigDecimal is thread safe, but there's peculiarity of the java memory model that the ARM JVM is not honoring and thus the bug.


That's what my question is about. The OP claims "immutable implies thread-safe". My question is whether the spec promises that, and if so, where.

Reading https://docs.oracle.com/javase/7/docs/api/java/math/BigDecim..., I can see the class is immutable, but that page mentions neither "thread" nor "concurrent".

And yes, I think it has to define what it means by those terms before one can assume that seemingly obvious claim to be true. Reason? Both thread-safe and immutable are fairly vague terms that different readers can interpret differently. For example, BigDecimal is declared to be immutable, but, in the implementation being discussed, has a field that can get modified when one calls toString() on it.


Immutable implies thread safe. Somewhere in the concurrency section of Effective Java, it both that this is true and that documenting a class as immutable is good enough to document that it's thread safe.

Not sure if the spec lays it out, but it's a consequence of the spec.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: