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.