Change character in string

[Andreas Leitgeb]

No, I meant "sport", not a typo, not an idiom but a literal meaning.
<http://www.merriam-webster.com/dictionary/sport[1]>
Transitive verb meaning 1.

Ok, it was a too wide stretch for me from people boastingly wearing
something like shoes to a class having been defined with some methods.
So "support" appeared to me more apt and more likely meant.

Why do you disregard Occam's razor?

I follow him with respect to APIs (designing methods to be called
by others). And there it means: "use just List unless you really
need something more specific". That doesn't in any way affect
which List implementing class I actually instanciate: Vector
or the (unknown) class returned by synchronizedList().

The point is that Vector and Hashtable are obsolete,

Their docs do not contain that string "obsolete".

have extraneous weight that isn't needed

....nor cared about... (after Hotspot had its turn, it's
all machine code, and perhaps even the same pairwise
for all those methods callable through List interface)

and doesn't fit into the Collections framework,

It was actively fitted into it. The Java guys put some effort
into doing that.

and isn't as flexible as the more modern alternatives.

No one here tries to *bend* innocent lists ;-)

I think you still owe me an example of what I can do after
List<Foo> lf= Collections.synchronizedList(new ArrayList());
which I cannot do after
List<Foo> lf= new Vector();
to support your flexibility claim.

 

[Lew]

Ok, it was a too wide stretch for me from people boastingly wearing
something like shoes to a class having been defined with some methods.
So "support" appeared to me more apt and more likely meant.

The notion of "boastingly" isn't always present in the use of "sport"
in that sense. More commonly the sense is "flamboyantly",
"glaringly", "in a way that stands out like a sore thumb". Anyway,
the Wiktionary definition:

to bear a mark or wound with embarrassment

clearly applies.

Again, I meant "sport" when I said "sport". I "more likely meant"
exactly what I, who said it, explained that I actually meant.
Regardless, the sense in which I used "sport" is very prevalent in
English, is literal and non-idiomatic. I have encountered that usage
innumerable times over the years from all kinds of sources. English
is my first language (well, American English anyway), I studied it a
lot in college and earlier, my mother was an English teacher, and I
assure you the usage is valid.

 

[Andreas Leitgeb]

List <Foo> lf = Collections.synchronizedList( new LinkedList<Foo>() );
List <Role> lf = Collections.synchronizedList( new RoleList() );
List <Attribute> lf = Collections.synchronizedList( new AttributeList() );
List <Foo> lf = Collections.synchronizedList( new MyList<Foo>() );

My claim was, that Vector was a fine synchronized implementation
of List, mostly equivalent to a synchronize-wrapped ArrayList.

If one needs a synchronized LinkedList or FubarList, then Vector
is of course no alternative for *those*.

But then again, I may have missed the point.

PS: next time you manually craft a followup (nothing bad about that),
please put the message id of the answered post into angle-brackets.

 

[Andreas Leitgeb]

I just wrote, what made me originally believe what I did.
Of course I accept and understand your explanation of your wording.

 

[Lew]

My claim was, that Vector was a fine synchronized implementation
of List, mostly equivalent to a synchronize-wrapped ArrayList.

Ah, I was answering something different from what you were saying.
When I referred to "flexibility" I was talking about the ability to
synchronize more than just an ArrayList-ish thing like 'Vector'. If
it weren't for the additional unwanted features of 'Vector', I'd even
agree with you.

If one needs a synchronized LinkedList or FubarList, then Vector
is of course no alternative for *those*.

But then again, I may have missed the point.

That was my point.

PS: next time you manually craft a followup (nothing bad about that),
  please put the message id of the answered post into angle-brackets.

I have no idea what you're talking about. What do you mean "manually
craft a followup"? All I did was edit content for flow and to reduce
the size. Is the "message id" something in the header? I never mess
with headers. I just use the client to answer posts.

Could you explain what you mean?

 

[Andreas Leitgeb]

When I referred to "flexibility" I was talking about the ability to
synchronize more than just an ArrayList-ish thing like 'Vector'.

Ok, misunderstanding cleared.
Nevertheless, this flexibility may or may not be relevant for any
particular situation of free choice between sync'd ArrayList and Vector.

