 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / GUI / July 2005Table Mode & Thread
I understand all updates to any components state should be executed from with the event-dispatching thread only. What about updates to TableModel and other Model class? If update to Model class should also be handled in thread safe manner (I believe), then why is DefaultTableModel implemented by Vector? If updating your table model will be handled in a thread safe manner, why does DefaultTableModel uses a Vector of Vector for its default implementation? Isn't that an overkill? Am I wrong in making this observation? Thanks a lot for any help > I understand all updates to any components state should be executed > from with the event-dispatching thread only. What about updates to > TableModel and other Model class? Same thing. > If update to Model class should also be handled in thread safe manner > (I believe), then why is DefaultTableModel implemented by Vector? > If updating your table model will be handled in a thread safe manner, > why does DefaultTableModel uses a Vector of Vector for its default > implementation? Isn't that an overkill? Am I wrong in making this > observation? Swing was written for Java 1.1, which didn't have java.util.List. DefaultTableModel is more than implemented with Vector. It exposes Vectors in its API. So it cannot be upgraded to use a plain ArrayList. Unfortunately there are many APIs that use the old collections. Tom Hawtin  SignatureUnemployed English Java programmer Vector is *not* a deprecated class as implied by Mr. Hawtin. It is a synchronized collection class that will help prevent concurrent access type exceptions if the Vector is accessed by two separate threads. If you only have one thread that accesses your Vector, you might consider using ArrayList instead since this is lighter-weight and does not have the overhead of ensuring synchronized access. On a separate note, if you update your table model on a thread other than the AWT/Swing thread, you will need to make sure you place such code in a Runnable and make sure it is run on the Swing thread using SwingUtilities.invokeLater or SwingUtilities.invokeAndWait. The reason being that the DefaultTableModel fires property change events when you modify it and it does not do anything special to make sure these events are called on the AWT thread. You'll have to do that yourself. If you don't make provisions for this problem, you run the risk of deadlock between the AWT thread and one of your other threads. - Mike > Vector is *not* a deprecated class as implied by Mr. Hawtin. It is a I did not imply that. Your inference was incorrect. List and friends are known as the "new collections", therefore Vector and co-conspirators are old collections. > On a separate note, if you update your table model on a thread other > than the AWT/Swing thread, you will need to make sure you place such [quoted text clipped - 3 lines] > modify it and it does not do anything special to make sure these events > are called on the AWT thread. You'll have to do that yourself. As a point of pedantry, DefaultTableModel fires table model not property change events. Probably more likely than deadlocks are race conditions. However, you are less likely to catch those in testing. Tom Hawtin SignatureUnemployed English Java programmer Hello Tom and Mike Thanks for your help. Mike, you wrote: The reason being that the DefaultTableModel fires property change events when you modify it and it does not do anything special to make sure these events are called on the AWT thread. You'll have to do that yourself. Do you mean that when we modify the model, and the model fires a change event, the event is fired and handled on the thread that triggered the update? So, if I update the model with myThread, then the event firing and handling will be done on myThread? Thanks again for your help That is exactly what happens. If you go look at the source for AbstractTableModel, you'll see that when the model talks to its TableModelListeners, it is looping over the listeners and doing direct method calls. This all happens on the same thread. The way to avoid having the listeners notified on a thread different than the AWT thread is to update your table model on the AWT thread like I described before. - Mike Thank you Mike for your help! > That is exactly what happens. If you go look at the source for > AbstractTableModel, you'll see that when the model talks to its [quoted text clipped - 5 lines] > > - Mike Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.