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

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

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, becau=
se the synchronization overhead is unnecessary most of the time - unless so=
me API forces you to.  The proper replacement is ArrayList.  If synchroniza=
tion is needed then usually Collections.synchronizedList() will do.

Kind regards

robert

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

(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

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

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

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/

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

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

Eric Sosman <esosman@ieee-dot-org.invalid> 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 <jjanney@shell.xmission.com> 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/%7Edoneill/papers/Storytelling%20and%20math.pdf

On 6/1/2012 7:41 AM, Jim Janney wrote:
> Eric Sosman<esosman@ieee-dot-org.invalid>  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.

Patricia

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!

On Fri, 01 Jun 2012 08:44:19 -0700, Patricia Shanahan <pats@acm.org>
wrote:

>On 6/1/2012 7:41 AM, Jim Janney wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  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

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Jim Janney <jjanney@shell.xmission.com> 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/%7Edoneill/papers/Storytelling%20and%20math.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

Patricia Shanahan <pats@acm.org> writes:

> On 6/1/2012 7:41 AM, Jim Janney wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid>  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

On 6/1/2012 11:44 AM, Patricia Shanahan wrote:
> On 6/1/2012 7:41 AM, Jim Janney wrote:
>> Eric Sosman<esosman@ieee-dot-org.invalid> 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
esosman@ieee-dot-org.invalid

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<esosman@ieee-dot-org.invalid> 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.

Patricia

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<esosman@ieee-dot-org.invalid> 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
esosman@ieee-dot-org.invalid

On 6/1/2012 5:24 PM, Eric Sosman wrote:
....
> 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.

I find it helpful to write unit tests and Javadocs at the same time.
Both require that sort of separation. Both require attention to extreme
and special cases.

Patricia

On Thu, 31 May 2012 16:50:24 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> 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
..

On Fri, 01 Jun 2012 08:48:23 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
someone who said :

>what I consider unhelpful documentatio

Perhaps docs should be written by the folks who write the test code.
The get to ask the coders, decide what makes sense. They will than
answer the questions that need answering and clarify that which is
guaranteed.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Controlling complexity is the essence of computer programming.
~ Brian W. Kernighan 1942-01-01
..

On Sun, 10 Jun 2012 12:16:33 -0700, Roedy Green wrote:

> Perhaps docs should be written by the folks who write the test code.
> The get to ask the coders, decide what makes sense. They will than
> answer the questions that need answering and clarify that which is
> guaranteed.
>
Ideally the javadocs would form at least part of the module-level 
documentation and so should be written by the designers, not the coders.
I think there's a case for the module design documentation to be written 
entirely as a javadoc package suite, i.e. they contain the descriptive 
text as class and public method level comments as well as the associated 
declarations. There's also a case for compiling, as a sanity check, them 
before they are given to the coders. 

Further, the design team are the people who should specify the module and 
regression tests and (hopefully) should be writing them too.

IME you really don't want coders writing module tests. The problem is 
that they will tend to write tests for what they coded rather than for 
what the specification asked them to write and they may skimp on corner 
cases and error handling.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Martin Gregorie wrote:
> Roedy Green wrote:
>
>> Perhaps docs should be written by the folks who write the test code.
>> The get to ask the coders, decide what makes sense. They will than
>> answer the questions that need answering and clarify that which is
>> guaranteed.
>>
> Ideally the javadocs would form at least part of the module-level
> documentation and so should be written by the designers, not the coders.
> I think there's a case for the module design documentation to be written
> entirely as a javadoc package suite, i.e. they contain the descriptive
> text as class and public method level comments as well as the associated
> declarations. There's also a case for compiling, as a sanity check, them
> before they are given to the coders.
>
> Further, the design team are the people who should specify the module and
> regression tests and (hopefully) should be writing them too.
>
> IME you really don't want coders writing module tests. The problem is
> that they will tend to write tests for what they coded rather than for
> what the specification asked them to write and they may skimp on corner
> cases and error handling.

"Can't we all just get along?"

The business world speaks of "siloing" - "to silo" is to isolate personnel to 
a narrow wedge of the overall project.

Siloing can be good, but in software development usually is not.

It's vanishingly unlikely to be good if it isn't done on purpose with full 
understanding of its effects.

Siloing is not the same as division of responsibility. One can divide 
responsibilities among a team who is generally, and to varying degrees 
specifically aware of various dimensions of the project.

Siloing would be to keep programmers entirely away from test writing.

There is more than one type of test. Loosely, tests fall into unit tests and 
everything else.

Unit tests are, as the name should indicate, aimed at rather minimal units of 
code. They verify the behavior of a type's public face. Positively and negatively.

For example, from the spec for 'List#get(int)' it follows directly that the 
argument might be negative, zero, or positive, and may equal, exceed or be 
less than the size of the list. Any programmer worth their salt had better be 
able to write a full suite of unit tests for such a method.

<http://docs.oracle.com/javase/7/docs/api/java/util/List.html#get(int)>

As the designer of a type, let's say 'Foo', with a method 'goof(Bar)', the 
programmer knows exactly how the method should handle various possible values 
of the 'Bar' argument. Ideally up front, whilst writing the Javadocs thereto.

 From the Javadocs the tests follow directly. It shall do thus and so with a 
'null' argument, and react in a certain way to a reference to an uninitialized 
instance, and another to one in an inconsistent state, and yet another to one 
in a valid, initialized state.

That part is unit testing. Unit tests operate on components in isolation, 
separated from the context of a larger application. Their sources and sinks 
(inputs and outputs) are simulated via mock objects and other tricks where 
absolutely necessary. This form of testing is also called "hermetic", meaning 
sealed away from the operational environment.

The rest goes by different names according to specific line of inquiry. Some 
suggest "functional" test for everything regarding how components function /in 
situ/, while others restrict it to just those that confirm behaviors' 
conformance to spec /in situ/. That narrower sense is also called "acceptance" 
testing or "regression" testing. (Note: I'm being a little loosey-goosey here. 
If you have more refined definitions by all means share them.) Tests to ensure 
that components function well with each other are "integration" tests. Tests 
for performance and throughput or stability or load are called "performance", 
or in that last case, "load" tests.

Unit tests

Everything else (Functional tests in the wide sense)
  - Acceptance / regression (functional in the narrow sense)
  - Integration
  - Performance
  - - Load

Your taxonomy may vary. It will cover pretty much the same range, though.

Cross that in a matrix with a second dimension of techniques: programmed 
tests, fixtured tests (those with deterministic setup conditions), 
simulations, random-event tests, parametrized probabilistic test scenarios, 
and so on.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On Sun, 10 Jun 2012 17:09:07 -0700, Lew wrote:

> The business world speaks of "siloing" - "to silo" is to isolate
> personnel to a narrow wedge of the overall project.
> 
> Siloing can be good, but in software development usually is not.
>
Yes, I'd agree, but still its desirable to have a separation between a 
module's developer(s) and its test writer(s), if only to help prevent 
misunderstandings getting baked into code.
 
> It's vanishingly unlikely to be good if it isn't done on purpose with
> full understanding of its effects.
>
Agreed.
 
> Siloing is not the same as division of responsibility.
>
Yes.

> One can divide
> responsibilities among a team who is generally, and to varying degrees
> specifically aware of various dimensions of the project.
> 
and a team that tries compartmentalize a project may well be on the track 
to failure.

> Siloing would be to keep programmers entirely away from test writing.
> 
> There is more than one type of test. Loosely, tests fall into unit tests
> and everything else.
>
I'd make a few more distinctions. Yes, unit teats are the very lowest 
level, with module tests above them. By module tests I mean anything from 
testing a function library, a small component program or, for that 
matter, even a complex class for somewhat higher level functions that can 
cover everything that module can do as an isolated component.

Next level is integration testing, which seeks to show that a system will 
work when its modules are built into a realistic configuration.

Functional tests are essentially end-to-end, user-level activities within 
a complete system. Performance tests are more of the same but with added 
'stopwatches'. Recovery tests are probably the highest level testing that 
gets done be for the user gets his hands on the system. Many shops seem 
to skimp on both performance and recovery tests judging by the number of 
systems I've seen that didn't perform adequately when data volumes got 
near the design volumes: the last data warehouse I worked on had 500,000 
facts in its test database, barely enough, yet I've seen and fixed 
databases 'tuned' with 200 or so detail records to work on.

Then, of course, acceptance testing is simply functional testing, but 
done on the target hardware with the involvement of end users.

You'll notice I've left out regression testing until now. Thats because 
its just an automated version of some combination of unit, module, or 
functional testing that is quick and easy to run and whose results are 
simple to interpret. These days I script all unit and module tests in 
such a way that I merely have to add a set of expected results and a 
comparator for them to become regression tests: if the comparator doesn't 
find any difference between expected and actual results its a pass.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

=E5=9C=A8 2012=E5=B9=B45=E6=9C=8830=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=89UTC+=
8=E4=B8=8B=E5=8D=889=E6=97=B632=E5=88=8643=E7=A7=92=EF=BC=8C=EF=BC=88=E6=9C=
=AA=E7=9F=A5=EF=BC=89=E5=86=99=E9=81=93=EF=BC=9A
> 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.
>=20
> import java.util.Vector;
> public class genericsdemo
> {
>   private static Vector<Vector> vdata =3D new Vector<Vector>(); //a Vecto=
r of Vectors
>   private static Vector<Object> vrow  =3D new Vector<Object>(); //a row
>=20
>   public static void main(String args[]) {
>     vrow.add(null); //two columns in the row
>     vrow.add(null);
>=20
>     vdata.add(vrow); //add the row to the Vector of Vectors
>=20
>     Vector vtmp =3D getrow(); //test
>   }
>=20
>   private static Vector<Object> getrow() {
>     return vdata.elementAt(0);  //warning: [unchecked] unchecked conversi=
on
>   }
> }
>=20
> JensJ
1.vector is no longer being supported.
2.

Broad Liyn wrote:
> （未知）写道：
>> 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

Vector<Vector<?>>

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

Raw types are bad.

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

> 1.vector is no longer being supported.
> 2.

Do you mean 'Vector', as in 'java.util.Vector'? Because spelling counts in Java.

If so, then you're mistaken, and if not, you need to explain what you mean.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

On 6/10/2012 9:52 PM, Broad Liyn wrote:
> 在 2012年5月30日星期三UTC+8下午9时32分43秒，（未知）写道：
>> 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
> 1.vector is no longer being supported.
> 2.
>


As of JDK 7, Vector is not even deprecated.

The documentation,
http://docs.oracle.com/javase/7/docs/api/java/util/Vector.html, says "If
a thread-safe implementation is not needed, it is recommended to use
ArrayList in place of Vector." which implies that Vector might be a
reasonable choice if thread safety is needed.

Personally, I prefer to use ArrayList as base, and wrap using
Collections.synchronizedCollection, but that is not mandatory.

Patricia

On 11.06.2012 09:06, Patricia Shanahan wrote:

> The documentation,
> http://docs.oracle.com/javase/7/docs/api/java/util/Vector.html, says "If
> a thread-safe implementation is not needed, it is recommended to use
> ArrayList in place of Vector." which implies that Vector might be a
> reasonable choice if thread safety is needed.
>
> Personally, I prefer to use ArrayList as base, and wrap using
> Collections.synchronizedCollection, but that is not mandatory.

I totally agree.  Btw, there is one interesting detail: JavaDoc of 
Collections.synchronizedList() and the other synchronized*() methods 
explicitly state that the mutex used for synchronizing is that of the 
returned object:

http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29

No such statement is done about Vector.  So while the source code of 
Vector tells us that the Vector instance is used to synchronize the 
JavaDoc does not give any guarantee about that and - at least 
theoretically - Sun/Oracle could change that and synchronize on another 
instance.

Kind regards

	robert

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

Robert Klemme wrote:
> I totally agree.  Btw, there is one interesting detail: JavaDoc of 
> Collections.synchronizedList() and the other synchronized*() methods 
> explicitly state that the mutex used for synchronizing is that of the 
> returned object:
> 
> http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29

I see no such promise there.

And in fact it's not true. The source for the 'synchronizedCollection()' family 
of methods reveals that there's a separate field 'mutex' of type 'Object' on 
which the methods synchronize.

> No such statement is done about Vector.  So while the source code of 
> Vector tells us that the Vector instance is used to synchronize the 
> JavaDoc does not give any guarantee about that and - at least 
> theoretically - Sun/Oracle could change that and synchronize on another 
> instance.

And that would rarely matter, unless a person were adding actions that tried to 
synchronize on the same monitor.

-- 
Lew

On 18.06.2012 21:28, Lew wrote:
> Robert Klemme wrote:
>> I totally agree.  Btw, there is one interesting detail: JavaDoc of
>> Collections.synchronizedList() and the other synchronized*() methods
>> explicitly state that the mutex used for synchronizing is that of the
>> returned object:
>>
>> http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29
>
> I see no such promise there.

<quote>
It is imperative that the user manually synchronize on the returned list 
when iterating over it:

   List list = Collections.synchronizedList(new ArrayList());
       ...
   synchronized (list) {
       Iterator i = list.iterator(); // Must be in synchronized block
       while (i.hasNext())
           foo(i.next());
   }


Failure to follow this advice may result in non-deterministic behavior.
</quote>

Pardon, my wording was wrong: it's not explicitly stated but it follows 
immediately from the quote.  For me that was "explicit" enough. ;-)

