Check odd numbers in Java, including negative values

In Java, a signed integer is odd when dividing it by two leaves a nonzero remainder. A long helper handles both ordinary int arguments and larger integer values without converting them to floating point. It also works directly for negative numbers.

A runnable long example

public final class OddNumbers {
    public static boolean isOdd(long n) {
        return n % 2L != 0L;
    }

    public static void main(String[] args) {
        long[] values = {-21L, -20L, 0L, 21L, Long.MIN_VALUE};
        for (long value : values) {
            System.out.println(value + ": " + isOdd(value));
        }
    }
}

Save this example as OddNumbers.java, compile it with javac OddNumbers.java, and run it with java OddNumbers. The results are true, false, false, true, and false in that order. The explicit L suffix keeps the examples visibly in the long domain.

Handle negatives without absolute values

A common mistake is n % 2 == 1. Java gives a negative dividend a negative nonzero remainder, so -21 % 2 is -1. The Java language specification defines integer remainder. Testing against zero avoids caring which sign the remainder has.

Do not take an absolute value just to handle negative inputs. The most negative signed value has no corresponding positive value in the same signed type. This helper needs no absolute value and no increment, so checking Long.MIN_VALUE does not introduce those extra arithmetic hazards. Dividing by the constant two also avoids a variable divisor that could be zero.

Parse external text explicitly

Text belongs at the input boundary. Use an exact integer parser and report its failure instead of routing through double or silently replacing invalid text with zero:

try {
    long count = Long.parseLong("-1003");
    System.out.println(OddNumbers.isOdd(count)); // true
} catch (NumberFormatException error) {
    System.err.println("Enter an integer in the long range.");
}

Long.parseLong rejects values outside the signed 64-bit range and text that cannot represent the requested integer. Its API reference describes accepted signs and failure cases. If your interface permits surrounding whitespace, trim it deliberately before parsing rather than assuming the helper does so.

Check nulls and range boundaries

Primitive long cannot be null, but a boxed Long can. Passing a null wrapper to this method causes unboxing to fail before the arithmetic. Decide whether missing values should be rejected, skipped, or represented separately in your application's result.

Test the two endpoints, zero, adjacent positive values, and adjacent negative values. For integers beyond long, use an arbitrary-precision integer representation from the start. A wider mathematical value cannot be restored after an earlier floating-point conversion has rounded it.

A successful parity result should be reusable outside the console program. Keep user-facing error messages in the input layer, leaving the helper free of printing, logging, or assumptions about a particular interface.