「x == y」が真なのに「x.equals(y)」が偽になるケースがあるのですがこれはJavaのバグでしょうか？1.5.0で試しています。

Integerクラスのequalsメソッドはオブジェクトの比較を行うからです。「1.0」はIntegerではないのでfalseを返します。

http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Integer.html#e...(java.lang.Object)

違いはIDでの比較と変数の中身の比較です。

http://msugai.fc2web.com/java/equals.html

Javaでは過去の経緯（主に実行速度の観点）からプリミティブ型と呼ばれる型が言語仕様として残ってしまいました。

オブジェクト指向言語であるならば、「プリミティブ型と呼ばれる特殊な型は存在せずに、全てIntegerクラスのインスタンスとして管理されるべきである」と、Java否定派の方が好んで持ち出す話です。

実際にC#では完全なオブジェクト指向に近づける為、プリミティブ型を採用せずに全てInt32のようなクラスのインスタンスとして解釈されます。

いわゆるJava5のauto-boxingが働いているわけです。

とは言っても、C#でも実行速度の点では考慮しており、クラスでありプリミティブ型のような扱いを内部で行う為に構造体クラスという特殊なクラスが用意されています。

さて、質問の内容ですが、バグか？という問いにはNOとなります。

どうして挙動が変わるかに関してはauto-boxingやequalsと==の違いを理解しているようなので改めて説明する必要はないでしょう。

flashrod氏も触れているように、言語仕様としては正しいが運用上の問題を内包してしまったと捉えるのが妥当なのではないでしょうか？

経緯と問題を知った上で、現代版Effective Javaを作るのであれば「項番:XX auto-boxingに注意して比較演算子を使う」というようなTipsとなる感じがします。

よって「Javaのバグではなく、質問者のコードがバグである」というのが私の回答です。

http://www.nextindex.net/java/equals.html

java関数equals()とは、文字列が同じかどうかを判定する関数です。よってInteger x = 1;ですから、1と1.0は数値としては同じなので、System.out.println(x == 1.0); // trueとなりますが、文字列としては異なるので、System.out.println(x.equals(1.0)); // falseとなります。もし、これをtrueにしたいのであれば、equalの代わりに、equalIgnoreCase関数をお試しください。

よろしければ、下記アドレスもご覧ください。

http://www.geocities.jp/snaruse_intage/index.html

多分もう理解されているのでしょうが、これは == と equalsメソッドの問題というよりも boxing の問題として認識した方がスッキリしますね。

見た目のコードではなくて、

Integer x = new Integer(1);
System.out.println(x.intValue() == 1.0); // true
System.out.println(x.equals(new Float(1.0))); // false

というソースコードをここでは考えるべきなのでしょう。(正確にautoboxing/unboxingの仕様を調べていないのでこれが正解かどうかは保証できません。すみません)

この様にしてみると == と equalsメソッドの関係に対して、バグじゃないのか? という風には見えません。

「autoboxing/unboxing の仕様」と、「== と equalsメソッド」との間に、「ちょっとそれはまずいんじゃないの?」とか「こうやって脳内変換して考えなきゃならないのはよくないのでは?」ということに関しては、確かにこりゃ紛らわしいなぁ、とは思いました。

蛇足

IntegerとFloatが、Numberを共通の親クラスにしていて、かつ intValue()メソッドはNumberで定義されているのに、Integer#equals(Object) が true になるのが Integer クラスを引数にした時だけ、というのも気になりましたが。でもこの辺は人それぞれで考え方は違うでしょうね……。