なぜ自動ボクシングは警告としてマークされていますか？

Question

私は、un-boxedされている参照がnullになる可能性があるため、自動un-boxingは注意深く行うべきであることを理解しています。オートボクシングに警告としてマークされているのはなぜですか？私はここに欠けているいくつかの落とし穴がありますか？

Answer 1

パフォーマンスの問題（マイクロ最適化の観点から）が期待できない場合は、この警告を安全に無効にすることができます。オートボクシングがここで起こっていることに気付かない場合に備えての表示に過ぎません。 I/Oオーバーヘッド（DBトランザクションまたはディスクアクセスによる）があるビジネスロジックコードでは、自動ボクシングは決して問題になりません。

Answer 2

私はこのEclipseの警告を無効にしようとしていましたが、次の記事では私には考慮しませんでした。私はまだ完全にはわかりませんが、オートボクシングを避けるだけの理由があるように見えます。これはおそらく、かなりあいまいなバグですが

https://effective-java.com/2010/05/the-advantages-and-traps-of-autoboxing/

Answer 3

はオートボクシングは、コレクションの「削除」の方法に関連したバグのために貢献することができます。

乱数ジェネレータを使用して、ArrayListから削除するアイテムのインデックスを選択したときに、このバグが発生しました。ジェネレータは長いプリミティブを返しました。私は誤ってList.remove（int index）のパラメータとして使用しようとしました。コンパイラはlongをLongに変換して、List.remove（Object o）で使用しました。これはまったく異なる動作をもたらしました。幸いにも、assertステートメントがエラーを素早くキャッ​​チしました。

"remove"というこの問題のこの議論によれば、他の誰かが、intが予想外にIntegerのように動作するような同様の問題に遭遇しました。 https://stackoverflow.com/questions/104799/why-arent-java-collections-remove-methods-generic （ScArcher2さんのコメントを参照）