問題タブ [autoboxing]

それで、私は今日この質問をされました。

このプログラムは何を印刷しますか？trueを返します。私は、自動（および自動解除）ボクシングをどのように理解したかにより、常にfalseと出力されると答えました。Integer a = 3を割り当てると、新しいInteger（3）が作成され、a==がプリミティブ値ではなく参照を評価するという印象を受けました。

誰かがこれを説明できますか？

私は Java での自動ボクシングの大ファンです。これにより、見苦しいボイラー プレート コードが大幅に節約されます。ただし、 Number オブジェクトが null である可能性がある状況では、自動ボックス化解除が混乱を招くことがわかりました。javac警告でコードベースで自動アンボックス化が発生している場所を検出する方法はありますか? ボックス化解除のみの発生を検出する他のソリューション (FindBugs や Eclipse 固有のコンパイラ警告など) が見つからないため、高く評価されます。

明確にするために、ボックス化時に警告を生成したくありません-ボックス化解除のみ。

混乱を招く NullPointerExceptions を引き起こす可能性のあるコードの簡単な例を次に示します。

クラスでこの動作を再現するにはどうすればよいですか？

引数がデータベースに存在する場合にID番号を返す関数があります。そうでない場合は、nullを返します。これはnullポインタ例外を懇願していますか？負のID番号は許可されていませんが、存在しない引数が-1のようなエラーコードの代わりにnullを返す方が明確だと思いました。どう思いますか？

2 番目のコードの方が速いのはなぜですか?

これらのオンライン Java テストの 1 つを行っていたところ、次の質問を受けました。

Q: 正しい割り当てを示してください:

先に進む前に、自分で試してみてください。

間違っていたと言えます。調査したところ、次のことがわかりました。

誰かが理由を教えてもらえますか：

Object o = 1;とObject o = "1";

どちらの場合もコンパイルして1を出力しますが、これは私を困惑させます。

どうもありがとう

JNI で新しいプリミティブ型を作成するにはどうすればよいですか。を返す関数がありますjobject。jint、jcharなどの返品が可能です。

NewString、なぜではないNewInteger、、、などがあります。現時点では、JNI レイヤーでのオートボクシングはありません。NewCharacterNewDouble

呼び出しを行うことはできますが、NewObjectプリミティブ型を作成するにはオーバーヘッドが大きすぎます。

Class と MethodID を取得するためのラッパー関数があります。

オートボクシングはかなり怖いです。==私はとの違いを完全に理解して.equalsいますが、次のバグを私から取り除くことはできません:

それは印刷します

なぜ彼らはこのようにしたのですか？キャッシュされた整数と関係がありますが、その場合、プログラムで使用されるすべての整数をキャッシュしないのはなぜですか? または、JVM が常にプリミティブに自動的にアンボックスしないのはなぜですか?

false false または true true を印刷する方がずっと良いでしょう。

編集

古いコードの破損については同意しません。trueをfoo.get(0) == bar.get(0)返すことで、すでにコードが壊れています。

これは、バイト コードで Integer を int に置き換えることによってコンパイラ レベルで解決できませんか (null が割り当てられない限り)。

複合代入とインクリメント/デクリメント演算子の暗黙的なキャストのおかげで、次のものがコンパイルされます。

また、自動ボクシングと自動アンボックスのおかげで、以下もコンパイルされます。

それでも、次のスニペットの最後の行でコンパイル時エラーが発生します。

ここで何が起こっているのかを理解するのを手伝ってくれる人はいますか? バージョンはbyte b問題なくコンパイルされるので、それByte bbに合わせて、必要に応じて適切なボックス化とボックス化解除を行うべきではありませんか?

追加の質問

Byteでは、複合代入演算子を、Character、およびShort左側で機能させる方法はありますか、それともこれらの型に対して単に違法 (!!!)ですか?

次のスニペットを検討してください。

最後の行が常に出力される理由は明らかです。参照同一性比較"false"を使用しており、オブジェクトが既存のオブジェクトになることは決してありません。==new==

問題は最初の 3 行についてです。これらの比較は、自動アンボックス化されたプリミティブ上にあることが保証されていますか? 代わりにプリミティブが自動ボックス化され、参照同一性比較が実行される場合はありますか? （それはすべてです！）intIntegerfalse