Path: csiph.com!news.mixmin.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd4-1a99-0-5c4b-a959-e755-65cd.ipv6dyn.netcologne.de!not-for-mail
From: Patrick Roemer <sangamon@netcologne.de>
Newsgroups: comp.lang.java.programmer
Subject: Re: DefaultTableModel.getDataVector() and Java 11
Date: Wed, 3 Apr 2019 18:37:33 +0200
Organization: news.netcologne.de
Distribution: world
Message-ID: <q82ngd$u5p$1@newsreader4.netcologne.de>
References: <slrnqa9lo4.cfl.avl@logic.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 3 Apr 2019 16:37:33 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-1a99-0-5c4b-a959-e755-65cd.ipv6dyn.netcologne.de:2001:4dd4:1a99:0:5c4b:a959:e755:65cd"; logging-data="30905"; mail-complaints-to="abuse@netcologne.de"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0
In-Reply-To: <slrnqa9lo4.cfl.avl@logic.at>
Content-Language: en-US
Xref: csiph.com comp.lang.java.programmer:38848

Responding to Andreas Leitgeb:
> In Java up to 8  DefaultTableModel had a method  getDataVector()
> that returned a raw Vector.
> 
> My application's custom TableModel overrode the method to return
> a Vector<MyRowType>, where MyRowType provided direct type-safe
> accessors for each column.
> 
> In Java 11 it seems to have changed to returning a Vector of 
> raw Vectors.
> 
> At first glance this seems just goofy to me, because that doesn't
> really make it type-safe (it still involves a raw type), and it even
> prevents me from making it type-safe myself.
> 
> I hope, someone here can provide me with a second glance that
> clarifies the rationale behind the change.

API doc for this method in Java 8: "Returns the Vector of Vectors that
contains the table's data values." There's quite a few occurrences of
casts such as "(Vector)dataVector.elementAt(row)" in the
DefaultTableModel code, too.

So it seems that using another element type than Vector with
DefaultTableModel has never really been a safe option, and the change
only codifies to types what the contract has always been saying. Custom
[Abstract]TableModel to the rescue...

Best regards,
Patrick