Missed something. Please see below...
On Wed, Mar 2, 2016 at 11:49 PM, Gail Badner <gbadner(a)redhat.com> wrote:
ExecutableList#add attempts to keep track of whether the Executable
objects are sorted. [1]
Except for entity insert actions (which use InsertActionSorter),
ExecutableList#add uses the following to determine if adding the current
Executable to the end invalidates the sort:
if ( previousLast != null && previousLast.compareTo( executable ) > 0 ) {
sorted = false;
}
EntityAction#compareTo compares the IDs for the current and previous
EntityAction if they have different entity names; similarly,
CollectionAction compares the collection keys for the current and previous
CollectionAction if they have different entity names.
In most cases, the ID class implements Comparable, although I don't know
of any requirement that says this needs to be true.
This breaks down when a byte[] ID is used as described by HHH-8999. The
reason is that AbstractTypeDescriptor#comparator is null because it is
assigned like this:
this.comparator = Comparable.class.isAssignableFrom( type )
? (Comparator<T>) ComparableComparator.INSTANCE
: null;
PrimitiveByteArrayTypeDescriptor does not override
AbstractTypeDescriptor#getComparator, so null is returned ultimately
causing a NullPointerException in AbstractStandardBasicType#compare:
public final int compare(Object x, Object y) {
return javaTypeDescriptor.getComparator().compare( (T) x, (T) y );
}
The same happens for PrimitiveCharacterArrayTypeDescriptor,
ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor. Are there others?
According to HHH-10413, this also affects version attributes.
Here are a couple of alternatives:
A) create comparators for PrimitiveCharacterArrayTypeDescriptor,
ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor.
PrimitiveByteArrayTypeDescript should also be in the list for A).
B) Change AbstractTypeDescriptor#comparator to:
this.comparator = Comparable.class.isAssignableFrom( type )
? (Comparator<T>) ComparableComparator.INSTANCE
: IncomparableComparator.INSTANCE;
IncomparableComparator#compare always returns 0, so that comparison would
never invalidate the sort.
B) is not acceptable for PrimitiveByteArrayTypeDescripter because a version
attribute can be of type byte[]. We definitely do not want all byte[]
version values to compare as equal. A Comparator needs to be implemented at
least for PrimitiveByteArrayTypeDescripter.
The following question only applies to
PrimitiveCharacterArrayTypeDescriptor, ByteArrayTypeDescriptor, and
CharacterArrayTypeDescriptor.
Does it make sense to sort Executable objects by an ID or collection
key
that is an array? In other words, would such IDs be generated in a natural
order? If not, I think B) makes more sense.