8

I know we have to use AWT thread for all table model update operations. Under the single AWT thread, any table model will be thread-safe. Why DefaultTableModel picks thread-safe Vector as its data stucture, which slower than other data structures like ArrayList?

user729309
  • 81
  • 1
  • 2

4 Answers4

7

Swing first appeared before Java 1.2, so before ArrayList was available. Unfortunately, the API for DefaultTableModel exposes the fact that it uses Vector, so changing it now would be backwardly incompatible.

This is exactly the kind of reason for thinking about encapsulation carefully - it lets you change the internals later on. (Admittedly getting serialization right would have been interesting, but that's a story for another day...)

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
5

Swing was available for, but not included in, Java 1.1. List/ArrayList was introduced in 1.2. Pity, because Swing could have done with a bit of extra time before locking down the API.

Tom Hawtin - tackline
  • 145,806
  • 30
  • 211
  • 305
2

The reason has already been explained above (Swing existed before java.util Collections library).

The bottom line is: never use DefaultTableModel but rather build your own (based on AbstractTableModel).

jfpoilpret
  • 10,449
  • 2
  • 28
  • 32
  • 4
    I disagree with the advice of never use DefaultTableModel. Only re-invent the wheel with AbstractTableModel when you have to. There are plenty of cases that using DefaultTableModel will not hurt. – jzd Apr 28 '11 at 13:31
  • 1
    @jzd Well, if you like defining a Vector of Vector of Object or an Object[][], then it's up to you, but you lack type-safety and code readability. In my whole life of Swing developer, I have never used DefaultTableModel (except for stupid code samples). Coding your own is straightforward, while using GlazedList does a much better work altogether. – jfpoilpret Apr 28 '11 at 13:36
  • 3
    @jzd, @jfpoilpret - mostly a matter of taste, there're pros and cons for both :-) It's not trivial (for starters) to implement a robust model. Most of the time it doesn't hurt, only looks sooo retro to simply use the default. My bottom line: use what is available until a custom implementation is really needed. – kleopatra Apr 28 '11 at 13:39
  • 1
    @jzd, i disagree with your advice :) A model should contain data in a usable domain specific format. A Vector of varying types, is not a proper model object. – MeBigFatGuy Apr 28 '11 at 13:39
  • 2
    @jfpoilpret, I agree if you don't have Object arrays or Vectors then DefaultTableModel is less appealing. My point that "never use" is too strong of a statement. – jzd Apr 28 '11 at 13:40
  • @kleopatra. How hard is a javabean? Frankly i think that maintaining a model object in a Vector to be significantly more difficult then a java bean. – MeBigFatGuy Apr 28 '11 at 13:41
  • @jzd OK, I could have said "avoid using it like the plague for your own sanity" ;-) – jfpoilpret Apr 28 '11 at 13:42
  • @MeBigFatGuy javabean (aside: assuming you mean a bean as of the beans spec, not the crippled construct used for java on a web-page) or not, it's not hard as such, it's the nofication that most custom implementations get wrong ;-) – kleopatra Apr 28 '11 at 13:46
  • I also recommend to create custom models, based on a list of MyObjects (OO approach) rather than using a vector of vector of Objects (data centric approach). Here is a simple read-only sample, I wrote some time ago: http://puces-samples.svn.sourceforge.net/viewvc/puces-samples/tags/sessionstate-1.0/sessionstate-suite/sessionstate-sample/src/blogspot/puce/sessionstate/sample/ParticipantTableModel.java?revision=13&view=markup – Puce Apr 28 '11 at 13:47
  • hey, hey... if many of us start leaving DefaultTableModel, and start using AbstractTableModel, then be prepared that the RemoveRow method is not easy! :D – gumuruh Apr 11 '12 at 09:54
1

I'm going to guess that the DefaultTableModel class was actually developed before The Collections Framework (which includes the ArrayList class) was introduced in Java -- therefore, the DefaultTableModel class wasn't implemented using the classes introduced as part of The Collections Framework.

Here are a few facts:

Furthermore, the use of a Vector as the underlying data structure by the DefaultTableModel class is an implementation detail, as the TableModel interface itself doesn't rely on the usage of a Vector.

coobird
  • 159,216
  • 35
  • 211
  • 226
  • Thanks for all the answers. I wish they could change the implementation in later version. – user729309 Apr 28 '11 at 13:51
  • @user729309 As a matter of fact, I'm not sure changing it to ArrayList instead of Vector would bring **dramatic** increase in performance (except if you have loads of rows but in this case, you already have a performance -and memory- problem anyway). – jfpoilpret Apr 28 '11 at 13:56
  • @jfpoilpret - without measuring it brings exactly zero increase ;-) – kleopatra Apr 28 '11 at 14:02