How to implement Comparable so it is consistent with identity-equality Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern) Data science time! April 2019 and salary with experience Should we burninate the [wrap] tag? The Ask Question Wizard is Live!How do I efficiently iterate over each entry in a Java Map?How do I read / convert an InputStream into a String in Java?How do I generate random integers within a specific range in Java?“implements Runnable” vs “extends Thread” in JavaComparing Java enum members: == or equals()?How does a ArrayList's contains() method evaluate objects?How do I convert a String to an int in Java?equals() vs compareTo() in Comparator/able (Theoretical)What does comparison being consistent with equals mean ? What can possibly happen if my class doesn't follow this principle?consequence of compare() method of Comparator interface not consistent with equals() method

What is known about the Ubaid lizard-people figurines?

Book where humans were engineered with genes from animal species to survive hostile planets

Sci-Fi book where patients in a coma ward all live in a subconscious world linked together

How do I keep my slimes from escaping their pens?

What does this icon in iOS Stardew Valley mean?

In predicate logic, does existential quantification (∃) include universal quantification (∀), i.e. can 'some' imply 'all'?

Should I use a zero-interest credit card for a large one-time purchase?

Can an alien society believe that their star system is the universe?

How come Sam didn't become Lord of Horn Hill?

How to override model in magento2?

If a contract sometimes uses the wrong name, is it still valid?

Compare a given version number in the form major.minor.build.patch and see if one is less than the other

Gordon Ramsay Pudding Recipe

When were vectors invented?

Why do people hide their license plates in the EU?

Why are both D and D# fitting into my E minor key?

ListPlot join points by nearest neighbor rather than order

How do I stop a creek from eroding my steep embankment?

What exactly is a "Meth" in Altered Carbon?

Is the Standard Deduction better than Itemized when both are the same amount?

Seeking colloquialism for “just because”

Why do we bend a book to keep it straight?

How to tell that you are a giant?

Extract all GPU name, model and GPU ram



How to implement Comparable so it is consistent with identity-equality



Announcing the arrival of Valued Associate #679: Cesar Manara
Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)
Data science time! April 2019 and salary with experience
Should we burninate the [wrap] tag?
The Ask Question Wizard is Live!How do I efficiently iterate over each entry in a Java Map?How do I read / convert an InputStream into a String in Java?How do I generate random integers within a specific range in Java?“implements Runnable” vs “extends Thread” in JavaComparing Java enum members: == or equals()?How does a ArrayList's contains() method evaluate objects?How do I convert a String to an int in Java?equals() vs compareTo() in Comparator/able (Theoretical)What does comparison being consistent with equals mean ? What can possibly happen if my class doesn't follow this principle?consequence of compare() method of Comparator interface not consistent with equals() method



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








17















I have a class for which equality (as per equals()) must be defined by the object identity, i.e. this == other.



I want to implement Comparable to order such objects (say by some getName() property). To be consistent with equals(), compareTo() must not return 0, even if two objects have the same name.



Is there a way to compare object identities in the sense of compareTo? I could compare System.identityHashCode(o), but that would still return 0 in case of hash collisions.










share|improve this question
























  • compareTo() must not return 0, even if two objects have the same name., This will break the contract of compareTo, and thus such a compareTo would be unusable

    – Lino
    Apr 1 at 8:18






  • 3





    Which clause of the contract would be broken exactly?

    – Balz Guenat
    Apr 1 at 8:21











  • Did you mean you want when A and B have getName() equal, you don't care whether A > B or B > A, but you want consistent result i.e. if for once A > B is true, then A > B is always true throughout the whole process lifetime?

    – Ricky Mo
    Apr 1 at 8:25











  • @RickyMo right.

    – Balz Guenat
    Apr 1 at 8:31






  • 3





    @Lino: It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y))

    – Haem
    Apr 1 at 9:40

















17















I have a class for which equality (as per equals()) must be defined by the object identity, i.e. this == other.



I want to implement Comparable to order such objects (say by some getName() property). To be consistent with equals(), compareTo() must not return 0, even if two objects have the same name.



Is there a way to compare object identities in the sense of compareTo? I could compare System.identityHashCode(o), but that would still return 0 in case of hash collisions.










share|improve this question
























  • compareTo() must not return 0, even if two objects have the same name., This will break the contract of compareTo, and thus such a compareTo would be unusable

    – Lino
    Apr 1 at 8:18






  • 3





    Which clause of the contract would be broken exactly?

    – Balz Guenat
    Apr 1 at 8:21











  • Did you mean you want when A and B have getName() equal, you don't care whether A > B or B > A, but you want consistent result i.e. if for once A > B is true, then A > B is always true throughout the whole process lifetime?

    – Ricky Mo
    Apr 1 at 8:25











  • @RickyMo right.

    – Balz Guenat
    Apr 1 at 8:31






  • 3





    @Lino: It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y))

    – Haem
    Apr 1 at 9:40













17












17








17


0






I have a class for which equality (as per equals()) must be defined by the object identity, i.e. this == other.



I want to implement Comparable to order such objects (say by some getName() property). To be consistent with equals(), compareTo() must not return 0, even if two objects have the same name.



Is there a way to compare object identities in the sense of compareTo? I could compare System.identityHashCode(o), but that would still return 0 in case of hash collisions.










share|improve this question
















I have a class for which equality (as per equals()) must be defined by the object identity, i.e. this == other.



I want to implement Comparable to order such objects (say by some getName() property). To be consistent with equals(), compareTo() must not return 0, even if two objects have the same name.



Is there a way to compare object identities in the sense of compareTo? I could compare System.identityHashCode(o), but that would still return 0 in case of hash collisions.







java equals comparator comparable






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Apr 1 at 18:46









Peter Mortensen

13.9k1987114




13.9k1987114










asked Apr 1 at 8:10









Balz GuenatBalz Guenat

4572519




4572519












  • compareTo() must not return 0, even if two objects have the same name., This will break the contract of compareTo, and thus such a compareTo would be unusable

    – Lino
    Apr 1 at 8:18






  • 3





    Which clause of the contract would be broken exactly?

    – Balz Guenat
    Apr 1 at 8:21











  • Did you mean you want when A and B have getName() equal, you don't care whether A > B or B > A, but you want consistent result i.e. if for once A > B is true, then A > B is always true throughout the whole process lifetime?

    – Ricky Mo
    Apr 1 at 8:25











  • @RickyMo right.

    – Balz Guenat
    Apr 1 at 8:31






  • 3





    @Lino: It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y))

    – Haem
    Apr 1 at 9:40

















  • compareTo() must not return 0, even if two objects have the same name., This will break the contract of compareTo, and thus such a compareTo would be unusable

    – Lino
    Apr 1 at 8:18






  • 3





    Which clause of the contract would be broken exactly?

    – Balz Guenat
    Apr 1 at 8:21











  • Did you mean you want when A and B have getName() equal, you don't care whether A > B or B > A, but you want consistent result i.e. if for once A > B is true, then A > B is always true throughout the whole process lifetime?

    – Ricky Mo
    Apr 1 at 8:25











  • @RickyMo right.

    – Balz Guenat
    Apr 1 at 8:31






  • 3





    @Lino: It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y))

    – Haem
    Apr 1 at 9:40
















