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.

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.

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.

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

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

not an oop issue

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

"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”.

😅

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.

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.

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<<unique_ptr!!:::af>> 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#

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

Yes 😄

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.

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.

Thanks brother!