Closed Getaji closed 10 months ago
Javaでは文字列の比較に比較演算子ではなく String::equals メソッドを用いることが強く推奨されているため、そのように修正しました。これは広く知られたbad practiceであるため理由の詳しい説明は省略します。なお、左辺にnullの可能性がある箇所は Object.equals を使用しています。
String::equals
Object.equals
特に SkinText::draw メソッドのそれは、前回の描画と異なる文字列だった場合に実行される prepareText メソッドによって不要なはずの負荷を招くケースが非常に多いことが確認されました (ただし SkinText の実装のうち .fnt ファイルを扱う SkinTextBitmap は prepareText メソッドの実装が空なので負荷はほぼない) 。
SkinText::draw
prepareText
SkinText
.fnt
SkinTextBitmap
修正された中にはそのままでも問題ないと思われる箇所があったかもしれませんが、個々に区別するのは脆弱な方針であり、また今後の仕様変更や実行環境の違いによって不具合として顕在化する可能性があるため、一括で修正すべきと判断しました。
余談: 頻繁に実行されるなら比較演算子を使った方がいいというのも全くの間違いではないですが、それでも String::equals メソッドの実装を見ると大抵の場合(Liberica 17など)高速化のため最初に == で比較しているようなので、やはり equals メソッドを使うのが良いでしょう。
==
equals
Javaでは文字列の比較に比較演算子ではなく
String::equals
メソッドを用いることが強く推奨されているため、そのように修正しました。これは広く知られたbad practiceであるため理由の詳しい説明は省略します。なお、左辺にnullの可能性がある箇所はObject.equals
を使用しています。特に
SkinText::draw
メソッドのそれは、前回の描画と異なる文字列だった場合に実行されるprepareText
メソッドによって不要なはずの負荷を招くケースが非常に多いことが確認されました (ただしSkinText
の実装のうち.fnt
ファイルを扱うSkinTextBitmap
はprepareText
メソッドの実装が空なので負荷はほぼない) 。修正された中にはそのままでも問題ないと思われる箇所があったかもしれませんが、個々に区別するのは脆弱な方針であり、また今後の仕様変更や実行環境の違いによって不具合として顕在化する可能性があるため、一括で修正すべきと判断しました。
余談: 頻繁に実行されるなら比較演算子を使った方がいいというのも全くの間違いではないですが、それでも
String::equals
メソッドの実装を見ると大抵の場合(Liberica 17など)高速化のため最初に==
で比較しているようなので、やはりequals
メソッドを使うのが良いでしょう。