Hi Andrew, thank you for the link, I will go through it tomorrow.
> http://www.cacr.math.uwaterloo.ca/hac/about/chap4.pdf > > I won't reproduce it all here, but please have a look. > >> Please don't feel bothered. It is only a technicality with no practical >> relevance. > > Sure. It's always worth examining one's assumptions, especially when it comes > to security. > >> BTW: I see that BigInteger attributes are non-final. Since the new memory >> model in >> Java 1.5, making them final would allow to pass instances of BigInteger to >> other >> threads without synchronization, so making all attributes final might be a >> good >> idea. > > That's an interesting point. Curiously, they're not final in OpenJDK either. > Yep, I assumed OpenJDK would use the semantics of final for all immutable objects since it is advertised in exactly this context: The semantics of final assure that we see the completely constructed object if the reference is published after completion of the constructor (initialization-safety). My statement was not accurate as we still need to synchronize in order to make sure that the reference will be seen by the other thread. A scenario where initialization-safety without synchronization is useful is, for instance, lazy evaluation, but only if accidently evaluating the same expression twice is harmless: This is the case for BigInteger and most other immutable objects. Second, I can only speculate about the performance costs of the semantics of final: I find it possible that the VM needs a memory fence under the hood but therefore can compensate by always keeping cache-local copies of final attributes. Could be that OpenJDK omitted initialization-safety here due to hidden performance issues.
