The conditional operator {{ Wiki Markup ?:
}} uses the {{boolean
}} value of one expression to decide which of the other two expressions should be evaluated \[[JLS 2005|AA. Bibliography#JLS 05]\]. The conditional operator is syntactically right-associative. For instance {{a?b:c?d:e?f:g}} is equivalent to {{a?b:(c?d:(e?f:g))}}. of its first operand to decide which of the other two expressions will be evaluated. (See §15.25, "Conditional Operator ? :
" of the Java Language Specification (JLS) [JLS 2013].)
The general form of a Java conditional expression is operand1 ? operand2 : operand3
.
- If the value of the first operand (
operand1
) istrue
, then the second operand expression (operand2
) is chosen. - If the value of the first operand is
false
, then the third operand expression (operand3
) is chosen.
The conditional operator is syntactically right-associative. For example, a?b:c?d:e?f:g
is equivalent to a?b:(c?d:(e?f:g))
.
The JLS rules for determining the result type of a conditional expression (see following table) are complicated; programmers could be surprised by the type conversions required for expressions they have written.
Result type determination begins from the top of the table; the compiler applies the first matching rule. The Operand 2 and Operand 3 columns refer to operand2
and operand3
(from the previous definition) respectively. In the table, constant int
The rules (tabulated below) used by a Java compiler to determine the type of the result of a conditional expression are quite complicated and may result in unexpected type conversions. The first matching rule, starting from the top of the table, is applied. In the table, *
refers to constant expressions of type int
(such as '0'
or variables declared final
), Operand 2 refers to operand2
in the general form of a Java conditional given above, and Operand 3 refers to operand3
:.
For the final table row, S1 and S2 are the types of the second and third operands respectively. T1 is the type that results from applying boxing conversion to S1, and T2 is the type that results from applying boxing conversion to S2. The type of the conditional expression is the result of applying capture conversion to S2. The type of the conditional expression is the result of applying capture conversion to the least upper bound of T1 and T2. See §5.1.7, "Boxing Conversion," §5.1.10, "Capture Conversion," and §15.12.2.7, "Inferring Type Arguments Based on Actual Arguments," of the JLS for additional information [JLS 2013].
Determining the Result Type of a Conditional Expression
Rule | Operand 2 | Operand 3 | Resultant |
---|
Type |
---|
1 |
Type T |
Type T |
Type T | |||
2 |
|
|
|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
8 |
|
const int*
, |
|
|
9 |
|
|
|
Byte
const int*
byte
if int
is representable as byte
const int*
Byte
byte
if int
is representable as byte
Short
const int*
short
if int
is representable as short
const int*
Short
short
if int
is representable as short
Character
const int*
char
if int
is representable as char
const int*
Character
char
if int
is representable as char
other numeric
other numeric
10 | Other numeric | Other numeric | Promoted type of the second and third operands |
11 | T1 = boxing conversion(S1) | T2 = boxing conversion(S2) |
Apply capture conversion to lub(T1,T2) |
Because The complexity of the complicated nature of the rules used to rules that determine the result type of a conditional expression and the possibility of can lead to unintended type casting, it is recommended that conversions. Consequently, the second and third operands of the each conditional expression should always have the same typeidentical types. This recommendation also applies to boxed primitives.
Noncompliant Code Example
This In this noncompliant code example prints , the programmer expects that both print statements will print the value of alpha
as A
, which is of the char
type. The third operand '0', is a constant expression of type int
whose value can be represented as a char
and hence does not cause any numeric promotion. However, this behavior depends on the value of the constant integer expression. Changing the value of the constant integer expression may lead to different behavior, as will be demonstrated in the second noncompliant code example. as a char
:
Code Block | ||
---|---|---|
| ||
public class Expr { public static void main(String[] args) { char alpha = 'A'; int i = 0; // Other code. Value of i may change boolean trueExp = true; // Some expression that evaluates to true System.out.print(true trueExp ? alpha : 0); // prints A System.out.print(trueExp ? alpha : 0i); // prints 65 } } |
The first print statement prints A
because the compiler applies rule 8 from the result type determination table to determine that the second and third operands of the conditional expression are, or are converted to, type char
. However, the second print statement prints 65
—the value of alpha
as an int
. The first matching rule from the table is rule 10. Consequently, the compiler promotes the value of alpha
to type int
.
Compliant Solution
This compliant solution recommends the use of the same uses identical types for the second and third operands of the conditional expressions. The clearer semantics help avoid confusion.each conditional expression; the explicit casts specify the type expected by the programmer:
Code Block | ||
---|---|---|
| ||
public class Expr { public static void main(String[] args) { char alpha = 'A'; // Castint i = 0; as a char toboolean explicitlytrueExp state that the type of the = true; // conditionalExpression expressionthat shouldevaluates beto char.true System.out.print(truetrueExp ? alpha : ((char) 0)); // } } |
Noncompliant Code Example
This noncompliant example prints 65
instead of the expected A
. 65
is the ASCII equivalent of A
. This happens because of the numeric promotion of the second operand alpha
to an int
. The numeric promotion occurs because the third operand (the constant expression '12345') is of type int
and consequently, inappropriate for being represented as a char
.
Code Block | ||
---|---|---|
| ||
public class Expr { public static void main(String[] args) { char alpha = 'A';Prints A // Deliberate narrowing cast of i; possible truncation OK System.out.print(true trueExp ? alpha : : 12345);((char) i)); // Prints A } } |
Compliant Solution
The compliant solution casts alpha
to int
for explicitly stating the result type (int
) of the conditional expression. While casting 12345
to type char
ensures that both operands in the conditional expression have the same type (and result in A
being printed), it results in data loss when an integer larger than Character.MAX_VAUE
is downsized to a char
. This compliant solution casts alpha
to int
, the wider of the operand types, to avoid this issue.
When the value of i
in the second conditional expression falls outside the range that can be represented as a char
, the explicit cast will truncate its value. This usage complies with exception NUM12-J-EX0 of NUM12-J. Ensure conversions of numeric types to narrower types do not result in lost or misinterpreted data.
Noncompliant Code Example
This noncompliant code example prints 100 as the size of the HashSet
rather than the expected result (some value between 0 and 50):
Code Block | ||
---|---|---|
| ||
public class ShortSet | ||
Code Block | ||
| ||
public class Expr { public static void main(String[] args) { charHashSet<Short> alphas = 'A'new HashSet<Short>(); for //(short Casti alpha= as0; ani int< to explicitly state that the type of the 100; i++) { s.add(i); // conditional expression should be int. Cast of i-1 is safe because value is always representable System.out.print(true ? ((int) alpha) : 12345); } } |
Noncompliant Code Example
This noncompliant code example prints 65
instead of A
. This is because of numeric promotion of the second operand alpha
to an int
, which happens because the third operand, variable i
, is an int
.
Code Block | ||
---|---|---|
| ||
public class Expr { public static void main(String[] args) { char alpha = 'A'; int i = 0; Short workingVal = (short) (i-1); // ... Other code may update workingVal s.remove(((i % 2) == 1) ? i-1 : workingVal); } System.out.print(true ? alpha : iprintln(s.size()); } } |
Compliant Solution
The combination of values of types short
and int
in the second argument of the conditional expression (the operation i-1
) causes the result to be an int
, as specified by the integer promotion rules. Consequently, the Short
object in the third argument is unboxed into a short
, which is then promoted into an int
. The result of the conditional expression is then autoboxed into an object of type Integer
. Because the HashSet
contains only values of type Short
, the call to HashSet.remove()
has no effect.
Compliant Solution
This compliant solution casts the second operand to type short
, then explicitly invokes the Short.valueOf()
method to create a Short
instance whose value is i-1
:This compliant solution declares i
as a char
, ensuring that the second and third operands of the conditional expression have the same type.
Code Block | ||
---|---|---|
| ||
public class ExprShortSet { public static void main(String[] args) { charHashSet<Short> alphas = 'A'new HashSet<Short>(); for char(short i = 0; //declarei as< char System.out.print(true ? alpha : i); } } |
Noncompliant Code Example
Wiki Markup |
---|
This noncompliant code example uses boxed and unboxed primitives of different types in the conditional expression. Consequently, the {{Integer}} object is auto-unboxed to its primitive type {{int}} and coerced to the primitive {{float}}. This results in loss of precision. \[[Findbugs 2008|AA. Bibliography#Findbugs 08]\] (sic) |
Code Block | ||
---|---|---|
| ||
public class Expr {
public static void main(String[] args) {
Integer i = Integer.MAX_VALUE;
float f = 0;
System.out.print(true ? i : f);
}
}
|
Compliant Solution
This compliant solution declares both the operands as Integer
.
Code Block | ||
---|---|---|
| ||
public class Expr { public static void main(String[] args) { Integer i = Integer.MAX_VALUE; Integer f = 0; //declare as Integer100; i++) { s.add(i); // Cast of i-1 is safe because the resulting value is always representable Short workingVal = (short) (i-1); // ... Other code may update workingVal // Cast of i-1 is safe because the resulting value is always representable s.remove(((i % 2) == 1) ? Short.valueOf((short) (i-1)) : workingVal); } System.out.println(s.print(true ? i : fsize()); } } |
Risk Assessment
As a result of the cast, the second and third operands of the conditional expression both have type Short
, and the remove()
call has the expected result.
Writing the conditional expression as ((i % 2) == 1) ? (short) (i-1)) : workingVal
also complies with this guideline because both If the types of the second and third operands in a conditional expression are not the same then the result of the conditional expression may be unexpected.
Guideline | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
EXP14-J | low | unlikely | medium | P2 | L3 |
Automated Detection
TODO
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
Bibliography
Wiki Markup |
---|
\[[JLS 2005|AA. Bibliography#JLS 05]\] [Section 15.25, Conditional Operator ? :|http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.25]
\[[Bloch 2005|AA. Bibliography#Bloch 05]\] Puzzle 8: Dos Equis
\[[Findbugs 2008|AA. Bibliography#Findbugs 08]\] "Bx: Primitive value is unboxed and coerced for ternary operator" |
this form have type short
. However, this alternative is less efficient because it forces unboxing of workingVal
on each even iteration of the loop and autoboxing of the result of the conditional expression (from short
to Short
) on every iteration of the loop.
Applicability
When the second and third operands of a conditional expression have different types, they can be subject to unexpected type conversions.
Automated detection of condition expressions whose second and third operands are of different types is straightforward.
Automated Detection
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Parasoft Jtest |
| CERT.EXP55.COMT | Avoid using the conditional operator with mismatched numeric types |
Bibliography
Puzzle 8, "Dos Equis" | |
"Bx: Primitive Value Is Unboxed and Coerced for Ternary Operator" | |
[JLS 2013] | §15.25, "Conditional Operator ? : " |
...
EXP13-J. Do not diminish the benefits of constants by assuming their values in expressions 04. Expressions (EXP) 05. Scope (SCP)