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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to