Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of dmsmith555@gmail.com
 designates 209.85.217.13 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:content-type:content-transfer-encoding
         :mime-version:subject:date:x-mailer;
        b=bj+lFnpfzj5WgzYsWjv1dv5VaFyNecBUVkGnHhkUMyFDid+v6Mw3HCTuHoInL/Fu0r
         R+DKxxNXQdosNXVzWpucdxG+fhlZXq7waij9NWj9os54h1jCaWgbvtvBd9Gk75izTRRS
         qjMUHweOBTeonppmZ76v1TtA5YRAHylFFSWNE=
Message-Id: <B167D260-268B-4A50-B51F-6CC43C7C6897@gmail.com>
From: DM Smith <dmsmith555@gmail.com>
To: java-dev@lucene.apache.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Vector and Hashtable usage
Date: Wed, 20 Aug 2008 08:18:40 -0400

I noticed that Vector and Hashtable are fairly widely used in Lucene  
both within classes and in their API. Looking at it, it appears that  
synchronization is inconsistent and that the classes were used more as  
a collection rather than for its sync.

For example, I frequently see something like the following:
for (int i = 0; i < v.size(); i++) {
	Object o = v.getElementAt(i);
}

Since Java 1.2, Vector implements List and Hashtable implements Map.  
When a synchronized List or Map is needed, it can be wrapped with  
Collections.synchronizeList(...) and Collections.synchronizedMap(...).

Am I missing something? Is there a reason for using Vector and  
Hashtable?

Replacing the internal usage is trivial. It's usage in the API is not  
very hard to replace, but it may break backward compatibility.

IIRC that all the methods that return Vector or Hashtable are all  
package protected. I presume that this means that the method is  
private to Lucene (though we all know how to cheat this:) and that  
these can be change easily.

When they are used as a parameter, they can be safely replaced with  
List and Map. If the method or class is final, then there would be no  
break in backward compatibility. If not final, then it breaks  
derivation but not usage.

I was surprised to see that Query uses it for the list of clauses and  
also as a super for a class.

Since we are talking about going to 2.4 and the plan is to get to 3.0  
shortly after that, this is the time to deprecate it's usage in a the  
API.

-- DM Smith


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org