Java Conditional Operator ?:: Writing Compact Expressions

Java's ternary conditional operator is the only one in the language that takes three operands, and that is where both of its names come from. It is called the **ternary** operator because of the three parts, and the **conditional** operator because it chooses between two values based on a condition. People also call it the "question mark operator", or the "elvis operator", though that last name properly belongs to the null-safe variant in Groovy and Kotlin rather than to Java.

condition ? valueIfTrue : valueIfFalse | | | must be evaluated only evaluated only boolean if condition if condition is true is false

The name to recognise in error messages and documentation is the JLS term, *conditional operator*, since that is what the compiler diagnostics call it.

int max =(15 > 25) ? 15 : 25;
System.out.println(max);
// 25

Two rules hold everywhere in the language. The condition must be a boolean, not a truthy value as in JavaScript or C, and the two branches are separated by a single colon.

int i = 1;
int j = i ? 1 : 2;
// error: incompatible types: int cannot be converted to boolean
int k = 1 == 1 ? 1 : 2;
// correct, the comparison produces a boolean

This is the single most important distinction, and it is what the ternary operator exists for. An if-else block is a **statement**, so it performs an action and produces no value. The ternary is an **expression**, so it produces a value that can be stored, passed, or returned.

// if-else: a statement, nothing comes out of it
String grade;
if (score >= 90) {
    grade = "A";
} else {
    grade = "B";
}// ternary: an expression, produces a value directly
String grade = score >= 90 ? "A" : "B";

Once the value exists, it can go anywhere an expression is allowed, which is a much wider set of positions than a statement occupies.

System.out.println(score >= 90 ? "A" : "B");
// directly as an argument
list.add(score >= 90 ? "A" : "B");
// inside a call
static String classify(int score) {
    return score >= 90 ? "A" : "B";
    // returned directly
}int bonus =(score >= 90 ? 100 : 50) + 10;
// combined arithmetically

Because it yields a value, the ternary also composes with the other operators in ways a statement cannot, which is the real payoff of the expression form.

int total = 5 +(score >= 90 ? 1 : 2);
// the ternary contributes a value

This is the behaviour that makes the operator useful for guarding, and it follows from the fact that the operator yields a value. Exactly one branch runs, and which one is decided before the other is evaluated, so an untaken branch cannot have side effects.

static int sideEffects = 0;
static int bump() {
    sideEffects++;
    return 42;
}int chosen = false ? bump() : bump2();

Only the selected branch executes, so sideEffects never moves when the condition picks the other path.

int a = 10;
int b = 0;
int safe =(b != 0) ? a / b : 0;
System.out.println(safe);
// 0, no ArithmeticException

Without the guard this throws, which is the canonical reason to reach for the operator. The same pattern protects a null dereference and an index access.

String name = maybeNull != null ? maybeNull.trim() : "";
int[] data = {
    1, 2, 3
};
int first = data.length > 0 ? data[0] : -1;
int safeDiv = divisor != 0 ? numerator / divisor : 0;

The counterpart is a trap: because the branches are not both evaluated, it is easy to believe that putting work in one branch means it always happens. It does not.

// validation is SKIPPED when isValid is false
isValid ? validateAndSave(record) : skip();
// if isValid is false, validateAndSave never runs at all

If both paths must happen, write a separate if for each one instead of expecting the ternary to run both branches.

The branches do not have to be the same type, because the compiler computes a common type for the whole expression. This is where the original explanations of this operator usually go wrong, since the rules are not simply "both branches must be compatible".

For **numeric** operands, binary numeric promotion applies, which is the same widening rule the arithmetic operators use.

The last two rows surprise people, so they are worth running. They are a special case belonging to the conditional operator itself rather than plain widening: when one branch is a byte, short or char and the other is an int *constant*, the result keeps the narrow type instead of widening to int. Assigning to Object is the easiest way to see the resulting type.

boolean c = true;
char ch = 'a';
Object a = c ? ch : 2;
// Character, not Integer
Object b = c ?(byte)1 :(short)2;
// Short
System.out.println(a.getClass().getSimpleName() + " " + b.getClass().getSimpleName());

The constant still has to fit in the narrow type. A value beyond its range promotes the result to int, which is the safety net that stops the narrow rule from silently wrapping.

short s = 1;
Object p = c ? s : 1000;
// Short,   1000 fits in a short
Object q = c ? s : 100000;
// Integer, 100000 does not fit

For **reference** types, the result is the nearest common supertype, that is the *least upper bound* of the two.

Two branches with nothing in common is a compile error, not a silent widening.

boolean c = true;
int bad = c ? 1 : "x";
// error: incompatible types: bad type in conditional expression

The null case is the useful one, because it lets you write a null-returning expression without a cast.

String found = lookup(id);
int nameLength = found != null ? found.length() : 0;
// result type is int, not Integer

Mixing a primitive with its wrapper unboxes, which is why the whole expression gets a numeric type rather than becoming an Object.

Integer boxed = c ? 5 : Integer.valueOf(7);
System.out.println(boxed.getClass().getSimpleName());
// Integer

Autoboxing turns a Boolean into a condition, and unboxing the null case throws. This is the most reliable way to get a NullPointerException from code that contains no visible dereference.

Boolean flag = null;
int result = flag ? 1 : 2;
// NullPointerException on unboxing

The exception message names the unboxing call rather than the ternary, so the stack trace can be confusing.

java.lang.NullPointerException: Cannot invoke "java.lang.Boolean.booleanValue()" because "" is null

The fix is to keep primitive boolean all the way in, which is why the primitive is the better type for a condition even when a field elsewhere is a Boolean.