> And in fact it's not true. The source for the 'synchronizedCollection()' family
> of methods reveals that there's a separate field 'mutex' of type 'Object' on
> which the methods synchronize.

Did you see how it's initialized?  It's initialized with this, i.e. the 
wrapper instance.  The field serves the sole purpose to be able to 
synchronize on a parent collection when a dependent collection is 
created (e.g. in 
java.util.Collections.SynchronizedRandomAccessList.subList(int, int)). 
So normally the monitor of the wrapper is used as illustrated by the 
JavaDoc quoted.

>> No such statement is done about Vector.  So while the source code of
>> Vector tells us that the Vector instance is used to synchronize the
>> JavaDoc does not give any guarantee about that and - at least
>> theoretically - Sun/Oracle could change that and synchronize on another
>> instance.
>
> And that would rarely matter, unless a person were adding actions that tried to
> synchronize on the same monitor.

No, it also matters in cases like the example quoted above, i.e. when 
you need to perform multiple operations on the Vector instance: when the 
monitor which the Vector instance uses internally is different from the 
one used for the external synchronization then you do not have thread 
safety.  Depending on the logic anything from inconsistent contents to 
CME can happen.

Kind regards

	robert

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

On Tuesday, June 19, 2012 2:14:06 PM UTC-7, Robert Klemme wrote:
> On 18.06.2012 21:28, Lew wrote:
> > Robert Klemme wrote:
> >> I totally agree.  Btw, there is one interesting detail: JavaDoc of
> >> Collections.synchronizedList() and the other synchronized*() methods
> >> explicitly state that the mutex used for synchronizing is that of the
> >> returned object:
> >>
> >> http://docs.oracle.com/javase/7/docs/api/java/util/Collections.html#synchronizedList%28java.util.List%29
> >
> > I see no such promise there.
> 
> <quote>
> It is imperative that the user manually synchronize on the returned list 
> when iterating over it:
> 
>    List list = Collections.synchronizedList(new ArrayList());
>        ...
>    synchronized (list) {
>        Iterator i = list.iterator(); // Must be in synchronized block
>        while (i.hasNext())
>            foo(i.next());
>    }
> 
> 
> Failure to follow this advice may result in non-deterministic behavior.
> </quote>
> 
> Pardon, my wording was wrong: it's not explicitly stated but it follows 
> immediately from the quote.  For me that was "explicit" enough. ;-)