compareTo() must not return 0, even if two objects have the same name., This will break the contract of compareTo, and thus such a compareTo would be unusable

– Lino
Apr 1 at 8:18





compareTo() must not return 0, even if two objects have the same name., This will break the contract of compareTo, and thus such a compareTo would be unusable

– Lino
Apr 1 at 8:18




3




3





Which clause of the contract would be broken exactly?

– Balz Guenat
Apr 1 at 8:21





Which clause of the contract would be broken exactly?

– Balz Guenat
Apr 1 at 8:21













Did you mean you want when A and B have getName() equal, you don't care whether A > B or B > A, but you want consistent result i.e. if for once A > B is true, then A > B is always true throughout the whole process lifetime?

– Ricky Mo
Apr 1 at 8:25





Did you mean you want when A and B have getName() equal, you don't care whether A > B or B > A, but you want consistent result i.e. if for once A > B is true, then A > B is always true throughout the whole process lifetime?

– Ricky Mo
Apr 1 at 8:25













@RickyMo right.

– Balz Guenat
Apr 1 at 8:31





@RickyMo right.

– Balz Guenat
Apr 1 at 8:31




3




3





@Lino: It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y))

– Haem
Apr 1 at 9:40





@Lino: It is strongly recommended, but not strictly required that (x.compareTo(y)==0) == (x.equals(y))

– Haem
Apr 1 at 9:40












6 Answers
6






active

oldest

votes


















31














I think the real answer here is: don't implement Comparable then. Implementing this interface implies that your objects have a natural order. Things that are "equal" should be in the same place when you follow up that thought.



If at all, you should use a custom comparator ... but even that doesn't make much sense. If the thing that defines a < b ... is not allowed to give you a == b (when a and b are "equal" according to your < relation), then the whole approach of comparing is broken for your use case.



In other words: just because you can put code into a class that "somehow" results in what you want ... doesn't make it a good idea to do so.






share|improve this answer


















  • 8





    A comparator seems like a non-broken solution. Even if the expectation of Comparable is that compare==0 only when the two objects are equal, a comparator does not have that expectation.

    – khelwood
    Apr 1 at 8:23






  • 2





    Hm yes, I think what's really happening is that my objects really only have a partial ordering and I'm trying to force a total ordering using object identity. When I want to sort these objects, I can use a separate Comparator where it is not an issue if two different objects are "equal".

    – Balz Guenat
    Apr 1 at 8:38











  • @BalzGuenat That sounds like a reasonable approach. Especially given the fact that this will avoid the headaches you get when thinking how to properly implement a reasonable hashcode for your class ;-)

    – GhostCat
    Apr 1 at 8:46






  • 1





    @BalzGuenat But then you define your order to be TWO orders. What you are asking for ... isn't that different. Like merging an "order" with ... well, something that is not?

    – GhostCat
    Apr 1 at 12:15






  • 1





    @Balz Your problem is inherently different from chained comparators. Chained comparators are independent of each other, particularly the result of the first does not depend on the latter. If you want to make your equals consistent with compareTo you'll have to violate one of the two contracts (there is btw. no requirement for equals being consistent with compareTo so that's your escape hatch if you wanted to - bad idea though). Even if you could represent object identity as a long you couldn't get around that.

    – Voo
    Apr 1 at 14:59



















5














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.






share|improve this answer


















  • 1





    This sounds simple at first but becomes tricky once multiple threads create objects and the counter has to be synchronized. It would also complicate things if you wanted to (de)serialize objects, as the ID would have to be regenerated.

    – Balz Guenat
    Apr 1 at 8:20











  • @BalzGuenat yes, the counter would have to be synchronized to support multiple threads. And as for (de)serialization, the id would have to be serialized.

    – Eran
    Apr 1 at 8:37






  • 1





    "the id would have to be serialized." Well, no, because then you'd end up with multiple objects with the same ID. Say execution 1 of the program will create an object with ID 42, serializes it and stores it on disk. Execution 2 then creates its own object with ID 42 but also deserializes the object from execution 1, resulting in two objects with the same ID. There are solutions to this of course, but it gets way too complicated for the task at hand.

    – Balz Guenat
    Apr 1 at 8:45











  • @BalzGuenat good point.

    – Eran
    Apr 1 at 8:47






  • 1





    The second property can be the hashCode. And with using the hashCode, I think this is the correct answer as it implements an order relation that is consistent with the equals implementation.

    – kutschkem
    Apr 1 at 10:07



















5














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.






share|improve this answer

























  • You could explain where to get that UUID, and why collision isn't a (practical) problem.

    – Yakk - Adam Nevraumont
    Apr 1 at 15:43











  • @Yakk-AdamNevraumont Added links and expanded a little. I didn't go into detail of the UUID because I want to stress more the "unique id" part. UUID is just an implementation provided by Java.

    – Tezra
    Apr 1 at 16:06


















1














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!");








