Relational Comparisons in Java: Evaluating Greater, Less, and Equal Values

Java has six relational operators. Every one of them returns a boolean, never a value of the operand's own type, which is what makes them safe to drop straight into an if.

Two of the six work on any operand, and the other four need numbers or something the language can order.

int x = 20;
int y = 30;
System.out.println(x < y);
// true
System.out.println(x > y);
// false
System.out.println(x == y);
// false
System.out.println(x != y);
// true
System.out.println(x >= y);
// false
System.out.println(x

The <, >, <= and >= operators are ordering comparisons, so they need operands the language knows how to put in order. String is not one of them, which surprises people who expect any type with compareTo to work directly.

String a = "apple";
String b = "banana";
System.out.println(a < b);
// error: operator '

The type of both operands must also be compatible. A boolean has no ordering at all, so every ordering comparison on one is rejected.

boolean flag = true;
System.out.println(flag < false);
// error: bad operand types for binary operator '

Before any comparison happens, both operands go through binary numeric promotion, the same widening rule the arithmetic operators use. That means a byte, short or char becomes an int first, and an int compared with a long becomes a long.

byte b1 = 10, b2 = 20;
System.out.println(b1 == b2);
// false, both widened to int, then compared
int i = 5;
long l = 5L;
System.out.println(i == l);
// true, i is widened to long, not the other way

Promotion also decides the result of comparing a narrow type against a literal, which is the only place a char surprises anyone.

char c = 'A';
System.out.println(c == 65);
// true, 'A' is the number 65
System.out.println('B' - 'A');
// 1, arithmetic on chars gives numbers
System.out.println('a' < 'b');
// true, because 97 is less than 98

That last point matters for input validation. A char read with Scanner.nextChar() is a single character, not a one character string, so comparing it against a String will not compile and comparing it against a char is what you actually want.

"5" is a String, two characters '5' is a char, the number 53 char c = '5';
c == '5' legal, both are chars c == "5" does not compile, char and String are unrelated types c == 53 legal, because '5' is the number 53 a common bug is reading a digit into a String and then comparing it with == instead of .equals, which silently fails for the reason covered in section 4

This is the single most common bug in Java. The == operator on objects asks only whether both variables point at the same instance in memory. It does not look at the contents at all.

String s1 = new String("hello");
String s2 = new String("hello");
System.out.println(s1 == s2);
// false, two separate objects
System.out.println(s1.equals(s2));
// true, same characters
System.out.println(s1.equals(s2));
// true, this is the content comparison

Two new expressions always produce two distinct objects, so the reference check is always false no matter how identical the text is.

System.out.println(new String("a") == new String("a"));
// always false
System.out.println(new String("a").equals(new String("a")));
// always true

To compare contents, call equals. Every value-carrying type in the standard library implements it, and it is defined by the class rather than by the operator.

The wrapper row catches experienced developers too, because small values are cached and the comparison appears to work until the value leaves that range.

Integer i1 = 100, i2 = 100;
System.out.println(i1 == i2);
// true, both are the cached 100
Integer i3 = 1000, i4 = 1000;
System.out.println(i3 == i4);
// false, outside the cache range of -128 to 127
System.out.println(i3.equals(i4));
// true, the reliable comparison

And the XOR trick from the bitwise topic is not a workaround here, because it compares the numbers and ignores the object identity completely.

System.out.println((i3 ^ i4) == 0);
// true, even though i3 == i4 is false

String literals are not subject to the rule above, which is exactly why the bug survives code review. The compiler puts every literal in a shared pool, so two literals with identical text are the same object and == on them is true.

String a = "hello";
String b = "hello";
System.out.println(a == b);
// true, both refer to the pooled literal
System.out.println("hello" == "hello");
// true

Once a string comes from anywhere else, the pooling no longer applies.

String s = "hello";
String u = new String("hello");
String v = s.intern();
System.out.println(s == u);
// false, u is a fresh object
System.out.println(s == v);
// true, v is the pooled literal
System.out.println(s.equals(u));
// true

The trap is that a variable's provenance depends on where it came from, which is not visible at the comparison site. That is why the rule stays simple: use equals for content and never rely on == for strings.

where the string came from == two such strings equals ---------------------------- ------------------- ------------------- string literals true true new String(...) false true read from a file or network usually false true built with concat or a builder usually false true a constant in another class true if interned true only the first row is predictable, so never rely on it

Even concatenation behaves unintuitively. The compiler folds a concatenation of compile time constants back into a pooled literal, but any runtime concatenation allocates a brand new object.

String s = "ab";
System.out.println(s ==(s + ""));
// false, the concat ran at runtime
System.out.println(s.equals(s + ""));
// true

Objects.equals(a, b) handles both sides being null, which equals cannot, since calling equals on a null reference throws.

String n1 = null;
String n2 = null;
System.out.println(Objects.equals(n1, n2));
// true
System.out.println(n1.equals(n2));
// throws NullPointerException

The reason is that equals is an instance method, so the receiver has to exist before the call can start. Objects.equals is a static helper that checks for null on both sides before delegating.

a.equals(b) b must be non null, and a must be non null to receive the call Objects.equals(a, b) either may be null, checked first null null -> true null "abc" -> false "abc" null -> false "abc" "abc" -> true

There is a subtlety about which side you null-check. a.equals(b) throws if a is null, while Objects.equals(b, a) never throws regardless of order.

String maybe = readUserInput();
// could be null
if (maybe != null && maybe.length() > 5) {
    // guard first, then compare, and this is fine
}if (maybe != null && Objects.equals(maybe, "admin")) {
    // also fine, the guard is what protects the call
}

The rule is that the guard belongs to the receiver, so write a != null && a.equals(b) rather than relying on Objects.equals when the first check is what makes the second safe. Reach for Objects.equals when either side may be null and you do not want to think about which one it is.

Comparing double or float with == looks like it should work and quietly does not, because values such as 0.1 cannot be represented exactly in binary.

double p = 0.1 + 0.2;
System.out.println(p);
// 0.30000000000000004
System.out.println(p == 0.3);
// false
System.out.println(0.5 + 0.25 == 0.75);
// true, these are exact in binary

The second line is the point. 0.5, 0.25 and 0.75 are all exact binary fractions, so they compare fine, and that is why the bug survives testing with round numbers. 0.1 is not exact, the sum lands one unit in the last place away from 0.3, and the equality fails.

The fix is to compare with a tolerance rather than exactly.

if (Math.abs(a - b) < 1e-9) {
    // treat as equal
}System.out.println(Math.abs(p - 0.3) < 1e-9);
// true

Choose the epsilon for the problem rather than pasting the same number everywhere. 1e-9 suits typical business arithmetic, while values measured from sensors or accumulated over many operations may need a much wider window, or a different approach entirely.

BigDecimal deserves special care because equals on it is not a value comparison. It also compares the scale, so 0.1 and 0.10 are unequal by equals and equal by compareTo.

BigDecimal b1 = new BigDecimal("0.1");
BigDecimal b2 = new BigDecimal("0.10");
System.out.println(b1.equals(b2));
// false, different scale
System.out.println(b1.compareTo(b2) == 0);
// true, same numeric value

NaN, the result of dividing zero by zero or taking the square root of a negative number, is not equal to anything, including itself. That single fact makes it behave differently from every other value in the language.

double nan = 0.0 / 0.0;
System.out.println(nan == nan);
// false
System.out.println(nan != nan);
// true, even this one
System.out.println(nan > 1.0);
// false
System.out.println(nan < 1.0);
// false
System.out.println(nan >= nan);
// false

Note that nan != nan is true. That is not a contradiction, it is the definition: NaN means not a number, so it compares unequal to everything. The consequence for ordinary code is that NaN can never be found by testing equality.

if (value == Double.NaN) never true, so this check never fires if (Double.isNaN(value)) the correct test and for sorting, == finds nothing while compareTo gives a total order Double.compare(nan, nan) == 0 true Double.compare(nan, 1.0) > 0 true, NaN sorts above everything

Double.compare is the tool when you need ordering, because it defines NaN as greater than every other value and equal to itself, which makes it usable as a sort key where == is not.

System.out.println(Double.isNaN(nan));
// true
System.out.println(Double.compare(nan, nan) == 0);
// true
System.out.println(Double.compare(nan, 1.0) > 0);
// true

Infinity, by contrast, compares normally, so only NaN needs special handling.

System.out.println(1.0 / 0.0 == Double.POSITIVE_INFINITY);
// true
System.out.println(Double.MAX_VALUE * 2 > Double.MAX_VALUE);
// true, overflow to infinity

Many objects define a natural ordering through the Comparable interface, which supplies compareTo. This is what sorting uses under the hood, and it is also how you get > and < behaviour for a type that does not support them directly.

String apple = "apple";
String banana = "banana";
System.out.println(apple.compareTo(banana));
// negative, apple sorts first
System.out.println(apple.compareTo(banana) < 0);
// true, the idiomatic form

The contract has three parts, and all three matter: a negative result means the receiver sorts first, zero means the two are equivalent by ordering, and a positive result means the receiver sorts last. Only the sign is specified, never the magnitude, so never write code that expects a difference of exactly one.

For strings the ordering is by UTF-16 code unit, which puts every uppercase letter before every lowercase one.

System.out.println("Z".compareTo("a"));
// -7, because 'Z' is 90 and 'a' is 97

That is worth knowing when you sort user-visible text, since a case-sensitive sort will not put lowercase names in the position a reader expects.

System.out.println("ABC".compareToIgnoreCase("abc"));
// 0
System.out.println("ABC".equalsIgnoreCase("abc"));
// true

Sorting a list uses the same ordering.

List words = new ArrayList(List.of("pear", "apple", "fig"));
Collections.sort(words);
System.out.println(words);
// [apple, fig, pear]

Note that compareTo on strings returns 1 for a prefix, which surprises people who expect shorter to be less than longer in a numeric sense. It is lexicographic, so "a" comes before "ab".

System.out.println("a".compareTo("ab"));
// -1
System.out.println("ab".compareTo("a"));
//  1

And the wrapper trap has a clean solution here too, since compareTo compares values rather than references.

Integer i3 = 1000, i4 = 1000;
System.out.println(i3 == i4);
// false
System.out.println(i3.compareTo(i4) == 0);
// true

Arrays inherit Object.equals, so == on two arrays compares references and the inherited equals gives the same answer. Neither does what a newcomer expects.

int[] a = {
    1, 2, 3
};
int[] b = {
    1, 2, 3
};
System.out.println(a == b);
// false
System.out.println(a.equals(b));
// false, inherited from Object
System.out.println(Arrays.equals(a, b));
// true, the correct answer

Arrays.equals walks both arrays element by element, and there is a matching family for the other cases.

The same distinction shows up in collections. List.equals compares contents element by element, which is why two separately built lists with the same items are equal.

List l1 = List.of("x");
List l2 = List.of("x");
System.out.println(l1.equals(l2));
// true, contents compared

Java has no combined less-than-or-equal operator the way some languages do. Writing a range check by chaining produces something that compiles but means something else entirely.

int age = 25;
System.out.println(age >= 18 && age

The chained form is rejected because the first comparison produces a boolean, and a boolean cannot be compared with an int. This is a good instinct, since even if it compiled it would be wrong: the parentheses in (18 <= age) <= 65 would compare a boolean to 65.

The rule is to use two separate comparisons joined by &&, or || when you want either end to be out of range.

if (age >= 18 && age 65) {
    System.out.println("out of range");
}

The same applies to any two-sided bound, and it is worth internalising because the chained form looks like it should work and the failure is a compile error rather than a silent bug.

The rule that covers most cases is short: use == for primitives, and equals for objects. The exceptions worth remembering are string literals, which are pooled so == appears to work, and the wrapper cache, which does the same for small numbers. Both are implementation details that should never be relied on, because a string that arrived from a file or a network will not be pooled and the comparison that passed in your test will fail in production.