SWING or THREADS

I hava a big problem and I have no ideea what is happening.
I hava a class Server and a class Client. Both implement the same GUI and more each one implements a server or a client connection. If I run them directly everything is fine.
The problem is that I have another GUI from where I call them by pressing a button.
In this case only the JFrame apears but not also the content of the panels. The server-client connection is ok so the only problem appears at loading the GUI.
In the Server class I'm working with a ServerSocket and I'm calling the accept() method which it said to block a thread.
Also for a minisecond you almost can see the containt of the JFrame(the window).
PLSSSSSSSSSSs help me

start separate threads for the connection stuff. Also read up on SwingUtilities.invokeAndWait() or invokeLater()

Similar Messages

  • Creator Freeze Often -- SWING Worker thread also

    I'm developping an app with creator. And I have many freezes in several minutes long as some people mentioned before.
    I'm running win XP on an opeteron 244(1.8G) x2 , with 2G memory. I've updated creator to the latest updates, but it doesn't seem to be better.
    The things I found is that when I edit Session Bean , Creator takes especially long time to come up.
    At that time, SWING worker thread of Creator IDE also stopping, No update of display , I only look window frame.
    You know the SWING has a Single thread model ,so if some logic uses SWING worker's thread long time, all displying process will be stopped.
    Below is the stacktrace just after a few seconds when Creator freeze by editing Session Bean.
    I use the stacktrace tool at http://tmitevski.users.mcs2.netarray.com/trace.do
    Full thread dump Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode):
    "StackTrace Remote Thread" prio=5 tid=0x48b10418 nid=0x368 waiting on condition [0x00000000..0x4e85fbac]
    "Inactive RequestProcessor thread [Was:TimedWeakReference/org.netbeans.modules.projectapi.TimedWeakReference]" daemon prio=2 tid=0x48cc9e78 nid=0x634 in Object.wait() [0x4e89f000..0x4e89fbe8]
         at java.lang.Object.wait(Native Method)
         at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:692)
         - locked <0x1eeb8620> (a java.lang.Object)
    "Inactive RequestProcessor thread [Was:Default RequestProcessor/org.netbeans.modules.editor.NbEditorUI$2]" daemon prio=2 tid=0x48d00d18 nid=0x814 in Object.wait() [0x4e79f000..0x4e79fce8]
         at java.lang.Object.wait(Native Method)
         at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:692)
         - locked <0x1eeb8690> (a java.lang.Object)
    "Inactive RequestProcessor thread [Was:Java Children Provider/org.netbeans.modules.java.ui.nodes.elements.SourceChildren$4]" daemon prio=2 tid=0x48ce0d98 nid=0xd8c in Object.wait() [0x4e65f000..0x4e65fae8]
         at java.lang.Object.wait(Native Method)
         at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:692)
         - locked <0x1edbfe00> (a java.lang.Object)
    "Inactive RequestProcessor thread [Was:Suggestions Broker/org.netbeans.modules.tasklist.suggestions.SuggestionsBroker$2]" daemon prio=2 tid=0x473e1c80 nid=0x9fc in Object.wait() [0x4b84f000..0x4b84fbe8]
         at java.lang.Object.wait(Native Method)
         at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:692)
         - locked <0x1ed09d38> (a java.lang.Object)
    "Timer-48" prio=7 tid=0x492d4748 nid=0x930 in Object.wait() [0x4e43f000..0x4e43fa68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1eb90290> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-46" prio=7 tid=0x4831ede8 nid=0xff0 in Object.wait() [0x4e71f000..0x4e71fae8]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1ea9f428> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-44" prio=7 tid=0x48b26ab0 nid=0xc50 in Object.wait() [0x4e81f000..0x4e81fb68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1dc0d688> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-42" prio=7 tid=0x50f3bb68 nid=0x8f0 in Object.wait() [0x4e7df000..0x4e7dfa68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1db078b8> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-40" prio=7 tid=0x48bbde20 nid=0xf0c in Object.wait() [0x4e75f000..0x4e75f9e8]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1d85d2b8> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-38" prio=7 tid=0x50e67840 nid=0x8a4 in Object.wait() [0x4e6df000..0x4e6dfae8]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1d7bc160> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-36" prio=7 tid=0x48ba3f50 nid=0xf58 in Object.wait() [0x4e5df000..0x4e5dfd68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1d7bc1d8> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-34" prio=7 tid=0x48abb270 nid=0xee8 in Object.wait() [0x4e53f000..0x4e53fb68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1d339d68> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-32" prio=7 tid=0x47a6e050 nid=0xe98 in Object.wait() [0x4e69f000..0x4e69fa68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1b93e2e8> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-30" prio=7 tid=0x4925bd38 nid=0x9a8 in Object.wait() [0x4e4bf000..0x4e4bfa68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1b3022f0> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-28" prio=7 tid=0x4930aae8 nid=0x620 in Object.wait() [0x4b70f000..0x4b70fae8]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1af19770> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-26" prio=7 tid=0x485620c8 nid=0x120 in Object.wait() [0x4e59f000..0x4e59fb68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1978f0f8> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-24" prio=7 tid=0x46d7e9e8 nid=0xaf8 in Object.wait() [0x4e61f000..0x4e61fbe8]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x196f19e8> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "VCS Command Tasks Starter Loop" daemon prio=2 tid=0x48aeed00 nid=0x96c in Object.wait() [0x4e4ff000..0x4e4ffbe8]
         at java.lang.Object.wait(Native Method)
         - waiting on <0x18841770> (a org.netbeans.modules.vcscore.commands.CommandProcessor)
         at java.lang.Object.wait(Object.java:474)
         at org.netbeans.modules.vcscore.commands.CommandProcessor.executorStarterLoop(CommandProcessor.java:757)
         - locked <0x18841770> (a org.netbeans.modules.vcscore.commands.CommandProcessor)
         at org.netbeans.modules.vcscore.commands.CommandProcessor.access$700(CommandProcessor.java:65)
         at org.netbeans.modules.vcscore.commands.CommandProcessor$5.run(CommandProcessor.java:776)
         at java.lang.Thread.run(Thread.java:595)
    "Timer-16" prio=7 tid=0x46fa81a8 nid=0x69c in Object.wait() [0x4e3ff000..0x4e3ffd68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x151bf408> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "Timer-12" prio=7 tid=0x479eacf0 nid=0x2ec in Object.wait() [0x4b4df000..0x4b4dfce8]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.util.TimerThread.mainLoop(Timer.java:483)
         - locked <0x1499b4e8> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "URLdisplayer" prio=7 tid=0x4865de20 nid=0xe2c in Object.wait() [0x4727f000..0x4727fd68]
         at java.lang.Object.wait(Native Method)
         - waiting on <0x12a02bb0> (a org.netbeans.modules.extbrowser.NbDdeBrowserImpl$URLDisplayer)
         at java.lang.Object.wait(Object.java:474)
         at org.netbeans.modules.extbrowser.NbDdeBrowserImpl$URLDisplayer.getNextTask(NbDdeBrowserImpl.java:223)
         - locked <0x12a02bb0> (a org.netbeans.modules.extbrowser.NbDdeBrowserImpl$URLDisplayer)
         at org.netbeans.modules.extbrowser.NbDdeBrowserImpl$URLDisplayer.run(NbDdeBrowserImpl.java:235)
         at java.lang.Thread.run(Thread.java:595)
    "Text-Layout" prio=2 tid=0x475967e8 nid=0xa68 in Object.wait() [0x4b68f000..0x4b68fae8]
         at java.lang.Object.wait(Native Method)
         - waiting on <0x129e8cd0> (a org.netbeans.editor.view.spi.ViewLayoutQueue)
         at java.lang.Object.wait(Object.java:474)
         at org.netbeans.editor.view.spi.ViewLayoutQueue.waitForTask(ViewLayoutQueue.java:128)
         - locked <0x129e8cd0> (a org.netbeans.editor.view.spi.ViewLayoutQueue)
         at org.netbeans.editor.view.spi.ViewLayoutQueue$LayoutThread.run(ViewLayoutQueue.java:182)
    "MDR event dispatcher" daemon prio=2 tid=0x47b8b450 nid=0x9c8 in Object.wait() [0x4b88f000..0x4b88fa68]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at org.netbeans.mdr.util.EventNotifier$EventsDelivery.run(EventNotifier.java:257)
         - locked <0x087d1b10> (a java.util.LinkedList)
         at java.lang.Thread.run(Thread.java:595)
    "DestroyJavaVM" prio=5 tid=0x00038890 nid=0x4e4 waiting on condition [0x00000000..0x0007fae8]
    "TimerQueue" daemon prio=5 tid=0x46da6908 nid=0x768 in Object.wait() [0x4716f000..0x4716fb68]
         at java.lang.Object.wait(Native Method)
         at javax.swing.TimerQueue.run(TimerQueue.java:233)
         - locked <0x07b22b68> (a javax.swing.TimerQueue)
         at java.lang.Thread.run(Thread.java:595)
    "AWT-EventQueue-1" prio=7 tid=0x46ea8478 nid=0x990 runnable [0x4820e000..0x4820fbe8]
         at java.net.Inet4AddressImpl.getHostByAddr(Native Method)
         at java.net.InetAddress$1.getHostByAddr(InetAddress.java:842)
         at java.net.InetAddress.getHostFromNameService(InetAddress.java:532)
         at java.net.InetAddress.getHostName(InetAddress.java:475)
         at java.net.InetAddress.getHostName(InetAddress.java:447)
         at java.net.InetSocketAddress.getHostName(InetSocketAddress.java:210)
         at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:341)
         at java.net.Socket.connect(Socket.java:507)
         at java.net.Socket.connect(Socket.java:457)
         at java.net.Socket.<init>(Socket.java:365)
         at java.net.Socket.<init>(Socket.java:207)
         at com.mysql.jdbc.StandardSocketFactory.connect(StandardSocketFactory.java:142)
         at com.mysql.jdbc.MysqlIO.<init>(MysqlIO.java:280)
         at com.mysql.jdbc.Connection.createNewIO(Connection.java:1774)
         at com.mysql.jdbc.Connection.<init>(Connection.java:437)
         at com.mysql.jdbc.NonRegisteringDriver.connect(NonRegisteringDriver.java:268)
         at com.sun.rave.sql.DesignTimeDataSource.getConnection(DesignTimeDataSource.java:238)
         at com.sun.rave.sql.DesignTimeDataSource.getConnection(DesignTimeDataSource.java:214)
         at com.sun.sql.rowset.JdbcRowSetXImpl.connect(JdbcRowSetXImpl.java:410)
         at com.sun.sql.rowset.JdbcRowSetXImpl.prepare(JdbcRowSetXImpl.java:532)
         at com.sun.sql.rowset.JdbcRowSetXImpl.execute(JdbcRowSetXImpl.java:349)
         at caico.jsf.svc.itemSvc.<init>(itemSvc.java:81)
         at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
         at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
         at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
         at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
         at java.lang.Class.newInstance0(Class.java:350)
         at java.lang.Class.newInstance(Class.java:303)
         at com.sun.rave.insync.beans.BeansUnit.instantiateBean(BeansUnit.java:884)
         at com.sun.rave.insync.live.LiveUnit.ressurectDesignBean(LiveUnit.java:339)
         at com.sun.rave.insync.live.LiveUnit.resurrect(LiveUnit.java:406)
         at com.sun.rave.insync.live.LiveUnit.sync(LiveUnit.java:294)
         at com.sun.rave.insync.live.LiveUnitWrapper.sync(LiveUnitWrapper.java:115)
         at com.sun.rave.insync.models.FacesModel.syncImpl(FacesModel.java:899)
         at com.sun.rave.insync.Model.sync(Model.java:207)
         at com.sun.rave.insync.Model.sync(Model.java:173)
         at com.sun.rave.insync.ModelSet$WindowManagerPropertyRegistry.processNodes(ModelSet.java:107)
         at com.sun.rave.insync.ModelSet$WindowManagerPropertyRegistry.propertyChange(ModelSet.java:125)
         at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:333)
         at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:270)
         at org.netbeans.core.windows.RegistryImpl.doFirePropertyChange(RegistryImpl.java:249)
         at org.netbeans.core.windows.RegistryImpl.tryFireChanges(RegistryImpl.java:222)
         at org.netbeans.core.windows.RegistryImpl.selectedNodesChanged(RegistryImpl.java:186)
         at org.netbeans.core.windows.RegistryImpl.topComponentActivated(RegistryImpl.java:138)
         at org.netbeans.core.windows.WindowManagerImpl.notifyRegistryTopComponentActivated(WindowManagerImpl.java:893)
         at org.netbeans.core.windows.Central.setActiveMode(Central.java:182)
         at org.netbeans.core.windows.Central.userActivatedMode(Central.java:1451)
         at org.netbeans.core.windows.view.DefaultView.userActivatedModeView(DefaultView.java:591)
         at org.netbeans.core.windows.view.ui.TabbedHandler$ActivationManager.handleActivation(TabbedHandler.java:477)
         at org.netbeans.core.windows.view.ui.TabbedHandler$ActivationManager.eventDispatched(TabbedHandler.java:425)
         at java.awt.Toolkit$SelectiveAWTEventListener.eventDispatched(Toolkit.java:2206)
         at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2100)
         at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
         at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
         at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
         at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
         at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
         at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
         at java.awt.Toolkit$ToolkitEventMulticaster.eventDispatched(Toolkit.java:2099)
         at java.awt.Toolkit.notifyAWTEventListeners(Toolkit.java:2058)
         at java.awt.Component.dispatchEventImpl(Component.java:3867)
         at java.awt.Container.dispatchEventImpl(Container.java:2024)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4212)
         at java.awt.LightweightDispatcher.processMouseEvent(Container.java:3889)
         at java.awt.LightweightDispatcher.dispatchEvent(Container.java:3822)
         at java.awt.Container.dispatchEventImpl(Container.java:2010)
         at java.awt.Window.dispatchEventImpl(Window.java:1774)
         at java.awt.Component.dispatchEvent(Component.java:3803)
         at java.awt.EventQueue.dispatchEvent(EventQueue.java:463)
         at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
         at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
         at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
         at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
    "Creator Error Handler Listener" prio=5 tid=0x4665f3d8 nid=0xf70 runnable [0x481cf000..0x481cfce8]
         at java.net.PlainSocketImpl.socketAccept(Native Method)
         at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
         - locked <0x0793baf0> (a java.net.SocksSocketImpl)
         at java.net.ServerSocket.implAccept(ServerSocket.java:450)
         at java.net.ServerSocket.accept(ServerSocket.java:421)
         at com.sun.rave.errorhandler.DebugServerThread.run(DebugServerThread.java:81)
    "Java2D Disposer" daemon prio=10 tid=0x467d6760 nid=0xa08 in Object.wait() [0x46c8f000..0x46c8fce8]
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
         - locked <0x07451380> (a java.lang.ref.ReferenceQueue$Lock)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
         at sun.java2d.Disposer.run(Disposer.java:107)
         at java.lang.Thread.run(Thread.java:595)
    "Active Reference Queue Daemon" daemon prio=2 tid=0x467bb638 nid=0xb70 in Object.wait() [0x46c4f000..0x46c4fd68]
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
         - locked <0x07451408> (a java.lang.ref.ReferenceQueue$Lock)
         at org.openide.util.Utilities$ActiveQueue.run(Utilities.java:2465)
         at java.lang.Thread.run(Thread.java:595)
    "Timer-0" daemon prio=5 tid=0x4678f2f0 nid=0xaf0 in Object.wait() [0x46c0f000..0x46c0f9e8]
         at java.lang.Object.wait(Native Method)
         at java.util.TimerThread.mainLoop(Timer.java:509)
         - locked <0x07451498> (a java.util.TaskQueue)
         at java.util.TimerThread.run(Timer.java:462)
    "AWT-Windows" daemon prio=7 tid=0x467a54a0 nid=0x790 runnable [0x46a6f000..0x46a6fa68]
         at sun.awt.windows.WToolkit.eventLoop(Native Method)
         at sun.awt.windows.WToolkit.run(WToolkit.java:269)
         at java.lang.Thread.run(Thread.java:595)
    "AWT-Shutdown" prio=5 tid=0x467a5008 nid=0xafc in Object.wait() [0x46a2f000..0x46a2fae8]
         at java.lang.Object.wait(Native Method)
         - waiting on <0x07451568> (a java.lang.Object)
         at java.lang.Object.wait(Object.java:474)
         at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
         - locked <0x07451568> (a java.lang.Object)
         at java.lang.Thread.run(Thread.java:595)
    "CLI Requests Server" daemon prio=5 tid=0x4676b380 nid=0xa64 runnable [0x4693f000..0x4693fbe8]
         at java.net.PlainSocketImpl.socketAccept(Native Method)
         at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
         - locked <0x07451720> (a java.net.SocksSocketImpl)
         at java.net.ServerSocket.implAccept(ServerSocket.java:450)
         at java.net.ServerSocket.accept(ServerSocket.java:421)
         at org.netbeans.CLIHandler$Server.run(CLIHandler.java:758)
    "Low Memory Detector" daemon prio=5 tid=0x00ab83b8 nid=0xee0 runnable [0x00000000..0x00000000]
    "CompilerThread0" daemon prio=10 tid=0x00ab7020 nid=0x9c4 waiting on condition [0x00000000..0x465cfa4c]
    "Signal Dispatcher" daemon prio=10 tid=0x00ab6470 nid=0x31c runnable [0x00000000..0x00000000]
    "Finalizer" daemon prio=9 tid=0x00aa95e0 nid=0x85c in Object.wait() [0x4654f000..0x4654fa68]
         at java.lang.Object.wait(Native Method)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
         - locked <0x074519c0> (a java.lang.ref.ReferenceQueue$Lock)
         at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
         at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
    "Reference Handler" daemon prio=10 tid=0x00aa8150 nid=0xf1c in Object.wait() [0x4650f000..0x4650fae8]
         at java.lang.Object.wait(Native Method)
         at java.lang.Object.wait(Object.java:474)
         at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
         - locked <0x07451590> (a java.lang.ref.Reference$Lock)
    "VM Thread" prio=10 tid=0x00aa5780 nid=0x808 runnable
    "VM Periodic Task Thread" prio=10 tid=0x00ab9858 nid=0x1b0 waiting on condition

    Use a SwingUtilities.invokeLater(...) to invoke the main GUI. This will allow the button to repaint itself before the main GUI is invoked.

  • NullPointerException in BasicTableUI - Table updated in Swing worker thread

    I am getting following exception while updating a table :-
    java.lang.NullPointerException
    at javax.swing.plaf.basic.BasicTableUI.paintCell(BasicTableUI.java:1141)
    at javax.swing.plaf.basic.BasicTableUI.paintCell(BasicTableUI.java:1051)
    at javax.swing.plaf.basic.BasicTableUI.paint(BasicTableUI.java:974)
    at javax.swing.plaf.ComponentUI.update(ComponentUI.java:142)
    at javax.swing.JComponent.paintComponent(JComponent.java:541)
    at javax.swing.JComponent.paint(JComponent.java:808)
    at javax.swing.JComponent.paintWithOffscreenBuffer(JComponent.java:4771)
    at javax.swing.JComponent.paintDoubleBuffered(JComponent.java:4724)
    at javax.swing.JComponent._paintImmediately(JComponent.java:4668)
    at javax.swing.JComponent.paintImmediately(JComponent.java:4477)
    at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:410)
    at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run (SystemEventQueueUtilities.java:117)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:178)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:448)
    at java.awt.EventDispatchThread.pumpOneEventForHierarchy (EventDispatchThread.java:197)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy
    (EventDispatchThread.java:150)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:144)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:136)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:99)
    Since swing is not thread safe the table is updated in a swing worker thread. This should ensure that all gui updates are scheduled in the main event dispatching thread. Following is that code :-
    SwingWorker sw = new SwingWorker() {
    public Object construct()
    try{
    _myTable.updateUI();
    return null;
    }catch(Exception e){
    return null;
    public void finished(){
    sw.start();
    Inspite of doing these i am getting these exceptions.

    try using javax.swing.SwingUtilities.invokeLater(Runnable doRun)

  • Java swing and threading issue

    i am trying to update swing components from some thread. at my first try, i noticed this was a disaster. upon further research, i found out about the single-threaded model of swing events (i.e. event dispatching thread).
    i did more research and could NOT find a good example on how to update swing components from other threads. many examples were showing too much.
    can someone post a simple example on here? i just want to see how to properly update a swing component from a non-swing class using threading.

    I think its a simple example:
    http://forum.java.sun.com/thread.jspa?forumID=57&threadID=621226
    Let us know what you think.

  • Swings and Threads

    My applet communicates with the database. To ensure that the GUI is updated in the Event-Dispatching Thread I am using a SwingWorker: in construct() the application communicates with DB, and in finished() it updates the GUI. In construct() of the SwingWorker thread I need to create a dialog box to prompt the user for an input like to chose a color or to answer yes/no.
    My question is: Do I need to use invokeAndWait() to create the dialog box? The more general question is: do we use invokeLater() or SwingWorker only for GUIs that are shared by several threads or we have to use it for every swing we create after Event-Dispatching Thread started running?
    Thank you

    One of the fun things about Swing and its EventDispatchThread is that
    doing things wrong (such as performing Swing operations from a thread
    other than the EDT) is that more often than not, even though they are done
    technically wrong, they will still appear to work, especially in small programs.
    (In a larger sense, this applies to any multi-threaded program: things might
    appear to work until the timing changes just a teensy bit...)
    What's even more fun is working with someone who has previously only
    done small programs and because of that, takes this approach in large programs, and then spending a large amount of time trying to figure out why
    something sporadically stops working, only to trace it back to a Swing
    operation being invoked from a thread other than the EDT. Fun!
    You know how to do it correctly.
    You know why to do it correctly.
    But you choose not to. Good luck with that.

  • Problem when using swings with thread

    Hi,
    I am trying to read a database randomly and printing it in a jframe(using jtable and jscrollpane). I am continously checking the values in the database using a infinite do .. while .. loop. and printing the values in the JFrame. I am also making the main thread sleep for every 5 seconds. but when the thread resumes from sleep the JFrame gets the focus. This disturbs me a lot, because of this i am not able to use any other programs like (outlook or word). Kindly provide me a way to continously check the database and print values in the JFrame in the background without JFrame gaining the focus until i click on it.
    Regards
    Kishdude

    It's not clear where you actually tell the JFrame to display itself (usually setVisible(true).
    But this is a bit confused.
    If the first loop is, in fact, infinite then the table will never be created, since the rest of the code won't be reached.
    Don't create a new JTable each time you update the data. Update the existing one. You should define a method, somewhere, to load the table data from the database, call it once while building the window to load the initial values and then - once the window is displayed, set a loop or a Timer going to rescan the data periodically using the same code.
    There are serveral ways you can manage the table data. The key is the TableModel associated with the table. You can change the content of the TableModel or create a new one each time you read the data and use JTable's setModel method to replace it. Personally I'd write a subclass of AbstractTableModel or perhaps DefaultTableModel and put the code to scan the database, plus the data read, in there.
    There's not a lot of point in making the main thread wait once you've openned a window. The program won't exit while it has a window open. You can call setDefaultCloseAction() on the window and tell it to close the program when the close button is clicked. Or you can add a WindowAdapter to the window and deal with the close attempt yourself.
    And don't throw away exceptions in cache clause like you are, because you're never going to debug successfully if you do that. At the very least call printStackTrace() on the exception.
    So your sequence should be (roughly)
    Load the first batch of data into a TableModel.
    Build the window, using the TableModel to create your table.
    display the window.
    Start a background Thread which repeatedly waits a few seconds, then rereads the data into the table model, ensuring it calls the fireTableModelChanged() method of the model that requests that the table be redrawn.

  • Swing Multi-Thread Question. Is this safe?

    I want to use a Thread to get data from db and put it into my TableModel.
    This doesn't update the GUI directly but causes a fireTableChangedEvent... to be called which will ultimately cause the GUI to be updated.
    Question: Can I therfore use a plain Thread for this or must I use a SwingWorker?

    And now understand that a plain Thread is totally
    unnaceptable (which answers my original question),
    could you clarify the code below would be an
    alternative solution to my problem or if there is some
    reason why I MUST NOT use this:
    final SwingWorker worker = new SwingWorker()
    List data = null;
    public Object construct()
    data = dataFetcher.getDate();
    return null;
    public void finished()
    myTableModel.add(data);
    myTableModel.fireTableDataChanged();
    worker.start();
    Written this way, SwingWorker is fine, will update the model in the AWT thread.
    However, be careful of one thing: the code after worker.start() is executed immediately, which means concurrently with DataFetcher.getDate() and maybe before (or after) myTableModel.add(data).
    Of course this applies to who is calling the code above and so on.
    In other words you must be 100% certain that no application code is executed after worker.start() nor here nor up in the stack frames.
    Foxtrot will block there, guaranteeing you a correct behavior and no nasty surprises. Big gain in reducing complexity and improve mantainability IMHO.
    Simon

  • Are the APIs of java.swing.Timer thread-safe?

    As the title.

    They are safe for use with the event thread, as the actionPerformed method is invoked on the event thread,
    so you can make UI changes from your actionPerformed without fear.
    That is their only thread-related-ness, so other than that, I would think they are not thread safe in general.
    : jay

  • Thread in Swing help please

    Hey gang, I am relatively new to Java world, and especially to swing and thread. I am trying to build an application with a main dashboard, where the users can click on a button and parse a text file. However, if there were an error in the file, I would like to stop paring the file, but not exit the application once there is an error. I don?t know quite how to stop the process without using System.exit(0); When I use System.exit(0); needless to say my main dashboard exits also, which I want to avoid.
    I was told to use threads by my friends, but I trying reading up on SwingWorker class found on the website to help with threads (at least I think so). I am still very lost. If there is any more clarification needed, please let me know

    Your problem has nothing to do with threads. As "kulkarni_ash" wrote, you need to surround code which crashes with try{ }catch(Throwable t}{...}. Most runtime problems are reported by throwing an exception, which is understood as "abrubtly abort code execution and gracefully return to closest enclosing catch". There is many exceptions classes, each tided to specific kind of error. Throwable is most general one, and you should not use it usually.
    Threads, on other hand are used only, if you expect to have a lot of work to be done and like to have it done "in background" what leaves user interface alive. Example is printing - without thread user interface will freez until last page is printed - with printing thread user may click cancel to abort printing.

  • Threads updating Swing

    Hi. I noticed that when trying to add text to a textbox:
    myJTextArea.append("abc");From a Thread:
    loop 100 times{call append()
    }>
    My application hangs.
    But when I add an sleep:
    loop 100 times{call append()
    Thread.Sleep(10);
    }>
    It all works fine. Is this correct behavior?
    If it is: can I speed up without Sleep? (synchronize?)

    Might be you are creating some sort of deadlock. You might want to check out this recent thread to learn how to properly deal with Swing and threads:
    Event Dispatching Thread
    or read the appropriate chapter of the tutorial of course:
    http://docs.oracle.com/javase/tutorial/uiswing/concurrency/index.html

  • In this case, can I modify swing GUI out of swing thread?

    I know the Swing single thread rule and design (Swing is not thread safe).
    For time-consuming task, we are using other thread to do the task and
    we use SwingUtilities.invokeAndWait() or SwingUtilities.invokeLater (or SwingWorker) to update Swing GUI.
    My problem is, my time-consuming task is related to Swing GUI stuff
    (like set expanded state of a huge tree, walk through entire tree... etc), not the classic DB task.
    So my time-consuming Swing task must executed on Swing thread, but it will block the GUI responsivity.
    I solve this problem by show up a modal waiting dialog to ask user to wait and
    also allow user to cancel the task.
    Then I create an other thread (no event-dispatch thread) to do my Swing time-consuming tasks.
    Since the modal dialog (do nothing just allow user to cancel) is a thread spawn by
    Swing event-dispatch thread and block the Swing dispatch-thread until dialog close.
    So my thread can modify Swing GUI stuff safely since there are no any concurrent access problem.
    In this case, I broke the Swing's suggestion, modify Swing stuff out of Swing event-dispatch thread.
    But as I said, there are no concurrent access, so I am safe.
    Am I right? Are you agree? Do you have other better idea?
    Thanks for your help.

    If you drag your modal dialog around in front of the background UI, then there is concurrent access: paint requests in your main window as the foreground window moves around.

  • Threaded swing applet

    Hi,
    I need to write an applet that shows the results of a database query on a JTable.
    The query will be executed every second (only a few registers are retrieved from a mySQL db), and if a change is detected, the JTable must be updated.
    I've been reading about Swing and threads, and I know I must be careful when workin with threads on my GUI.
    So far, I know there exists a few methods to perform what I need, but I'm not shure which one would be the best for my app.
    The methods I'm considering are:
    - invokeLater or invokeAndWait
    - timer
    - SwingWorker
    What do you guys sugest and why ?
    Thanks

    Not sure of this, but I think you need both Timer (to query DB every second) and SwingUtilities.invokeLater (because your update task must be run outside of EDT)...
    Hope this helped a little,
    Regards.

  • Swing event queue, modal dialogs, event threads, etc...

    Hey all,
    So I am playing around with the focus manager, swing event thread and event queue, etc. Learned quite a bit. I am also playing around with test automation of our UI, using jfcUnit. I have written a few simple apps to play aorund with record/playback, coding tests, etc. What this thread is about though, is figuring out how modal and non-modal dialogs "take over" the event thread/queue? The reason I ask is, if I put a simple test harness like tool embeded in my app as a separate pop-up modal dialog, and from within it there is a GUI that I can use to select a "Test" to run. Now, when I run this test, jfcUnit needs to run on the main window, not within my non-modal dialog. What I am not sure of, however, is that if by using a non-modal dialog all events will go to the main event thread? I mean, I know if I mouse over my second non-modal frame (spawned from the application frame), that events will trigger for that dialog. I remember reading somewhere that modal dialogs "block" the main event queue, all left over events are given to the newly added event queue (presumably by the modal dialog) and existing left-over events get moved to the event queue. If that is the case, I am curious why events for the "old" queue are moved to the new queue if they were orginally intended for the old queue? I would think a "flush" before adding a new queue would be more appropriate so that the old queue can process all of its intended events.
    Now, I am just about to try this, but I am hoping a non-modal pop-up will not interfere with the jfcUnit running the UI of the main window. I am guessing, however, that it might. How are non-modal dialogs handled in terms of events and the event queue? Is it the same as modal dialogs? Or is there no blockage of the mainwindow event queue? If there is no blockage, than any sort of automation based on relative positions to a window may occur on the non-modal dialog, in which case it's best to hide the non-modal dialog during running of these tests.
    What are your thoughts, or better yet, knowledge of this topic? A decent explanation from a developer standpoint and not from the API's which dont give some of the more detailed info I am seeking is what I am hoping to get out of this.
    Thanks.

    Check this out. First, AWTListener has a LOT of
    different types you can register it for. I ORd all
    them together and when I ran my app, it took almost 30
    minutes for it to show up because of the huge stream
    of events being spit out via System.out. ...Yes, that doesn't surprise me in the least. There's hundreds of events that are fired around, usually unbeknownst to the user for every little thing. Lots of component and container events, in particular.
    Just make sure you OR ( using | not || ) ALL the
    "mask" values you want to watch for. That may be why
    you aren't seeing anything. When I did all that, and
    opened a menu, a ton of events came out.Maybe, I'll try that again, but I did specifically add an ActionEvent mask to get action events, and that should be all I need to get action events on buttons or menu items, and it wasn't getting them for either. It was only getting events on buttons when I used SwingEventMonitor, but not menu items.
    So I don't quite understand enough of the underlying event handling. Although, I suspect it could have something to do with the fact that these are Swing components, not AWT components (which their native peers) and it's pretty clear from AbstractButton (or was it DefaultButtonModel) how ActionEvents are fired, and they don't seem to have any connection to the code that deals with AWTListeners.
    My problem is that I kinda need a way to catch events without having a listener attached directly. Normally, I would have a listener, but there's this situation whereby an action may be triggered before I can get hold of the component to attach my listener to it. Perhaps I can get mouse press/release and just deal with it that way.
    Let me know if you did that and still didn't see what
    you were looking for. After playing with this, I am
    guessing the main reason for AWTListener is to
    register a listener for a specific type of event,
    instead of listening to them all, hence avoiding lots
    of extra overhead. Then again, the main event
    dispatcher must do a decent amount of work to fire off
    events to listeners of specific awt event types.Yes, it's definitely that. There's no point in sending events if no one is listening for it, so it does save some time.
    You are right, popup menus I think are dialogs, I
    don't know for sure, but you can access them via the
    JMenu.getPopupMenu() and JMenu.isPopupShowin().
    However, I am still not getting my test stuff working
    quite right.
    Yes, for menu popups. For a JPopupMenu on a right-click on any component (tree or whatever), I had a need to know about that from any arbitrary application (it's this GU testing app I'm working on), and since the popup menu doesn't belong to any component before it's shown, I couldn't necessarily know about it til it was displayed. I managed to use a combination of HierarchyEvents (using an AWTEventListener) and "component added" ContainerEvents. Not a simple matter, but it seems to work well.

  • How can I use the same thread to display time in both JPanel & status bar

    Hi everyone!
    I'd like to ask for some assistance regarding the use of threads. I currently have an application that displays the current time, date & day on three separate JLabels on a JPanel by means of a thread class that I created and it's working fine.
    I wonder how would I be able to use the same thread in displaying the current time, date & day in the status bar of my JFrame. I'd like to be able to display the date & time in the JPanel and JFrame synchronously. I am developing my application in Netbeans 4.1 so I was able to add a status bar in just a few clicks and codes.
    I hope somebody would be able to help me on this one. A simple sample code would be greatly appreciated.
    Thanks in advance!

    As you're using Swing, using threads directly just for this kind of purpose would be silly. You might as well use javax.swing.Timer, which has done a lot of the work for you already.
    You would do it something like this...
        ActionListener timerUpdater = new ActionListener() {
            public void actionPerformed(ActionEvent evt) {
                // DateFormat would be better, but this is an example.
                String timeString = new Date().toString();
                statusBar.setText(timeString);
                someOtherLabel.setText(timeString);
        new Timer(1000, timerUpdater).start();That code will update the time once a second. If you aren't going to display seconds, you might as well increase the delay.
    The advantage of using a timer over using an explicit thread, is that multiple Swing timers will share a single thread. This way you don't blow out your thread count. :-)

  • I have a doubt about The Single-Thread Rule

    The [url http://java.sun.com/docs/books/tutorial/uiswing/overview/threads.html#rule]Single Thread Rule states:
    Rule: Once a Swing component has been realized, all code that might affect or depend on the state of that component should be executed in the event-dispatching thread.
    I began to wonder about this because so much code seems to work just fine when it isn't executed in the event dispatching thread. Why are there exceptions? I went looking for some code which acted differently when executed on the event thread than when it was not. I found this
    http://forum.java.sun.com/thread.jsp?forum=57&thread=410423&message=1803725#1803725
    Now I started wondering why this was the case. What I found was that DefaultCaret adds a document listener to the document of the JTextComponent. In this listener, the insertUpdate() method specifically tests if it is running on the event dispatch thread and if it is, it updates the caret position.public void insertUpdate(DocumentEvent e) {
        if (async || SwingUtilities.isEventDispatchThread()) {
            // ... update the caret position ...
    }I then copied the code from DefaultCaret and made a MyCaret. I needed to tweek the code a little bit, but it ran. I removed the event thread test. It worked outside the event thread. There was a small difference in the results though. The textarea did not scroll all the way to the bottom. Almost, but not quite. I didn't test enough to make sure this was the only problem, but there was at least one problem.
    Now I started think about why this would be. The thought crossed my mind that the order of the events which were posted to the event queue were probably important. Sun found bugs when components were updated out of the event thread, so they essentially ignored events which weren't on the event thread and created the The Single-Thread Rule.
    A few days pass. I'm starting to wonder if Sun could have done a better job making Swing components thread safe. I also don't know that this specific case I found was the rule or the exception to the rule. But without insight into the design philosopy of Swing, I would have to examine all their components and see how they have written them and see if I can come up with a better design. That sound like a lot of work. Especially without getting paid for it.
    But wait a second, all you have to do is call the append() method of JTextArea on the event thread. If that is the case, why didn't they write the freakin component that way? Well, I'll try itclass MyTextArea extends JTextArea {
      public MyTextArea(int rows, int columns) { super(rows,columns); }
      public void append(final String text) {
        if (SwingUtilities.isEventDispatchThread()) super.append(text);
        else {
          SwingUtilities.invokeLater(new Runnable() {
            public void run() { myAppend(text); }
      private void myAppend(String text) { super.append(text); }
    }I change [url http://forum.java.sun.com/thread.jsp?forum=57&thread=410423&message=1803725#1803725]camickr's code to use a MyTextArea and it works fine without calling from the event thread. I've essentially moved The Single-Thread Rule to the component itself rather than relying on each and every one of the [url http://www.aboutlegacycoding.com/default.htm?AURL=%2FSurveys%2FSurvey6intro%2Easp]2.5 million Java programmers worldwide to use SwingUtilities.invaokeLater().
    Now for my question...
    Why didn't Sun do this?

    Swing is slow enough as it is. Lets not make it slower
    just
    because dense "programmers" don't know what they are
    doing.I agree with you in defending the current model, but aren't you a bit harsh there?!? ;-)
    Well, there are a number of not-so-dense programmers that expect such high-level components to be thread-safe. The question is worth asking whether Sun intentionally favor the explicit thread management for performance reasons, or whether this was an oversight.
    I'd go for the former (intentional) : indeed any GUI toolkit is inherently thread-based; there is always a distinction between the graphical thread(s) and the application threads - and the programmer always has to manage explicit thread creation to handle long-running event handlers without blocking the event dispatching thread. Extending thread concerns to the updating of components is therefore not a big move.
    So it seems fair that a core GUI toolkit does not hide thread issues (though to the best of my knowledge there is no such limitation in updating AWT components), or at least that's what Sun deemed.
    An ease-of-use-focused toolkit wrapping the core toolkit for thread-safety can be provided as a third-party product. Though I agree that wrapping the dozens of existing widgets and hundreds of methods is cumbersome - and the lack of such products probably shows it would have a low added value to trained developpers.
    Because your way is an extra method call and if
    statement, neither of which is necessary if you already know you
    are in the correct thread. Now count the number of methods
    which will need to be changed (and add up the extra cost).Indeed it's quite common to update several properties of several widgets in one bulk (when user clicks "OK", add a row to the table, change the title of the window, update status bar, re-enable all buttons, change some color,...).
    In this case explicit thread management doesn't spare one if but a dozen of redundant ifs!
    Note that there could have been if-less ways to cope for thread safety, such as creating a copy of the component's model when a change is made to a component, and switching the model only before paint() is called in the event-dispatching - of course coalescing all changes into the same "updated" model until paint() is called.
    But this would trade ease of use for redundant memory consumption, especially for some components with potentially huge models (JTree, JTable, JTextArea,...). And Swing appears to be already quite memory-greedy!

Maybe you are looking for