Is there a possibility of the string equality operator (==) being fixed?
David Alayachew
davidalayachew at gmail.com
Sun Oct 22 19:29:58 UTC 2023
Hello,
Thank you for reaching out!
I'm pretty sure that the amber-dev mailing list is not the correct place
for this type of question. This topic usually goes on at the following
mailing list instead. I've CC'd it for you. I would also encourage you to
remove amber-dev from your CC when responding to me, or anyone else on this
thread.
discuss at openjdk.org
To answer your question, this is a very common request, and the biggest
answer is definitely still the backwards compatibility problem. But tbh,
the question I have for you is this -- is it such a big cost to call the
o1.equals(o2) method instead of using ==? And if you want to handle nulls
too, you can import java.util.Objects (that class is full of useful static
utility methods) and then just say Objects.equals(o1, o2) instead. I am
pretty sure that that exact method was created in response to your exact
question.
I understand it might be inconvenient, but making a change like you
suggested would be very disruptive for very little benefit. All you would
gain from doing this would be a slightly better syntax for representing
object equality and a little more ease when it comes to teaching somebody
Java. Is that really worth the effort?
As for the class-file api, I'll CC them so that someone can fact check me.
Assuming I'm not wrong (no one responds to that point specifically), I
would also drop that mailing list from your CC when responding.
The purpose of the Class-File API was to build and transform class files.
So that seems unrelated to what you want. You want to repurpose old syntax,
but syntax stops being relevant after compilation, and it is these compiled
class files that the Class-File API deals in. If we tried to use that API
to handle class files created with the old syntax, then we would have a
migration and clarity problem, amongst much more.
Let us know if you have any more questions.
Thank you for your time!
David Alayachew
On Sun, Oct 22, 2023 at 2:12 PM tzengshinfu <tzengshinfu at gmail.com> wrote:
> Hi, folks:
>
> When I switched my primary programming language from C# to Java, I found
> myself perplexed by 'string comparison' (and still do at times). While
> string comparisons can sometimes become quite intricate, involving issues
> like case sensitivity, cultural nuances... most of the time, all that's
> needed is string1 == string2.
>
> I discovered that a similar question was asked a decade ago (
> https://www.reddit.com/r/java/comments/1gjwpu/will_the_equals_operator_ever_be_fixed_with/),
> with responses indicating that it's due to 'Backward compatibility,' and
> therefore, unlikely to change. (Backward compatibility! We just keep piling
> new things on top of historical baggage, and for users coming from school
> or from other languages like C#, Python, C++, Rust, Golang, Kotlin, Scala,
> JavaScript, PHP, Rlang, Swift, Ruby, Dart... the top 20 languages according
> to PYPL, having to consult the so-called 'Java FAQ' can be frustrating.
>
> But I believe that if something is amiss, it should be corrected to keep
> moving forward. It would be fantastic if this issue could be addressed in a
> new version of Java and an automatic conversion feature provided to fix
> places in user code that use String.equals. (Similar to the JVM's preview
> feature switch) Is the Class-File API a potential solution to this problem?
> Is my idea unrealistic?
>
> /* GET BETTER EVERY DAY */
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20231022/dd918607/attachment-0001.htm>
More information about the amber-dev
mailing list