Fix Login Failures: Use equals() Not == for String Comparison
A developer is implementing a login system where users enter a password that is then hashed using SHA-256. The system stores the hash as a String in the database. On login, the entered password is hashed and compared to the stored hash using the == operator. Occasionally, valid users are denied access, even though the hashes are identical when printed. The developer has confirmed that the hash algorithm is correctly implemented and that the stored hash is exactly the same string as the computed hash. What is the most likely cause and correct fix?
Quick Answer
The answer is to use equals() instead of == for string comparison. The == operator in Java compares object references, not the actual content of the strings, so even when two hash strings are identical in value, they are distinct objects in memory, causing == to return false and denying valid users. This question tests your understanding of Java string equality with equals vs double equals, a core concept in the Oracle Java Foundations 1Z0-811 exam that frequently appears in scenarios involving user input validation or data retrieval. The common trap is assuming == works for strings because it works for primitives; remember that strings are objects, so reference comparison fails where content comparison succeeds. A reliable memory tip: think of == as checking "are they the same object?" while equals() asks "do they have the same characters?"—for login systems, you always want the latter.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Change the comparison from == to equals().
The == operator in Java compares object references, not string content. Even if two hash strings are logically identical, they are distinct String objects, so == returns false. Option A (equals()) is the correct and idiomatic fix because equals() compares the actual content. Option B (hashCode()) is incorrect because hash codes can collide (different strings can have the same hash code), and passwords require exact string equality. Option C (intern()) would allow == to work after interning, but it is unnecessary and not recommended for password validation due to the permanent string pool and performance overhead. Option D (compareTo()) would also return 0 for equal strings, but equals() is the standard method for equality checks.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Change the comparison from == to equals().
Why this is correct
This directly fixes the issue.
- ✗
Use hashCode() to compare integer representations.
Why it's wrong here
Using hashCode() compares integers, not strings.
- ✗
Call intern() on both hash strings before using ==.
Why it's wrong here
Calling intern() is not standard.
- ✗
Use compareTo() which returns 0 if equal.
Why it's wrong here
Using compareTo() could work but equals() is idiomatic.
Go deeper
Related to this question
About these practice questions
This 1Z0-811 question is part of Courseiva's 481-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
2 more ways this is tested on 1Z0-811
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Given: String s1 = "Java"; String s2 = new String("Java"); What does (s1 == s2) evaluate to?
medium- A.true if interned, false otherwise
- ✓ B.false
- C.true
- D.Compilation error
Why B: S1 is a string literal which is interned, while s2 is created using the 'new' keyword, resulting in a different object in heap memory. The '==' operator compares object references, so it returns false. Option A is incorrect because 'true if interned' is misleading; s1 is interned, but the comparison is false because s2 is a separate object. Option C ('true') is wrong because references differ. Option D ('Compilation error') is incorrect; the code compiles and runs without error.
Variation 2. Refer to the exhibit. What is the output?
hard- A.false true false
- B.true false true
- C.true true true
- ✓ D.false true true
Why D: The exhibit is not provided, but based on the correct answer D (false true true), a typical code snippet that produces this output is: String s1 = "true"; String s2 = new String("true"); String s3 = s2; System.out.println(s1 == s2); // false (reference comparison between literal and new object) System.out.println(s1.equals(s2)); // true (value equality) System.out.println(s3 == s2); // true (same reference). This exact ordering yields false, true, true.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This 1Z0-811 practice question is part of Courseiva's free Oracle certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 1Z0-811 exam.