Just spent like ten minutes searching why my api always returned false.
I forgot, that I am using Java and therefore cant compare strings using equal signs 🤦‍♂️

Same thing happens to me when I'm on C# for a while then go back to Java 😅

do you use StringUtils.equals()?

the amount of times this has screwed me over is unbelievable.

Why is it like this ? There must be a reason. Seems silly though :/

Even c++'s string has the == operator working🤔one more thing why I hate java

@Wytchley The reason is that there is no operator overloading in Java.

Plain, simple and painful.

AFAIK you can actually use the == operator is you use .intern() on both strings before.

I don't know if I dislike Java because it truly is silly, or if because it was never focussed on much at my school. I want to lean towards the former...

@theCalcaholic You're right, and it's beyond my imagination why they haven't implemented it yet, since Kotlin seems to implement it just fine

Why are you all overcomplicating the problem when you can simply use .equalsIgnoreCase ? 😂

@theCalcaholic ah so that's what it is. Cheers I didn't know that was the reason :)

@aaxa it's pretty simple why they don't allow operator overloading. People overload craziest shit and it makes code harder to read. Imagine being afraid of every value assignment to a variable because simple = might do what u are not expecting.

@sSam Hmm, I see your point, that makes pretty good sense.

@sSam Yeah, it's another example of this fear (by the Oracle or whoever decides these things) that Java devs might be stupid.

That's why I always feel a bit infantilized when working with Java...

@theCalcaholic it's not even that Java devs are stupid. Not stupid overloads make it harder to read/understand the code too. Let's say = operator assigns the copy(same values different reference) of the object instead of real one. Seems like pretty valid overloading, but after debugging for some hours it's way easier to understand:
Object o2 = o1.copy();
than
Object o2 = o1;
Call it verbose or whatever, but I like it.

@sSam You shouldn't be able to overload assignment, but it makes a lot of sense for comparisons, increment, accessors ('[x]') and so on.

These are defined differently for different dates types anyways.

Btw, are you aware that for immutables (e. g. strings) your exact example applies?

Immutable o1 = o2;
is the same as
Immutable o1 = o2.copy();

Uhm?
o1 = o2
o1 == o2 -> true

o1 = o2.copy()
o1 == o2 -> false

@sSam Ah sorry, I just had a brain fart (the stuff about immutables). Of course you can have multiple references to the same Immutable.

However the rest still applies. In my opinion there's no real difference between overriding the 'equals' method and overloading the '==' operator for example - apart from the latter being more convenient.

The same applies to 'object[i]' and 'object.get(i)'.

@theCalcaholic the difference is, without operator overloading when you see == you know it's comparing references and when you see .equals you know it's a custom or default implementation. With operator overloading you are not sure what == is doing until you check. It doesn't really matter what kind of operators are allowed to be overloaded all of them can be abused. Of course there are great cases where operator overloading makes the code more readable. (Matrix, complex number operations)
In the end, I think it's just Java devs believing that operator overloading gives more trouble than advantages.

@sSam Not the java devs I know. ;)

Most of them are annoyed by it.

@theCalcaholic by java devs I meant developers/designers of Java. Of course most people will be happy as long as it makes them type one character less. I believe Java is designed with a bit different ideology in mind(designed for business?), it's verbose, has set of rules you have to follow, it doesn't implement all 'new, cool' features instantly, they go through long process that filters which features would fit in Java environment.
In my experience, I'm happy they didn't allow operator overloading.
If you want Java with cool, new stuff it's exactly what Kotlin is.

@sSam Well operator overloading is not exactly 'new', but I know what you mean.

I mainly dislike these kinds of inconveniences because

1. You really have to type a lot more in Java compared to other languages, which is only bearable with good type hinting (which you should have anyways of course, but I still don't like it when a language depends on it to be worked with).

2. It makes the code less readable. '==' for example is the equality operator, not the identity operator, but can't be used according to its meaning in Java except for primitives.

When I'm working with Java (which happens a lot), I'm virtually feeling insulted by the language from time to time, because it appears to assume that I'm an idiot. :P

@theCalcaholic I already wrote about readability and == overloading. It's not that the language assumes you are stupid, but it assumes that you'll make some stupid mistake, which happens to everyone.
In the end, I guess devs of Java thought that stupid mistakes introduced by operator overloading waste more time than some verbosity. What I mean is people overloading operator+ for Person classes and such.

@sSam I wasn't only referring to operator overloading with the 'The language gives me the implications that it thinks I'm stupid' thing.

I know why they decided on it, I just disagree with their reasoning. :)