java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

We have an Client-/Server-Application, which starts Swing-Frames/Dialogs via
RMI on the client.

With JWS 1.0.1 there is a second AWT-Event-Queue-Thread, which is active, when
we enter text in a textfield. Therefore the EventQueue.isDispatchThread()-
Method returns wrong result (false), although we are in the Event-Dispatch-
Thread.
The funny effect is, that the Caret in the Textfield got a wrong position while
editing. The text goes from right to left. This is, because the DefaultCaret
checks for an Dispatch-Thread in DefaultCaret.insertUpdate(DocumentEvent e).

Using JRE 1.3.1 without JWS all works fine.

Here some trace information with JWS:
Creating View on Client - Current-Thread: Thread[RMI TCP Connection(4)-
10.3.24.202,5,RMI Runtime]
Creating View on Client - Dispatch-Thread: Thread[AWT-EventQueue-
1,6,javawsApplicationThreadGroup]
Creating View on Client - isDispatchThread: false

Editing Textfield - CurrentThread: Thread[AWT-EventQueue-
0,6,javawsApplicationThreadGroup]
Editing Textfield - Dispatch-Thread: Thread[AWT-EventQueue-
1,6,javawsApplicationThreadGroup]
Editing Textfield - isDispatchThread: false

Without JWS we got this:
Creating View on Client - Current-Thread: Thread[RMI TCP Connection(8)-
10.3.24.202,5,RMI Runtime]
Creating View on Client - Dispatch-Thread: Thread[AWT-EventQueue-0,6,main]
Creating View on Client - isDispatchThread: false

Editing Textfield - CurrentThread: Thread[AWT-EventQueue-0,6,main]
Editing Textfield - Dispatch-Thread: Thread[AWT-EventQueue-0,6,main]
Editing Textfield - isDispatchThread: true

Note, that without JWS there is only one Event-Dispatch-Thread. With JWS the
comparison in EventQueue.isDispatchThread: "return (Thread.currentThread() ==
eq.dispatchThread)" compares Thread[AWT-EventQueue-
0,6,javawsApplicationThreadGroup] with Thread[AWT-EventQueue-
1,6,javawsApplicationThreadGroup]. This returns false.

I'v tested it with jdk1.3.0 - 1.3.1.

Maybe it has something to do with the Bug 4429811 - Comment 2001-04-06.
Also there may be a dependence to the RMI-Thread, because it seems, that only
the Views created via the RMI-Thread are problematic.
(Review ID: 126456) 
======================================================================

N/A

This is fixed in javaws 1.0.1_02 by moving toolkit initialization to before 
starting new AppContext
  xxxxx@xxxxx   2002-01-17

I have a seemingly related issue with RMI and JWS using 
jre1.3.0_01 and jre1.3.0.  I have an rmi server callback to 
my client which was started with web start.  When the 
server calls the client, I do a textfield.setText and a 
button.setEnabled(false).  Neither of these actually show 
up, although they do execute.  If I do something to command 
the refresh, such as put a window over them, and then move 
the window away, the gui client will then refresh 
correctly...  Seems very related

In the meantime you can move your client update code into 
an invokeLater call. This executes the code on the correct 
thread.