Puzzle 32: The Curse of the loop

Please provide a Statement on I to convert the following loop into an infinite loop:

while (i <= j && j <= i && i != j) {}

Oh, no, don't show me the impossible loop again! If I <= J and j <= I, isn't I necessarily equal to J? This attribute must be valid for real numbers. In fact, it is so important that it has such a definition: The ≤ relationship on the real number is called back. The <= Operator of Java is called back before version 5.0, but it is no longer called after version 5.0.

Java numeric comparison operators (<<=, >>and >=) until version 5.0) the two operands must be of the original numeric type (byte, Char, short, Int, long, float, and double) [JLS 15.20.1]. However, in version 5.0, the specification has been modified. The new specification describes that the type of each operand must be convertible to the original numeric type [JLS 15.20.1, 5.1.8]. The problem is difficult here.

In version 5.0, autoboxing and auto-unboxing are added to Java. If you don't know about them, see: http://java.sun.com/j2se/5.0/docs/guide/language/autoboxing.html [boxing]. <= The operator is still called back in the original numeric type set, but now it is applied to the packaged numeric type. (The encapsulated numeric types include byte, character, short, integer, long, float, and double .) <= Operators are not called back on these types of operands, Because Java's judgment operators (= and! =) When acting on Object Reference, compare the reference ID instead of the value.

Let's be more specific. The following declaration grants the expression (I <= J & J <= I & I! = J) is true, which converts this loop into an infinite loop:

Integer i = new Integer(0);Integer j = new Integer(0);

The first two subexpressions (I <= J and j <= I) perform unpackage conversion on I and j [JLS 5.1.8] and compare the generated int values in numbers. Both I and J indicate 0, so both subexpressions are calculated as true. Third subexpression (I! = J) Compare the IDs on the object references I and J, because they are initialized to a new integer instance, so the third subexpression is also calculated as true, the cycle will always go on.

You may wonder why the language specification is not changed to: When the operators such as criterion act on the encapsulated numeric type, they perform value comparison. The answer is simple: compatibility. It is unacceptable to change existing programs in a way that violates existing regulations when a language is widely used. In the past, the following program always allowed to print false, so it must continue to maintain this feature:

public class ReferenceComparison {    public static void main(String[] args) {        System.out.println(             new Integer(0) == new Integer(0));    }}

Only one of its two operands is the packaged numeric type, and the other is the original type. The comparison is actually a numerical value. Because this was illegal before version 5.0, there is no compatibility problem here. Let's be more specific. The following program is illegal in version 1.4, and true will be printed in version 5.0:

public class ValueComparison {    public static void main(String[] args) {        System.out.println(             new Integer(0) == 0);    }}

In short, when both operands are packaged numeric types, there is a fundamental difference between the behavior of the value comparison operator and the judgment OPERATOR: The value comparison operator executes the value comparison, the comparison of the quote Mark is performed by the operator such as criterion.

For Language designers, if operators such as sentence operators always perform numerical comparison (puzzle 13), life may be much simpler and happier. Perhaps the real lesson should be: Language designers should have high-quality crystal balls to predict the future of the language and make design decisions accordingly. To be more serious, Language designers should consider how the language may evolve and try to minimize the constraints on the evolution.

Puzzle 32: The Curse of the loop