Tim Holloway wrote:the object "pointer" for a constructed object doesn't exist in the application code space until the constructor method is complete and therefore there's nothing to pass to any other thread until it is.
Unless someone can provide me with an explicit indication in the language spec that construction is not an atomic operation I'm going to be adamant about this.
but from the outside, an atomic operation has to act like it was done in the sequence it was coded, regardless.
Think of what would happen within a thread if you took the classic 3-statement swap: x=a; a=b; b=x and made it so that the movements ocurred in random order. It would be useless. Similarly. an object is not an object until it's completely an object. The JVM does not simply allocate object memory and then immediately return it before it runs the constructor.
Tim Holloway wrote:Unless someone can provide me with an explicit indication in the language spec that construction is not an atomic operation I'm going to be adamant about this.
3. Make all fields final. This clearly expresses your intent in a manner that is enforced by the system. Also, it is necessary to ensure correct behavior if a reference to a newly created instance is passed from one thread to another without synchronization, as spelled out in the the memory model [JLS, 17.5; Goetz06, 16].
Mike Simmons wrote:
And this would not be protected - containsPerson could still throw an NPE because mySet is null. Probably not, yes. But it can.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koophttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton