equals(...) and equalsIgnoreCase(...)

Why do we have equals() and equalsIgnoreCase() as two different methods, when equals() could have been overloaded with a special ignoreCase argument to prov开发者_开发技巧ide equalsIgnoreCase() functionality?

The method equals() is inherited from Object, so its signature should not be changed. equals() can often be used without actually knowing the concrete class of the object, e.g. when iterating through a collection of objects (especially before Java 5 generics). So then you wouldn't even see the other equals() without downcasting your object to String first.

This was a design choice from the creators of Java to make the idiom of using equals() usable exactly the same way for all objects.

Moreover, IMO

if (string1.equalsIgnoreCase(string2)) ...

is more readable, thus less error-prone than

if (string1.equals(string2, true)) ...

Of course, in your own classes you are free to add an equals() with different signature (on top of the standard equals(), that is).

equalIgnoreCase() is used for ignore the Case sensitive of our String. But the equals() is only returns true, while be same case of string

ex,

String value="java";
if(value.equals("JAva")
{
    System.out.println("Return True");
}
else
{
    System.out.println("Return False");
}

Ans: Returns False

but the other one is,

if(value.equalIgnoreCase("JAva")
{
    System.out.println("Return True");
}
else
{
    System.out.println("Return False");
}

Ans: Returns True

It's absolutely possible to do what you are suggesting but the language designers chose to go the other way and hence we have equalsIgnoreCase(otherString) instead of say equals(otherString, StringConstants.IGNORE_CASE) or equals(otherString, true).

Because equals() method is inherited from Object.

If they did it as you suggest then we would have something like this:

public final class String {

    public boolean equals () { ... }

    public boolean equals (boolean ignoreCase) { ... }

} 

And without reading documentation it would be impossible to understand what method equals() (which without parameter) do.

The main test when overridng a method with additional parameters is that I would expect any method override to do exactly the same thing as the method it's overriding. Equals(), being derived from Object has a contract it must follow. Two objects that are equal() should have identical hashcodes. I don't think two objects that are case insensitive equal should have the same hashcode, so I believe overriding equal here is the wrong thing to do.

    // Demonstrate equals() and equalsIgnoreCase(). 
    class equalsDemo { 
    public static void main(String args[]) { 
    String s1 = "Hello"; 
    String s2 = "Hello"; 
    String s3 = "Good-bye"; 
    String s4 = "HELLO"; 
    System.out.println(s1 + " equals " + s2 + " -> " + 
    s1.equals(s2)); 
    System.out.println(s1 + " equals " + s3 + " -> " + 
    s1.equals(s3)); 
    System.out.println(s1 + " equals " + s4 + " -> " + 
    s1.equals(s4)); 
    System.out.println(s1 + " equalsIgnoreCase " + s4 + " -> " + 
    s1.equalsIgnoreCase(s4)); 
    } 
}

The output from the program is shown here:

Hello equals Hello -> true 
Hello equals Good-bye -> false 
Hello equals HELLO -> false 
Hello equalsIgnoreCase HELLO -> true

I think they just chose one of the alternatives. .NET chose the other. StringComparison.InvariantCultureIgnoreCase etc.

Definitely what you are suggesting and [even better what] .NET implemented would have been more flexible for different cultures etc. In fact I don't even know what culture they use in this ignore case. I guess Current culture.