From: "Doug Felt" <###@###.###>
Date: Wed, 17 Oct 2001 16:24:28 -0700

While running some tests recently, we encountered a bug in
sun.nio.cs.ThreadLocalCoders.java version 1.3 01/09/30. The build I have
here is a few weeks out of date so this may have been fixed.

We were testing the thread-safe claims of Charset, and were failing because
of a NullPointerException. We spawn two threads each holding a reference
to a Charset, then each thread creates encoders and decoders and invokes
them. But we never get the encoders because of the NullPointerException:

java.lang.NullPointerException
     at
sun.nio.cs.ThreadLocalCoders$Cache.forName(ThreadLocalCoders.java:45)
     at sun.nio.cs.ThreadLocalCoders.encoderFor(ThreadLocalCoders.java:110)
     at java.nio.charset.Charset.encode(Charset.java:596)
[...]

ThreadLocalCoders creates two static caches for the encoders and decoders.
The Cache object uses a ThreadLocal to hold an array of the cached coders
for a particular thread. The Cache constructor is calling cache.set(new
Object[size])), to initialize the thread-local cache to the array. The
problem is, it's thread local, so only the thread in which the constructor
executes has a copy of the array. Cache.forName extracts the (thread
local) copy of the array, and immediately tries to use it. In threads
other than the one in which the constructor ran, this array is null, and
the attempt to use the null array throws the exception.

I experimented by modifying Cache to store the size in the constructor, and
in forName, check whether the returned array is null, and if so construct
the array of the requested size and initialize the cache. Ths ensures that
each thread that calls forName has its own copy of the array. This fixed
the problem that our test was encountering.