You can simply use Apache Commons Lang:

result = ObjectUtils.compare(firstComparable, secondComparable)

I try to avoid casts whenever possible, so I'd rather use the following, which also looks nicer in my opinion:

Integer.valueOf(8).equals(m.get("null"))

I think you want:

if (count1 != null && count2 != null && count1 > count2)
    do something;
else
    do something else;

Java will auto un-box the Integer objects to int primitive values to make the mathematical > comparison.

The Short Answer

The key point is this:

• == between two reference types is always reference comparison
  • More often than not, e.g. with Integer and String, you'd want to use equals instead
• == between a reference type and a numeric primitive type is always numeric comparison
  • The reference type will be subjected to unboxing conversion
  • Unboxing null always throws NullPointerException
• While Java has many special treatments for String, it is in fact NOT a primitive type

The above statements hold for any given valid Java code. With this understanding, there is no inconsistency whatsoever in the snippet you presented.

The Long Answer

Here are the relevant JLS sections:

JLS 15.21.3 Reference Equality Operators == and !=

If the operands of an equality operator are both of either reference type or the null type, then the operation is object equality.

This explains the following:

Integer i = null;
String str = null;

if (i == null) {   // Nothing happens
}
if (str == null) { // Nothing happens
}
if (str == "0") {  // Nothing happens
}

Both operands are reference types, and that's why the == is reference equality comparison.

This also explains the following:

System.out.println(new Integer(0) == new Integer(0)); // "false"
System.out.println("X" == "x".toUpperCase()); // "false"

For == to be numerical equality, at least one of the operand must be a numeric type:

JLS 15.21.1 Numerical Equality Operators == and !=

