4 ms·
That’s not an oops. You’re comparing pointers.
by dpratt 5y ago
That’s not an oops. You’re comparing pointers.
- jraph 5y agoStill, coming from other languages, it is all too easy to write this and this silently fails without any warning. This is consistent with the rest of the language, but I'd bet one rarely wants referential equality when comparing strings. People commenting "yeah but that's because you are a newbie / you are comparing references and you should know better" miss the point I think. I can easily see myself making this mistake while fully understanding what's going on.
- jrsj 5y agoMost editors will warn you about this now as soon as you type it
- pritambarhate 5y agoLinters catch this: https://rules.sonarsource.com/java/RSPEC-4973 https://rules.sonarsource.com/java/RSPEC-4973 Basically the tooling around Java is very evolved and Java static type system helps the IDEs a lot. One of the main reason enterprises prefer Java. Also majority of the tools and IDEs is free for commercial use.
- __float 5y agoIt's easy to make this mistake, still: https://github.com/openjdk/jdk/blob/722d639fad2e4fc6eb2aabd427e2719501899cfe/src/java.base/share/classes/sun/net/www/http/HttpClient.java#L310 https://github.com/openjdk/jdk/blob/722d639fad2e4fc6eb2aabd4...
- nsxwolf 5y agoI learned this 25 years ago when I got started with the language. It tripped me up once, I learned about how references work in Java, and that was that. We are expected to learn about our tools.
- jraph 5y ago> We are expected to learn about our tools. I hope making mistakes is ok though? I learnt C years before Java, it's also the first language I properly learnt. And a little bit of C++ too, so I've known the concepts of pointers and references way before learning Java. In C, you also either do pointer equality or explicit value equality (with strcmp) for string equality tests. I never had any issue understanding how things work in Java. It's not about learning anything. It's about doing mistakes. And I won't take "you should know better" as a counter argument to a mention of some rough edge in an API or a programming language. It's like Javascript: you might know the differences between == and === in Javascript full well, but still happen to write == by mistake because you just wrote some C/Java/Python code just before. I'll probably not forget about .equals(...) in Java most of the time but the fact that == would be silently accepted and not do what is wanted is still a bit concerning (and .equals(...) is ugly, too). A linter will do indeed and that's a fair point. I'd argue that linters are there to work around rough edges of programming languages, but that's fair enough too, every programming language has its gotchas and I'll accept considering a programming language + its linter(s) instead of a programming language alone. However, that's still not ideal because you might have to work on non linted code and deal with these gotchas without any safety net. I hadn't thought about number comparisons (mentioned in other comments) but that's even worse indeed. It's no wonder Kotlin and Groovy both chose value comparison for ==.
- dtech 5y agoReference equality being the default instead of something you very explicitly have to ask for is a flaw.