share|improve this answer
































    0














    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());






    share|improve this answer























    • Object.hashCode has the same problem as System.identityHashCode in that in case of a collision, compareTo will return 0 for two different objects.

      – Balz Guenat
      Apr 1 at 8:22











    • That is the reason why I advised overriding hashcode() and make it rely not just on name.

      – Darshan Mehta
      Apr 1 at 8:26











    • any hash function, by definition, will have collisions, regardless of whether it relies on just the name or not.

      – Balz Guenat
      Apr 1 at 8:33


















    0














    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.





    share|improve this answer




















    • 1





      This is basically a resource leak; anything that every collided has its lifetime extended to the end of the program. Thanks however, I can use this as a good example of why garbage collection doesn't imply no resource leaks.

      – Yakk - Adam Nevraumont
      Apr 1 at 15:44












    • @Yakk-AdamNevraumont true, just the mention of static should trigger an immediate nausea. "So go with the answer of Eran". The code was just a temptative argument. There is something fishy here, Eran's solution is probably also not what is actually desired. Does the OP want an ideal hash function?

      – Joop Eggen
      Apr 1 at 15:55






    • 1





      Contrary to all other solutions this can at least be made to work correctly without violating either equals or compareTo contracts. Although if your solution involves WeakHashMaps you already have much bigger problems.

      – Voo
      Apr 1 at 16:31











    • @Voo but compareTo only returns 0 or 1... Is the second 1 supposed to be -1 or is there a return -1 missing? Also would probably be more efficient to just remove static and just use system.idenity on that object to resolve collisions. If you have 2 collisions, that should prove god hates you. =P

      – Tezra
      Apr 2 at 19:18











    • @Tezra "Made to work", agreed that the current solution is not going to be correct.

      – Voo
      Apr 2 at 19:27











    Your Answer






    StackExchange.ifUsing("editor", function ()
    StackExchange.using("externalEditor", function ()
    StackExchange.using("snippets", function ()
    StackExchange.snippets.init();
    );
    );
    , "code-snippets");

    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "1"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader:
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    ,
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );













    draft saved

    draft discarded


















    StackExchange.ready(
    function ()
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55450569%2fhow-to-implement-comparable-so-it-is-consistent-with-identity-equality%23new-answer', 'question_page');

    );

    Post as a guest















    Required, but never shown

























    6 Answers
    6






    active

    oldest

    votes








    6 Answers
    6






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    31














    I think the real answer here is: don't implement Comparable then. Implementing this interface implies that your objects have a natural order. Things that are "equal" should be in the same place when you follow up that thought.



    If at all, you should use a custom comparator ... but even that doesn't make much sense. If the thing that defines a < b ... is not allowed to give you a == b (when a and b are "equal" according to your < relation), then the whole approach of comparing is broken for your use case.



    In other words: just because you can put code into a class that "somehow" results in what you want ... doesn't make it a good idea to do so.






    share|improve this answer


















    • 8





      A comparator seems like a non-broken solution. Even if the expectation of Comparable is that compare==0 only when the two objects are equal, a comparator does not have that expectation.

      – khelwood
      Apr 1 at 8:23






    • 2





      Hm yes, I think what's really happening is that my objects really only have a partial ordering and I'm trying to force a total ordering using object identity. When I want to sort these objects, I can use a separate Comparator where it is not an issue if two different objects are "equal".

      – Balz Guenat
      Apr 1 at 8:38











    • @BalzGuenat That sounds like a reasonable approach. Especially given the fact that this will avoid the headaches you get when thinking how to properly implement a reasonable hashcode for your class ;-)

      – GhostCat
      Apr 1 at 8:46






    • 1





      @BalzGuenat But then you define your order to be TWO orders. What you are asking for ... isn't that different. Like merging an "order" with ... well, something that is not?

      – GhostCat
      Apr 1 at 12:15






    • 1





      @Balz Your problem is inherently different from chained comparators. Chained comparators are independent of each other, particularly the result of the first does not depend on the latter. If you want to make your equals consistent with compareTo you'll have to violate one of the two contracts (there is btw. no requirement for equals being consistent with compareTo so that's your escape hatch if you wanted to - bad idea though). Even if you could represent object identity as a long you couldn't get around that.

      – Voo
      Apr 1 at 14:59
















    31














    I think the real answer here is: don't implement Comparable then. Implementing this interface implies that your objects have a natural order. Things that are "equal" should be in the same place when you follow up that thought.



    If at all, you should use a custom comparator ... but even that doesn't make much sense. If the thing that defines a < b ... is not allowed to give you a == b (when a and b are "equal" according to your < relation), then the whole approach of comparing is broken for your use case.



    In other words: just because you can put code into a class that "somehow" results in what you want ... doesn't make it a good idea to do so.






    share|improve this answer


















    • 8





      A comparator seems like a non-broken solution. Even if the expectation of Comparable is that compare==0 only when the two objects are equal, a comparator does not have that expectation.

      – khelwood
      Apr 1 at 8:23






    • 2





      Hm yes, I think what's really happening is that my objects really only have a partial ordering and I'm trying to force a total ordering using object identity. When I want to sort these objects, I can use a separate Comparator where it is not an issue if two different objects are "equal".

      – Balz Guenat
      Apr 1 at 8:38











    • @BalzGuenat That sounds like a reasonable approach. Especially given the fact that this will avoid the headaches you get when thinking how to properly implement a reasonable hashcode for your class ;-)

      – GhostCat
      Apr 1 at 8:46






    • 1





      @BalzGuenat But then you define your order to be TWO orders. What you are asking for ... isn't that different. Like merging an "order" with ... well, something that is not?

      – GhostCat
      Apr 1 at 12:15






    • 1





      @Balz Your problem is inherently different from chained comparators. Chained comparators are independent of each other, particularly the result of the first does not depend on the latter. If you want to make your equals consistent with compareTo you'll have to violate one of the two contracts (there is btw. no requirement for equals being consistent with compareTo so that's your escape hatch if you wanted to - bad idea though). Even if you could represent object identity as a long you couldn't get around that.

      – Voo
      Apr 1 at 14:59














    31












    31








    31







    I think the real answer here is: don't implement Comparable then. Implementing this interface implies that your objects have a natural order. Things that are "equal" should be in the same place when you follow up that thought.



    If at all, you should use a custom comparator ... but even that doesn't make much sense. If the thing that defines a < b ... is not allowed to give you a == b (when a and b are "equal" according to your < relation), then the whole approach of comparing is broken for your use case.



    In other words: just because you can put code into a class that "somehow" results in what you want ... doesn't make it a good idea to do so.






    share|improve this answer













    I think the real answer here is: don't implement Comparable then. Implementing this interface implies that your objects have a natural order. Things that are "equal" should be in the same place when you follow up that thought.



    If at all, you should use a custom comparator ... but even that doesn't make much sense. If the thing that defines a < b ... is not allowed to give you a == b (when a and b are "equal" according to your < relation), then the whole approach of comparing is broken for your use case.



    In other words: just because you can put code into a class that "somehow" results in what you want ... doesn't make it a good idea to do so.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Apr 1 at 8:19









    GhostCatGhostCat

    96.6k1794164




    96.6k1794164







    • 8





      A comparator seems like a non-broken solution. Even if the expectation of Comparable is that compare==0 only when the two objects are equal, a comparator does not have that expectation.

      – khelwood
      Apr 1 at 8:23






    • 2





      Hm yes, I think what's really happening is that my objects really only have a partial ordering and I'm trying to force a total ordering using object identity. When I want to sort these objects, I can use a separate Comparator where it is not an issue if two different objects are "equal".

      – Balz Guenat
      Apr 1 at 8:38











    • @BalzGuenat That sounds like a reasonable approach. Especially given the fact that this will avoid the headaches you get when thinking how to properly implement a reasonable hashcode for your class ;-)

      – GhostCat
      Apr 1 at 8:46






    • 1





      @BalzGuenat But then you define your order to be TWO orders. What you are asking for ... isn't that different. Like merging an "order" with ... well, something that is not?

      – GhostCat
      Apr 1 at 12:15






    • 1





      @Balz Your problem is inherently different from chained comparators. Chained comparators are independent of each other, particularly the result of the first does not depend on the latter. If you want to make your equals consistent with compareTo you'll have to violate one of the two contracts (there is btw. no requirement for equals being consistent with compareTo so that's your escape hatch if you wanted to - bad idea though). Even if you could represent object identity as a long you couldn't get around that.

      – Voo
      Apr 1 at 14:59













    • 8





      A comparator seems like a non-broken solution. Even if the expectation of Comparable is that compare==0 only when the two objects are equal, a comparator does not have that expectation.

      – khelwood
      Apr 1 at 8:23






    • 2





      Hm yes, I think what's really happening is that my objects really only have a partial ordering and I'm trying to force a total ordering using object identity. When I want to sort these objects, I can use a separate Comparator where it is not an issue if two different objects are "equal".

      – Balz Guenat
      Apr 1 at 8:38











    • @BalzGuenat That sounds like a reasonable approach. Especially given the fact that this will avoid the headaches you get when thinking how to properly implement a reasonable hashcode for your class ;-)

      – GhostCat
      Apr 1 at 8:46






    • 1





      @BalzGuenat But then you define your order to be TWO orders. What you are asking for ... isn't that different. Like merging an "order" with ... well, something that is not?

      – GhostCat
      Apr 1 at 12:15






    • 1





      @Balz Your problem is inherently different from chained comparators. Chained comparators are independent of each other, particularly the result of the first does not depend on the latter. If you want to make your equals consistent with compareTo you'll have to violate one of the two contracts (there is btw. no requirement for equals being consistent with compareTo so that's your escape hatch if you wanted to - bad idea though). Even if you could represent object identity as a long you couldn't get around that.

      – Voo
      Apr 1 at 14:59








    8




    8





    A comparator seems like a non-broken solution. Even if the expectation of Comparable is that compare==0 only when the two objects are equal, a comparator does not have that expectation.

    – khelwood
    Apr 1 at 8:23





    A comparator seems like a non-broken solution. Even if the expectation of Comparable is that compare==0 only when the two objects are equal, a comparator does not have that expectation.

    – khelwood
    Apr 1 at 8:23




    2




    2





    Hm yes, I think what's really happening is that my objects really only have a partial ordering and I'm trying to force a total ordering using object identity. When I want to sort these objects, I can use a separate Comparator where it is not an issue if two different objects are "equal".

    – Balz Guenat
    Apr 1 at 8:38





    Hm yes, I think what's really happening is that my objects really only have a partial ordering and I'm trying to force a total ordering using object identity. When I want to sort these objects, I can use a separate Comparator where it is not an issue if two different objects are "equal".

    – Balz Guenat
    Apr 1 at 8:38













    @BalzGuenat That sounds like a reasonable approach. Especially given the fact that this will avoid the headaches you get when thinking how to properly implement a reasonable hashcode for your class ;-)

    – GhostCat
    Apr 1 at 8:46





    @BalzGuenat That sounds like a reasonable approach. Especially given the fact that this will avoid the headaches you get when thinking how to properly implement a reasonable hashcode for your class ;-)

    – GhostCat
    Apr 1 at 8:46




    1




    1





    @BalzGuenat But then you define your order to be TWO orders. What you are asking for ... isn't that different. Like merging an "order" with ... well, something that is not?

    – GhostCat
    Apr 1 at 12:15





    @BalzGuenat But then you define your order to be TWO orders. What you are asking for ... isn't that different. Like merging an "order" with ... well, something that is not?

    – GhostCat
    Apr 1 at 12:15




    1




    1





    @Balz Your problem is inherently different from chained comparators. Chained comparators are independent of each other, particularly the result of the first does not depend on the latter. If you want to make your equals consistent with compareTo you'll have to violate one of the two contracts (there is btw. no requirement for equals being consistent with compareTo so that's your escape hatch if you wanted to - bad idea though). Even if you could represent object identity as a long you couldn't get around that.

    – Voo
    Apr 1 at 14:59






    @Balz Your problem is inherently different from chained comparators. Chained comparators are independent of each other, particularly the result of the first does not depend on the latter. If you want to make your equals consistent with compareTo you'll have to violate one of the two contracts (there is btw. no requirement for equals being consistent with compareTo so that's your escape hatch if you wanted to - bad idea though). Even if you could represent object identity as a long you couldn't get around that.

    – Voo
    Apr 1 at 14:59














    5














    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.






    share|improve this answer


















    • 1





      This sounds simple at first but becomes tricky once multiple threads create objects and the counter has to be synchronized. It would also complicate things if you wanted to (de)serialize objects, as the ID would have to be regenerated.

      – Balz Guenat
      Apr 1 at 8:20











    • @BalzGuenat yes, the counter would have to be synchronized to support multiple threads. And as for (de)serialization, the id would have to be serialized.

      – Eran
      Apr 1 at 8:37






    • 1





      "the id would have to be serialized." Well, no, because then you'd end up with multiple objects with the same ID. Say execution 1 of the program will create an object with ID 42, serializes it and stores it on disk. Execution 2 then creates its own object with ID 42 but also deserializes the object from execution 1, resulting in two objects with the same ID. There are solutions to this of course, but it gets way too complicated for the task at hand.

      – Balz Guenat
      Apr 1 at 8:45











    • @BalzGuenat good point.

      – Eran
      Apr 1 at 8:47






    • 1





      The second property can be the hashCode. And with using the hashCode, I think this is the correct answer as it implements an order relation that is consistent with the equals implementation.

      – kutschkem
      Apr 1 at 10:07
















    5














    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.






    share|improve this answer


















    • 1





      This sounds simple at first but becomes tricky once multiple threads create objects and the counter has to be synchronized. It would also complicate things if you wanted to (de)serialize objects, as the ID would have to be regenerated.

      – Balz Guenat
      Apr 1 at 8:20











    • @BalzGuenat yes, the counter would have to be synchronized to support multiple threads. And as for (de)serialization, the id would have to be serialized.

      – Eran
      Apr 1 at 8:37






    • 1





      "the id would have to be serialized." Well, no, because then you'd end up with multiple objects with the same ID. Say execution 1 of the program will create an object with ID 42, serializes it and stores it on disk. Execution 2 then creates its own object with ID 42 but also deserializes the object from execution 1, resulting in two objects with the same ID. There are solutions to this of course, but it gets way too complicated for the task at hand.

      – Balz Guenat
      Apr 1 at 8:45











    • @BalzGuenat good point.

      – Eran
      Apr 1 at 8:47






    • 1





      The second property can be the hashCode. And with using the hashCode, I think this is the correct answer as it implements an order relation that is consistent with the equals implementation.

      – kutschkem
      Apr 1 at 10:07














    5












    5








    5







    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.






    share|improve this answer













    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.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Apr 1 at 8:16









    EranEran

    293k37483565




    293k37483565







    • 1





      This sounds simple at first but becomes tricky once multiple threads create objects and the counter has to be synchronized. It would also complicate things if you wanted to (de)serialize objects, as the ID would have to be regenerated.

      – Balz Guenat
      Apr 1 at 8:20











    • @BalzGuenat yes, the counter would have to be synchronized to support multiple threads. And as for (de)serialization, the id would have to be serialized.

      – Eran
      Apr 1 at 8:37






    • 1





      "the id would have to be serialized." Well, no, because then you'd end up with multiple objects with the same ID. Say execution 1 of the program will create an object with ID 42, serializes it and stores it on disk. Execution 2 then creates its own object with ID 42 but also deserializes the object from execution 1, resulting in two objects with the same ID. There are solutions to this of course, but it gets way too complicated for the task at hand.

      – Balz Guenat
      Apr 1 at 8:45











    • @BalzGuenat good point.

      – Eran
      Apr 1 at 8:47






    • 1





      The second property can be the hashCode. And with using the hashCode, I think this is the correct answer as it implements an order relation that is consistent with the equals implementation.

      – kutschkem
      Apr 1 at 10:07













    • 1





      This sounds simple at first but becomes tricky once multiple threads create objects and the counter has to be synchronized. It would also complicate things if you wanted to (de)serialize objects, as the ID would have to be regenerated.

      – Balz Guenat
      Apr 1 at 8:20











    • @BalzGuenat yes, the counter would have to be synchronized to support multiple threads. And as for (de)serialization, the id would have to be serialized.

      – Eran
      Apr 1 at 8:37






    • 1





      "the id would have to be serialized." Well, no, because then you'd end up with multiple objects with the same ID. Say execution 1 of the program will create an object with ID 42, serializes it and stores it on disk. Execution 2 then creates its own object with ID 42 but also deserializes the object from execution 1, resulting in two objects with the same ID. There are solutions to this of course, but it gets way too complicated for the task at hand.

      – Balz Guenat
      Apr 1 at 8:45











    • @BalzGuenat good point.

      – Eran
      Apr 1 at 8:47






    • 1





      The second property can be the hashCode. And with using the hashCode, I think this is the correct answer as it implements an order relation that is consistent with the equals implementation.

      – kutschkem
      Apr 1 at 10:07








    1




    1





    This sounds simple at first but becomes tricky once multiple threads create objects and the counter has to be synchronized. It would also complicate things if you wanted to (de)serialize objects, as the ID would have to be regenerated.

    – Balz Guenat
    Apr 1 at 8:20





    This sounds simple at first but becomes tricky once multiple threads create objects and the counter has to be synchronized. It would also complicate things if you wanted to (de)serialize objects, as the ID would have to be regenerated.

    – Balz Guenat
    Apr 1 at 8:20













    @BalzGuenat yes, the counter would have to be synchronized to support multiple threads. And as for (de)serialization, the id would have to be serialized.

    – Eran
    Apr 1 at 8:37





    @BalzGuenat yes, the counter would have to be synchronized to support multiple threads. And as for (de)serialization, the id would have to be serialized.

    – Eran
    Apr 1 at 8:37




    1




    1





    "the id would have to be serialized." Well, no, because then you'd end up with multiple objects with the same ID. Say execution 1 of the program will create an object with ID 42, serializes it and stores it on disk. Execution 2 then creates its own object with ID 42 but also deserializes the object from execution 1, resulting in two objects with the same ID. There are solutions to this of course, but it gets way too complicated for the task at hand.

    – Balz Guenat
    Apr 1 at 8:45





    "the id would have to be serialized." Well, no, because then you'd end up with multiple objects with the same ID. Say execution 1 of the program will create an object with ID 42, serializes it and stores it on disk. Execution 2 then creates its own object with ID 42 but also deserializes the object from execution 1, resulting in two objects with the same ID. There are solutions to this of course, but it gets way too complicated for the task at hand.

    – Balz Guenat
    Apr 1 at 8:45













    @BalzGuenat good point.

    – Eran
    Apr 1 at 8:47





    @BalzGuenat good point.

    – Eran
    Apr 1 at 8:47




    1




    1





    The second property can be the hashCode. And with using the hashCode, I think this is the correct answer as it implements an order relation that is consistent with the equals implementation.

    – kutschkem
    Apr 1 at 10:07






    The second property can be the hashCode. And with using the hashCode, I think this is the correct answer as it implements an order relation that is consistent with the equals implementation.

    – kutschkem
    Apr 1 at 10:07












    5














    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.






    share|improve this answer

























    • You could explain where to get that UUID, and why collision isn't a (practical) problem.

      – Yakk - Adam Nevraumont
      Apr 1 at 15:43











    • @Yakk-AdamNevraumont Added links and expanded a little. I didn't go into detail of the UUID because I want to stress more the "unique id" part. UUID is just an implementation provided by Java.

      – Tezra
      Apr 1 at 16:06















    5














    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.






    share|improve this answer

























    • You could explain where to get that UUID, and why collision isn't a (practical) problem.

      – Yakk - Adam Nevraumont
      Apr 1 at 15:43











    • @Yakk-AdamNevraumont Added links and expanded a little. I didn't go into detail of the UUID because I want to stress more the "unique id" part. UUID is just an implementation provided by Java.

      – Tezra
      Apr 1 at 16:06













    5












    5








    5







    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.






    share|improve this answer















    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.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Apr 1 at 16:02

























    answered Apr 1 at 14:57









    TezraTezra

    5,23321244




    5,23321244












    • You could explain where to get that UUID, and why collision isn't a (practical) problem.

      – Yakk - Adam Nevraumont
      Apr 1 at 15:43











    • @Yakk-AdamNevraumont Added links and expanded a little. I didn't go into detail of the UUID because I want to stress more the "unique id" part. UUID is just an implementation provided by Java.

      – Tezra
      Apr 1 at 16:06

















    • You could explain where to get that UUID, and why collision isn't a (practical) problem.

      – Yakk - Adam Nevraumont
      Apr 1 at 15:43











    • @Yakk-AdamNevraumont Added links and expanded a little. I didn't go into detail of the UUID because I want to stress more the "unique id" part. UUID is just an implementation provided by Java.

      – Tezra
      Apr 1 at 16:06
















    You could explain where to get that UUID, and why collision isn't a (practical) problem.

    – Yakk - Adam Nevraumont
    Apr 1 at 15:43





    You could explain where to get that UUID, and why collision isn't a (practical) problem.

    – Yakk - Adam Nevraumont
    Apr 1 at 15:43













    @Yakk-AdamNevraumont Added links and expanded a little. I didn't go into detail of the UUID because I want to stress more the "unique id" part. UUID is just an implementation provided by Java.

    – Tezra
    Apr 1 at 16:06





    @Yakk-AdamNevraumont Added links and expanded a little. I didn't go into detail of the UUID because I want to stress more the "unique id" part. UUID is just an implementation provided by Java.

    – Tezra
    Apr 1 at 16:06











    1














    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!");








    share|improve this answer





























      1














      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!");








      share|improve this answer



























        1












        1








        1







        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!");








        share|improve this answer















        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!");









        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Apr 2 at 19:02

























        answered Apr 2 at 18:51









        TezraTezra

        5,23321244




        5,23321244





















            0














            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());






            share|improve this answer























            • Object.hashCode has the same problem as System.identityHashCode in that in case of a collision, compareTo will return 0 for two different objects.

              – Balz Guenat
              Apr 1 at 8:22











            • That is the reason why I advised overriding hashcode() and make it rely not just on name.

              – Darshan Mehta
              Apr 1 at 8:26











            • any hash function, by definition, will have collisions, regardless of whether it relies on just the name or not.

              – Balz Guenat
              Apr 1 at 8:33















            0














            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());






            share|improve this answer























            • Object.hashCode has the same problem as System.identityHashCode in that in case of a collision, compareTo will return 0 for two different objects.

              – Balz Guenat
              Apr 1 at 8:22











            • That is the reason why I advised overriding hashcode() and make it rely not just on name.

              – Darshan Mehta
              Apr 1 at 8:26











            • any hash function, by definition, will have collisions, regardless of whether it relies on just the name or not.

              – Balz Guenat
              Apr 1 at 8:33













            0












            0








            0







            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());






            share|improve this answer













            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());







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Apr 1 at 8:20









            Darshan MehtaDarshan Mehta

            23.7k42956




            23.7k42956












            • Object.hashCode has the same problem as System.identityHashCode in that in case of a collision, compareTo will return 0 for two different objects.

              – Balz Guenat
              Apr 1 at 8:22











            • That is the reason why I advised overriding hashcode() and make it rely not just on name.

              – Darshan Mehta
              Apr 1 at 8:26











            • any hash function, by definition, will have collisions, regardless of whether it relies on just the name or not.

              – Balz Guenat
              Apr 1 at 8:33

















            • Object.hashCode has the same problem as System.identityHashCode in that in case of a collision, compareTo will return 0 for two different objects.

              – Balz Guenat
              Apr 1 at 8:22











            • That is the reason why I advised overriding hashcode() and make it rely not just on name.

              – Darshan Mehta
              Apr 1 at 8:26











            • any hash function, by definition, will have collisions, regardless of whether it relies on just the name or not.

              – Balz Guenat
              Apr 1 at 8:33
















            Object.hashCode has the same problem as System.identityHashCode in that in case of a collision, compareTo will return 0 for two different objects.

            – Balz Guenat
            Apr 1 at 8:22





            Object.hashCode has the same problem as System.identityHashCode in that in case of a collision, compareTo will return 0 for two different objects.

            – Balz Guenat
            Apr 1 at 8:22













            That is the reason why I advised overriding hashcode() and make it rely not just on name.

            – Darshan Mehta
            Apr 1 at 8:26





            That is the reason why I advised overriding hashcode() and make it rely not just on name.

            – Darshan Mehta
            Apr 1 at 8:26













            any hash function, by definition, will have collisions, regardless of whether it relies on just the name or not.

            – Balz Guenat
            Apr 1 at 8:33





            any hash function, by definition, will have collisions, regardless of whether it relies on just the name or not.

            – Balz Guenat
            Apr 1 at 8:33











            0














            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.





            share|improve this answer




















            • 1





              This is basically a resource leak; anything that every collided has its lifetime extended to the end of the program. Thanks however, I can use this as a good example of why garbage collection doesn't imply no resource leaks.

              – Yakk - Adam Nevraumont
              Apr 1 at 15:44












            • @Yakk-AdamNevraumont true, just the mention of static should trigger an immediate nausea. "So go with the answer of Eran". The code was just a temptative argument. There is something fishy here, Eran's solution is probably also not what is actually desired. Does the OP want an ideal hash function?

              – Joop Eggen
              Apr 1 at 15:55






            • 1





              Contrary to all other solutions this can at least be made to work correctly without violating either equals or compareTo contracts. Although if your solution involves WeakHashMaps you already have much bigger problems.

              – Voo
              Apr 1 at 16:31











            • @Voo but compareTo only returns 0 or 1... Is the second 1 supposed to be -1 or is there a return -1 missing? Also would probably be more efficient to just remove static and just use system.idenity on that object to resolve collisions. If you have 2 collisions, that should prove god hates you. =P

              – Tezra
              Apr 2 at 19:18











            • @Tezra "Made to work", agreed that the current solution is not going to be correct.

              – Voo
              Apr 2 at 19:27















            0














            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.





            share|improve this answer




















            • 1





              This is basically a resource leak; anything that every collided has its lifetime extended to the end of the program. Thanks however, I can use this as a good example of why garbage collection doesn't imply no resource leaks.

              – Yakk - Adam Nevraumont
              Apr 1 at 15:44












            • @Yakk-AdamNevraumont true, just the mention of static should trigger an immediate nausea. "So go with the answer of Eran". The code was just a temptative argument. There is something fishy here, Eran's solution is probably also not what is actually desired. Does the OP want an ideal hash function?

              – Joop Eggen
              Apr 1 at 15:55






            • 1





              Contrary to all other solutions this can at least be made to work correctly without violating either equals or compareTo contracts. Although if your solution involves WeakHashMaps you already have much bigger problems.

              – Voo
              Apr 1 at 16:31











            • @Voo but compareTo only returns 0 or 1... Is the second 1 supposed to be -1 or is there a return -1 missing? Also would probably be more efficient to just remove static and just use system.idenity on that object to resolve collisions. If you have 2 collisions, that should prove god hates you. =P

              – Tezra
              Apr 2 at 19:18











            • @Tezra "Made to work", agreed that the current solution is not going to be correct.

              – Voo
              Apr 2 at 19:27













            0












            0








            0







            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.





            share|improve this answer















            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.






            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Apr 1 at 15:55

























            answered Apr 1 at 8:40









            Joop EggenJoop Eggen

            79.1k755106




            79.1k755106







            • 1





              This is basically a resource leak; anything that every collided has its lifetime extended to the end of the program. Thanks however, I can use this as a good example of why garbage collection doesn't imply no resource leaks.

              – Yakk - Adam Nevraumont
              Apr 1 at 15:44












            • @Yakk-AdamNevraumont true, just the mention of static should trigger an immediate nausea. "So go with the answer of Eran". The code was just a temptative argument. There is something fishy here, Eran's solution is probably also not what is actually desired. Does the OP want an ideal hash function?

              – Joop Eggen
              Apr 1 at 15:55






            • 1





              Contrary to all other solutions this can at least be made to work correctly without violating either equals or compareTo contracts. Although if your solution involves WeakHashMaps you already have much bigger problems.

              – Voo
              Apr 1 at 16:31











            • @Voo but compareTo only returns 0 or 1... Is the second 1 supposed to be -1 or is there a return -1 missing? Also would probably be more efficient to just remove static and just use system.idenity on that object to resolve collisions. If you have 2 collisions, that should prove god hates you. =P

              – Tezra
              Apr 2 at 19:18











            • @Tezra "Made to work", agreed that the current solution is not going to be correct.

              – Voo
              Apr 2 at 19:27












            • 1





              This is basically a resource leak; anything that every collided has its lifetime extended to the end of the program. Thanks however, I can use this as a good example of why garbage collection doesn't imply no resource leaks.

              – Yakk - Adam Nevraumont
              Apr 1 at 15:44












            • @Yakk-AdamNevraumont true, just the mention of static should trigger an immediate nausea. "So go with the answer of Eran". The code was just a temptative argument. There is something fishy here, Eran's solution is probably also not what is actually desired. Does the OP want an ideal hash function?

              – Joop Eggen
              Apr 1 at 15:55






            • 1





              Contrary to all other solutions this can at least be made to work correctly without violating either equals or compareTo contracts. Although if your solution involves WeakHashMaps you already have much bigger problems.

              – Voo
              Apr 1 at 16:31











            • @Voo but compareTo only returns 0 or 1... Is the second 1 supposed to be -1 or is there a return -1 missing? Also would probably be more efficient to just remove static and just use system.idenity on that object to resolve collisions. If you have 2 collisions, that should prove god hates you. =P

              – Tezra
              Apr 2 at 19:18











            • @Tezra "Made to work", agreed that the current solution is not going to be correct.

              – Voo
              Apr 2 at 19:27







            1




            1





            This is basically a resource leak; anything that every collided has its lifetime extended to the end of the program. Thanks however, I can use this as a good example of why garbage collection doesn't imply no resource leaks.

            – Yakk - Adam Nevraumont
            Apr 1 at 15:44






            This is basically a resource leak; anything that every collided has its lifetime extended to the end of the program. Thanks however, I can use this as a good example of why garbage collection doesn't imply no resource leaks.

            – Yakk - Adam Nevraumont
            Apr 1 at 15:44














            @Yakk-AdamNevraumont true, just the mention of static should trigger an immediate nausea. "So go with the answer of Eran". The code was just a temptative argument. There is something fishy here, Eran's solution is probably also not what is actually desired. Does the OP want an ideal hash function?

            – Joop Eggen
            Apr 1 at 15:55





            @Yakk-AdamNevraumont true, just the mention of static should trigger an immediate nausea. "So go with the answer of Eran". The code was just a temptative argument. There is something fishy here, Eran's solution is probably also not what is actually desired. Does the OP want an ideal hash function?

            – Joop Eggen
            Apr 1 at 15:55




            1




            1





            Contrary to all other solutions this can at least be made to work correctly without violating either equals or compareTo contracts. Although if your solution involves WeakHashMaps you already have much bigger problems.

            – Voo
            Apr 1 at 16:31





            Contrary to all other solutions this can at least be made to work correctly without violating either equals or compareTo contracts. Although if your solution involves WeakHashMaps you already have much bigger problems.

            – Voo
            Apr 1 at 16:31













            @Voo but compareTo only returns 0 or 1... Is the second 1 supposed to be -1 or is there a return -1 missing? Also would probably be more efficient to just remove static and just use system.idenity on that object to resolve collisions. If you have 2 collisions, that should prove god hates you. =P

            – Tezra
            Apr 2 at 19:18





            @Voo but compareTo only returns 0 or 1... Is the second 1 supposed to be -1 or is there a return -1 missing? Also would probably be more efficient to just remove static and just use system.idenity on that object to resolve collisions. If you have 2 collisions, that should prove god hates you. =P

            – Tezra
            Apr 2 at 19:18













            @Tezra "Made to work", agreed that the current solution is not going to be correct.

            – Voo
            Apr 2 at 19:27





            @Tezra "Made to work", agreed that the current solution is not going to be correct.

            – Voo
            Apr 2 at 19:27

















            draft saved

            draft discarded
















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid


            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.

            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55450569%2fhow-to-implement-comparable-so-it-is-consistent-with-identity-equality%23new-answer', 'question_page');

            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Boston (Lincolnshire) Stedsbyld | Berne yn Boston | NavigaasjemenuBoston Borough CouncilBoston, Lincolnshire

            Ballerup Komuun Stääden an saarpen | Futnuuten | Luke uk diar | Nawigatsjuunwww.ballerup.dkwww.statistikbanken.dk: Tabelle BEF44 (Folketal pr. 1. januar fordelt på byer)Commonskategorii: Ballerup Komuun55° 44′ N, 12° 22′ O

            Serbia Índice Etimología Historia Geografía Entorno natural División administrativa Política Demografía Economía Cultura Deportes Véase también Notas Referencias Bibliografía Enlaces externos Menú de navegación44°49′00″N 20°28′00″E / 44.816666666667, 20.46666666666744°49′00″N 20°28′00″E / 44.816666666667, 20.466666666667U.S. Department of Commerce (2015)«Informe sobre Desarrollo Humano 2018»Kosovo-Metohija.Neutralna Srbija u NATO okruzenju.The SerbsTheories on the Origin of the Serbs.Serbia.Earls: Webster's Quotations, Facts and Phrases.Egeo y Balcanes.Kalemegdan.Southern Pannonia during the age of the Great Migrations.Culture in Serbia.History.The Serbian Origin of the Montenegrins.Nemanjics' period (1186-1353).Stefan Uros (1355-1371).Serbian medieval history.Habsburg–Ottoman Wars (1525–1718).The Ottoman Empire, 1700-1922.The First Serbian Uprising.Miloš, prince of Serbia.3. Bosnia-Hercegovina and the Congress of Berlin.The Balkan Wars and the Partition of Macedonia.The Falcon and the Eagle: Montenegro and Austria-Hungary, 1908-1914.Typhus fever on the eastern front in World War I.Anniversary of WWI battle marked in Serbia.La derrota austriaca en los Balcanes. Fin del Imperio Austro-Húngaro.Imperio austriaco y Reino de Hungría.Los tiempos modernos: del capitalismo a la globalización, siglos XVII al XXI.The period of Croatia within ex-Yugoslavia.Yugoslavia: Much in a Name.Las dictaduras europeas.Croacia: mito y realidad."Crods ask arms".Prólogo a la invasión.La campaña de los Balcanes.La resistencia en Yugoslavia.Jasenovac Research Institute.Día en memoria de las víctimas del genocidio en la Segunda Guerra Mundial.El infierno estuvo en Jasenovac.Croacia empieza a «desenterrar» a sus muertos de Jasenovac.World fascism: a historical encyclopedia, Volumen 1.Tito. Josip Broz.El nuevo orden y la resistencia.La conquista del poder.Algunos aspectos de la economía yugoslava a mediados de 1962.Albania-Kosovo crisis.De Kosovo a Kosova: una visión demográfica.La crisis de la economía yugoslava y la política de "estabilización".Milosevic: el poder de un absolutista."Serbia under Milošević: politics in the 1990s"Milosevic cavó en Kosovo la tumba de la antigua Yugoslavia.La ONU exculpa a Serbia de genocidio en la guerra de Bosnia.Slobodan Milosevic, el burócrata que supo usar el odio.Es la fuerza contra el sufrimiento de muchos inocentes.Matanza de civiles al bombardear la OTAN un puente mientras pasaba un tren.Las consecuencias negativas de los bombardeos de Yugoslavia se sentirán aún durante largo tiempo.Kostunica advierte que la misión de Europa en Kosovo es ilegal.Las 24 horas más largas en la vida de Slobodan Milosevic.Serbia declara la guerra a la mafia por matar a Djindjic.Tadic presentará "quizás en diciembre" la solicitud de entrada en la UE.Montenegro declara su independencia de Serbia.Serbia se declara estado soberano tras separación de Montenegro.«Accordance with International Law of the Unilateral Declaration of Independence by the Provisional Institutions of Self-Government of Kosovo (Request for Advisory Opinion)»Mladic pasa por el médico antes de la audiencia para extraditarloDatos de Serbia y Kosovo.The Carpathian Mountains.Position, Relief, Climate.Transport.Finding birds in Serbia.U Srbiji do 2010. godine 10% teritorije nacionalni parkovi.Geography.Serbia: Climate.Variability of Climate In Serbia In The Second Half of The 20thc Entury.BASIC CLIMATE CHARACTERISTICS FOR THE TERRITORY OF SERBIA.Fauna y flora: Serbia.Serbia and Montenegro.Información general sobre Serbia.Republic of Serbia Environmental Protection Agency (SEPA).Serbia recycling 15% of waste.Reform process of the Serbian energy sector.20-MW Wind Project Being Developed in Serbia.Las Naciones Unidas. Paz para Kosovo.Aniversario sin fiesta.Population by national or ethnic groups by Census 2002.Article 7. Coat of arms, flag and national anthem.Serbia, flag of.Historia.«Serbia and Montenegro in Pictures»Serbia.Serbia aprueba su nueva Constitución con un apoyo de más del 50%.Serbia. Population.«El nacionalista Nikolic gana las elecciones presidenciales en Serbia»El europeísta Borís Tadic gana la segunda vuelta de las presidenciales serbias.Aleksandar Vucic, de ultranacionalista serbio a fervoroso europeístaKostunica condena la declaración del "falso estado" de Kosovo.Comienza el debate sobre la independencia de Kosovo en el TIJ.La Corte Internacional de Justicia dice que Kosovo no violó el derecho internacional al declarar su independenciaKosovo: Enviado de la ONU advierte tensiones y fragilidad.«Bruselas recomienda negociar la adhesión de Serbia tras el acuerdo sobre Kosovo»Monografía de Serbia.Bez smanjivanja Vojske Srbije.Military statistics Serbia and Montenegro.Šutanovac: Vojni budžet za 2009. godinu 70 milijardi dinara.Serbia-Montenegro shortens obligatory military service to six months.No hay justicia para las víctimas de los bombardeos de la OTAN.Zapatero reitera la negativa de España a reconocer la independencia de Kosovo.Anniversary of the signing of the Stabilisation and Association Agreement.Detenido en Serbia Radovan Karadzic, el criminal de guerra más buscado de Europa."Serbia presentará su candidatura de acceso a la UE antes de fin de año".Serbia solicita la adhesión a la UE.Detenido el exgeneral serbobosnio Ratko Mladic, principal acusado del genocidio en los Balcanes«Lista de todos los Estados Miembros de las Naciones Unidas que son parte o signatarios en los diversos instrumentos de derechos humanos de las Naciones Unidas»versión pdfProtocolo Facultativo de la Convención sobre la Eliminación de todas las Formas de Discriminación contra la MujerConvención contra la tortura y otros tratos o penas crueles, inhumanos o degradantesversión pdfProtocolo Facultativo de la Convención sobre los Derechos de las Personas con DiscapacidadEl ACNUR recibe con beneplácito el envío de tropas de la OTAN a Kosovo y se prepara ante una posible llegada de refugiados a Serbia.Kosovo.- El jefe de la Minuk denuncia que los serbios boicotearon las legislativas por 'presiones'.Bosnia and Herzegovina. Population.Datos básicos de Montenegro, historia y evolución política.Serbia y Montenegro. Indicador: Tasa global de fecundidad (por 1000 habitantes).Serbia y Montenegro. Indicador: Tasa bruta de mortalidad (por 1000 habitantes).Population.Falleció el patriarca de la Iglesia Ortodoxa serbia.Atacan en Kosovo autobuses con peregrinos tras la investidura del patriarca serbio IrinejSerbian in Hungary.Tasas de cambio."Kosovo es de todos sus ciudadanos".Report for Serbia.Country groups by income.GROSS DOMESTIC PRODUCT (GDP) OF THE REPUBLIC OF SERBIA 1997–2007.Economic Trends in the Republic of Serbia 2006.National Accounts Statitics.Саопштења за јавност.GDP per inhabitant varied by one to six across the EU27 Member States.Un pacto de estabilidad para Serbia.Unemployment rate rises in Serbia.Serbia, Belarus agree free trade to woo investors.Serbia, Turkey call investors to Serbia.Success Stories.U.S. Private Investment in Serbia and Montenegro.Positive trend.Banks in Serbia.La Cámara de Comercio acompaña a empresas madrileñas a Serbia y Croacia.Serbia Industries.Energy and mining.Agriculture.Late crops, fruit and grapes output, 2008.Rebranding Serbia: A Hobby Shortly to Become a Full-Time Job.Final data on livestock statistics, 2008.Serbian cell-phone users.U Srbiji sve više računara.Телекомуникације.U Srbiji 27 odsto gradjana koristi Internet.Serbia and Montenegro.Тренд гледаности програма РТС-а у 2008. и 2009.години.Serbian railways.General Terms.El mercado del transporte aéreo en Serbia.Statistics.Vehículos de motor registrados.Planes ambiciosos para el transporte fluvial.Turismo.Turistički promet u Republici Srbiji u periodu januar-novembar 2007. godine.Your Guide to Culture.Novi Sad - city of culture.Nis - european crossroads.Serbia. Properties inscribed on the World Heritage List .Stari Ras and Sopoćani.Studenica Monastery.Medieval Monuments in Kosovo.Gamzigrad-Romuliana, Palace of Galerius.Skiing and snowboarding in Kopaonik.Tara.New7Wonders of Nature Finalists.Pilgrimage of Saint Sava.Exit Festival: Best european festival.Banje u Srbiji.«The Encyclopedia of world history»Culture.Centenario del arte serbio.«Djordje Andrejevic Kun: el único pintor de los brigadistas yugoslavos de la guerra civil española»About the museum.The collections.Miroslav Gospel – Manuscript from 1180.Historicity in the Serbo-Croatian Heroic Epic.Culture and Sport.Conversación con el rector del Seminario San Sava.'Reina Margot' funde drama, historia y gesto con música de Goran Bregovic.Serbia gana Eurovisión y España decepciona de nuevo con un vigésimo puesto.Home.Story.Emir Kusturica.Tercer oro para Paskaljevic.Nikola Tesla Year.Home.Tesla, un genio tomado por loco.Aniversario de la muerte de Nikola Tesla.El Museo Nikola Tesla en Belgrado.El inventor del mundo actual.República de Serbia.University of Belgrade official statistics.University of Novi Sad.University of Kragujevac.University of Nis.Comida. Cocina serbia.Cooking.Montenegro se convertirá en el miembro 204 del movimiento olímpico.España, campeona de Europa de baloncesto.El Partizan de Belgrado se corona campeón por octava vez consecutiva.Serbia se clasifica para el Mundial de 2010 de Sudáfrica.Serbia Name Squad For Northern Ireland And South Korea Tests.Fútbol.- El Partizán de Belgrado se proclama campeón de la Liga serbia.Clasificacion final Mundial de balonmano Croacia 2009.Serbia vence a España y se consagra campeón mundial de waterpolo.Novak Djokovic no convence pero gana en Australia.Gana Ana Ivanovic el Roland Garros.Serena Williams gana el US Open por tercera vez.Biography.Bradt Travel Guide SerbiaThe Encyclopedia of World War IGobierno de SerbiaPortal del Gobierno de SerbiaPresidencia de SerbiaAsamblea Nacional SerbiaMinisterio de Asuntos exteriores de SerbiaBanco Nacional de SerbiaAgencia Serbia para la Promoción de la Inversión y la ExportaciónOficina de Estadísticas de SerbiaCIA. Factbook 2008Organización nacional de turismo de SerbiaDiscover SerbiaConoce SerbiaNoticias de SerbiaSerbiaWorldCat1512028760000 0000 9526 67094054598-2n8519591900570825ge1309191004530741010url17413117006669D055771Serbia