Re: unchecked conversion warning.
On 5/31/2012 4:23 PM, Jens wrote:
On Wed, 30 May 2012 07:54:33 -0700 (PDT), Robert Klemme<shortcutter@googlemail.com>
wrote:
On Wednesday, May 30, 2012 3:32:43 PM UTC+2, (unknown) wrote:
import java.util.Vector;
Another remark: it is usually recommended to not use Vector any more, because the synchronization overhead is unnecessary most of the time - unless some API forces you to. The proper replacement is ArrayList. If synchronization is needed then usually Collections.synchronizedList() will do.
Kind regards
robert
I used DefaultTableModel and Vector because it was the simplest and easiest way to get the
project up and running. And the Oracles tutorial is, even today (2012), still using this
approach without any remarks.
DefaultTableModel requires Vector; that's that. An alternative
would be to write your own TableModel, most likely by extending
AbstractTableModel (which already has default implementations for
most of what you'll need).
It would be silly to roll your own TableModel merely to avoid
using Vector. But if you already have your data in another form,
extending AbstractTableModel is pretty easy. If the data doesn't
all live in memory at once -- maybe it's backed by a data base, or
being supplied by a remote server, or arriving in real time --
then Vector can't hold it and DefaultTableModel is a non-starter.
By the yway, Vector has been 'retrofitted'. From the docs:
"As of the Java 2 platform v1.2, this class was retrofitted to implement the List
interface, making it a member of the Java Collections Framework".
There's nothing fundamentally wrong with Vector. People will
moan and wring their hands over the cost of its synchronized methods,
but I haven't heard of any actual measurements.
I would like to ty out what you suggest, but I have not been able to find an example where
JTable is used.
The Java Tutorial has some. Unfortunately, JTable is a bit on
the "overdecorated" or even "baroque" side, and some things about it
don't seem to be written down anywhere at all. This leaves you with
"Read the JTable source" or "Start with a JTable not too far from
what you want, and tweak until it's closer." Both approaches are
vulnerable to "It works, but does it rely on things that are
guaranteed to keep working, or only on peculiarities of the current
version?"
(JavaDoc is both a blessing and a curse: It's a blessing in that
developers *are* encouraged to write documentation, and it's a curse
in that *developers* are encouraged to write documentation. ;)
--
Eric Sosman
esosman@ieee-dot-org.invalid