• 1
    Ok, what? Why the fuck would it behave differently in the two cases? Could you show a working example of this?
  • 0
    @endor that is the code right there... Try it out yourself.
  • 0
    Well Well Well, guess what programming language is Satanic.
  • 35
    Primitives' caching.

    Java caches boxed primitives up to some value (I think it's in byte.min and byte.max range) and once allocated references are reused to the same blocks of memory. Since all primitives (also boxed primitives) are immutable it's all goocy. And it makes sense.

    And we get this: comparing references to (Integer)65 we are actualy comparing the same reference. Since we are comparing a cached value.

    Comparing references between two Integer objects (boxed primitives) of value 666 we are comparing different objects neither of which is cached. Different objects == different references.

    Remember that you are comparing references. Not values.

    And many people do not know about this cache
  • 5
    Why does it work this way?

    Integers are objects unlike ints. It makes sense that c and d are not the same one. But why a == b?

    In Java, the Integer type keeps a cache of all objects with a value in the range of -128 to 127 for performance reasons. So when you declare new variables in that range, you’re actually referring to the same object.
  • 11
    Hey, look! More reminders of why I don't like Java.
  • 0
    Hell is not an integer, just a sauna, come on in!
  • 0
    It's like a monad where the value isn't for you.
  • 0
    @GiddyNaya using JVM but tries to be efficient. Java, you son of a bitch.
  • 1
    That's the reason the equals method exists, you wouldn't use == for string comparison either
  • 0
    @EaZyCode when you're going to use equals, you're going to put a null check as well.
    I think most of the Java code spent most of the time checking given variable is null or not :D
  • 4
    If you want to see it abused... https://codegolf.stackexchange.com/...
  • 3
    Aren't you using it wrong at the first place? My limited knowledge says if its a non primitive , equate using .equals(...) , No questions asked (ofcourse the class should have equals() defined in it)
  • 0
    @EqualsAndHashCode if nothing else
  • 1
    @StopWastingTime you are correct. And equals is always defined since it originates from java.lang.Object, which is the parent of all the objects.

    Some objects simply prefer overriding that method to custom values
  • 0
    I believe this is the real quirk
  • 0
    @ZwoRmi That alone wouldn't be unusual at all. Integer is an object, int is not. It's a well known fact that == compares references in Java, so two distinct objects are supposed to not be reference-equal. The quirky part in original code is that two instances of Integer object for 42 are actually equal and the reason is pretty obscure and implementation-dependent.
  • 1
    @EaZyCode Any language which has such ambiguous methods of comparison, has a design flaw.

    Of course you could claim "any experienced developer knows not to compare values of type x using ==", but why does the language make things so unintuitive in the first place? Why is there a special extra function for comparison where you have to know about references?

    The idea that the developer should understand the difference between a value in heap memory and a pointer to such a value could make sense... If we weren't talking about the classic "you don't have to worry about memory"-language, Java.

    I think a language should allow types to define what equality means for them, or actually, what any operator means to them.

    In languages like Haskell & Rust, you could define colors which could be mixed using +; a card deck in which cards can be compared using < & >; and you could divide a cake object into slices of cake using /. Whatever makes the code more intuitive to the developer.
  • 1
    @bittersweet I really have to learn Haskell. But I just don't know what to use it for. 🤷
  • 1
    @Wombat For drawing ASCII penises?

    I wouldn't learn it for any particular purpose to be honest. If you're bored one weekend, just go through this, program along, fiddle around with the examples:


    I've worked professionally on Haskell projects, but employers looking for Haskell devs are rare (outside of Facebook, Microsoft, and a bunch of R&D multinationals).

    Learning Haskell is incredibly useful as a mental exercise though.

    It becomes much easier to see shortcomings & inconsistencies in the designs of other languages.

    When you're used to function purity and a highly perfected type system, you know what to pay extra attention to when you're working with OOP languages.

    I've actually started hating PHP less, because Haskell made me aware of patterns to isolate logic in ways which make it easier to test OOP code.
  • 1
    @bittersweet thank you, I will check that site out.
Add Comment