If the operands of an equality operator are both of numeric type, or one is of numeric type and the other is convertible to numeric type, binary numeric promotion is performed on the operands. If the promoted type of the operands is int or long, then an integer equality test is performed; if the promoted type is float or double`, then a floating-point equality test is performed.

Note that binary numeric promotion performs value set conversion and unboxing conversion.

This explains:

Integer i = null;

if (i == 0) {  //NullPointerException
}

Here's an excerpt from Effective Java 2nd Edition, Item 49: Prefer primitives to boxed primitives:

In summary, use primitives in preference to boxed primitive whenever you have the choice. Primitive types are simpler and faster. If you must use boxed primitives, be careful! Autoboxing reduces the verbosity, but not the danger, of using boxed primitives. When your program compares two boxed primitives with the == operator, it does an identity comparison, which is almost certainly not what you want. When your program does mixed-type computations involving boxed and unboxed primitives, it does unboxing, and when your program does unboxing, it can throw NullPointerException. Finally, when your program boxes primitive values, it can result in costly and unnecessary object creations.

There are places where you have no choice but to use boxed primitives, e.g. generics, but otherwise you should seriously consider if a decision to use boxed primitives is justified.

References

• JLS 4.2. Primitive Types and Values
  • "The numeric types are the integral types and the floating-point types."
• JLS 5.1.8 Unboxing Conversion
  • "A type is said to be convertible to a numeric type if it is a numeric type, or it is a reference type that may be converted to a numeric type by unboxing conversion."
  • "Unboxing conversion converts [...] from type Integer to type int"
  • "If r is null, unboxing conversion throws a NullPointerException"
• Java Language Guide/Autoboxing
• JLS 15.21.1 Numerical Equality Operators == and !=
• JLS 15.21.3 Reference Equality Operators == and !=
• JLS 5.6.2 Binary Numeric Promotion

Related questions

• When comparing two Integers in Java does auto-unboxing occur?
• Why are these == but not equals()?
• Java: What’s the difference between autoboxing and casting?

Related questions

• What is the difference between an int and an Integer in Java/C#?
• Is it guaranteed that new Integer(i) == i in Java? (YES!!! The box is unboxed, not other way around!)
• Why does int num = Integer.getInteger("123") throw NullPointerException? (!!!)
• Java noob: generics over objects only? (yes, unfortunately)
• Java String.equals versus ==

it is possible to handle null pointer exception using Comparator.comparing static method. If you want to comparing loanAmount fields in your objects and you want that every not null value is greater than null you can use Comparator.nullFirst method in combination with Comparator.comparing like the below code:

Comparator.comparing(LoanAccount::getLoanAmount,
                     Comparator.nullsFirst(Comparator.naturalOrder()))

NaturalOrder is a method returning a comparator that compares Comparable objects in natural order. You can also combine more comparators in a chain with method Comparator.thenComparing like the code below:

Comparator
        .comparing(LoanAccount::getLoanAmount,
                   Comparator.nullsFirst(Comparator.naturalOrder()))
        .thenComparing(LoanAccount::getCreationDate, 
                       Comparator.nullsFirst(Comparator.naturalOrder()))
        .compare(o1, o2);

Now you can rewrite your comparator with equal behaviour shortly:

public class LoanAccountAmountComparator
        implements Comparator<LoanAccount> {

    @Override
    public int compare(LoanAccount o1, LoanAccount o2) {
        if (o1 == null && o2 == null) return 0;
        if (o1 == null) return -1;
        if (o2 == null) return 1;
        return Comparator
                .comparing(LoanAccount::getLoanAmount,
                           nullsFirst(naturalOrder()))
                .thenComparing(LoanAccount::getCreationDate,
                               nullsFirst(naturalOrder()))
                .compare(o1, o2);
    }
}

Note: the use of class Date is discouraged, it is better if you use instead the java.time package classes for time related code.

Surprisingly (to me), this behavior is documented. I have pasted the reference for <, but the same statement is made for <=, >, and >=.

Operator <

Syntax
x < y

Description
Less than operator. If x is less than y, the expression evaluates to true. Otherwise, the expression evaluates to false.
Note:

• Unlike other database stored procedures, Apex does not support tri-state Boolean logic, and the comparison of any two values can never result in null.
• If x or y equal null and are Integers, Doubles, Dates, or Datetimes, the expression is false.
• A non-null String or ID value is always greater than a null value.
• If x and y are IDs, they must reference the same type of object. Otherwise, a runtime error results.
• If x or y is an ID and the other value is a String, the String value is validated and treated as an ID.
• x and y cannot be Booleans.
• The comparison of two strings is performed according to the locale of the context user and is case-insensitive.

On the contrary, the following operators note

x and y cannot be null

• +=
• *=
• -=
• /=
• |=
• &=
• &&
• ||

Surprisingly, this indication is not made for arithmetic operations, even though it still holds.

From javadoc for Comparable

Note that null is not an instance of any class, and e.compareTo(null) should throw a NullPointerException even though e.equals(null) returns false.

No, == between Integer, Long etc will check for reference equality - i.e.

Integer x = ...;
Integer y = ...;

System.out.println(x == y);

this will check whether x and y refer to the same object rather than equal objects.

So

Integer x = new Integer(10);
Integer y = new Integer(10);

System.out.println(x == y);

is guaranteed to print false. Interning of "small" autoboxed values can lead to tricky results:

Integer x = 10;
Integer y = 10;

System.out.println(x == y);

This will print true, due to the rules of boxing (JLS section 5.1.7). It's still reference equality being used, but the references genuinely are equal.

If the value p being boxed is an integer literal of type int between -128 and 127 inclusive (§3.10.1), or the boolean literal true or false (§3.10.3), or a character literal between '\u0000' and '\u007f' inclusive (§3.10.4), then let a and b be the results of any two boxing conversions of p. It is always the case that a == b.

Personally I'd use:

if (x.intValue() == y.intValue())

or

if (x.equals(y))

As you say, for any comparison between a wrapper type (Integer, Long etc) and a numeric type (int, long etc) the wrapper type value is unboxed and the test is applied to the primitive values involved.

This occurs as part of binary numeric promotion (JLS section 5.6.2). Look at each individual operator's documentation to see whether it's applied. For example, from the docs for == and != (JLS 15.21.1):

If the operands of an equality operator are both of numeric type, or one is of numeric type and the other is convertible (§5.1.8) to numeric type, binary numeric promotion is performed on the operands (§5.6.2).

and for <, <=, > and >= (JLS 15.20.1)

The type of each of the operands of a numerical comparison operator must be a type that is convertible (§5.1.8) to a primitive numeric type, or a compile-time error occurs. Binary numeric promotion is performed on the operands (§5.6.2). If the promoted type of the operands is int or long, then signed integer comparison is performed; if this promoted type is float or double, then floating-point comparison is performed.

Note how none of this is considered as part of the situation where neither type is a numeric type.

Personally, I like Guava's Ordering for null-safe comparing. You can specify #nullsFirst() or #nullsLast() to avoid NullPointerExceptions.

Other important notes, mostly from the comments:

• this is never null in Java
• Consider using Guava's ComparisonChain if you're implementing a fine-grained compareTo()

• When implementing Comparable, be sure to specify the type parameter so you get compile-time type safety and don't have to use instanceof or casts:

  class Tok implements Comparable<Tok> {
      // snip
  
      public int compareTo(Tok other) {
          // snip
      }
  }