unchecked conversion warning.

[Jens]

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

 

[Andreas Leitgeb]

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

This is solved by changed vdata declaration above.

 

[Jens]

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

 

[Robert Klemme]

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

 

[Jens]

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

 

[Lew]

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.

 

[Eric Sosman]

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.

 

[Lew]

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.

 

[Robert Klemme]

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

 

[Eric Sosman]

[...]
(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.

 

[Robert Klemme]

[...]
(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.

I didn't but I was curios what you meant by that.

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

Right, still often mediocre docs are better than no docs. I agree that a lot of people in the software industry can use some training when it comes to writing documentation (either in code or separate in office document formats).

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.

"broken" is not a property of the stream which can be learned via a method of the API so the comment is really only of limited usefulness.

Finally, don't overlook the smiley.

Huh, what smiley?

Cheers

robert

 

[Jim Janney]

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

If I ever found myself screening applicants for a programming job (not
something that's ever likely to happen) I would be very tempted to ask
them to write a short essay. If you can write clearly then I know you
can think clearly too.

 

[Stefan Ram]

If I ever found myself screening applicants for a programming job (not
something that's ever likely to happen) I would be very tempted to ask
them to write a short essay. If you can write clearly then I know you
can think clearly too.

»I've found that some of the best [Software ]developers
of all are English majors. They'll often graduate with
no programming experience at all, and certainly without
a clue about the difference between DRAM and EPROM.

But they can write. That's the art of conveying
information concisely and clearly. Software development
and writing are both the art of knowing what you're going
to do, and then lucidly expressing your ideas.«

http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html

»Besides a mathematical inclination, an exceptionally
good mastery of one's native tongue is the most vital
asset of a competent programmer.«

Edsgar Dijkstra

»While sloppy writing does not invariably mean sloppy
thinking, we've generally found the correlation to be
strong -- and we have no use for sloppy thinkers.
If you can't yet write competently, learn to.«

Eric Raymond

http://www.catb.org/~esr/faqs/hacker-howto.html#skills4

»The narrative measures of conjunction use, event
content, perspective shift, and mental state reference
were significantly predictive of later Math scores.«

http://www.arts.uwaterloo.ca/~doneill/papers/Storytelling and math.pdf

 

[markspace]

Help! I hate writing English essays, and was never very good at it.

Perhaps I picked the wrong career, but it's a little late now that I'm
retired on the proceeds of my ill-chosen career path. I needed to know
that I would not be good at programming back in 1970.

Yes! What we need now is a time machine!

<http://xkcd.com/1063/>

Darn it!

 

[Gene Wirchenko]

Help! I hate writing English essays, and was never very good at it.

I find your writing to be clear. I think the problem with
essay-writing is when the academics get hold of it. It seems to
attract arbitraries.

I would evaluate an essay on clarity of language and logic. That
is what we are looking for in documentation.

Perhaps I picked the wrong career, but it's a little late now that I'm
retired on the proceeds of my ill-chosen career path. I needed to know
that I would not be good at programming back in 1970.

Sincerely,

Gene Wirchenko

 

[Jim Janney]

If I ever found myself screening applicants for a programming job (not
something that's ever likely to happen) I would be very tempted to ask
them to write a short essay. If you can write clearly then I know you
can think clearly too.

»I've found that some of the best [Software ]developers
of all are English majors. They'll often graduate with
no programming experience at all, and certainly without
a clue about the difference between DRAM and EPROM.

But they can write. That's the art of conveying
information concisely and clearly. Software development
and writing are both the art of knowing what you're going
to do, and then lucidly expressing your ideas.«

http://praisecurseandrecurse.blogspot.com/2007/03/english-majors-as-programmers.html

»Besides a mathematical inclination, an exceptionally
good mastery of one's native tongue is the most vital
asset of a competent programmer.«

Edsgar Dijkstra

»While sloppy writing does not invariably mean sloppy
thinking, we've generally found the correlation to be
strong -- and we have no use for sloppy thinkers.
If you can't yet write competently, learn to.«

Eric Raymond

http://www.catb.org/~esr/faqs/hacker-howto.html#skills4

»The narrative measures of conjunction use, event
content, perspective shift, and mental state reference
were significantly predictive of later Math scores.«

http://www.arts.uwaterloo.ca/~doneill/papers/Storytelling and math.pdf

Not an original thought, obviously

There are probably counter-arguments to be made, but I don't recollect
ever seeing one. Not a well-written one, anyway...

 

[Jim Janney]

Help! I hate writing English essays, and was never very good at it.

Perhaps I picked the wrong career, but it's a little late now that I'm
retired on the proceeds of my ill-chosen career path. I needed to know
that I would not be good at programming back in 1970.

If your writing in this group is any example, you wouldn't have any
trouble passing.

 

[Eric Sosman]

Help! I hate writing English essays, and was never very good at it.

Perhaps I picked the wrong career, but it's a little late now that I'm
retired on the proceeds of my ill-chosen career path. I needed to know
that I would not be good at programming back in 1970.

Pull the other one; it's got bells on.

 

[Eric Sosman]

Yes, I'm joking about reconsidering my choice of career, but if getting
a programming job in 1970 had depended on English writing skill, I would
have been rejected - I write much better now than I did then.

Aside from pure linguistic tasks -- writing grammatically and
correct, spelling words propperly, punctuating well that, sort?
of thing -- The developer needs some skill at separating himself
from his own context when documenting his artifact. The person
who wrote the code participated in the design discussions, knows
what approaches were considered and rejected (and why), remembers
only too clearly the bugs that were easy to fix and those that
kept him awake nights, and is aware that class X began as a bunch
of parallel `switch' statements in class Y before refactoring.
When he sets out to document class X, he may have a hard time
writing in a way that will be intelligible to someone who does
not share his prior knowledge.

A documentor needs some of the same skills as a teacher, most
especially the knack of seeing things from the point of view of a
reader not yet versed in them. "Empathy," if you will.

 

[Roedy Green]

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.

Originally Vector was much slower than ArrayList then somebody souped
up the low level code for locking and most of the difference
disappeared. I am just repeating what I heard.

JComboBox insists on a Vector of choices. You also need it for code
you want to run under any version of Java. JTable constructor likes
Vectors though you can get around that.


--
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
..