@Mr. DOS said:@DeepThought said:The throwing of the exception upon trying to cast the results of the Vector.toArray() to an array of Member[] would be expect.The use of a Vector was the original WTF I was trying to point out. It seems to have gone largely ignored, though...
It's gone largely ignored because it isn't that big of a WTF. As mentioned above, it's pretty standard practice to build a collection and then convert it to an array. Memory usage is a non-issue for several reasons:
Building a collection and converting it to an array creates two memory structures, both with n elements, where n is the number of members returned. However, directly creating an array and populating it also create 2n memory allocations. One for the array, and another for the RecordSet that has to be fully populated in memory so it can be counted. With the collection strategy, the RecordSet can be streamed (assuming it is created as a forward-only RecordSet, which is the default ResultSet).
Returning an array of members isn't the pattern you'd use when you planned on the number of members being large enough to cause memory problems.
So, the lack of memory optimization in the method actually matches the lack of memory optimization in the RecordSet design and the method signature. Personally, I'm OK with it. A lot of people like to think about performance above all else, but I'm a big fan of avoiding premature optimization. The code, as written, is a good example of how to write readable and maintainable code if memory constraints are not an issue. Of course the code isn't perfect, like the strange choice of collection type and other minor issues mentioned in this thread.