Hcfyk

You could add a second property (say int id or long id) which would be unique for each instance of your class (you can have a static counter variable and use it to initialize the id in your constructor).

Then your compareTo method can first compare the names, and if the names are equal, compare the ids.

Since each instance has a different id, compareTo will never return 0.

By definition, by assigning each object a Universally unique identifier (UUID) (or a Globally unique identifier, (GUID)) as it's identity property, the UUID is comparable, and consistent with equals. Java already has a UUID class, and once generated, you can just use the string representation for persistence. The dedicated property will also insure that the identity is stable across versions/threads/machines. You could also just use an incrementing ID if you have a method of insuring everything gets a unique ID, but using a standard UUID implementation will protect you from issues from set merges and parallel systems generating data at the same time.

If you use anything else for the comparable, that means that it is comparable in a way separate from its identity/value. So you will need to define what comparable means for this object, and document that. For example, people are comparable by name, DOB, height, or a combination by order of precedence; most naturally by name as a convention (for easier lookup by humans) which is separate from if two people are the same person. You will also have to accept that compareto and equals are disjoint because they are based on different things.

While I stick by my original answer that you should use a UUID property for a stable and consistent compare / equality setup, I figured I'd go ahead an answer the question of "how far could you go if you were REALLY paranoid and wanted a guaranteed unique identity for comparable".

Basically, in short if you don't trust UUID uniqueness or identity uniqueness, just use as many UUIDs as it takes to prove god is actively conspiring against you. (Note that while not technically guaranteed not to throw an exception, needing 2 UUID should be overkill in any sane universe.)

import java.time.Instant;

import java.util.ArrayList;

import java.util.UUID;



public class Test implements Comparable<Test>{



    private final UUID antiCollisionProp = UUID.randomUUID();

    private final ArrayList<UUID> antiuniverseProp = new ArrayList<UUID>();



    private UUID getParanoiaLevelId(int i) {

        while(antiuniverseProp.size() < i) {

            antiuniverseProp.add(UUID.randomUUID());

        }



        return antiuniverseProp.get(i);

    }



    @Override

    public int compareTo(Test o) {

        if(this == o)

            return 0;



        int temp = System.identityHashCode(this) - System.identityHashCode(o);

        if(temp != 0)

            return temp;



        //If the universe hates you

        temp = this.antiCollisionProp.compareTo(o.antiCollisionProp);

        if(temp != 0)

            return temp;



        //If the universe is activly out to get you

        temp = System.identityHashCode(this.antiCollisionProp) - System.identityHashCode(o.antiCollisionProp);;

        if(temp != 0)

            return temp;



        for(int i = 0; i < Integer.MAX_VALUE; i++) {

            UUID id1 = this.getParanoiaLevelId(i);

            UUID id2 = o.getParanoiaLevelId(i);

            temp = id1.compareTo(id2);

            if(temp != 0)

                return temp;



            temp = System.identityHashCode(id1) - System.identityHashCode(id2);;

            if(temp != 0)

                return temp;

        }



        // If you reach this point, I have no idea what you did to deserve this

        throw new IllegalStateException("RAGNAROK HAS COME! THE MIDGARD SERPENT AWAKENS!");

    }



}

Assuming that with two objects with same name, if equals() returns false then compareTo() should not return 0. If this is what you want to do then following can help:

• Override hashcode() and make sure it doesn't rely solely on name
  


• Implement compareTo() as follows:

public void compareTo(MyObject object) {

    this.equals(object) ? this.hashcode() - object.hashcode() : this.getName().compareTo(object.getName());

}

You are having unique objects, but as Eran said you may need an extra counter/rehash code for any collisions.

private static Set<Pair<C, C> collisions = ...;



@Override

public boolean equals(C other) {

    return this == other;

}



@Override

public int compareTo(C other) {

    ...

    if (this == other) {

        return 0

    }

    if (super.equals(other)) {

        // Some stable order would be fine:

        // return either -1 or 1

        if (collisions.contains(new Pair(other, this)) {

            return 1;

        } else if (!collisions.contains(new Pair(this, other)) {

            collisions.add(new Par(this, other));

        }

        return 1;

    }

    ...

}

So go with the answer of Eran or put the requirement as such in question.

• One might consider the overhead of non-identical 0 comparisons neglectable.


• One might look into ideal hash functions, if at some point of time no longer instances are created. This implies you have a collection of all instances.