eawagner
commented
8 years ago I understand that this is currently very tightly couple in accumulo-recipes which always assumes that leaf's extend AbstractKeyValueLeaf in order to work.
The way accumulo-recipes uses these objects makes a lot of assumptions about these objects, which probably means that these objects have been created with with wrong abstractions. For instance, perhaps there should be a TermLeaf interface with a term (instead of generic key) for the term portion of a criteria. Additionally, possibly a TypedTermLeaf which additionally returns the class for the types of values. This would sort of solve the issue with Objects being of the wrong type.
Mostly because it is sort of shoe-horned into fit into a key value leaf. Because of this the getValue() method just picks the start value, which is just as arbitrary as if it picks the end value.
This tends to make the API a little clunky, and hard to predict. For instance, if I try to use null to represent the neg infinity bound to the start of a range, then things that rely on using the getValue get the impression that there are no values in the range, even if there is an end value. I am definitely not saying that we should just pick one or the other, I am saying that it should not be treated as a Key/Value object unless the Value is handled as a proper Range object.