My GUI gets stuck

Question

I have a very simple graphical application. The first two constructions are responsive and variations on the third not. The responsive code is very simple:
frame = new JFrame("Frame");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.pack();
frame.setVisible(true);or
frame = new JFrame("Frame");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setContentPane(new JPanel());
frame.pack();
frame.setVisible(true);The below example (and pretty much anything more complex) results in bad behavior:
frame = new JFrame("Frame");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setContentPane(new JButton("Button");
frame.pack();
frame.setVisible(true);In all cases I construct the GUI in a Runnable via (EventQueue/SwingUtilities).invokeLater(). Now for the circumstances. Prior to scheduling the Runnable I'm doing some JNI stuff with a USB device in Windows. I open my file handle to the USB driver which resets the device, I then send a protocol reset command and receive a reset response. Let's say I don't send the protocol reset. In this case all the examples work as expected- I can resize the frame, it responds to a close operation (top right 'X' or Alt + F4), any added elements respond to mouse clicks, etc. However, if I do send a protocol reset then only the 'frame' and 'frame & panel' versions work. I can adjust the window repeatedly to any size, maximize, minimize, etc., it always paints and the close operation is also responsive. The final case is when I send the reset and the frame is constructed with, say, a button. The button behavior is intermittent. Rollover changes to the button may work but then get stuck. Clicks may work but then no more. Resizing the frame will always do it in- you can still drag the edges to a different size but you see background painting gets all messed up. The added element no longer paints. Once it's hosed it will no longer accept a close operation- I need to manually kill the process.
Here's another tidbit. I thought maybe sending the reset was causing perhaps the thread in the driver wrapper library to go high priority or something. So I scheduled a Timer/TimerTask to execute some additional operations on the USB device at 2 and 20 seconds after the reset. I thought if the library thread was a problem then the timer shouldn't run. Well, upon both expiries the TimerTasks were able to run, sending commands and receiving events from the driver lib.
And if that wasn't enough, here's some more circumstantial evidence. This was awhile back but I was trying to couple this application (sans the GUI if I remember correctly) with some RMI. Admittedly I haven't done much with RMI but just enough to be familiar. I had a working example in one case and when I brought something equivalent into this workspace I would see an RMI call seemingly block (never return) on a call that shouldn't block. I don't have that part of the workspace in front of me but I really believe the method was non-blocking and should've returned.
So, I tried to give the executive summary. I can give more JNI details if you think it'll be useful. I don't see how sending the reset changes anything in the driver/library, because in both cases when it reaches steady state there's still a thread blocking on a read from the driver.
Any help you have will be greatly appreciated. Thanks. Jerry.
P.S. I'm using JDK/JRE 1.6.0 update 18.

Answer 1

That was the entire class, just not the entire .java file. I'm really not trying to make this any more difficult for you than it has to be. It's not compilable or runnable because you would need several other things: the .jar, the driver .dll, the driver .sys, and a Bluetooth dongle. My guess was this isn't necessary or even wise as you probably shouldn't install drivers from someone you don't know. I'm not even certain if I can attach such things to a post. So from my understanding it will be impossible for you to compile and run my setup if even one of those is missing. Therefore I'm asking if you can think of anything from what I've described that can lead to the problems I'm experiencing. For .java entirety:
package com.spongeminded.protocol.bluetooth.gui.test;
import com.spongeminded.protocol.bluetooth.BluetoothStack;
import com.spongeminded.protocol.bluetooth.stack.transport.UsbTransport;
import com.spongeminded.protocol.bluetooth.stack.transport.UsbTransportIdentifier;
import com.spongeminded.util.log.Logger;
import java.awt.EventQueue;
import java.io.IOException;
import java.util.Enumeration;
import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.UIManager;
public final class
BluetoothStackFrame
    private final JFrame frame;
    public
    BluetoothStackFrame()
        try
            UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
        catch (final Exception e)
            Logger.throwable(e);
        frame = new JFrame("Frame");
        frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frame.setContentPane(new JButton("Button"));
        frame.pack();
        frame.setVisible(true);
    public static void
    main(
        final String[] args)
        final Enumeration<UsbTransportIdentifier> enumeration;
        UsbTransportIdentifier usbTransportIdentifier;
        usbTransportIdentifier = null;
        enumeration = UsbTransportIdentifier.getIdentifiers();
        while ((null == usbTransportIdentifier) && (enumeration.hasMoreElements()))
            usbTransportIdentifier = enumeration.nextElement();
            if (!usbTransportIdentifier.path.contentEquals("\\\\?\\usb#vid_0a12&pid_0001#5&c7739ab&0&8#{00873fdf-61a8-11d1-aa5e-00c04fb1728b}"))
                usbTransportIdentifier = null;
        if (null != usbTransportIdentifier)
            try
                final UsbTransport usbTransport = usbTransportIdentifier.open();
                final BluetoothStack bluetoothStack = new BluetoothStack("", usbTransport);
                //SwingUtilities.invokeLater(new Runnable()
                EventQueue.invokeLater(new Runnable()
                    public void
                    run()
                        new BluetoothStackFrame();
            catch (final IOException e)
                Logger.throwable(e);
}Again, I verified that what I post here has the same problems as described. I changed it oh so slightly to make the point that simply commenting out 'final BluetoothStack bluetoothStack = new BluetoothStack("", usbTransport);' prevents the problems. Thank you for your input. Jerry.