Platforms: WINDOWS 95, WINDOWS 98 (works correctly on NT, Win2000 and Solaris)

Java Versions: tested on 1.2.2 and 1.3.0

Customer has an AWT-based application "Wrapper" which needs to start a sub-application "Mapping Editor" in a separate sub-process. The "Mapping Editor" uses JFC/Swing. It may emit some diagnostic messages or errors which shall be displayed in an "output messages" Wrapper window. For this reason, the "Wrapper" listens to the "Mapping Editor's" output and error channels. It does this by starting two threads which read() on the input and error streams coming from the sub-process (see example listing).
This works fine on NT and Solaris. However, on WIN95 and WIN98, before starting any other Swing-based application (or after a reboot), the reading threads are not terminated at the "Mapping Editor's" exit, so the following "join()" statements to catch the thread terminations locks forever. This causes the "Wrapper" to hang. tThe "Wrapper"'s threads were monitored andit was seen that the reading threads are locked in FileInputStream.read() resp. FIleInputStream.readBytes().
Note that this behaviour is NOT reproducible if any other Swing-based application is run before! If the "Wrapper" is killed by hand and then rerun, the error is not reproducible. A diagnostic message is seen (NOT emitted by the customers code!) on WIN98 before locking up in the thread.join() calls; it says that a LoadLibrary call fails with an error status of "baaa0000" just prior to the lock.

(However, if the DLL is loaded by another Swing-based application, it does not need to be loaded or unloaded again, so the erroneous code is skipped????)
The error is not present if the sub-process uses AWT instead of Swing, so this must have to do with a Swing-specific component (DLL?).
The bug was tested on several WIN95 and WIN98 versions, e.g. WIN98 first and second version.