Meet Jorman

Jorman is a successful businessman and has 2 houses.

But others don't know that.

Is it the same Jorman?

When you ask neighbours from either Madison or Burke streets, this is the only thing they can say:

Using the residence alone, it's tough to confirm that it's the same Jorman. Since they're 2 different addresses, it's just natural to assume that those are 2 different persons.

That's how the operator == behaves. So it will say that datos[0]==usuario is false, because it only compares the addresses.

An Investigator to the Rescue

What if we sent an investigator? We know that it's the same Jorman, but we need to prove it. Our detective will look closely at all physical aspects. With thorough inquiry, the agent will be able to conclude whether it's the same person or not. Let's see it happen in Java terms.

Here's the source code of String's equals() method:

It compares the Strings character by character, in order to come to a conclusion that they are indeed equal.

That's how the String equals method behaves. So datos[0].equals(usuario) will return true, because it performs a logical comparison.

== operator checks the equality of the object identity, i.e. 2 objects == each other if they are indistinguishable from each other. Currently, in Java, each object has its own unique identity, but not a unique address. As a result, understanding that == tests for address equality is not correct.

Java does not optimised == so that "hello" == "hello", the thing got optimised here is how Java stores the String object, which leads to 2 string literal declarations with the same contents are detected and assigned to a single String object.

With respect to the String class:

The equals() method compares the "value" inside String instances (on the heap) irrespective if the two object references refer to the same String instance or not. If any two object references of type String refer to the same String instance then great! If the two object references refer to two different String instances .. it doesn't make a difference. Its the "value" (that is: the contents of the character array) inside each String instance that is being compared.

On the other hand, the "==" operator compares the value of two object references to see whether they refer to the same String instance. If the value of both object references "refer to" the same String instance then the result of the boolean expression would be "true"..duh. If, on the other hand, the value of both object references "refer to" different String instances (even though both String instances have identical "values", that is, the contents of the character arrays of each String instance are the same) the result of the boolean expression would be "false".

As with any explanation, let it sink in.

I hope this clears things up a bit.

I would add that == is more null safe. Consider the following examples.

String a;
String b = null;
system.assert(a == b);

This will pass.

String a;
String b = null;
system.assert(a.equals(b));

This will throw a null pointer exception.

The above demonstration is why I tend to prefer == over .equals. If you are going to use .equals, you should always first check that it is not null, though it is not necessary when using constants.

final String SOME_CONSTANT = 'abc';
...
if (SOME_CONSTANT.equals('abc'))
{
    // do stuff
}
if (someParameter == SOME_CONSTANT)
{
    // do other stuff
}

Also note that while .equals is case sensitive, you can still call .equalsIgnoreCase.

In addition to what I've already stated, I did some informal profiling and it seems == may be significantly faster than .equals. More than 7 times as fast.

.equals

String a = 'abc';
String b = 'abc';
DateTime start = Datetime.now();
for (Integer i = 0; i < 100000; i++) Boolean isEqual = a.equals(b);
Decimal interval = Datetime.now().getTime() - start.getTime();
system.debug(interval); // yields 1831

.equalsIgnoreCase

String a = 'abc';
String b = 'abc';
DateTime start = Datetime.now();
for (Integer i = 0; i < 100000; i++) Boolean isEqual = a.equalsIgnoreCase(b);
Decimal interval = Datetime.now().getTime() - start.getTime();
system.debug(interval); // yields 1514

==

String a = 'abc';
String b = 'abc';
DateTime start = Datetime.now();
for (Integer i = 0; i < 100000; i++) Boolean isEqual = a == b;
Decimal interval = Datetime.now().getTime() - start.getTime();
system.debug(interval); // yields 239

Even the slowest of these is consuming less than 1/5 ms per execution, but if you get in a big loop and your calls start to number in the millions, that can add up.