unchecked conversion warning.

Discussion in 'Java' started by Jens, May 30, 2012.

  1. Jens

    Jens Guest

    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
     
    Jens, May 30, 2012
    #1
    1. Advertising

  2. 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
     
    Andreas Leitgeb, May 30, 2012
    #2
    1. Advertising

  3. Jens

    Jens Guest

    On Wed, 30 May 2012 13:48:29 +0000 (UTC), Andreas Leitgeb <>
    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
     
    Jens, May 30, 2012
    #3
  4. 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
     
    Robert Klemme, May 30, 2012
    #4
  5. Jens

    Jens Guest

    On Wed, 30 May 2012 07:54:33 -0700 (PDT), Robert Klemme <>
    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
     
    Jens, May 31, 2012
    #5
  6. Jens

    Lew Guest

    (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
     
    Lew, May 31, 2012
    #6
  7. Jens

    Eric Sosman Guest

    On 5/31/2012 4:23 PM, Jens wrote:
    > On Wed, 30 May 2012 07:54:33 -0700 (PDT), Robert Klemme<>
    > 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
    d
     
    Eric Sosman, May 31, 2012
    #7
  8. Jens

    Lew Guest

    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
     
    Lew, Jun 1, 2012
    #8
  9. 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<>
    >> 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/
     
    Robert Klemme, Jun 1, 2012
    #9
  10. Jens

    Eric Sosman Guest

    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
    d
     
    Eric Sosman, Jun 1, 2012
    #10
  11. On Friday, June 1, 2012 2:48:23 PM UTC+2, Eric Sosman wrote:
    > 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.


    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
     
    Robert Klemme, Jun 1, 2012
    #11
  12. Jens

    Jim Janney Guest

    Eric Sosman <> writes:

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

    --
    Jim Janney
     
    Jim Janney, Jun 1, 2012
    #12
  13. Jens

    Stefan Ram Guest

    natural/native language capabilities (was: unchecked conversion warning.)

    Jim Janney <> writes:
    >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
     
    Stefan Ram, Jun 1, 2012
    #13
  14. Jens

    markspace Guest

    On 6/1/2012 8:44 AM, Patricia Shanahan wrote:
    > 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!
     
    markspace, Jun 1, 2012
    #14
  15. On Fri, 01 Jun 2012 08:44:19 -0700, Patricia Shanahan <>
    wrote:

    >On 6/1/2012 7:41 AM, Jim Janney wrote:
    >> Eric Sosman<> writes:
    >>
    >>> (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.
    >>

    >
    >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
     
    Gene Wirchenko, Jun 1, 2012
    #15
  16. Jens

    Jim Janney Guest

    Re: natural/native language capabilities (was: unchecked conversion warning.)

    -berlin.de (Stefan Ram) writes:

    > Jim Janney <> writes:
    >>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
     
    Jim Janney, Jun 1, 2012
    #16
  17. Jens

    Jim Janney Guest

    Patricia Shanahan <> writes:

    > On 6/1/2012 7:41 AM, Jim Janney wrote:
    >> Eric Sosman<> writes:
    >>
    >>> (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.
    >>

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

    --
    Jim Janney
     
    Jim Janney, Jun 1, 2012
    #17
  18. Jens

    Eric Sosman Guest

    On 6/1/2012 11:44 AM, Patricia Shanahan wrote:
    > On 6/1/2012 7:41 AM, Jim Janney wrote:
    >> Eric Sosman<> writes:
    >>
    >>> (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.
    >>

    >
    > 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
    d
     
    Eric Sosman, Jun 1, 2012
    #18
  19. Jens

    Eric Sosman Guest

    On 6/1/2012 7:44 PM, Patricia Shanahan wrote:
    > On 6/1/2012 10:54 AM, Eric Sosman wrote:
    >> On 6/1/2012 11:44 AM, Patricia Shanahan wrote:
    >>> On 6/1/2012 7:41 AM, Jim Janney wrote:
    >>>> Eric Sosman<> writes:
    >>>>
    >>>>> (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.
    >>>>
    >>>
    >>> 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.
    >>

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

    --
    Eric Sosman
    d
     
    Eric Sosman, Jun 2, 2012
    #19
  20. Jens

    Roedy Green Guest

    On Thu, 31 May 2012 16:50:24 -0400, Eric Sosman
    <> wrote, quoted or indirectly quoted
    someone who said :

    > 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
    ..
     
    Roedy Green, Jun 10, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew Lee
    Replies:
    2
    Views:
    3,126
    Andrew Lee
    Nov 18, 2004
  2. Ian Pilcher

    Avoid unchecked cast warning

    Ian Pilcher, Aug 20, 2005, in forum: Java
    Replies:
    0
    Views:
    3,537
    Ian Pilcher
    Aug 20, 2005
  3. Knute Johnson

    Unchecked cast warning?

    Knute Johnson, Nov 1, 2006, in forum: Java
    Replies:
    4
    Views:
    1,005
    Knute Johnson
    Nov 1, 2006
  4. Knute Johnson
    Replies:
    2
    Views:
    2,063
    Knute Johnson
    Apr 15, 2007
  5. RVic
    Replies:
    19
    Views:
    1,395
Loading...

Share This Page