unchecked conversion warning.
 

This code compiles with an 'unchecked conversion' warning.
I have tried various corrections, for example casting like (Vector<Object>), but to no
avail.
What am I doing wrong?l
The code is the smallest demo I could make from the original application.

import java.util.Vector;
public class genericsdemo
{
private static Vector<Vector> vdata = new Vector<Vector>(); //a Vector of Vectors
private static Vector<Object> vrow = new Vector<Object>(); //a row

public static void main(String args[]) {
vrow.add(null); //two columns in the row
vrow.add(null);

vdata.add(vrow); //add the row to the Vector of Vectors

Vector vtmp = getrow(); //test
}

private static Vector<Object> getrow() {
return vdata.elementAt(0); //warning: [unchecked] unchecked conversion
}
}

JensJ

Re: unchecked conversion warning.
 

Jens <Jens> wrote:
> This code compiles with an 'unchecked conversion' warning.
> import java.util.Vector;
> public class genericsdemo
> {
> private static Vector<Vector> vdata = new Vector<Vector>(); //a Vector of Vectors

private static Vector<Vector<Object>> vdata = new Vector<Vector<Object>>(); //a Vector of Vectors

> private static Vector<Object> vrow = new Vector<Object>(); //a row
>
> public static void main(String args[]) {
> vrow.add(null); //two columns in the row
> vrow.add(null);
>
> vdata.add(vrow); //add the row to the Vector of Vectors
>
> Vector vtmp = getrow(); //test

Vector<Object> vtmp = ...

> }
>
> private static Vector<Object> getrow() {
> return vdata.elementAt(0); //warning: [unchecked] unchecked conversion

This is solved by changed vdata declaration above.

> }
> }
>
> JensJ

Re: unchecked conversion warning.
 

On Wed, 30 May 2012 13:48:29 +0000 (UTC), Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at>
wrote:

>Jens <Jens> wrote:
>> This code compiles with an 'unchecked conversion' warning.
>> import java.util.Vector;
>> public class genericsdemo
>> {
>> private static Vector<Vector> vdata = new Vector<Vector>(); //a Vector of Vectors
[snip]
>This is solved by changed vdata declaration above.
>
>> }
>> }
>>
>> JensJ

Thanks! (obvous now I see it).
JensJ

Re: unchecked conversion warning.
 

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

Re: unchecked conversion warning.
 

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.

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".

I would like to ty out what you suggest, but I have not been able to find an example where
JTable is used.

JensJ

Re: unchecked conversion warning.
 

(unknown) wrote:
> Robert Klemme wrote:
>> (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.

> 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.

So it's an old tutorial. That not only does not contravene Robert's advice,
he mentioned that you use 'Vector' when legacy code calls for it. So this
is one of those cases.

> 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".

And that is relevant because ...?

Note: Your comment doesn't address Robert's point in the slightest.

--
Lew

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

Re: unchecked conversion warning.
 

Eric Sosman wrote:
> 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.

For me the cost is measured by the Javadocs.

Synchronization - unnecessary for the 99%. Why have it?

This is a logical cost, not a temporal one. Why include
features you won't ever use? The burden of proof is on
the decision to use 'Vector', not the one to eschew it.

'Enumeration' and the other legacy methods and members:
Unnecessary except for legacy code that relied on 'Vector' to
start with.

Same argument.

The cost is in features you don't need and never will.

'ArrayList' is simpler, less decorated with unnecessary features,
and therefore better except when you need 'Vector'. Wrapped
in
<http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList(java.util.List)>
it's equivalent in all collections-compatible respects to 'Vector'.

So for new code 'Vector' is never necessary and always has stuff
you don't need. It's redundant. So just pick the one equivalent choice
with respect to stuff you do need, that is better with respect to the
stuff you don't need.

There's your measurement.

--
Lew

Re: unchecked conversion warning.
 

On 31.05.2012 22:50, Eric Sosman wrote:
> 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.

>> 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 wasn't mentioned in the original post. Then that's
the API case I mentioned (as has been stated already).

> 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.

You could argue whether it's worthwhile to synchronize every method.
Note that this does not automatically give thread safety out of the box
(concurrent iteration, multiple operations which need to be atomic) so
Vector could give you a false impression of thread safety. See Lew's
remarks also.

> (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. ;)

In what ways is that a curse? I would actually say that the weight
totally falls on the blessing side because JavaDoc together with modern
IDE makes the threshold so low to write documentation that there really
is not much of an excuse left to not do it. And documentation is important.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Re: unchecked conversion warning.
 

On 6/1/2012 2:14 AM, Robert Klemme wrote:
> On 31.05.2012 22:50, Eric Sosman wrote:
>>[...]
>> (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. ;)
>
> In what ways is that a curse? I would actually say that the weight
> totally falls on the blessing side because JavaDoc together with modern
> IDE makes the threshold so low to write documentation that there really
> is not much of an excuse left to not do it. And documentation is important.

First, don't overlook the smiley.

My point is simply that the people who write code are trained in
writing code, not necessarily in writing documentation. Meanwhile,
the people who are good at expository technical prose are quite often
not empowered to change the code. Result: You nearly always get
documentation (that's the blessing), but the quality thereof is a
crap-shoot (the curse).

As an example of what I consider unhelpful documentation, take
a look at java.io.PipedInputStream. We are told

"A pipe is said to be /broken/ if a thread that was
providing data bytes to the connected piped output
stream is no longer alive."

Does this make sense? Does it imply that a PipedOutputStream is
writable by one and only one Thread? Which Thread? Or, if it's
writable by many Threads, does it mean that the PipedInputStream
gets "broken" as soon as any one of those threads exits, even if
the others are still alive and writing? What, exactly, *does*
this statement mean? To me, it means "Use the Source, Luke" --
Which is where I'd have been were there no JavaDoc at all.

Finally, don't overlook the smiley.

--
Eric Sosman
esosman@ieee-dot-org.invalid