FULL PRODUCT VERSION :
java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b58)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b58, mixed mode, sharing)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows 2000 [Version 5.00.2195]


A DESCRIPTION OF THE PROBLEM :
java.math.BigInteger is supposed to be immutable.

Unfortunately, this is true only for single-threaded applications.

java.math.BigInteger is *not* thread-safe immutable. Given that its main fields are not declared as final, an instance constructed in one thread can be seen differently (not immutable) in another. This is true ven if the instance is fully constructed in the first thread before passing a reference to it to the second thread.

This is discussed in chapter 17 of the Java Language Specification, 3rd ed. about the Java memory model.

Because it is claimed that java.math.BigInteger is immutable, it is natural for programmers to use it without concerns about synchronizing access to instances. This can lead to security breaches in cryptographic software by accessing the same instance in more threads that see different values.




REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Short-term, for the clients of the API: use synchronization to make use of BigIntegers.

Long-term, for JDK developer: Rewrite BigInteger making the fields final and ensuring that it is fully thread-safe immutable.
Posted Date : 2005-11-10 06:17:43.0

N/A

Responding to a JDC comment on reproducing this problem, we have not been able to demonstrate this problem with the shipped jvm implementations.  The problem may arise in some potential jvm implementation that *could* exist but currently does not.
Posted Date : 2006-01-09 22:36:22.0

I believe with the work of 6622432 which is going to be in 6u14 and jdk 7, the thread-safety issue will be gone. First of all, in BigDecimal class, intVal is defined as "volatile" and it has the synmantic of montorexit which essntially flushes all the previous store to memory so that visibility will be guaranteed based on the new Java memory model. Second of all, in BigInteger, signum & magnitude fields are now defined as "final" which makes them perfect thread safe.
Posted Date : 2009-02-03 02:20:19.0

Can you give an example to reproduce the bug ? 

To be clear: this is not a JVM bug but a specification bug. To ensure that an instance is thread-safe immutable, it is necessary to declare the fields that are supposed to be unmodifiable as final. It is not a simple matter of source compilation: it impacts how the newer JVMs accesses the fields across threads as well.

As described thoroughly in http://java.sun.com/docs/books/jls/third_edition/html/memory.html#17.5 under "Discussion", it is important to declare a field as final if its ultimate value is to be read identically by all threads.

Before Java 5, final fields had no special JVM semantics during execution. Starting with Java 5, the JVM semantics of finals is defined to allow really thread-safe immutable classes.

As a matter of fact, all immutable fields of classes like String, Double, Integer, etc. have been declared as final starting with Java 5. Before, they were not declared final, (even if their value never changed outside constructors), because the former memory model didn't attach special semantics to final fields.

It may well happen that Sun's JVM implementation doesn't present any problem, but nevertheless the current BigInteger implementation is conceptually unsound.

It took years to redefine the new memory model and final fields were a hot topic. Thus, it is vital for immutable classes to have their fields declared final. With the advent of multicore cpus and multiprocessor machines, it will become even more important.

Thus, to ensure that BigInteger is really thread-safe immutable across *all* compliant implementations of the JVM, its immutable fields need to be declared final.

BTW, the reference to the particular JVM in the bug is present only because it is a required field in the submission form :-(