Why Integer has this weird behaviour? | Java Interview Question
HTML-код
- Опубликовано: 1 окт 2024
- In this mind-blowing video, we dive into the fascinating world of Integer and uncover a surprising concept that will leave you in awe. Have you ever wondered why in case of Integer a = 2; Integer b = 2; a == b evaluates to true, while Integer a = 200; Integer b = 200; results in false? Join us as we unravel this epic programming mystery and reveal the secrets behind this unexpected(or may be expected?) behavior. Get ready to have your mind blown by this Java code revelation!
[Java,software engineering,programming,computer science,Java projects,Java tutorial,coding,programming secrets,Java programming,software development,programming tricks,Java code tricks,coding tricks,Java development,Java tricks,Java tips,programming tips,Java secrets,Java hacks,python, javascript,equals and hash, ==, Integer, Integer.valueOf, comedy, programming memes, programming humour]
Well.... when comparing objects, you are supposed to use the .equals() method. This is the ONLY way to test the equality of objects. You can use == ONLY on primitive types.
Yes, that is the rule: always use .equals() for object equality checks. The goal of this video was to educate. Even if == sometimes gives the correct result, it should not be made standard practice. For example, if you create two strings like String a = "Hello"; String b = "Hello";, both a == b and a.equals(b) will always give the correct result no matter what.
However, in real-world scenarios and more complex repositories, we cannot be certain. Let's say someone somewhere creates String c = new String("Hello");, then most probably == will fail. Therefore, to prevent any mishaps, do not use the == operator for object content comparison.
cheers!
I reckon there's a safer option with static method Object.equals() that takes two arguments instead. It won't derp out with a NullPointerException
@@mr.rabbit5642 Yes there is java.util.Objects.equals() for null safe and deepEquals for checking arrays equality.
I mean sorry, if the Integer class has not yet overriden the == operator, that's not the users problem. Gezus how is Java so behind??
@@MortvmMM You indeed bring up a good point. The designers behind Java are highly reluctant to change behavior like you suggest, so it stays that way. And this brings up the reason for languages like Groovy, Scala, and most recently Kotlin. You can design your own operators on any class to behave the way you think it should be.
I was so confused until I realized it's the Integer not int
"OOP will be the future" -- Oracle probably
not an oop issue
@@1creeperbomb it was the future! Shame Java couldn't keep up lol
"Shooting in my own leg and making worst realizations possible will be the future" - Oracle, perhaps.
In that particular case...
OOP = obfuscated Oracle programming😂
@@Andreas_Manncorrect, it's Java being dumb and not having operator overload...
This shouldn’t be an interview question, it should be a question for the C-Suite of any company that thinks it’s a good idea to build critical systems using Java.
Operator overloading doesn't sound like a bad idea now, huh?
Operator overloading, while powerful, is also dangerous. The amount of times I've opened up someone's C++ code base and they thought they were clever for overloading
@@DaSquydwell OOP can be abused as well. Giving the programmer more features rather than fewer features to me sounds like the better tradeoff. Tldr; skill issue
@@DaSquydI don't think a language should presume that programmers will misuse features. Any feature can be misused. Consider that there aren't real limitations on identifiers; a programmer *could* make a variable name random English letters. That's also very bad code, but so what? Should the language prevent you from doing it? Or should you give the programmer the tool and some guidance and call it a day
Correct!
@@awesomedavid2012 oh, I agree. I much prefer C++ over languages like Java for that very reason. I'm just saying that it does come with its own problems. While you can argue that it's a skill issue all you'd like, that doesn't somehow mean that you won't have to deal with others doing things in a confusing way because of that freedom.
I should also note that some features are definitely more prone to misuse. Part of designing a language is making the features intuitive.
Never touched java before, I've learned from this vid that I'm not gonna touch it ever
Try it with C++ class, not int primitive.
Lmao that's why I'm still on C. But I like Java too.
Im even a c++ user, and damn this Java is not an honest language lol
@@zanagi Yeah. I liked C++, coming from C but the problem with it is that the learning curve is a lot high. I've met people who write blackmagic C++ and it fucks up the code. But who gives a fuck when you can have Aesthetic "std::views::iota new" instead of just writing shit in the way that makes sense.
@@friedrichmyers C++ was created to avoid common bugs and make software more solid by adding lots of features to 'automate' things. They made programmingso easy that nobody has a clue what they're doing. C++ (and Java) are the perfect examples of missing your original design objectives by a mile.
@@friedrichmyers well to use C++, you don't need to use that "black magic" stuff though... just use the features you want to use, and you can still write in C for the rest
Try c#
Disgusting. Java is gross.
Small Fun Fact: you can access the Integer Cache via Reflection. Just add a static Code block and rewrite the Cache with random numbers and enjoy the Autoboxing chaos unfold
That's why all my homies hate Java
Avoiding Java at all cost
Why is there an object for an int
Primitives can't be used as generic types so these wrapper classes were created.
Why primitives can’t be used as generic types?
@@Abc-jq4oz If I remember correctly during compilation generic type provided is swapped to Object. Object is base class for everything in Java. Everything except primitives such as int or byte. Because of this caveat you have to use objects like Integer. If you want more in depth explanation search this topic on the net. There are more wierd things with generics in Java. For example you can't create generic arrays.
@@Abc-jq4oz Because Java
Because this is Java and everything needs to be unnecessarily complicated
The main problem is that in Java == works like in C, whereas in all modern programming languages, == works like .equals() in Java, which makes much more sense, as there are barely any situations where it really matters that two object references really point to the same object, most of the time it only matters if two objects are equal or not.
For Integer types == does not have that problem. Otherwise most of the embedded code could be shredded.
@@Durayne YYou mean for "primitive" types (the types in the video were integer types, but they were objects, not primitives). Yet that's just another weakness of Java. There shouldn't even be primitive types. A language can cheat all it wants under the hood, but at least to the programmer it should be consistent.
In SmallTalk, everything is an object, but that's a lie. SmallTalk only pretends that everything is an object. In actual SmallTalk implementations, not everything is an object, but the language just hides that fact from you as a programmer. Swift is similar: In Swift, all simple numbers can be used as complex data types; in fact, the compiler will often just store them as primitives in the compiled code, even in CPU registers when possible, but there is no boxing/unboxing for the developer at any time.
Java could simply change "a == b" to "a.equals(b)" for all object types after compilation to bytecode, and for primitives it would just compare them directly at runtime instead, as it does today. And if you mix primitives and objects, it would box/unbox each as needed to compare them. After all, Java is completely type-safe, so it always knows the type of everything, even at compile time. At runtime, the bytecode would have looked the same as it does today, only the compiler (javac) would have produced slightly different bytecode depending on the two types to the left and right of ==.
primitiveA == primitiveB => Do what you do today.
objectA == objectB => Compile to "objectA.equals(objectB)".
objectA == primitiveB => Unbox objectA if possible, then compare primitives, otherwise box primitiveB and compare with equals().
It does. Have you not watched the video?
@@zekiz774 I was talking about C. Which the autor clearly was referring to.
@@Durayne You mean for "primitive" types (the types in the video where Integer types, but they were objects, not primitives). But that's another weakness of Java. There shouldn't even be primitive types. Under the hood, a language may cheat as much as it likes but at least to the programmer it should be consistent.
In SmallTalk everything is an object but that's a lie. SmallTalk only pretends everything is an object. In actual SmallTalk implementations not everything is an object but the language just hides that fact from you as a programmer. Similar with Swift: In Swift all simple numbers can be used just as if they were complex data types; the compiler will in fact often just store them as primitives in the compiled code, even in CPU registers when possible, but it will store them as object-like types whenever required.
Java could just made "a == b" to mean "a.equals(b)" after compilation in case a and b are objects, it could compare them just as it does today in case they are primitives and it could just box/unbox automatically if one is a primitive and one is an object (if the object can be unboxed, do that, otherwise box the primitive and use equals()). This would not have required any change to the Bytecode specification at all and thus would not have affected interpreters or JIT compilers. This would only be a change to the Java compiler (javac), after all Java is fully type-safe and the compiler knows the type of every variable and return value at compile time, so it would always know how to compile == according the rules I just specified.
because java sucks
😅
Pretty sure python does a similar thing too lol
In python == checks for equality (including for strings) and “is” checks for reference (pointer location). So, this isn’t usually a problem in python unless you are writing custom objects you need to compare, then you need to build your own comparison (ex based on their attributes) anyway.
Python also sucks
@@elementaltamago1297 Python has its uses, primarily anything that doesn’t need low level access and you want to write quickly. As long as you don’t need to squeeze out tons of speed, it’s not a problem.
Lmao, and ppl are bitching JavaScript 🤣
typeof(idk)
>> Object
At least Javascript breaks no matter what. I would hate having to fix a bug that happens because of some obscure cache
Python has similar behavior! Integers from 0 to 255 and (if I recall) -1 to -4 get cached, so any instance of 255 `is` 255, but multiple instances of 256 may not be true when compared with `is` and not `==`.
"is" is used for checking same object pointer.
"==" is used for checking contents.
In 9/10 cases you want to use "==".
@@cmyk8964 This behavior feels more like a bug rather than a feature. If I'm using a language like Java or Python, it's clear that I don't want to deal with pointers.
@@williamdrum9899 Agreed - if you create a language with the intention that any idiot can use it, "because it's safe", this kind of behavior is unacceptable - for it violates the primary design objectives.
Now I don't mind languages that require you to know what's under the hood in order to do some useful work with it. That's why I (personally) like C and Forth. What I absolutely hate, though, is "simple languages" that do lots of stealthy transformations and conversions behind the curtains in order "to make it simple", but by doing so open up gaping holes every unaware programmer falls into. Which is not that bad when those things are caught early enough, but devastating when left undetected.
I think that language designers should refrain from implementing these "hidden" conversions and design a language that does what it says it does. Sure, it's cool you can do *"A$ == A"* and simply transform the string to an integer, but what you're actually doing is supporting bad habits. Programmers need discipline - especially when they're actually noobs (you can give a true professional a language like C and it'll work out fine).
@@williamdrum9899You normally don't use it at all. Only for things like None object but you can also just use ==
In python, they make it pretty clear that “is” compares references so I don’t think you could call this “similar behavior”.
Always, always, always... use programming language that doesn't introduce such illogical behavior.
What a horrible question to ask on an interview. I couldn't care less if someone knows caveats like this
Not a problem in C#
Integer myGirlFriends = -1;
xD ...;(
What a horrible mess! What genius thought caching some values was a good idea so the == operator doesn't have consistent semantics?
Maybe someone from dieselgate.
@@csuporj lol
TECHNOLOGY IS AWESOME🗣🗣🗣🗣💯💯💯💯🔥🔥🔥🔥
WTF!? Is this really a problem in Java?? That’s a failure in basic functionality. Why do people use this language?
Well every language has some quirky behavior, otherwise Java is really powerful language.
Still better than the mess they call JavaScript, especially on the backend nowadays.
I bet you're a python programmer
Nah bro, just use int when you can. There is almost no case where Integer is good, except for LinkedLists and stuff
Thank god I never learned Java, and I never planned to do so.
There's nothing really wrong here
@@youtubepooppismo5284 It's incredibly pointless to leave in such an obscure issue, and it is definitely wrong as equality is expected to pass in this case, even without the use of `isEquals()`.
@@fusedqyou Clearly you don't understand Java. Every language has its "weird" things which arise from the design. If you understand the basics of Java it totally makes sense. Why would an integer value be equal to the pointer value of an object pointing to an integer? It shouldn't. It's not obscure, you just don't understand memory in Java. The only weird thing here is that he first example (with the 9) does work. That's obscure. But it's just because there is a cache for low value integers, so the pointers are effectively the same. But you shouldn't really to it in the first place if you understand Java
@@youtubepooppismo5284 No, I don't understand Java. I understand programming in general and when it comes to equality I would expect equality to work the way where it would make sense. When it comes to value types I would expect them to have equality in a way where it compares for uniqueness, or where it is relevant. I would NOT expect it to have some obscure check like this. You just don't see the issue here because you're used to this bad system and you know what to look out for. Imagine the average programmer that tries using Java and has to deal with the weird bugs it brings because of this.
@@fusedqyou Maybe what you don't understand is that using "Integer" is rather advanced in java. If you want to deal with integers, you use "int". Equality works fine with "int". That's what everybody uses. "Integer", is a class wrapper around an int. You don't usually use it. It's "advanced" stuff. So, no. the average programmer doesn't really have to deal with it, even though he should understand that's it's not a good idea to do == between two "Integer". If you really must know, I abandoned java years ago and have fully switched to rust. I'm not "accustomed to a bad design", I just understand that it's not bad. I mean you don't even code in Java and have the audacity to say "it's a bad design" - yet you don't understand the basics. It makes perfect sense if you understand basic java memory management and should not jump to conclusions after watching a 1 minute video which doesn't even really explain what's going on
what is the point of having Integer class? this seems like such a bloat
cuz Object-Oriented Programming ;)
Well, Integer (or other wrapper classes) are very much required for certain reasons, for example if I fetch data from DB and certain (integer) column is blank then I don't think representing it as '0' or '-1' is a good idea, in that case Integer is required so that we can represent it as null (primitive can't have null values).
2nd. In Java generics (which is powerful feature of Java), primitive can't be used.
C# (which was based on Java) implement this differently, and there is no Integer class, only primitive type. And everything works fine.
C# is better. What a headache is java, tbh.
Yea c# you can just add a ? to the data type to make it nullable and generics don’t have this constraint
@@bytepint What a horrible system, why would they make it so complicated? Take a look at C#
tldr: Java is broken
Why is Integer an object anyways? What functionality would be lost by using a primitive value?
Integer (or other wrapper classes) are very much required for certain reasons, for example if I fetch data from DB and certain (integer) column is blank then I don't think representing it as '0' or '-1' is a good idea, in that case Integer is required so that we can represent it as null (primitive can't have null values).
2nd. In Java generics (which is powerful feature of Java), primitive can't be used.
such a quality,short, to the-point video... thanks i did not knew this happens
[edit: dang, youtube interpreted the underscores as indicating italics. Does youtube support escaping characters? Apparently not quite.] Seems to me like Python has the right idea here: use “is” for checking if the lhs and the rhs are the same object, and use “==“ to do lhs.\_\_eq\_\_(rhs) (or rhs.__req__(lhs) if lhs has no __eq__ attribute, maybe. Idk if Python actually has a __req__ thing, as I believe Object has a default implementation of __eq__ , so it would only fail to exist if you removed it?).
Or I guess your language could use “===“ in place of “is” if you prefer sigils to keywords.
Having == check for identity for type Integer seems inconvenient without a good reason..
(other than possibly legacy code, I guessss…)
i know why. (without watching.) Autoboxing and Integer.valueOf(n) will return a cached Integer instance for values -1 to 100 (IIRC), so those Integer objects are the same instance. For 900, it's a fresh Integer instance each time. You're using reference equality rather than Integer::equals so it's returning whether it's the same instance, regardless of value.
That's why C++ is still one of the most reliable languages out there.
C++ offers full control over a lot of things including cache.
I chose C++ because it's the only language I know. 😅 There are surely more than one language offering this much freedom.
Why doesn't Integer implement __eq__() to override ==?
... oh.
😀 at 0:36 this is German TV actor Walther Hoffmann performing in popular wedding soap
Another way of saying this is that == is "reference equals" for objects and "value equals" for value types. This doesn't surprise experienced programmers, this is Java 101. This difference exists in virtually every language (though with different syntax).
Seems oddly confusing to have the same operator for different use cases. I'd rather they add a === or some other unique operator and catch an invalid syntax error than get a false result.
Good to be aware of that. My 1st lessons with Java were learning how to compare objects and primitives, and our teacher told us about ".equals()" and "instanceof". Cool video!
Okay, but... _why_ do you need an object version of a primitive data type, anyway?
Only reason I use java is android studio and majority of help on internet are in java.
Object types store memory addresses, not values.
this is y i dont like an abstracted lang like java. then again i dont like the 0xffffffff times my program segfaults cuz a pointer was freed with new address 0x01 instead of NULL in c
Actually - according to the standard _free()_ does *NOT* update your pointer. You have to reassign your pointer yourself when you want to check its value later on. And that's a good practice.
@@HansBezemer i was making a screen saver for fun and i had to deal with the pointer pointing to 0x01 instead of 0x00 or null and it is weird cuz i set the pointer to be equal to NULL after free too.
the "fix" was to not have the condition be pointer != NULL but pointer >= (illigalPageSize) 0x1000
you could always use rust and have neither problems.
Integer in Java is a Class. Next Vídeo.
This is the stupid of Java side 😂 and it's inherited on Kotlin too 😂
Nice animations and explanation. Keep it up!
Actually it works differently. The following code may print true and true, but only if you run it by a command like java -XX:AutoBoxCacheMax=9000 Test.java
public class Test {
public static void main(String[] args) {
Integer a = 9;
Integer b = 9;
Integer c = 9000;
Integer d = 9000;
System.out.println(a == b);
System.out.println(d == d);
}
}
Ok so, int does not stand for interger... What is int then?
Hell yea, I knew this one. Just watched the video to confirm and I was absolutely correct. Last time I used Java was almost 3 years ago
I was so confused by the thumbnail until the first seconds reminded me of the existence of this idiotic wrapper class concept.
Java is truly the worst major programming language.
i love the accent and the info, thx bro
Putting 9==9 and 900 == 900 both in interview questions is evil. People are used to equals method so some might assume 9==9 is false while rhea reality is that such developer would simply use equals and thus the code would not fail.
Well I was reviewing some PRs and found people(mostly junior devs) were still using == for some reason for Integer class.
You do a test with some small numbers, see that == works as you intended, then in prod you get strange bugs due to larger numbers. You may even have 10 unit tests that proves that your == code works, all with small numbers.
Me when I use C# and don't need to use a wrapper class for primitives because generics support the usage of primitives.
Yet it doesn’t automatically cast floats 😂
@@plaidchuck floats will be implicitly casted to doubles but not vice versa, as such a cast is lossy. Why you would want implicit, destructive casting is beyond me
Also neither does Java, frankly I'm not sure what you're talking about here
Great video
I never have seen a language without such quirks, but i think this a serious crap quirk.
The fffff okay i saw such in python but there is with "is" statement, Java absolutely weird on this, tf i should care, am i not comparing values??
Who tf even made Integer class and why??
Use freaking int, wtf is Integer ahha??
Don’t treat Integer objects like the primitive type. Use the primitive type in preference. Check for null if needed and get the primitive value for comparison.
Solution- Use int instead of Integer
That's probably why you should just use primitive int.
The wrapper class should only be used for it's methods.
or for generics
that's why you should just use c#, lmao.
@@henrycgs I do, honestly was easy after learning Java. And tbh I haven't returned to Java since getting into C# lol.
Better generics, less verbose, more features, really nice.
Having implementation details affect the result is horrible design.
I kinda knew it but thanks man. There's never enough knowledge about something.
Yes 😄
why would you use Integer instead of int in the first place
Javascript: Perhaps we are related (==,===)
Because Java isn´t a serious programming language
It is possible in c++
In c++ afaik there is not concept of Integer caching and autoboxing hence behaviour is different.
@@bytepintEven if there was, the concept of operator overloading to get desired behaviour is common in C++. You can also already check if two objects are same kindof with &a == &b
In C++, the == operator is a lot more honest. You know when you’re comparing pointers and you know when you’re comparing primitives.
And people go crazy about JS ;)
good explanation
Thanks brother!
so it almost acts like a 7 bit integer 💀
Java seems cursed. I already didn't like it and refuse to use it because it has no concept of unsigned integers (ICK!) but this is even worse. James Gosling should have been slapped with a trout when he was designing this cancer of a language.
Deep but not much to dive in 😺👍🏻
So they have an IT somewhere that deceides If sth IS in this specific range IT will use Cache...
But why?
that's mad silly.
nice bro i always use equals method for comparing 2 strings... now got some info
Thanks bro.
Yes, Make a thumb rule.
If primitive then ==
Anything else .equals no matter what.
@@bytepint "Primitive" being anything like your typical C numeric types, char, short, int, long, float, double. Just checking to see if I understand
Yes Primitives are : all you mentioned + byte.
Nice🎉🎉🎉🎉
That's interesting but if i got that as an interview question i would leave the interview.
A good reason why to use .equals through. But then just have that as a rule in your code pipeline so your team all have the same level of best practises.
Does this occur in C# as well? Cause' they are very similar languages.
Hey this is a great video, make more!
Yes
So perhaps its safer to use `if a< b else if b< a else`
it'd still be the same problem tho. The issue is with object references, not with the comparison
So even Oracle hard codes the values.
Interesting 😂
Just no.
Nice
Does ur channel teaches java
Right now I’m new to RUclips so you might not find enough videos, but yeah i am planning to create some tutorials in near future.
this is indefensible. having an Integer class to begin with is insane!
Super
Maybe don't use Integer and just use int?
In Java, generics require object types and don't allow primitive types, so they’re unavoidable unfortunately.
@@DaSquyd yeah but that still doesn't explain why anybody would use Integer instead of int. When working with generics you will write Integer, but your variables will usually still be of type int
@@russianyoutube correct. I don't use Java much, but I've never used Integer in the way shown in the video. I'm not sure who does or why they would.
In Rust we trust 🦀
until it doesn’t compile that is
Thx
👍
Doesn't Python do the same thing?
Yes, see reply comment of @cmyk8964
No. Python supports operator overloading, so A == B is defined by a method of type(A). You may be thinking of the “is” operator, which always and only compares references.
I knew there was a reason I never bothered to learn Java. YUCK. I hope Scala isn't repeating this same type of nonsense.
The same as LUA, you need to know how the VM works to program it. That's stupid.