A single instance of ComplexKey might hold something like: a String, an
Integer and a Double. Simply put, the type of values you could find in the
fields of a primary key in a relational db.

Yes, I think you're correct here.
A single instance of the ComplexKey can hold several different types in its
array, with the only common denominator being that they are comparable to
their own types - not to each other.

They all must implement Comparable, because otherwise the ComplexKey itself
can't become Comparable. (So changing the signature to accepting an array
of Objects would not be satisfactory).

Basically, the ComplexKey class is used for caching record keys from db
tables. In practice, this means that ComplexKeys are compared with other
ComplexKeys built with records from the same table (same order of class
instances in the keyValues array). To be more concrete, an instance of
ComplexKey holding a reference to a record in table "Orders" will only be
compared to other ComplexKeys referencing that same table, "Orders", never
to records in a table "Farmers". Attempting this would most likely throw a
run-time error, as two different tables are likely to have different types
of primary keys.

Does this mean that I should create a subclass of ComplexKey for every
possible combination of field types in the primary key? Rather than
accepting an array with field values, each subclass would have a different
constructor:

  public ComplexKey(Integer farmerId)
  public ComplexKey(Integer farmerId, Integer Year, Integer speciesId)

This would create an explosion of classes and seems like a lot of work...