Introduction

Comparing integers in Java is easy when you are working with primitive int values, but wrapper objects change the rules. The main distinction is that == compares numeric value for primitives and object identity for Integer, which is why wrapper comparisons sometimes look correct and then fail unexpectedly.

Compare primitive values with operators

For primitive int, normal comparison operators are the right tool.

1int a = 10;
2int b = 20;
3
4System.out.println(a == b);
5System.out.println(a < b);
6System.out.println(a > b);

There is no reference identity involved here. Java compares the actual numeric values directly.

If your variables are already primitive, stay in the primitive world. That is usually the simplest and safest path.

Compare Integer objects by value

For wrapper objects, use equals when you want equality and compareTo or Integer.compare when you want ordering.

1Integer x = 200;
2Integer y = 200;
3
4System.out.println(x.equals(y));     // true
5System.out.println(x.compareTo(y));  // 0
6System.out.println(Integer.compare(x, y)); // 0

These methods compare numeric content, not whether the two variables refer to the same object.

Integer.compare is especially useful in comparators and sorting code because it works cleanly with primitive int values too.

Why == is dangerous with Integer

When you write x == y for two Integer objects, Java checks whether both references point to the same object instance.

1Integer x = new Integer(5);
2Integer y = new Integer(5);
3
4System.out.println(x == y);      // false
5System.out.println(x.equals(y)); // true

Autoboxing makes this more confusing because Java caches some small Integer objects. That means == may appear to work for some values:

1Integer a = 100;
2Integer b = 100;
3Integer c = 200;
4Integer d = 200;
5
6System.out.println(a == b); // often true
7System.out.println(c == d); // often false

This is exactly why == is the wrong comparison for wrapper value equality. The result depends on object identity and caching behavior, not just the number.

Handle nulls deliberately

Integer exists partly because it can be null, unlike primitive int. That means null safety matters when comparing values that came from a database row, request parameter, or optional field.

1import java.util.Objects;
2
3Integer left = null;
4Integer right = 5;
5
6System.out.println(Objects.equals(left, right)); // false
7System.out.println(Objects.equals(left, null));  // true

Objects.equals is a strong default when wrapper values may be absent. It avoids NullPointerException and still performs value comparison when both values are non-null.

For ordering with possible nulls, decide the business rule first. Should null sort first, last, or be rejected entirely. That policy matters more than the method call.

Choose comparison style by intent

A simple rule set works well in practice:

• use operators for primitive int
• use equals or Objects.equals for wrapper equality
• use compareTo or Integer.compare for ordering

If null is not meaningful, unboxing to int can simplify the code:

Integer boxed = 42;
int value = boxed;
System.out.println(value == 42);

Just be careful. Unboxing a null Integer throws NullPointerException, so only do this when null has already been ruled out.

Common Pitfalls

The most common mistake is using == with Integer and assuming it compares numeric value. It only compares references.

Another common issue is being fooled by the small-integer cache, where == appears to work for one value and fails for another.

Developers also forget that calling equals on a null reference throws. If either side may be null, use Objects.equals or validate earlier.

Finally, avoid mixing primitives and wrappers carelessly. Autoboxing and unboxing are convenient, but they can hide whether the code is doing value comparison, reference comparison, or null-sensitive conversion.

Summary

• Compare primitive int values with normal operators.
• Compare Integer values with equals, Objects.equals, compareTo, or Integer.compare.
• Do not use == for wrapper value equality.
• Remember that integer caching makes incorrect == code look correct sometimes.
• Unbox only when null is impossible or already handled.