I have no idea what you're talking about. ...

The "References:" header was somehow syntactically different (broken?).
Newsreaders usually do not do this at random, so I thought you perhaps
started with a normal posting (i.e. not a followup) and added the citations
and that header e.g. from googles archive. (especially the "a...@" looked
a lot like a typical google-attribution.)
Ok, as you say, it wasn't so, so whatever else the reason for the
broken header: I don't really care.

 

[blue indigo]

[...]
Except for interaction with old APIs that were built with 'Vector' or
'Hashtable' before 1998, I can think of no advantage to make those
dinosaurs "still useful".

Straw man. There need not be an "advantage" for something to be "still
useful".

My twenty-year-old car provides zero _advantage_ over a brand new car.
But it's absolutely still useful. There's no reason for me to "deprecate"
it as long as it continues to serve its purpose.

The reason not to is the expense. But whereas a new car is expensive, a
new ArrayList() is free.

They should go ahead and deprecate Vector. That might prod the maintainers
of those old APIs to get with the 21st century by finally ditching Vector
(and Enumeration) and using ArrayList and Iterator, and maybe in some
cases another sort of List or other collection that works even better.

LinkedHashSet is superior for listener lists, for example, because the
operations typically needed there are: add (anywhere), iterate (in no
particular order), and remove (by search rather than index). LinkedList
and LinkedHashSet give O(1) adds and efficient traversal of all the
items; the latter also has O(1) search.

