Generalize interface types where possible and prudent

[frizbog]

(See Issue #79)

There are a number of places where we could use less-specific interface types than we use currently. Scenarios to evaluate on parameters and return types:

• Collections instead of Sets and Lists
  • Set and List should only be used when the type of collection matters
  • Particular attention should be made to using the right underlying implementation:
  • HashSets when duplicates are forbidden but order is not significant
  • LinkedHashSets when duplicates are forbidden but order is significant
  • ArrayLists whenever duplicates are allowed
• CharSequences instead of Strings

Of course, this should only be done when it makes sense.

[frizbog]

I've decided to continue return Strings as return types on the API instead of CharSequences. People generally expect to receive a String back, and expect it to be immutable and have defined behavior for equals() and hashCode(), none of which are guaranteed for CharSequences.

I may still accept CharSequences as parameters into the API from calling code to allow more flexibility for callers.

[frizbog]

Upon further experimentation and consideration, I will not be switching to HashSets in the object model to avoid duplicates.

The lightest Set implementation that ships with Java is a HashSet, and it has an overhead of 32 bytes per entry compared to ArrayList's 4 bytes. When I'm working this hard to reduce the memory footprint (especially for large files), I'm not inclined to add that much memory overhead just to keep users from adding an item to a collection more than once.

An argument could also be made that if someone is reading a GEDCOM file that has duplicated entries in it, that duplication should be preserved in the object model. There's nothing in the GEDCOM spec that specifically forbids it or considers it an error, although I don't know anyone who is arguing that support for duplication is actually desirable.

I am opening another issue, though, for a compromise: The validators could look for duplicates, and if autorepair is enabled in the validators, the duplicates could be automatically removed.

For release 3.0.0, though, Collections are staying Lists backed by ArrayLists, and Maps are remaining HashMaps.

[frizbog]

Decided against using CharSequences anywhere. In order to safely work with the data from a CharSequence, I'd need to make defensive String copies anyway, which further bloats things.