Java seems to have been designed to uphold a fundamental rule that the `==` operator should be legal any time one operand can be converted to the type of the other, and should compare the result of such conversion with the non-converted operand. This rule is hardly unique to Java, but it has some far-reaching (and IMHO unfortunate) effects on the design of other type-related aspects of the language. It would have been cleaner to specify the behaviors of `==` with regard to particular combinations of operand types, and forbid combinations of types X and Y where `x1==y1` and `x2==y1` wouldn't imply `x1==x2`, but languages seldom do that [under that philosophy, `double1 == long1` would either have to indicate whether `double1` is not an *exact* representation of `long1`, or else refuse to compile; `int1==Integer1` should be forbidden, but there should be a convenient and efficient non-throwing means of testing whether an object is a boxed integer with particular value (comparison with something that isn't a boxed integer should simply return `false`)].

With regard to applying the `==` operator to strings, if Java had forbidden direct comparisons between operands of type `String` and `Object`, it could have pretty well avoided surprises in the behavior of `==`, but there's no behavior it could implement for such comparisons that wouldn't be astonishing. Having two string references kept in type `Object` behave differently from references kept in type `String` would have been far less astonishing than having either of those behaviors differ from that of a legal mixed-type comparison. If `String1==Object1` is legal, that would imply that the only way for the behaviors of `String1==String2` and `Object1==Object2` to match `String1==Object1` would be for them to match each other.