Okay, I see what you're saying, but it doesn't follow immediately. 
You have to go through at least two logical steps.

> No, it also matters in cases like the example quoted above, i.e. when 
> you need to perform multiple operations on the Vector instance: when the 
> monitor which the Vector instance uses internally is different from the 
> one used for the external synchronization then you do not have thread 
>safety.  Depending on the logic anything from inconsistent contents to 
> CME can happen. 

Nope.

The successive operations can synchronize on a second monitor without 
harm even though the individual methods synchronize on the first one.
Provided all your code uses that monitor, of course, in addition to the 
default one.

But then the Javadoc's advice wouldn't be right, so therefore you are.

Thanks for the eye-opener.

-- 
Lew

On 6/11/2012 12:52 AM, Broad Liyn wrote:
> 1.vector is no longer being supported.

It is supported.

It is not deprecated.

It is generally considered best practice to use ArrayList
instead of Vector and has been so for many years.

Arne

On 6/11/2012 3:06 AM, Patricia Shanahan wrote:
> On 6/10/2012 9:52 PM, Broad Liyn wrote:
>> 1.vector is no longer being supported.
>
> As of JDK 7, Vector is not even deprecated.
>
> The documentation,
> http://docs.oracle.com/javase/7/docs/api/java/util/Vector.html, says "If
> a thread-safe implementation is not needed, it is recommended to use
> ArrayList in place of Vector." which implies that Vector might be a
> reasonable choice if thread safety is needed.

For other readers: thread safety here is for single calls.

> Personally, I prefer to use ArrayList as base, and wrap using
> Collections.synchronizedCollection, but that is not mandatory.

That is what is considered best practice today.

Arne

On 5/31/2012 4:50 PM, Eric Sosman wrote:
> On 5/31/2012 4:23 PM, Jens wrote:
>> 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.

Java Performance Tuning / Jack Shirazi has some tests
in Chapter 10 (Threading).

The difference were significant for 1.2.2, 1.3.1, 1.3.1 server
and 1.4.0 but not for 1.4.0 server.

The versions indicates something about the age of book.

I would expect the difference to be small for newer JVM's.
Synchronization has been optimized.

Arne