This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
The equals methods of all wrapper class check not only the primitive representation, but also that the checked object is of the same wrapper class (in our case Integer and Double) as well.
Joined: Apr 02, 2004
Well, as I emphasized, they are true from compilation perspective: In other words, they don't give compilation errors. This does not mean that run time results would be boolean "true".
Please try compiling and running the following code as-is, and then try again with "//" removed for the print statements one at a time.
The following specs from the sections 15.21.3 and 5.5 of JLS may be pertinent here
| A compile-time error occurs if it is impossible to convert the type of either operand to the type of the other by a casting conversion (�5.5). |
| The detailed rules for compile-time correctness checking of a casting conversion of a value of compile-time reference type S (source) to a compile-time reference type T (target) are as follows: If S is a class type: If T is a class type, then S and T must be related classes-that is, S and T must be the same class, or S a subclass of T, or T a subclass of S; otherwise a compile-time error occurs. |