CHAPTER 15: Expressions

Previous

Java Language

Index

Next

15.19 Relational Operators

The relational operators are syntactically left-associative (they group left-to- right), but this fact is not useful; for example, a<b<c parses as (a<b)<c , which is always a compile-time error, because the type of a<b is always boolean and < is not an operator on boolean values.

RelationalExpression:

	ShiftExpression

	RelationalExpression < ShiftExpression

	RelationalExpression > ShiftExpression

	RelationalExpression <= ShiftExpression

	RelationalExpression >= ShiftExpression

	RelationalExpression instanceof ReferenceType

The type of a relational expression is always boolean .

15.19.1 Numerical Comparison Operators <, <=, >, and >=

The type of each of the operands of a numerical comparison operator must be a primitive numeric type, or a compile-time error occurs. Binary numeric promotion is performed on the operands (S5.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.

The result of a floating-point comparison, as determined by the specification of the IEEE 754 standard, is:

• If either operand is NaN, then the result is false .
• All values other than NaN are ordered, with negative infinity less than all finite values, and positive infinity greater than all finite values.
• Positive zero and negative zero are considered equal. Therefore, -0.0<0.0 is false , for example, but -0.0<=0.0 is true . (Note, however, that the methods Math.min (S20.11.27, S20.11.28) and Math.max (S20.11.31, S20.11.32) treat negative zero as being strictly smaller than positive zero.)

Subject to these considerations for floating-point numbers, the following rules then hold for integer operands or for floating-point operands other than NaN:

• The value produced by the < operator is true if the value of the left-hand operand is less than the value of the right-hand operand, and otherwise is false .
• The value produced by the <= operator is true if the value of the left-hand operand is less than or equal to the value of the right-hand operand, and otherwise is false .
• The value produced by the > operator is true if the value of the left-hand operand is greater than the value of the right-hand operand, and otherwise is false .
• The value produced by the >= operator is true if the value of the left-hand operand is greater than or equal to the value of the right-hand operand, and otherwise is false .

15.19.2 Type Comparison Operator instanceof

The type of a RelationalExpression operand of the instanceof operator must be a reference type or the null type; otherwise, a compile-time error occurs. The ReferenceType mentioned after the instanceof operator must denote a reference type; otherwise, a compile-time error occurs.

At run time, the result of the instanceof operator is true if the value of the RelationalExpression is not null and the reference could be cast (S15.15) to the ReferenceType without raising a ClassCastException . Otherwise the result is false .

If a cast of the RelationalExpression to the ReferenceType would be rejected as a compile-time error, then the instanceof relational expression likewise produces a compile-time error. In such a situation, the result of the instanceof expression could never be true .

Consider the example program:

class Point { int x, y; }
class Element { int atomicNumber; }
class Test {
	public static void main(String[] args) {
		Point p = new Point();
		Element e = new Element();
		if (e instanceof Point) {											// compile-time error
			System.out.println("I get your point!");
			p = (Point)e;										// compile-time error
		}
	}
}

This example results in two compile-time errors. The cast (Point)e is incorrect because no instance of Element or any of its possible subclasses (none are shown here) could possibly be an instance of any subclass of Point . The instanceof expression is incorrect for exactly the same reason. If, on the other hand, the class Point were a subclass of Element (an admittedly strange notion in this example):

class Point extends Element { int x, y; }

then the cast would be possible, though it would require a run-time check, and the instanceof expression would then be sensible and valid. The cast (Point)e would never raise an exception because it would not be executed if the value of e could not correctly be cast to type Point .