Boolean boxed = null;
boolean primitive = boxed != null && boxed;

Comparing the results of a ternary with == is a genuine trap when the target type is a wrapper, because autoboxing means the comparison is on references rather than values.

Integer i = true ? 1000 : 2000;
Integer j = true ? 1000 : 2000;
System.out.println(i == j);
// false, and this looks like a compiler bug
System.out.println(i.equals(j));
// true

The == result is false because the cache that makes small wrapper comparisons work only covers -128 to 127, so each 1000 was boxed into a fresh object. This is the same cache discussed in the comparison topic, and it is worth internalising because the ternary makes it easy to write without noticing.

System.out.println(Integer.valueOf(100) == Integer.valueOf(100));
// true, in the cache
System.out.println(true ? 1000 : 2000 == true ? 1000 : 2000);
// beware the precedence too

Declaring the variable as int sidesteps the whole question, because there is no reference to compare.

int p = true ? 1000 : 2000;
int q = true ? 1000 : 2000;
System.out.println(p == q);
// true, value comparison

The ternary operator is right-associative, meaning that a chain groups from the right. This is what makes threshold ladders read the way they do.

String grade = score >= 90 ? "A" : score >= 80 ? "B" : "C";

parses as if it had been written with the parentheses below, which is the opposite of how the text reads left to right.

String grade = score >= 90 ? "A" :(score >= 80 ? "B" : "C");

Because of that, a ladder of thresholds is the readable direction and the reversed form is not.

Note that right associativity here is not about arithmetic precedence, since + and ?: do not mix the way they do in C. In Java the ternary binds looser than every arithmetic and relational operator, so the condition is simply everything to the left of the first ?.

System.out.println(true || false ? 1 : 2);
// 1, the || is part of the condition

Nesting works in both directions, but only one of them is ever worth writing.

// readable: threshold ladder, right associative
String g = score >= 90 ? "A" : score >= 80 ? "B" : "C";
// equivalent, written out with explicit parens
String g2 = score >= 90 ? "A" :(score >= 80 ? "B" : "C");

The limit is readability, not the compiler. Three or four levels will compile and run correctly, and beyond that the intent is no longer clear to the next reader.

The ternary sits below every arithmetic and relational operator and above assignment, which means expressions that look ambiguous usually parse in a way that surprises you.

The most common trap is string concatenation, because + on a String swallows everything to its right.

System.out.println("5 + (ternary) = " + 5 +(true ? 1 : 2));
// 51, not 7
System.out.println(5 +(true ? 1 : 2));
// 6, correct

The first line evaluates the + chain left to right: the string is built by concatenating "5 + (ternary) = ", then 5, then the ternary result, giving text that begins with 51. The parentheses around the whole expression fix it.

Assignment is looser still, so the variable receives the ternary's value rather than the other way round.

int r;
r = true ? 1 : 2;
// r is 1, the ternary is the right hand side

When nesting a ternary inside a condition, wrap the condition in parentheses for the same reason.

boolean b =(true ? 1 : 2) == 1;
// clear, and correct

There is a second, less familiar syntax with no colon at all, and it does not do what most explanations claim. The form is condition ? statement, intended purely to run a statement when a condition holds.

int grade = 85;
grade >= 90 ? System.out.println("Excellent") : System.out.println("Keep going");

This does not compile. The error is not a statement, and the same happens for every variation you might try.

The reason is a grammar detail that matters. The Java grammar allows a conditional statement only when the branches are assignment-style *expressions*, and that is narrower than "any statement". Method invocations and object creations look like statements but are not accepted in that position, which is why even the most natural cases fail.

boolean flag = true;
flag ? someVoidCall() : someOtherVoidCall();
// error: not a statement

Only a genuine assignment in the branches is accepted, and even then the compiler rejects it, so the form is effectively unreachable in real code.

c ? a = 5 : a = 7 unexpected type c ?(a += 2) :(a -= 2) not a statement conclusion, the else-less and statement forms of ?: are in the grammar, and are not usable in practice use a plain if statement for side effects

The practical conclusion is that neither the else-less form nor the ternary-as-statement is useful in everyday Java. Use a plain if for the side effect and reserve the ternary for producing a value.

// clear and idiomatic
if (grade >= 90) {
    System.out.println("Excellent");
} else {
    System.out.println("Keep going");
}

So when a guide tells you to use the ternary to run a statement such as flag ? method() : null, the advice is describing the shape and not a program that compiles.

The operator earns its place in a few specific shapes, and hurts readability in others.

Good uses are genuine two-way value selection, guarding an operation that would otherwise throw, and choosing a default.

String name = user == null ? "anonymous" : user.getName();
int safeDiv = divisor != 0 ? numerator / divisor : 0;
int clamped = Math.max(0, Math.min(value, 100));

Poor uses are anything where the condition has multiple independent parts, because a nested ternary hides the logic.

// hard to read, three unrelated questions in one expression
String status = isActive ? hasError ? "active with errors" : "active" : "inactive";

Also poor are conditions that have side effects, since only one branch runs and the intent becomes unclear.

// confusing: which of these actually happens?
return validate(x) ? save(x) : delete(x);

The consistent test is whether the expression is producing a value that the surrounding code uses. If it is, the ternary is a good fit. If it is really a statement in disguise, an if is clearer.

The summary worth remembering is short. The ternary operator is an expression that picks one of two values, so it belongs wherever a value is needed and an if-else cannot be used. Its two real strengths are choosing between two values and guarding a risky operation, and its real pitfalls are the wrapper comparison trap and the string concatenation precedence trap.