You'll find the cruft of Vector cropping up where you'd least expect it
sometimes. It's not just old pre-1.3 little-used corners of the Java APIs
and old third-party libraries. For instance there's three ways to make a
Swing combobox with a pre-populated list of items: set the listmodel
yourself, use an array, or use a Vector. No use a List option, it has to
be Vector. Some other APIs that do still-useful things, like return lists
of available resources, produce Enumerations rather than Iterators
(unmodifiable Collection views would be better still, as they could be
for-each'd).

I say deprecate Vector, Hashtable, and Enumeration, which will send a
not-so-gentle reminder to the maintainers of those APIs as well as to the
newbies that keep using them in place of their preferred modern
replacements. That's what deprecation is for, folks! When something has a
preferred modern replacement. We shouldn't be too reluctant to use it on
something that *almost* everyone agrees is obsolete.

(Stringbuffer, on the other hand...)

 

[Joshua Cranmer]

They should go ahead and deprecate Vector. That might prod the maintainers
of those old APIs to get with the 21st century by finally ditching Vector
(and Enumeration) and using ArrayList and Iterator, and maybe in some
cases another sort of List or other collection that works even better.

The problem is this:
<http://java.sun.com/javase/6/docs/api/java/util/class-use/Vector.html>.
Swing classes, in particular JTable and JList, use Vector, so
deprecating it would force you to use deprecated APIs for those interfaces.

They could--and probably should--make the methods containing Vector as
an argument use List instead, but retrofitting return types is not so
easily doable.

I'm also of the opinion that at some point, Java should do a redesign of
its APIs to remove deprecated or effectively-deprecated cruft and fix
related annoyances.

 

[blue indigo]

The problem is this:
<http://java.sun.com/javase/6/docs/api/java/util/class-use/Vector.html>.
Swing classes, in particular JTable and JList, use Vector, so
deprecating it would force you to use deprecated APIs for those interfaces.

That's the point. Or rather, the point is that deprecating Vector would
force the maintainers of APIs like those ones to update them right quick.

They could--and probably should--make the methods containing Vector as
an argument use List instead, but retrofitting return types is not so
easily doable.

Sure it is -- add a parallel method with List (or other appropriate
Collection) return type and deprecate the one that returns Vector.

I'm also of the opinion that at some point, Java should do a redesign of
its APIs to remove deprecated or effectively-deprecated cruft and fix
related annoyances.

That would have been an excellent idea if they hadn't shot themselves in
the foot by going from 1.0, 1.1, 1.2, 1.3, 1.4 straight to 5.0 and 6.0 and
basically no longer using the "1." part. Because otherwise they could have
put out a Java 2.0 that was no longer backward-compatible with 1.x. Now
that people expect Java to be backward compatible even when the major
version changes, they can't do that. They'd have to either call it
something else than Java, or "Java 2010" or some such. Software developers
don't like dates instead of versions, though, only marketers, but Java is
marketed at software developers

 

[RedGrittyBrick]

I think you still owe me an example of what I can do after
List<Foo> lf= Collections.synchronizedList(new ArrayList());
which I cannot do after
List<Foo> lf= new Vector();
to support your flexibility claim.

One thing you can do with the former but not the latter is compile
without warnings. The latter gives me this warning in Eclipse:
"Type safety: The expression of type Vector needs unchecked conversion
to conform to List<Foo>"

I've always thought that ArrayList was intended as a replacement for
Vector and act accordingly.

Sun says[1]:

"Think of ArrayList as Vector without the synchronization overhead. ...
If you need synchronization, a Vector will be slightly faster than an
ArrayList synchronized with Collections.synchronizedList. But Vector has
loads of legacy operations, so be careful to always manipulate the
Vector with the List interface or else you won't be able to replace the
implementation at a later time."

Which, to me, make Vector look like a second choice (in almost all cases
I'm likely to encounter.)


So for me, the more interesting question is: what can I do after
`List<Foo> lf = new Vector();` that I could not do after `List<Foo> lf =
new ArrayList<Foo>();`?



[1]
http://java.sun.com/docs/books/tutorial/collections/implementations/list.html

 

[Andreas Leitgeb]

Sun:
If you need synchronization, a Vector will be slightly faster than an
ArrayList synchronized with Collections.synchronizedList.

So for me, the more interesting question is: what can I do after
`List<Foo> lf = new Vector();` that I could not do after `List<Foo> lf =
new ArrayList<Foo>();`?

I'd say, Sun answered this question for me - of course only in the
context where you actually need a synchronized List with ArrayList
characteristics. If you never ever need one of those, then Vector
surely couldn't be more useless to you.

About the [unchecked] warning: of course each of my two lines
should have had the "<Foo>" not only for the variable's type, but

One thing you can do with the former[sync'd ArrayList] but not
the latter[Vector] is compile without warnings.

For the claim of only Vector throwing the warning, I made an sscce:
--- snip ---
import java.util.*;// "*"? Hey, it's just for the sscce
public class Test {
List<Test> lt1 = new Vector();
List<Test> lt2 = new Vector<Test>();
List<Test> lt3 = Collections.synchronizedList(new ArrayList());
List<Test> lt4 = Collections.synchronizedList(new ArrayList<Test>());
}
--- snip ---
Compiling it with (jdk 1.5.0_10 and 1.6.0_12) and option -Xlint:unchecked set,
complains (surprise surprise) about *both* of the lines 3 and 5, emitting one
warning for line 3 and three warnings for line 5 (due to the static method)

The latter gives
me this warning in Eclipse: "Type safety: The expression of type
Vector needs unchecked conversion to conform to List<Foo>"

You may want to submit a bugreport to eclipse, if it does not give
an equivalent warning for the other case. (I haven't tried eclipse
myself)

 

[Lew]

For the claim of only Vector throwing the warning, I made an sscce:

I don't see that they made that claim. It looked like they were
simply calling out the minor omission of the type argument in the
'new' expression in that specific example, not making a general claim,
your emendation of their post to change its meaning notwithstanding.

 

[Andreas Leitgeb]

I don't see that they made that claim.

Oh really? (Or are you just splitting hairs now, about eclipse -
not Vector - being the one writing/throwing/issuing warnings?)

My original two contestants *both* had that omission. (I just checked
back.) And in that case, eclipse really should have warned about both.

RGB: Would you care to re-check and elaborate on your experiment?

your emendation of their post to change its meaning notwithstanding.

I'm not sure, what emendations in the relevant lines 3 and 5 of my sscce
you think I could have meant to change any meaning?
Changing Foo to Test? Changing the varname from lf to lt and a digit?

PS: Is RGB plural?

 

[Andreas Leitgeb]

After rereading this, I guess you meant, that I removed the "but"-part
from RGB quoting Sun.

That "but"-part mostly suggested to use a List-typed variable when dealing
with Vectors to maintain exchangeability of implementations, and this same
recommendation is just as well applicable to ArrayList, of course.

 

[Andreas Leitgeb]

Btw., it was me who rearranged her post, because I intended to
answer on the contest first and only then on the warning.

I was aware, that just by re-arranging the paragraphs the meanings
of "former" and "latter" could break, *therefore* I added bracketed
explanations to what each referred to in the original post.

Also, against your attributions, both of these two paragraphs were
written by RGB. It was RGB's obvious intent to make his/her point
by changing the contestants, but I missed an important part of the
change namely that he/she also dropped the synchronization.

If synchronisation *wasn't* a requirement, then no doubt, ArrayList
is better.

 

[Tom Anderson]

One thing you can do with the former[sync'd ArrayList] but not
the latter[Vector] is compile without warnings.

For the claim of only Vector throwing the warning, I made an sscce:
--- snip ---
import java.util.*;// "*"? Hey, it's just for the sscce
public class Test {
List<Test> lt1 = new Vector();
List<Test> lt2 = new Vector<Test>();
List<Test> lt3 = Collections.synchronizedList(new ArrayList());
List<Test> lt4 = Collections.synchronizedList(new ArrayList<Test>());
}
--- snip ---
Compiling it with (jdk 1.5.0_10 and 1.6.0_12) and option -Xlint:unchecked set,
complains (surprise surprise) about *both* of the lines 3 and 5, emitting one
warning for line 3 and three warnings for line 5 (due to the static method)

I think Sun missed a trick here: they could have made the post-generics
declaration of Vector look like:

public class Vector implements List<Object>

That would ease the pain of legacy code which uses raw Vectors, as it
would need the addition of lots of type bindings to compile without
warnings, and at the same time strongly discourage any new uses.

tom

 

[Tom Anderson]

Sun says[1]:

"Think of ArrayList as Vector without the synchronization overhead. ... If
you need synchronization, a Vector will be slightly faster than an ArrayList
synchronized with Collections.synchronizedList. But Vector has loads of
legacy operations,

Okay, *really* random aside: is 'loads of' a Britishism? It's a perfectly
normal expression to me, but it's jarring to see it in American english
text (as i presume, perhaps mistakenly, that that document is). Am i right
to be jarred, or have i imagined a difference between our languages where
there isn't one?

tom

[1] http://java.sun.com/docs/books/tutorial/collections/implementations/list.html

 

[Lew]

After rereading this, I guess you meant, that I removed the "but"-part
from RGB quoting Sun.

That "but"-part mostly suggested to use a List-typed variable when dealing
with Vectors to maintain exchangeability of implementations, and this same
recommendation is just as well applicable to ArrayList, of course.

No, I was referring to your insertion of "[sync'd ArrayList]" and
"[Vector]". That changed the thrust of their post from "[new
expression with type parameter]" and "[new expression without type
parameter]", respectively.

 

[Lew]

Btw., it was me who rearranged her post, because I intended to
answer on the contest first and only then on the warning.

You also inserted editorial comment in square brackets that changed
the thrust of the post.

I was aware, that just by re-arranging the paragraphs the meanings
of "former" and "latter" could break, *therefore* I added bracketed
explanations to what each referred to in the original post.

Those "explanations" distorted the meaning of the post, as I read it.

Also, against your attributions, both of these two paragraphs were
written by RGB.  It was RGB's obvious intent to make his/her point

Oops. My mistake.

by changing the contestants, but I missed an important part of the
change namely that he/she also dropped the synchronization.

If synchronisation *wasn't* a requirement, then no doubt, ArrayList
is better.

Synchronization had nothing to do with my remark, which is that by
focusing "former" on "sync'ed ArrayList" you missed the point of RGB's
post.

 

[Lew]

Okay, *really* random aside: is 'loads of' a Britishism? It's a perfectly
normal expression to me, but it's jarring to see it in American english
text (as i presume, perhaps mistakenly, that that document is). Am i right
to be jarred, or have i imagined a difference between our languages where
there isn't one?

As an American myself, I can tell you that I've heard "loads of" loads
of times throughout my life from loads of American speakers and
written sources.