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

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows XP [Version 5.1.2600]

A DESCRIPTION OF THE PROBLEM :
Every once in awhile when I run the application, JTextFields fail to allow any text entry. Keypresses appear to be ignored. After extensive investigation, it appears that the crux of the problem lies in the lack of any default action associated with the Keymap while executing JTextComponent.get(KeyStroke keyStroke).

The only possible cause seems like it would be a malfunction in JTextComponent.getKeymapTable(). Upon closer examination, it appears this method may be a case of the "lazy initialization without synchronization" anti-pattern. This method can be called from multiple threads because a "setUI" can activate it, and it is allowable to create new Swing components and set their UI from any thread until they are realized. I think calling it from two threads simultaneously could cause the default keymap to get set, initialized, then discarded and replaced with an empty one.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create JTextFields with many threads simultaneously. Occasionally, they will fail to allow any text entry, although the "delete" key still works.



REPRODUCIBILITY :
This bug can be reproduced occasionally.

---------- BEGIN SOURCE ----------

import javax.swing.*;
import java.awt.*;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.BrokenBarrierException;

/**
  * A class that reproduces a race condition when the first couple JTextField created are done
  * in parallel threads. I believe this is legal in Swing, but Swing contains some static
  * methods that perform unsynchronized lazy initialization, such as JTextComponent.getKeymapTable().
  *
  * My workaround for this, for now, is to always create one JTextField at static initialization time
  * and throw it away. That triggers all the Swing JTextField static initializers from a single
  * thread. (The same antipattern, and workaround, is present for MTextArea in Sun bug #6258268.)
  * Sun, ALWAYS synchronize lazy initialization!
  */
public class JTextFieldNoWorkie extends JPanel
{
   public static void main(String[] args)
   {
     JDialog dialog = new JDialog();
     dialog.setLayout(new BorderLayout());
     dialog.setModal(true);
     dialog.setPreferredSize(new Dimension(200,600));
     final JTextFieldNoWorkie rbbp = new JTextFieldNoWorkie();
     rbbp.init();
     dialog.add(rbbp);
     dialog.pack();
     dialog.setVisible(true);
     System.exit(0);
   }

   public JTextFieldNoWorkie()
   {
     super();
   }

   public void init()
   {
     for (int i = 0; i < THREAD_COUNT; ++i)
     {
       JTextFieldMaker runnable = new JTextFieldMaker();
       Thread thread = new Thread(runnable, "thread"+i);
       thread.start();
     }

     while (getAdded() < THREAD_COUNT)
     {
       // I'm not going to spend time worrying that this is a busy- wait antipattern.
       try {
         Thread.sleep(500);
       } catch (InterruptedException ex) {}
     }
   }


   private class JTextFieldMaker implements Runnable
   {
     public void run()
     {
       try {
         // Try to make it even more likely bug will occur by doing things at exactly the same time.
         // This line is not technically necessary for the bug to occur. JDK 1.5 only.
         // Note: MUCH more likely on SMP or SMT machines
         barrier.await();
       } catch (InterruptedException ex) {
         return;
       } catch (BrokenBarrierException ex) {
         return;
       }

       // It should be valid to create a Swing component on a non- Swing thread.
       final JTextField field = new JTextField(10);

// Uncomment the lines below and at the end of the block to do the add on the Swing thread instead.
// Bug still often happens, but may help disabmiguate the race condition(s).
// SwingUtilities.invokeLater(new Runnable()
// {
// public void run()
// {

             // It should be valid to add an unrealized Swing child to an unrealized parent
             // from a non-Swing thread,
             JTextFieldNoWorkie.this.add(field);

             // So we know when we're done...
             synchronized (addedSync)
             {
               added++;
             }

// });
     }
   }

   public int getAdded()
   {
     return added;
   }

   final Object addedSync = new Object();
   int added = 0;
   private static final int THREAD_COUNT = 20;
   private CyclicBarrier barrier = new CyclicBarrier(THREAD_COUNT);
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
No workaround found yet-- experimenting with overriding more methods and making them synchronized.

While progress is possible without this bug being fixed, the app is undeployable in its current state.