what I consider unhelpful documentatio
Ideally the javadocs would form at least part of the module-levelPerhaps 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.
Martin said: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.
Yes, I'd agree, but still its desirable to have a separation between aThe 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.
and a team that tries compartmentalize a project may well be on the trackIt'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.
I'd make a few more distinctions. Yes, unit teats are the very lowestSiloing 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.
1.vector is no longer being supported.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
Broad said:（未知）写é“：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 VectorsVector said: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
}
}
1.vector is no longer being supported.
2.
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.
Robert said: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(java.util.List)
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.
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.
And that would rarely matter, unless a person were adding actions that tried to
synchronize on the same monitor.
<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. ;-)
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.
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.
Personally, I prefer to use ArrayList as base, and wrap using
Collections.synchronizedCollection, but that is not mandatory.
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.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.