Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: Jan Burse <janburse@fastmail.fm>
Newsgroups: comp.lang.java.programmer
Subject: Re: setSize ArrayList, when will it come?
Date: Wed, 10 Aug 2011 00:31:33 +0200
Organization: albasani.net
Lines: 73
Message-ID: <j1scg8$s3l$1@news.albasani.net>
References: <j1pp1j$3rf$1@news.albasani.net> <j1q1cv$aos$1@dont-email.me> <j1q596$gs8$1@news.albasani.net> <j1q6kj$3cp$2@dont-email.me> <slrnj41q1k.6gl.avl@gamma.logic.tuwien.ac.at> <j1rk6u$8li$1@dont-email.me> <j1rnb5$bv0$1@news.albasani.net> <j1s8uj$16a$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net /JoTqKMU2PD6ILzwgw4zz/HK7noaonPXcUwWO1Vy6qfWlTFMSZd3XS3/U/HQ9EbnOTUKjXaz+4yiDTfS+heJhw==
NNTP-Posting-Date: Tue, 9 Aug 2011 22:31:36 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="7b1jRH3rB052RZNc0Gntqnu9f1hPecwny+kkeTquHxyAayI9PJ+7ZElQyT0PimTxr7la+Bvv740BBjbzaysoXLBM5PiPbKQVQzjrc5ei5hWW6lF53ZvIdUpySQ00VcFj"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110706 Firefox/5.0 SeaMonkey/2.2
In-Reply-To: <j1s8uj$16a$1@dont-email.me>
Cancel-Lock: sha1:k0hss4f+NN+FIVFN6HHvFDQZMO0=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6929

Joshua Cranmer schrieb:
> Anything reflective is a dead giveaway, and I'm pretty sure that the two
> classes have slightly different sizes, so you could observe differences
> in memory characteristics.

In vector you can parametrisize the growing characteristics, either
by a constant increment or doubling the size. For this purpose there
is an extra field not found in ArrayList.

Array list always follows a 150% + 1 rule when growing the internal
data buffer. There is no extra field need to store some parameter.
But otherwise the two use the same data representation.

But I think it would not prevent me from using ArrayList instead
of Vector, that this parameter is missing. The 150% has its merits
over the strategies implemented in vector.

 > More seriously, the Collections API tweaked some method names
 > differently, so there are a few methods in Vector which are kept
 > around for legacy use (addElement, e.g.).

Yes when replacing Vector by ArrayList, one has to rename the method
calls. For example instead of addElement() one needs to use add(), and 
instead of elementAt().

But renaming methods does not prevent me from using ArrayList. As
long each legacy method has a new buddy, I don't see any problem
whatever with it.

 > In general, an ArrayList is a list that happens to be backed by an
 > array. A Vector is a synchronized, automatically-growing array that
 > leaks details about its array all over the place; it was shoehorned
 > into the Collections API upon introduction to allow for a more
 > gradual, correct migration.

I don't see that Vector leaks more details than ArrayList about its
implementation. Could you make an example? I only see that the fields
of vector are protected, and well yes this means vector is not fully
encapsulated.

But I want to migrate to ArrayList whereever possible, so why should
I bother that Vector is not fully encapsulated. And if ArrayList has
the merrit that it is fully encapsulated the better.

But the protected fields would only be seen by a subclass, which could
sneak into some of your parameters of your methods, and spy on you or
cheat on you. Since vector is not final. That is a drawback. But same
problem with ArrayList.

Vector and ArrayList both implement the following protocolls:
	AbstractList<E>
         List<E>,
	RandomAccess,
	Cloneable,
	Serializable

If only somebody would have had the brains to include setSize() 
somewhere. List has the methods size(), add() and remove() in it.
setSize(n) could be neatly abstractly specified as having the
post condition size()=n and after.get(i)=before.get(i) for 
i<before.size() and after.get(i)=null for i>=before.size() and 
i<after.size().

And the AbstractList could implement abstractly the inefficient
setSize() that would use remove() and add(), when Random access is
present via index, or otherwise maybe with a backward iterator.
Backward iterator is also missing btw. And then concrete classes
could provide more efficient implementations if necessary.

Bye


Best Regards