As I am interested in this class behaviour, I would like to know if someone was able to reproduce this bug because I was not. I tried to instanciate several Threads and passing them a BigInteger reference but nothing append.
Edit : Sorry for my name I forgot to change it after having seen the rules. Now it is done :-) [ December 22, 2005: Message edited by: James Stonert ]
Joined: Mar 22, 2005
Welcome to JavaRanch.
I glanced at the bug report, and it doesn't say how a BigInteger is supposed to be changed. As you point out, by their public API they're immutable. It's possible to change the fields the value is based on by using the reflection API, but I wouldn't say that that makes them thread-unsafe. And even final fields would not be safe from that.
But the bug was filed against a development version of Java 1.6, so I don't know what might be different in that compared to current production versions.
Can an object be interrupted during the call to its constructor ? IT would mean that one object that has been interrupted during the assignment to its final fields can be passed to one other Thread which will complete the assignment at its manner ?
Not usually. The only way in which some other thread could get a reference to an object whose constructor is still running, is if that constructor explicitly passes a reference to "this" to some other object. Example:But that isn't what that bug report says anyway. It is talking about different threads seeing a single instance differently because of the "Java memory model". If you want to know what that is all about, read chapter 17 of the Java Language Specification for yourself. It's certainly beyond my ability to explain that sort of thing. But on the other hand if you have real work to do, I would not worry about it too much.
Joined: Dec 22, 2005
I think that the bug can be reproduced by creating an object which encapsulates a BigInteger and instanciate this into its constructor. The Java Memory Model deals with the writing of final fields and their consequence.
It deals with the fact you were talking about, and I think that the bug is relative to the example shown at page 608 from the JLS.
I keep on testing this and will post in my topic later ;-)
Well, if you do produce bug-like behaviour then you should post the information on the bug database. What I saw there was just theoretical and didn't actually say the bug had ever occurred anywhere, so you would be providing useful information to them.
Joined: Dec 22, 2005
It seems that the problem comes from the fields used by a BigInteger to store differents values to avoid re-computing at each time.
I think it is a waste of time to try to reproduce the bug, because of the random and the rarity of Thread-based bugs.
Fields used to store some values cannot be set final, because they are assigned dynamically. So the first thing to do is certainly to synchronize all the methods that access to these fields.
Then, some fields are declared with the package visibility because they are used in other classes like BigDecimal for example. These fields cannot be set private to avoid modifying other implementations, but I think we need to synchronize the methods which write these fields too.
In conclusion, I think that the problem can be resumed into a synchronization from some methods of the class, and put a private modifier where we can.