otbugs.spotbugs.4.8.4.source-code.messages_ja.xml Maven / Gradle / Ivy
Go to download
Show more of this group Show more artifacts with this name
Show all versions of spotbugs Show documentation
Show all versions of spotbugs Show documentation
SpotBugs: Because it's easy!
<?xml version="1.0" encoding="UTF-8"?>
<MessageCollection xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="messagecollection.xsd">
<!--
************************************************f**********************
Plugin information
**********************************************************************
-->
<Plugin>
<ShortDescription>コア SpotBugs プラグイン</ShortDescription>
<Details>
<![CDATA[
<p>
このプラグインにはすべての標準的な SpotBugs ディテクタがあります。
</p>
]]>
</Details>
<BugsUrl>https://spotbugs.readthedocs.io/ja/latest/bugDescriptions.html</BugsUrl>
<AllBugsUrl>https://spotbugs.readthedocs.io/ja/latest/bugDescriptions.html</AllBugsUrl>
</Plugin>
<FindBugsMain cmd="addMessages" class="edu.umd.cs.findbugs.AddMessages">
<Description>add msgs (e.g., textual descriptions of bugs) to analysis results</Description>
</FindBugsMain>
<FindBugsMain cmd="analyze" class="edu.umd.cs.findbugs.FindBugs2">
<Description>Perform FindBugs Analysis</Description>
</FindBugsMain>
<FindBugsMain cmd="gui" class="edu.umd.cs.findbugs.gui2.Driver">
<Description>Launch FindBugs GUI</Description>
</FindBugsMain>
<FindBugsMain cmd="list" class="edu.umd.cs.findbugs.PrintingBugReporter">
<Description>Convert analysis results to textual form</Description>
</FindBugsMain>
<FindBugsMain cmd="help" class="edu.umd.cs.findbugs.ShowHelp">
<Description>Provide help for commands</Description>
</FindBugsMain>
<FindBugsMain cmd="version" class="edu.umd.cs.findbugs.Version">
<Description>List FindBugs version</Description>
</FindBugsMain>
<FindBugsMain cmd="filter" class="edu.umd.cs.findbugs.workflow.Filter">
<Description>Filter analysis results</Description>
</FindBugsMain>
<FindBugsMain cmd="set" class="edu.umd.cs.findbugs.workflow.SetBugDatabaseInfo">
<Description>Set project configuration/options</Description>
</FindBugsMain>
<FindBugsMain cmd="history" class="edu.umd.cs.findbugs.workflow.MineBugHistory">
<Description>List details from multi-version analysis results</Description>
</FindBugsMain>
<FindBugsMain cmd="union" class="edu.umd.cs.findbugs.workflow.UnionResults">
<Description>Merge analysis results from disjoint components</Description>
</FindBugsMain>
<FindBugsMain cmd="merge" class="edu.umd.cs.findbugs.workflow.Update">
<Description>Combine analysis results from different versions of software to produce multi-version analysis results </Description>
</FindBugsMain>
<FindBugsMain cmd="dis" class="edu.umd.cs.findbugs.workflow.PrintClass">
<Description>Disassemble a class file</Description>
</FindBugsMain>
<FindBugsMain cmd="errors" class="edu.umd.cs.findbugs.workflowListErrors">
<Description>List analysis errors stored in results file</Description>
</FindBugsMain>
<!-- これを変えたら FindbugsPlugin のデフォルト ID も更新して下さい -->
<Cloud id="edu.umd.cs.findbugs.cloud.doNothingCloud">
<Description>(クラウド無効)</Description>
<Details>このプラグインを使うとバグレビューは無効になります。</Details>
</Cloud>
<PluginComponent id="edu.umd.cs.findbugs.bugReporter.SuppressMultithreaded">
<Description>マルチスレッドの正確性問題を抑止する</Description>
<Details>すべてのマルチスレッドの正確性問題を抑止します</Details>
</PluginComponent>
<PluginComponent id="edu.umd.cs.findbugs.bugReporter.SuppressI18N">
<Description>国際化問題を抑止する</Description>
<Details>すべての国際化問題を抑止します</Details>
</PluginComponent>
<PluginComponent id="edu.umd.cs.findbugs.bugReporter.SelectivelySuppressI18N">
<Description>選択したパッケージ以外のすべての国際化問題を抑止する</Description>
<Details>i18n.properties リソースで指定した以外のすべての国際化問題を抑止します</Details>
</PluginComponent>
<PluginComponent id="edu.umd.cs.findbugs.bugReporter.MaxRank14">
<Description>ランク14を越えるすべての問題を抑止する</Description>
<Details>ランク14を越えるすべての問題を抑止します</Details>
</PluginComponent>
<PluginComponent id="edu.umd.cs.findbugs.bugReporter.SuppressMalicious">
<Description>悪意のあるコードに対する脆弱性について警告を抑止する</Description>
<Details>悪意のあるコードに対する脆弱性について警告を抑止します</Details>
</PluginComponent>
<!--
**********************************************************************
Categories (replacing the BugCategoryDescriptions.properties file)
**********************************************************************
-->
<BugCategory category="CORRECTNESS">
<Description>正確性</Description>
<Abbreviation>C</Abbreviation>
<Details>バグの可能性 - おそらく，開発者が意図していなかったコードになっている明らかなコーディングミスです。
我々は低い誤検出率のために努力します。
</Details>
</BugCategory>
<BugCategory category="NOISE">
<Description>偽のランダムノイズ</Description>
<Abbreviation>N</Abbreviation>
<Details>偽のランダムノイズ: ソフトウェアで実際のバグを発見するのではなく，データマイニング実験のコントロールとして役に立つことを意図しています。</Details>
</BugCategory>
<BugCategory category="SECURITY">
<Description>セキュリティ</Description>
<Abbreviation>S</Abbreviation>
<Details>リモートから悪用可能なセキュリティ脆弱性を引き起こすかもしれない信頼できない入力を使用しています。 </Details>
</BugCategory>
<BugCategory category="BAD_PRACTICE">
<Description>バッドプラクティス</Description>
<Abbreviation>B</Abbreviation>
<Details>推奨または必須のコーディングプラクティスへの違反です。たとえば，hashCode と equals の問題，Cloneable イディオム，捨てられた例外，Serializable の問題，finalize の誤用などです。
いくつかのグループはバッドプラクティスを気にしないかもしれないが，我々はこの解析が正確になるよう努力しています。
</Details>
</BugCategory>
<BugCategory category="STYLE">
<Description>危ないコード</Description>
<Abbreviation>D</Abbreviation>
<Details>紛らわしいコード，異常なコード，またはエラーを引き起こす方法で書かれたコードです。
たとえば，ローカル変数への無効な代入，switch 文のフォールスルー，未確認のキャスト，null とわかっている値の冗長な null チェックなどです。
より多くの誤検出を受け入れました。
SpotBugs の以前のバージョンでは，このカテゴリは Style として知られていました。
</Details>
</BugCategory>
<BugCategory category="PERFORMANCE">
<Description>性能</Description>
<Abbreviation>P</Abbreviation>
<Details>必ずしも間違っているというわけではないが，効率が悪いかもしれないコードです。 </Details>
</BugCategory>
<BugCategory category="MALICIOUS_CODE">
<Description>悪意のあるコード脆弱性</Description>
<Abbreviation>V</Abbreviation>
<Details>信頼できないコードからの攻撃に対して脆弱なコードです。</Details>
</BugCategory>
<BugCategory category="MT_CORRECTNESS">
<Description>マルチスレッドの正確性</Description>
<Abbreviation>M</Abbreviation>
<Details>スレッド，ロック，volatile に関係があるコードの欠陥です。 </Details>
</BugCategory>
<BugCategory category="I18N">
<Description>国際化</Description>
<Abbreviation>I</Abbreviation>
<Details>国際化とロケールに関係があるコードの欠陥です。 </Details>
<!-- DM_CONVERT_CASE is the only core bug pattern in this category -->
</BugCategory>
<BugCategory category="EXPERIMENTAL">
<Description>実験用</Description>
<Abbreviation>X</Abbreviation>
<Details>実験用で完全に精査されていないバグパターンです。 </Details>
<!-- DM_CONVERT_CASE is the only core bug pattern in this category -->
</BugCategory>
<!--
**********************************************************************
Detectors
**********************************************************************
-->
<Detector class="edu.umd.cs.findbugs.detect.OverridingMethodsMustInvokeSuperDetector">
<Details>
<![CDATA[
<p>オーバーライドしているメソッドのうち、スーパークラスのメソッドを呼び出すべきものを見つけます。</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindRoughConstants">
<Details>
<![CDATA[
<p>
このディテクタは，ほぼ (しかし，正確ではなく) 同じである <code>Math.PI</code> のような既知の定数を見つけます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InitializeNonnullFieldsInConstructor">
<Details>
<![CDATA[
<p>
このディテクタは，コンストラクタで書き込まれない非 <code>null</code> フィールドを見つけます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.IntCast2LongAsInstant">
<Details>
<![CDATA[
<p>
このディテクタは，エポックからミリ秒を記述する32ビット値の使い方を見つけます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TrainLongInstantfParams">
<Details>
<![CDATA[
<p>
このディテクタは，エポックからミリ秒を記述している64ビット値を取るパラメータのデータベースを構築します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InconsistentAnnotations">
<Details>
<![CDATA[
<p>
このディテクタは，型修飾子が直接適用されるメソッドパラメータとそれらのメソッドパラメータの使い方との間で矛盾を見つけます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.AtomicityProblem">
<Details>
<![CDATA[
<p>
このディテクタは，アトミックに実行されない並行抽象の操作シーケンス（たとえば，get/put）を見つけます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SynchronizationOnSharedBuiltinConstant">
<Details>
<![CDATA[
<p>
このディテクタは，共有された組込み定数 (たとえば， <code>String</code>) の同期化を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SynchronizeAndNullCheckField">
<Details>
<![CDATA[
<p>
このディテクタは，同期化されたフィールドを <code>null</code> チェックしているコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CheckImmutableAnnotation">
<Details>
<![CDATA[
<p>
このディテクタは， <code>net.jcip.annotations.Immutable</code> または <code>javax.annotation.concurrent.Immutable</code> というアノテーションが付けられたクラスのルール違反を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.VarArgsProblems">
<Details>
<![CDATA[
<p>
このディテクタは，J2SE 5.0の可変長引数に起因する問題を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteJCIPAnnotation">
<Details>
<![CDATA[
<p>
このディテクタは，net.jcip.annotations パッケージからアノテーションを記録します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteDirectlyRelevantTypeQualifiers">
<Details>
<![CDATA[
<p>
このディテクタは，メソッドを解析することに関連する型修飾子に注意します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BuildInterproceduralCallGraph">
<Details>
<![CDATA[
<p>
このディテクタは，プロシージャー間の呼び出しグラフを構築します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BuildObligationPolicyDatabase">
<Details>
<![CDATA[
<p>
このディテクタは，FindUnsatisfiedObligation ディテクタによって使われる責務の種類とメソッドのデータベースを構築します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteSuppressedWarnings">
<Details>
<![CDATA[
<p>
このディテクタは， <code>edu.umd.cs.findbugs.annotations.NoteSuppressWarnings</code> アノテーションの使い方に基づく警告を抑止します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteAnnotationRetention">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Retention</code> アノテーションを記録します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteSyntheticElements">
<Details>
<![CDATA[
<p>
このディテクタは，合成クラス，メソッド，フィールドなどを記録します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.Methods">
<Details>
<![CDATA[
<p>
このディテクタは，他のディテクタが使用するための解析されたクラスで定義されているすべてのメソッドのデータベースを構築します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.ReflectiveClasses">
<Details>
<![CDATA[
<p>
このディテクタは，どのクラスが .class オブジェクトへの定数参照を持っているのか決定しようと試みます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CalledMethods">
<Details>
<![CDATA[
<p>
このディテクタは，他のディテクタが使用するための解析されたクラスで呼び出されるすべてのメソッドのデータベースを構築します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindNoSideEffectMethods">
<Details>
<![CDATA[
<p>
値を返すだけの副作用を持たないメソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BuildStringPassthruGraph">
<Details>
<![CDATA[
<p>
このディテクタは，メソッドから変化していないメソッドに渡された文字列パラメータのデータベースを構築します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FunctionsThatMightBeMistakenForProcedures">
<Details>
<![CDATA[
<p>
このディテクタは，クラスの新しいインスタンスを返すメソッドがある不変クラスを探します。
メソッドが呼び出されるとインスタンスが変化させられると思います。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.ConfusionBetweenInheritedAndOuterMethod">
<Details>
<![CDATA[
<p>
このディテクタは，継承されたメソッドと外部のメソッドとの潜在的混同を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteCheckReturnValueAnnotations">
<Details>
<![CDATA[
<p>
このディテクタは，メソッドの戻り値をチェックするためにアノテーションを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SynchronizeOnClassLiteralNotGetClass">
<Details>
<![CDATA[
<p>
このディテクタは，クラスリテラルではなく， <code>getClass</code> メソッドの結果で同期化するコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FieldItemSummary">
<Details>
<![CDATA[
<p>
このディテクタは，何がフィールドに格納されたのかについて，サマリー情報を作り出します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteNonNullAnnotations">
<Details>
<![CDATA[
<p>
このディテクタは，メソッド，フィールド，パラメータで <code>@Nonｎull</code> アノテーションを探します。
FindNullDeref ディテクタで，非 <code>null</code> 値だけが使われるべきコンテキストで <code>null</code> かもしれない値が使われたときに警告を生成するために使用できます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteUnconditionalParamDerefs">
<Details>
<![CDATA[
<p>
このディテクタは，無条件にパラメータの参照外しが行われるのかを決定するためにアプリケーションのすべてのメソッドを解析します。
この情報は， <code>null</code> 値がメソッドに渡されるかもしれない呼び出し場所を発見するために後の解析パスで使われます。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteNonnullReturnValues">
<Details>
<![CDATA[
<p>
このディテクタは，どのメソッドが常に非 <code>null</code> 値を返すのかを決定するためにアプリケーションのすべてのメソッドを解析します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BooleanReturnNull">
<Details>
<![CDATA[
<p>
このディテクタは，明示的に <code>null</code> 値を返す戻り型が <code>Boolean</code> のメソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.OptionalReturnNull">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Optional</code> の戻り型が明示的に <code>null</code> 値を返すメソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUselessObjects">
<Details>
<![CDATA[
<p>
このディテクタは役に立たないオブジェクトを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.MutableEnum">
<Details>
<![CDATA[
<p>
このディテクタは，可変列挙型フィールドを探して警告します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BadUseOfReturnValue">
<Details>
<![CDATA[
<p>
このディテクタは，メソッドの戻り値が <code>null</code> ではないことをチェックした後で捨てるケースを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InheritanceUnsafeGetResource">
<Details>
<![CDATA[
<p>
このディテクタは，クラスが別のパッケージのクラスによって拡張されるなら，予想外の結果をもたらす可能性がある <code>this.getClass().getResource(...)</code> の使用を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InfiniteRecursiveLoop">
<Details>
<![CDATA[
<p>
このディテクタは，無限再帰ループを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InfiniteLoop">
<Details>
<![CDATA[
<p>
このディテクタは，無限ループを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.VolatileUsage">
<Details>
<![CDATA[
<p>
このディテクタは， <code>volatile</code> フィールドの使い方のバグパターンを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.EmptyZipFileEntry">
<Details>
<![CDATA[
<p>
このディテクタは，空の zip ファイルエントリの作成を探します。
</p>
<p>
中速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.UncallableMethodOfAnonymousClass">
<Details>
<![CDATA[
<p>
このディテクタは，無名内部クラスに定義されたメソッドで，スーパークラスのメソッドをオーバーライドすることを意図していますが，実際はオーバーライドになっていないメソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DontUseEnum">
<Details>
<![CDATA[
<p>
このディテクタは，フィールドとメソッドが J2SE 5.0のキーワードである <code>assert</code> や <code>enum</code> を名前として使用していないことをチェックします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.URLProblems">
<Details>
<![CDATA[
<p>
<code>java.net.URL</code> の <code>equals</code> と <code>hashCode</code> メソッドはドメイン名の解決をします。
その結果，これらの操作はかなり高くつきます。このディテクタは，メソッドが呼び出されるかもしれない場所を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FinalizerNullsFields">
<Details>
<![CDATA[
<p>
このディテクタは，クラスのフィールドを <code>null</code> にするファイナライザを探します。
どんな方法でもフィールドを <code>null</code> にすることは効果がなく，ガベージコレクタの助けになりません。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CrossSiteScripting">
<Details>
<![CDATA[
<p>
このディテクタは XSS 脆弱性の自明で露骨なケースを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.RepeatedConditionals">
<Details>
<![CDATA[
<p>
このディテクタは， <code>(x == 5 || x == 5)</code> のような繰り返される条件テストを含んでいるコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.RedundantConditions">
<Details>
<![CDATA[
<p>
このディテクタは，この式 <code>(x >= 10 && x >= 5)</code> の2番目の条件のような役に立たない条件を含んでいるコードを探します.
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CallToUnsupportedMethod">
<Details>
<![CDATA[
<p>
このディテクタは，サポートされていないメソッドの呼び出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FormatStringChecker">
<Details>
<![CDATA[
<p>
このディテクタは，間違った書式文字列をチェックします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.EqualsOperandShouldHaveClassCompatibleWithThis">
<Details>
<![CDATA[
<p>
このディテクタは， <code>equals</code> メソッドを定義しているクラスと互換性がないクラスのインスタンスをオペランドにしてチェックする <code>equals</code> メソッドをチェックします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TestingGround">
<Details>
<![CDATA[
<p>
このディテクタは，新しいディテクタをテストするためのフックです。通常このディテクタは何もしません。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TestingGround2">
<Details>
<![CDATA[
<p>
このディテクタは，新しいディテクタをテストするためのフックです。通常このディテクタは何もしません。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.LostLoggerDueToWeakReference">
<Details>
<![CDATA[
<p>
このディテクタは，OpenJDK 1.6の下で異なる振る舞いをするコードを探します。OpenJDK 1.6では， <code>Logger</code> を保持するのに弱参照が使われます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TestingGround2">
<Details>
<![CDATA[
<p>
このディテクタは，新しいディテクタをテストするためのフックです。通常このディテクタは何もしません。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.Noise">
<Details>
<![CDATA[
<p>
このディテクタは，ランダムな信号を生成します。メソッドによって実行される演算のハッシュ値に基づく警告です。
これらの警告はソフトウェアで実際のバグを発見するのではなく，データマイニング実験のコントロールとして役に立つことを目的とした偽のランダムノイズです。
</p>
<p>
このディテクタは，新しいディテクタをテストするためのフックです。通常このディテクタは何もしません。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoiseNullDeref">
<Details>
<![CDATA[
<p>
<code>null</code> の参照解除のためのノイズが多いディテクタです。コードの問題を見つける方法として使用するのではく，警告の妥当性または予測能力の実験でコントロールとして役に立つことを意図しました。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.HugeSharedStringConstants">
<Details>
<![CDATA[
<p>
このディテクタは，複数のクラスファイルにわたって複製されている文字列定数を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DoInsideDoPrivileged">
<Details>
<![CDATA[
<p>
このディテクタは， <code>doPrivileged</code> ブロックの中で実行すべきコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.ResolveAllReferences">
<Details>
<![CDATA[
<p>
このディテクタは，すべての参照呼び出しが解決されることをチェックします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SwitchFallthrough">
<Details>
<![CDATA[
<p>
このディテクタは，フォールスルーがある <code>switch</code> 文を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindFieldSelfAssignment">
<Details>
<![CDATA[
<p>
このディテクタは，フィールドが同じフィールドの値を読み出して代入される場所を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindSelfComparison">
<Details>
<![CDATA[
<p>
このディテクタは，値がそれ自身と比較される場所を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindSelfComparison2">
<Details>
<![CDATA[
<p>
このディテクタは，値がそれ自身と比較される場所を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindNonShortCircuit">
<Details>
<![CDATA[
<p>
このディテクタは，非短絡論理演算子の疑わしい使用を探します（<code>||</code> と <code>&&</code> の代わりに <code>|</code> と <code>&</code>)。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DontCatchIllegalMonitorStateException">
<Details>
<![CDATA[
<p>
このディテクタは， <code>IllegalMonitorStateException</code> をキャッチする <code>try-catch</code> ブロックを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindFloatMath">
<Details>
<![CDATA[
<p>
このディテクタは，浮動小数点演算の使用を探します。
</p>
<p>
中速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CloneIdiom">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Cloneable</code> クラスを書くためのイディオムの違反を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.ComparatorIdiom">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Comparator</code> を実装するクラスを書くためのイディオムの違反を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DroppedException">
<Details>
<![CDATA[
<p>
このディテクタは，例外をキャッチしていますが，何もしていないコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.LoadOfKnownNullValue">
<Details>
<![CDATA[
<p>
このディテクタは， <code>null</code> とわかっている値の読み出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DumbMethodInvocations">
<Details>
<![CDATA[
<p>
このディテクタは，メソッド (例：<code>substring(0)</code>) に渡されている間違った引数を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DumbMethods">
<Details>
<![CDATA[
<p>
このディテクタは，引数のない <code>String</code> コンストラクタのような無意味なメソッドの呼び出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CovariantArrayAssignment">
<Details>
<![CDATA[
<p>
このディテクタは，実行時に <code>ArrayStoreException</code> を引き起こすかもしれない <code>Object[] array = new String[10]</code> のような共変配列代入を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NumberConstructor">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Number</code> コンストラクタのプリミティブ型の引数による呼び出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindDoubleCheck">
<Details>
<![CDATA[
<p>
このディテクタは，ダブルチェックロッキングのインスタンスを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindFinalizeInvocations">
<Details>
<![CDATA[
<p>
このディテクタは， <code>finalize</code> メソッドの呼び出しと他のファイナライザ関連の問題を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindHEmismatch">
<Details>
<![CDATA[
<p>
このディテクタは， <code>hashCode</code> メソッドと <code>equals</code> メソッドの定義の問題を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.OverridingEqualsNotSymmetrical">
<Details>
<![CDATA[
<p>
このディテクタは，同値関係が対称的ではないかもしれないスーパークラスの <code>equals</code> メソッドをオーバーライドする <code>equals</code> メソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindNakedNotify">
<Details>
<![CDATA[
<p>
このディテクタは，可変オブジェクトの状態を変更するとは思えない <code>notify</code> メソッドの呼び出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindReturnRef">
<Details>
<![CDATA[
<p>
このディテクタは，可変静的データを返すメソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindRunInvocations">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Thread.run()</code> の呼び出しを探します。
</p>
<p>
高速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindSpinLoop">
<Details>
<![CDATA[
<p>
このディテクタは，フィールドからの読み取りをするスピンループを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindTwoLockWait">
<Details>
<![CDATA[
<p>
このディテクタは，2つ以上のロックを保持している状態で <code>wait</code> メソッドの呼び出しを探します。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUnconditionalWait">
<Details>
<![CDATA[
<p>
このディテクタは，条件文，またはループの中にない <code>wait</code> メソッドの呼び出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUninitializedGet">
<Details>
<![CDATA[
<p>
このディテクタは，コンストラクタで初期化されていないフィールドの読み出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUnsyncGet">
<Details>
<![CDATA[
<p>
このディテクタは，set メソッドは同期化していて get メソッドは同期化していない get メソッドと set メソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InitializationChain">
<Details>
<![CDATA[
<p>
このディテクタは，潜在的循環クラス初期化依存関係を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.IteratorIdioms">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Iterator</code> クラスの定義方法の問題を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.LockedFields">
<Details>
<![CDATA[
<p>
このディテクタは，ロックに関して一貫性のない方法でアクセスされるフィールドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.EqStringTest">
<Details>
<![CDATA[
<p>
このディテクタは <code>==</code> や <code>!=</code> 演算子を使用している <code>String</code> オブジェクトの比較を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.MutableLock">
<Details>
<![CDATA[
<p>
このディテクタは，変更されたフィールドから読み込まれるオブジェクトの同期化を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SynchronizingOnContentsOfFieldToProtectField">
<Details>
<![CDATA[
<p>
このディテクタは，フィールドの更新をガードするためにフィールドを同期化しているように思われるコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.MutableStaticFields">
<Details>
<![CDATA[
<p>
このディテクタは，悪意のあるコードによって変更されるかもしれない <code>static</code> フィールドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.Naming">
<Details>
<![CDATA[
<p>
このディテクタは，疑わしい名前のメソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.ReadReturnShouldBeChecked">
<Details>
<![CDATA[
<p>
このディテクタは，戻り値が無視される <code>InputStream.read()</code> または <code>InputStream.skip()</code> の呼び出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SerializableIdiom">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Serializable</code> クラスの実装の潜在的な問題を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.StartInConstructor">
<Details>
<![CDATA[
<p>
このディテクタは，スレッドを開始するコンストラクタを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindBadForLoop">
<Details>
<![CDATA[
<p>
このディテクタは，間違った <code>for</code> ループを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.ExplicitSerialization">
<Details>
<![CDATA[
<p>
このディテクタは，このクラスが本当に直列化されるという証拠として， <code>readObject</code> と <code>writeObject</code> による明示的な直列化を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.UnreadFields">
<Details>
<![CDATA[
<p>
このディテクタは，値が決して読み出されないフィールドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.WaitInLoop">
<Details>
<![CDATA[
<p>
このディテクタは，ループの中にない <code>wait</code> メソッドの呼び出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BCPMethodReturnCheck">
<Details>
<![CDATA[
<p>
このディテクタは，戻り値が疑わしく無視されるメソッドの呼び出しを探します。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindComparatorProblems">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Comparator.compare</code> または <code>Comparable.compareTo</code> の実装における問題を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindNullDeref">
<Details>
<![CDATA[
<p>
このディテクタは， <code>NullPointerException</code> が発生するかもしれない場所を探します。
また， <code>null</code> に対する参照値の冗長な比較を探します。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindNullDerefsInvolvingNonShortCircuitEvaluation">
<Details>
<![CDATA[
<p>
このディテクタは， <code>NullPointerException</code> が発生するかもしれない場所を探します。
非短絡評価の使用はありふれたテクニックで失敗の原因になります。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindOpenStream">
<Details>
<![CDATA[
<p>
このディテクタは，メソッドから脱出しないで，メソッドからのすべての経路でクローズされるように見えない I/O ストリームオブジェクトを探します。
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.PreferZeroLengthArrays">
<Details>
<![CDATA[
<p>
このディテクタは，配列か明示的に <code>null</code> 参照を返すメソッドを探します。
長さが0の配列を返すことは，このコンテキストにおいて <code>null</code> 参照を返すことよりも一般的に好ましいです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUselessControlFlow">
<Details>
<![CDATA[
<p>
このディテクタは，効果がない制御フロー文を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUnreleasedLock">
<Details>
<![CDATA[
<p>
このディテクタは，JSR-166(java.util.concurrent) のロックを獲得したのにメソッドからのすべての経路で解除されないロックを探します。
</p>
<p>
中速ディテクタです。
</p>
<p>
補助クラスパスに java.util.concurrent パッケージ (またはパッケージ自体を解析している) が必要であることに注意してこのディテクタを使用してください
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindRefComparison">
<Details>
<![CDATA[
<p>
このディテクタは，2つの参照値を <code>==</code> や <code>!=</code> 演算子で比較している場所を探します。
<code>java.lang.String</code> のような型のクラスの参照値を比較することは一般的に誤りです。
</p>
</p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindMismatchedWaitOrNotify">
<Details>
<![CDATA[
<p>
このディテクタは，現在ロックされているオブジェクトで作成されるように見えない <code>wait</code> メソッド， <code>notify</code> メソッド， <code>notifyAll</code> メソッドの呼び出しを探します。
</p>
</p>
中速ディテクタです。
<p>
このディテクタは，まだ開発中で，あまりに多くの誤検出が発生するので，無効にされています。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindEmptySynchronizedBlock">
<Details>
<![CDATA[
<p>
このディテクタは，空の <code>synchronized</code> ブロックを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindInconsistentSync2">
<Details>
<![CDATA[
<p>
このディテクタは，ロックに関して一貫性のない方法でアクセスされるフィールドを探します。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindLocalSelfAssignment2">
<Details>
<![CDATA[
<p>
このディテクタは，ローカル変数の自己代入を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.IncompatMask">
<Details>
<![CDATA[
<p>
このディテクタは，疑わしいビット論理式を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.LazyInit">
<Details>
<![CDATA[
<p>
このディテクタは，フィールドが <code>volatile</code> ではないフィールドの遅延初期化を探します。
</p>
<p>
中速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindJSR166LockMonitorenter">
<Details>
<![CDATA[
<p>
このディテクタは，JSR-166 のロックで実行される通常の同期化を探します。
</p>
<p>
中速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUncalledPrivateMethods">
<Details>
<![CDATA[
<p>
このディテクタは，決して呼び出されない <code>private</code> メソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.StringConcatenation">
<Details>
<![CDATA[
<p>
このディテクタは，+を使ったループによる文字列の連結を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InefficientInitializationInsideLoop">
<Details>
<![CDATA[
<p>
このディテクタは，パフォーマンスを向上させるために外側に移せるループ内で初期化しているオブジェクトを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InefficientIndexOf">
<Details>
<![CDATA[
<p>
このディテクタは， <code>String.indexOf(String)</code> または <code>String.lastIndexOf(String)</code> を使用して定数に長さ1の文字列を渡すコードを探します。
より効率的な整数実装を使用することを推奨します。
高速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InefficientToArray">
<Details>
<![CDATA[
<p>
このディテクタは， <code>toArray(T[] a)</code> メソッドに長さが0の配列を渡してコレクションを配列に変換するコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InefficientReplaceAll">
<Details>
<![CDATA[
<p>
このディテクタは， <code>replaceAll(String regex, String replacement)</code> メソッドに
正規表現固有の文字を含まない文字列を渡しているコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InvalidJUnitTest">
<Details>
<![CDATA[
<p>
このディテクタは，不正な形式の JUnit テストを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BadlyOverriddenAdapter">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Adapter</code> クラスを拡張して，間違ったシグネチャで <code>Listener</code> メソッドをオーバーライドするコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BadResultSetAccess">
<Details>
<![CDATA[
<p>
このディテクタは，列インデックス番号が0の <code>ResultSet</code> の <code>getXXX</code> または <code>setXXX</code> メソッドの呼び出しを探します。
<code>ResultSet</code> の列インデックス番号は1で始まるので，これは常に間違いです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SuperfluousInstanceOf">
<Details>
<![CDATA[
<p>
このディテクタは，静的に判定される <code>instanceof</code> 演算子を使用している型チェックを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BadAppletConstructor">
<Details>
<![CDATA[
<p>
このディテクタは， <code>Applet</code> スタブに依存する親 <code>Applet</code> でメソッドを呼び出す <code>Applet</code> コンストラクタを探します。
このスタブは <code>init</code> メソッドの前まで初期化されないので，これらのメソッドはコンストラクタで失敗します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SuspiciousThreadInterrupted">
<Details>
<![CDATA[
<p>
このディテクタは，非スタティックなコンテキストから <code>Thread.interrupted()</code> の呼び出しを探します。
<code>Thread.currentThread().interrupted()</code> から呼び出されるなら，役に立たない行為なので <code>Thread.interrupted()</code> を使用します。
しかしながら， <code>interrupted</code> メソッドは常にカレントスレッドで呼び出されるので，任意のスレッドオブジェクトで呼び出すのはほぼ間違いなく誤りです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindSqlInjection">
<Details>
<![CDATA[
<p>
このディテクタは， <code>switch</code> 文で定数文字列以外の何かが引数として渡される SQL 文の <code>execute</code> メソッドの呼び出しを探すためにデータフロー解析を使います。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindDeadLocalStores">
<Details>
<![CDATA[
<p>
このディテクタは，その後，決して読み出されないローカル変数への代入を探します。
</p>
<p>
中速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindMaskedFields">
<Details>
<![CDATA[
<p>
このディテクタは，メソッドで定義されたローカル変数によって隠されるフィールドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.WrongMapIterator">
<Details>
<![CDATA[
<p>
このディテクタは， <code>keySet</code> イテレータから取り出されたキーを使用して <code>Map</code> エントリの値にアクセスするコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InstantiateStaticClass">
<Details>
<![CDATA[
<p>
このディテクタは， <code>static</code> メソッドしか定義していないクラスのオブジェクトを作成しているコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.RuntimeExceptionCapture">
<Details>
<![CDATA[
<p>
このディテクタは，ブロックの中のコードが例外をスローしないのに例外をキャッチする <code>catch</code> 節を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindFloatEquality">
<Details>
<![CDATA[
<p>
このディテクタは，浮動小数点の等価式を探します。
</p>
<p>
高速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUnsatisfiedObligation">
<Details>
<![CDATA[
<p>
このディテクタは，メソッドからのすべての経路でクリーンアップされない入出力ストリームとデータベースリソースを探します。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.UnnecessaryMath">
<Details>
<![CDATA[
<p>
このディテクタは，計算結果が静的に知られている値を計算するために <code>java.lang.Math</code> の <code>static</code> メソッドを呼び出すコードを探します。
その代わりに定数を使用する方がより高速で，ときにはより正確です。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindCircularDependencies">
<Details>
<![CDATA[
<p>
このディテクタは，クラス間の循環依存関係を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.RedundantInterfaces">
<Details>
<![CDATA[
<p>
このディテクタは，スーパークラスと同じインタフェースを実装すると宣言しているサブクラスを探します。
スーパークラスがインタフェースを実装しているので，サブクラスで同じことをするのは冗長です。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.MultithreadedInstanceAccess">
<Details>
<![CDATA[
<p>
このディテクタは，Struts フレームワークを実装する際の潜在的な問題を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.PublicSemaphores">
<Details>
<![CDATA[
<p>
このディテクタは，同期化して <code>this</code> に対して <code>wait</code> メソッド， <code>notify</code> メソッド， <code>notifyAll</code> メソッドを使用する <code>public</code> クラスを探します。
これは <code>public</code> クラスの同期化実装を暴露することになります。
クラスのクライアントは，そのクラスのインスタンスをそれ自身の同期オブジェクトとして使用し，ベース実装に大惨事をもたらします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.MethodReturnCheck">
<Details>
<![CDATA[
<p>
このディテクタは，戻り値が疑わしく無視されるメソッドの呼び出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.IDivResultCastToDouble">
<Details>
<![CDATA[
<p>
このディテクタは，整数除算の結果が <code>double</code> にキャストされる場所を探します。
多くの場合，意味されたことは，整数オペランドを <code>double</code> にキャストしてから除算を実行することでした。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindBadCast2">
<Details>
<![CDATA[
<p>
このディテクタは，データフロー解析を使用してオブジェクト参照の間違ったキャストを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindNonSerializableStoreIntoSession">
<Details>
<![CDATA[
<p>
このディテクタは，HTTP セッションへの非直列化オブジェクトの格納を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUseOfNonSerializableValue">
<Details>
<![CDATA[
<p>
このディテクタは，それらが直列化可能であることを要求するコンテキストで，非 <code>Serializable</code> オブジェクトの使用を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindNonSerializableValuePassedToWriteObject">
<Details>
<![CDATA[
<p>
このディテクタは， <code>ObjectOutput</code> の <code>writeObject</code> メソッドに渡される非 <code>Serializable</code> オブジェクトを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BadSyntaxForRegularExpression">
<Details>
<![CDATA[
<p>
このディテクタは，無効な構文がある正規表現を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindPuzzlers">
<Details>
<![CDATA[
<p>
このディテクタは，Joshua Bloch と Neal Gafter が『Java Puzzlers』で言及した多方面にわたるささいな誤りを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindSleepWithLockHeld">
<Details>
<![CDATA[
<p>
このディテクタは，ロックを保持している状態での <code>Thread.sleep()</code> の呼び出しを探します。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DuplicateBranches">
<Details>
<![CDATA[
<p>
このディテクタは，2つの分岐に同じコードがある <code>if</code>/<code>else</code> または <code>switch</code> 文を探します。
これは多くの場合，2つの分岐に同じコードをコピー & ペーストしていることが片方の分岐の間違ったロジックの原因になります。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InefficientMemberAccess">
<Details>
<![CDATA[
<p>
このディテクタは，所有クラスの <code>private</code> フィールドに書き込んでいる内部クラスを探します。
この場合，コンパイラは必ずこのフィールドへ書き込むことに使われるアクセサメソッドを生成します。
可視性を <code>protected</code> に緩和することは，フィールドに直接書き込むことを可能にします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.XMLFactoryBypass">
<Details>
<![CDATA[
<p>
このディテクタは，XML インタフェースを実装したクラスのインスタンスを直接生成しているコードを探します。
これらのオブジェクトを作成するために提供されたファクトリパターンを使用するのではなく，特定の実装にコードを結びつけます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.UselessSubclassMethod">
<Details>
<![CDATA[
<p>
このディテクタは，スーパークラスで定義されたメソッドを実装して，スーパークラスのメソッドにパラメータをそのまま渡しているだけのサブクラスを探します。
これらのメソッドは除去できます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.ConfusedInheritance">
<Details>
<![CDATA[
<p>
このディテクタは， <code>protected</code> メンバを宣言する <code>final</code> クラスを探します。
このクラスは派生させることができないので， <code>protected</code> メンバの使用は正しくありません。
アクセス権は，メンバの正しい意図を表すために <code>public</code> か <code>private</code> に変更すべきです。
</p>
<p>
おそらく，新しいパラダイムにクラスのすべてを完全に変更することではなく，クラスの使用中の変化が原因となりました。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.QuestionableBooleanAssignment">
<Details>
<![CDATA[
<p>
このディテクタは，条件式で変数にリテラルブール値の単純な代入を探します。
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TrainNullReturnValues">
<Details>
<![CDATA[
<p>
このディテクタは，どのメソッドが <code>null</code> を返すのかを決定してファイルに保存します。
結果ファイルは， <code>null</code> 間接参照ディテクタの精度を向上させるために後続のパスで使われることがあります。
これはトレーニングパスなので警告は報告されません。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TrainUnconditionalDerefParams">
<Details>
<![CDATA[
<p>
このディテクタは，どのメソッドが無条件に <code>null</code> の参照外しを行うのかを決定してファイルに保存します。
結果ファイルは， <code>null</code> 間接参照ディテクタの精度を向上させるために後続のパスで使われることがあります。
これはトレーニングパスなので警告は報告されません。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TrainFieldStoreTypes">
<Details>
<![CDATA[
<p>
このディテクタは，フィールドに格納される型を解析してデータベースに保存します。
データベースは，型解析をより正確にするために後続のパスで使われることがあります。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TrainNonNullAnnotations">
<Details>
<![CDATA[
<p>
このディテクタは， <code>@Nonｎull</code> と <code>@PossiblyNull</code> アノテーションを集めて，データベースに保存します。
</p>
<p>
高速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CheckCalls">
<Details>
<![CDATA[
<p>
このディテクタは，SpotBugs でメソッド呼び出しの解決をデバッグするためにあります。
</p>
<p>
有効にしないでください。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindBugsSummaryStats">
<Details>
<![CDATA[
<p>
このディテクタは，解析過程のサマリー統計情報を収集します。
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TestASM">
<Details>
<![CDATA[
<p>
このディテクタは，ASM バイトコード解析フレームワークを使用した SpotBugs ディテクタを書く方法を示しているコード例です。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindUnrelatedTypesInGenericContainer">
<Details>
<![CDATA[
<p>
このディテクタは，引数の型がコレクションのパラメータに関連しているかどうか確かめるために <code>java.lang.Object</code> を受け取る総称型コレクションメソッドへの呼び出しの引数を見ます。
無関係なクラス型による引数は決してコレクションの中に格納されることはありません。
たとえば， <code>foo</code> が<code>List<String></code> で， <code>bar</code> が <code>StringBuffer</code> なら <code>foo.contains(bar)</code> の呼び出しは常に <code>false</code> を返すことになります。
</p>
<p>
高速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.StaticCalendarDetector">
<Details>
<![CDATA[
<p>
<code>Calendar</code> は，マルチスレッドでの使用は本質的に安全ではないので，このディテクタは， <code>java.util.Calendar</code> や <code>java.text.DateFormat</code> (サブクラスも) の <code>static</code> フィールドについて警告します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TestDataflowAnalysis">
<Details>
<![CDATA[
<p>
これはデータフロー解析を検証するためにだけ使われる内部のディテクタです。
</p>
<p>
デフォルトでは有効にされません。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CheckTypeQualifiers">
<Details>
<![CDATA[
<p>
このディテクタは，JSR-305 の型修飾子アノテーションで特定されたプロパティの違反をチェックします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.AppendingToAnObjectOutputStream">
<Details>
<![CDATA[
<p>
このディテクタは，オブジェクト出力ストリームに追加しようとする試みを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CheckExpectedWarnings">
<Details>
<![CDATA[
<p>
このディテクタは，@ExpectedWarning と @NoWarning アノテーションをチェックします。
このディテクタは，SpotBugs をテストするためだけに使われます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DontIgnoreResultOfPutIfAbsent">
<Details>
<![CDATA[
<p>
このディテクタは， <code>ConcurrentMap</code> の <code>putIfAbsent</code> メソッドの結果が無視されるなら，2番目の引数として渡された値が再利用されていないことをチェックします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.ReadOfInstanceFieldInMethodInvokedByConstructorInSuperclass">
<Details>
<![CDATA[
<p>
このディテクタは，スーパークラスのためのコンストラクタから呼び出されるメソッドをチェックします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DefaultEncodingDetector">
<Details>
<![CDATA[
<p>
このディテクタは，ユーザのデフォルトプラットフォームエンコーディングを使用して， <code>byte</code> から <code>String</code> (または <code>String</code> から <code>byte</code>) に変換するメソッドの呼び出しをチェックします。
これはアプリケーションの振る舞いがプラットフォーム間で異なる原因となります。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CheckRelaxingNullnessAnnotation">
<Details>
<![CDATA[
<p>
このディテクタは，オーバライドメソッドが 戻り値またはパラメータの <code>@CheckForNull</code> (<code>@Nonnull</code> で作られた) で <code>@Nonnull</code> (<code>@CheckForNull</code> で作られた) を緩和していないことをチェックします。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.DontAssertInstanceofInTests">
<Details>
<![CDATA[
<p>
このディテクタは、インスタンスの型を instanceof 演算子を使って検証しているJUnitテストをチェックします。
</p>
<p>
instanceof 演算子を使うと "false is not true" という直感的でないメッセージを
伴う例外が記録されます。これは ClassCastException などよりも情報に乏しいため、他の手法を
用いることが推奨されます。
</p>
<p>このディテクタは高速に動作します。</p>
]]>
</Details>
</Detector>
<!--
**********************************************************************
BugPatterns
**********************************************************************
-->
<BugPattern type="JUA_DONT_ASSERT_INSTANCEOF_IN_TESTS">
<ShortDescription> テストコードで instanceof 演算子を用いて型を検証するのは推奨されません。 </ShortDescription>
<LongDescription> 型 {0} の検証を {2} の {3} で実行していますが、これは期待通りの挙動が確認されなかった場合に有用な情報が得られません。 </LongDescription>
<Details>
<![CDATA[
<p>
テストコードで型を instanceof 演算子を使って検証することは、ClassCastExceptionなどに比べて有用な情報が得られないため
推奨されません。
</p>
<p>
デバッグのためには <code>"false is not true"</code> のような意味のない情報よりも、
ClassCastException 例外のようにどの型がどの型にキャストできなかったのかを説明できる手法が良いでしょう。
</p>
<p>
もしJUnitをhamcrestと組み合わせて使っているのであれば、 hamcrestの<a href="https://junit.org/junit4/javadoc/latest/index.html?org/hamcrest/core/IsInstanceOf.html"><code>IsInstanceOf</code></a>
クラスを使うことが推奨されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="OVERRIDING_METHODS_MUST_INVOKE_SUPER">
<ShortDescription>スーパークラスのメソッドが @OverridingMethodsMustInvokeSuper で修飾されていますが, オーバーライドしているメソッドはスーパークラスのメソッドを呼び出していません。</ShortDescription>
<LongDescription>スーパークラスのメソッドが @OverridingMethodsMustInvokeSuper で修飾されていますが, {1}はスーパークラスのメソッドを呼び出していません。</LongDescription>
<Details>
<![CDATA[
<p>スーパークラスのメソッドが @OverridingMethodsMustInvokeSuper で修飾されていますが, オーバーライドしているメソッドはスーパークラスのメソッドを呼び出していません。</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CNT_ROUGH_CONSTANT_VALUE">
<ShortDescription>既知の定数の雑な値を見つけた</ShortDescription>
<LongDescription>{3} の雑な値を見つけました: {2}</LongDescription>
<Details>
<![CDATA[
<p>
コードの明確さともっと良い正確さのために定義済みライブラリ定数を使用することを推奨します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SKIPPED_CLASS_TOO_BIG">
<ShortDescription>解析するにはあまりにも大きいクラス</ShortDescription>
<LongDescription>{0} は，解析するにはあまりにも大きいです。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは効率的に処理できないほど大きいです。また，エラーのために完全に解析されませんでした。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NOISE_NULL_DEREFERENCE">
<ShortDescription>null ポインタ間接参照に関する偽の警告</ShortDescription>
<LongDescription>null ポインタ間接参照に関する偽の警告です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
偽の警告です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NOISE_METHOD_CALL">
<ShortDescription>メソッド呼び出しに関する偽の警告</ShortDescription>
<LongDescription>メソッド呼び出し {2} に関する偽の警告です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
偽の警告です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NOISE_FIELD_REFERENCE">
<ShortDescription>フィールド参照に関する偽の警告</ShortDescription>
<LongDescription>フィールド参照 {2} に関する偽の警告です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
偽の警告です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NOISE_OPERATION">
<ShortDescription>演算に関する偽の警告</ShortDescription>
<LongDescription>演算 {2} に関する偽の警告です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
偽の警告です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLE">
<ShortDescription>正確に表されない double から構築された BigDecimal</ShortDescription>
<LongDescription>{4} から BigDecimal が構築されています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは10進数の数にうまく変換されない <code>double</code> 値から <code>BigDecimal</code> を作成しています。
たとえば，Java で <code>new BigDecimal(0.1)</code> と書くと，0.1と正確に等しい <code>BigDecimal</code> (スケールが1でスケールなしの値が1) が作成されると思うかもしれませんが，
実際には0.1000000000000000055511151231257827021181583404541015625と等しくなります。
</p>
<p>
おそらく <code>BigDecimal.valueOf(double d)</code> メソッドの使用が望ましいです。<code>BigDecimal</code> (たとえば， <code>BigDecimal.valueOf(0.1)</code> は0.1を与えます) を作成するためには <code>double</code> の文字列表現を使用します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_DOH">
<ShortDescription>D'oh! 無意味なメソッド呼び出し</ShortDescription>
<LongDescription>D'oh! {2.nameAndSignature} の無意味なメソッド呼び出し。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この部分的なメソッド呼び出しは，検査から明らかな理由で意味がありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_VACUOUS_CALL_TO_EASYMOCK_METHOD">
<ShortDescription>EasyMock メソッドへの役に立たない/無意味な呼び出し</ShortDescription>
<LongDescription>EasyMock メソッド {2} の呼び出しは役に立たない/無意味です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この呼び出しは EasyMock メソッドにどんなオブジェクトも渡さないので何もしません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_SCHEDULED_THREAD_POOL_EXECUTOR_WITH_ZERO_CORE_THREADS">
<ShortDescription>コアプールサイズが0の ScheduledThreadPoolExecutor の作成</ShortDescription>
<LongDescription>コアプールサイズが0の ScheduledThreadPoolExecutor を作成しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
コアプールサイズが0の <code>ScheduledThreadPoolExecutor</code> は決して何も実行しません。
最大プールサイズへの変更は無視されます。<br>
(<a href="https://docs.oracle.com/javase/jp/8/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html#ScheduledThreadPoolExecutor-int-">Javadoc</a>)
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_FUTILE_ATTEMPT_TO_CHANGE_MAXPOOL_SIZE_OF_SCHEDULED_THREAD_POOL_EXECUTOR">
<ShortDescription>ScheduledThreadPoolExecutor の最大プールサイズを変えようとする無駄な試み</ShortDescription>
<LongDescription>ScheduledThreadPoolExecutor の最大プールサイズを変えようとするのは無駄な試みです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>ScheduledThreadPoolExecutor</code> は <code>ThreadPoolExecutor</code> から継承されますが継承されたチューニングメソッドの一部は有用ではありません。
特に，corePoolSize スレッドとアンバウンド形式のキューを使用する固定サイズプールとして動作するので，maximumPoolSize の調整は有用な効果がありません。<br>
(<a href="https://docs.oracle.com/javase/jp/8/docs/api/java/util/concurrent/ScheduledThreadPoolExecutor.html">Javadoc</a>)
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_UNSUPPORTED_METHOD">
<ShortDescription>サポートされていないメソッドの呼び出し</ShortDescription>
<LongDescription>サポートされていないメソッド {2} を呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッド呼び出しのすべてのターゲットは <code>UnsupportedOperationException</code> をスローします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_EMPTY_DB_PASSWORD">
<ShortDescription>空のデータベースパスワード</ShortDescription>
<LongDescription>空のデータベースパスーワードです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは空白または空のパスワードを使用してデータベース接続を作成しています。
これはデータベースがパスワードによって保護されていないことを示しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_CONSTANT_DB_PASSWORD">
<ShortDescription>ハードコードされた定数データベースパスワード</ShortDescription>
<LongDescription>ハードコードされた定数データベースパスワードです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはハードコードされた定数パスワードを使用してデータベース接続を作成しています。
ソースコードかコンパイルされたコードへアクセスできる人なら誰でも簡単にパスワードを知ることができてしまいます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="HRS_REQUEST_PARAMETER_TO_COOKIE">
<ShortDescription>信頼できない入力から形成された HTTP cookie</ShortDescription>
<LongDescription>HTTP cookie は信頼できない入力から形成されました。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは信頼できない HTTP パラメータを使用して HTTP クッキーを構築しています。
このクッキーが HTTP レスポンスに追加されるなら，HRS(HTTP レスポンス分割) 脆弱性を可能にします。<br>
詳細は， <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a> を参照してください。
</p>
<p>
SpotBugs は，HRS の最も露骨で自明なケースだけを探します。
SpotBugs が何かを発見したなら，ほぼ間違いなく SpotBugs が報告しない多くの脆弱性があるでしょう。
HRS を心配するなら，商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="HRS_REQUEST_PARAMETER_TO_HTTP_HEADER">
<ShortDescription>HTTP レスポンス分割脆弱性</ShortDescription>
<LongDescription>HTTP ヘッダ出力に HTTP パラメータを直接書き込んでいます。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはHTTP ヘッダに HTTP パラメータを直接書き込んでいます。これは HRS(HTTP レスポンス分割) 脆弱性を可能にします。<br>
詳細は， <a href="http://en.wikipedia.org/wiki/HTTP_response_splitting">http://en.wikipedia.org/wiki/HTTP_response_splitting</a> を参照してください。
</p>
<p>
SpotBugs は，HRS の最も露骨で自明なケースだけを探します。
SpotBugs が何かを見つけたなら，ほぼ間違いなく SpotBugs が報告しない多くの脆弱性があるでしょう。
HRS を心配するなら，商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="PT_RELATIVE_PATH_TRAVERSAL">
<ShortDescription>サーブレットの相対パストラバーサル</ShortDescription>
<LongDescription>相対パストラバーサル。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ソフトウェアは，制限されたディレクトリ内にあるパス名を構築するためにHTTPリクエストのパラメータを使いますが，パラメータはそのディレクトリの外にある場所に解決できる「.」のようなシーケンスを適切に無効にしていません。<br>
詳細は， <a href="http://cwe.mitre.org/data/definitions/23.html">http://cwe.mitre.org/data/definitions/23.html</a> を参照してください。
</p>
<p>
SpotBugs は，相対パストラバーサルの最も露骨で自明なケースだけを探します。
SpotBugs が何かを見つけたなら，ほぼ間違いなく SpotBugs が報告しない多くの脆弱性があるでしょう。
相対パストラバーサルを心配するなら，商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="PT_ABSOLUTE_PATH_TRAVERSAL">
<ShortDescription>サーブレットの絶対パストラバーサル</ShortDescription>
<LongDescription>絶対パストラバーサル。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ソフトウェアは，制限されたディレクトリ内にあるパス名を構築するためにHTTPリクエストのパラメータを使いますが，パラメータはそのディレクトリの外にある場所に解決できる「/abs/path」のような絶対パスシーケンスを適切に無効にしていません。<br>
詳細は， <a href="http://cwe.mitre.org/data/definitions/36.html">http://cwe.mitre.org/data/definitions/36.html</a> を参照してください。
</p>
<p>
SpotBugs は，絶対パストラバーサルの最も露骨で自明なケースだけを探します。
SpotBugs が何かを見つけたなら，ほぼ間違いなく SpotBugs が報告しない多くの脆弱性があるでしょう。
絶対パストラバーサルを心配するなら，商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER">
<ShortDescription>反射型クロスサイトスクリプティング脆弱性があるサーブレット</ShortDescription>
<LongDescription>サーブレットの出力に HTTP パラメータを直接書き込んでいます。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはサーブレットの出力に HTTP パラメータを直接書き込んでいます。これは反射型 XSS(クロスサイトスクリプティング) 脆弱性を可能にします。<br>
詳細は， <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> を参照してください。
</p>
<p>
SpotBugs は，XSS の最も露骨で自明なケースだけを探します。
SpotBugs が何かを見つけたなら，ほぼ間違いなく SpotBugs が報告しない多くの脆弱性があるでしょう。
XSS を心配するなら，商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="XSS_REQUEST_PARAMETER_TO_SEND_ERROR">
<ShortDescription>反射型クロスサイトスクリプティング脆弱性がエラーページにあるサーブレット</ShortDescription>
<LongDescription>サーブレットのエラーページに HTTP パラメータを直接書き込んでいます。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはサーブレットのエラーページに <code>HttpServletResponse.sendError</code> を使用して HTTP パラメータを直接書き込んでいます。
信頼できない入力を返すことは反射型 XSS(クロスサイトスクリプティング) 脆弱性を可能にします。<br>
詳細は， <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> を参照してください。
</p>
<p>
SpotBugs は，XSS の最も露骨で自明なケースだけを探します。
SpotBugs が何かを見つけたなら，ほぼ間違いなく SpotBugs が報告しない多くの脆弱性があるでしょう。
XSS を心配するなら，商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="XSS_REQUEST_PARAMETER_TO_JSP_WRITER">
<ShortDescription>反射型クロスサイトスクリプティング脆弱性がある JSP</ShortDescription>
<LongDescription>JSP の出力に HTTP パラメータを直接書き込んでいます。{1.class}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはJSP の出力に HTTP パラメータを直接書き込んでいます。これは XSS(クロスサイトスクリプティング) 脆弱性を可能にします。<br>
詳細は， <a href="http://en.wikipedia.org/wiki/Cross-site_scripting">http://en.wikipedia.org/wiki/Cross-site_scripting</a> を参照してください。
</p>
<p>
SpotBugs は，XSS の最も露骨で自明なケースだけを探します。
SpotBugs が何かを見つけたなら，ほぼ間違いなく SpotBugs が報告しない多くの脆弱性があるでしょう。
XSS に関して心配しているなら商用の静的解析ツールかペネトレーションテストツールの使用を真剣に検討すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SW_SWING_METHODS_INVOKED_IN_SWING_THREAD">
<ShortDescription>Swing メソッドは AWT イベントディスパッチスレッドから呼び出す必要がある</ShortDescription>
<LongDescription>Swing メソッドの呼び出しは AWT イベントディスパッチスレッドで実行される必要があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
(<a href="http://web.archive.org/web/20090526170426/http://java.sun.com/developer/JDCTechTips/2003/tt1208.html">From JDC Tech Tip</a>)<br>
に解説されているとおり，Swing のメソッド， <code>show</code> メソッド， <code>setVisible</code> メソッド， <code>pack</code> メソッドは，フレームのための関連したピアを作成します。
ピアの作成で，システムはイベントディスパッチスレッドを作成します。
これが問題になることがあります。なぜなら <code>pack</code> メソッドと <code>validate</code> メソッドがまだ処理中でもイベントディスパッチスレッドがリスナに通知できるからです。
この状況は，2つのスレッドが Swing コンポーネントにアクセスする可能性があり，デッドロックや，その他のスレッドに関する問題になる可能性がある重大な欠陥です。
<code>pack</code> メソッドの呼び出しはコンポーネントを実体化させます。実体化しているときに，イベントディスパッチスレッドがリスナへの通知を開始する可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IL_INFINITE_LOOP">
<ShortDescription>明らかな無限ループ</ShortDescription>
<LongDescription>明らかな無限ループです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このループは，例外をスローする以外の方法で終了させることができないように思われます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IL_INFINITE_RECURSIVE_LOOP">
<ShortDescription>明らかな無限再帰ループ</ShortDescription>
<LongDescription>明らかな無限再帰ループです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，無条件で自分自身を呼び出します。これはスタックオーバーフローになる無限再帰ループを示しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IL_CONTAINER_ADDED_TO_ITSELF">
<ShortDescription>コレクションは自分自身を追加している</ShortDescription>
<LongDescription>コレクションは，自分自身を追加しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
コレクションは，自分自身を追加しています。その結果，hashCode を計算すると <code>StackOverflowException</code> をスローします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VO_VOLATILE_REFERENCE_TO_ARRAY">
<ShortDescription>配列への volatile 参照は，配列要素を volatile として扱わない</ShortDescription>
<LongDescription>{1} は，配列への volatile 参照です。配列要素は，volatile として扱われません。</LongDescription>
<Details>
<![CDATA[
<p>
配列に <code>volatile</code> 参照を宣言していますが，あなたが望むものではないかもしれません。
配列への <code>volatile</code> 参照は，配列への参照の読み出し，書き込みは <code>volatile</code> として扱われますが，配列要素は <code>volatile</code> として扱われません。
配列要素を <code>volatile</code> として扱いたいのであれば，J2SE 5.0で提供された java.util.concurrent パッケージのアトミック配列クラスを使用する必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VO_VOLATILE_INCREMENT">
<ShortDescription>volatile フィールドへのインクリメントはアトミックではない</ShortDescription>
<LongDescription>volatile フィールド {2} をインクリメントしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>volatile</code> フィールドをインクリメントしています。
<code>volatile</code> フィールドのインクリメントはアトミックではありません。
複数のスレッドが同時にフィールドをインクリメントすると，インクリメントが失われる可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UI_INHERITANCE_UNSAFE_GETRESOURCE">
<ShortDescription>クラスが拡張されるなら getResource の使い方は安全ではないかもしれない</ShortDescription>
<LongDescription>クラスが拡張されるなら，getResource の使い方は安全ではないかもしれません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このクラスが別のパッケージによって拡張されるなら， <code>this.getClass().getResource(...)</code> の呼び出しは予想外の結果をもたらす可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_BOOLEAN_RETURN_NULL">
<ShortDescription>戻り型が Boolean のメソッドが明示的に null を返している</ShortDescription>
<LongDescription>{1} は，戻り型が Boolean なのに明示的に null を返しています。</LongDescription>
<Details>
<![CDATA[
<p>
<code>Boolean.TRUE</code> ， <code>Boolean.FALSE</code> ， <code>null</code> を返すメソッドはいつ事故が起きてもおかしくないです。
このメソッドは，まるで論理型の値を返すかのように呼び出されます。
コンパイラは <code>Boolean</code> 値のオートアンボクシングを挿入します。
<code>null</code> 値が返されるなら <code>NullPointerException</code> が発生することになります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_OPTIONAL_RETURN_NULL">
<ShortDescription>Optional の戻り型を持つメソッドが明示的に null を返す</ShortDescription>
<LongDescription>{1} は，Optional の戻り型を持っていて，明示的に null を返しています。</LongDescription>
<Details>
<![CDATA[
<p>
<code>Optional</code> の戻り型 (<code>java.util.Optional</code> または <code>com.google.common.base.Optional</code>) の使い方で明示的に <code>null</code> を返すのは設計が望ましくないことを意味します。
<code>null</code> 値をこのようなケースで返すことは契約違反で，多分クライアントコードを破壊するでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NONNULL_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">
<ShortDescription>非 null フィールドは初期化されていない</ShortDescription>
<LongDescription>非 null フィールド {2.name} は {1} によって初期化されていません。</LongDescription>
<Details>
<![CDATA[
<p>
フィールドは，非 <code>null</code> としてマークされていますが，コンストラクタで書き込まれていません。
フィールドは，コンストラクタの間，ほかの場所で初期化されるか，または使用する前に常に初期化されるかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_SYNC_AND_NULL_CHECK_FIELD">
<ShortDescription>同じフィールドでの同期化と null チェック</ShortDescription>
<LongDescription>フィールド {2.givenClass} は，同期化して null チェックしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
フィールドは同期化しているので，おそらく <code>null</code> ではないと思われます。
<code>null</code> のフィールドを同期化すると <code>NullPointerException</code> がスローされるので， <code>null</code> チェックは無意味になります。
別のフィールドで同期化したほうがよいです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RpC_REPEATED_CONDITIONAL_TEST">
<ShortDescription>条件テストの繰り返し</ShortDescription>
<LongDescription>条件テストを繰り返しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードには条件テストが2回，つまり，1つめの条件テストが正しいとき，2つめの条件テストが実行されます (たとえば， <code>x == 0 || x == 0</code>)。
多分，2つめの条件テストは何か他のことを意図しています (たとえば， <code>x == 0 || y == 0</code>)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TESTING">
<ShortDescription>テスト</ShortDescription>
<LongDescription>生成されたテスト警告です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このバグパターンは，新しい不完全に実装されたバグディテクタによって生成されるだけです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TESTING1">
<ShortDescription>テスト1</ShortDescription>
<LongDescription>生成されたテスト警告1です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このバグパターンは，新しい不完全に実装されたバグディテクタによって生成されるだけです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TESTING2">
<ShortDescription>テスト2</ShortDescription>
<LongDescription>生成されたテスト警告2です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このバグパターンは，新しい不完全に実装されたバグディテクタによって生成されるだけです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TESTING3">
<ShortDescription>テスト3</ShortDescription>
<LongDescription>生成されたテスト警告3です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このバグパターンは，新しい不完全に実装されたバグディテクタによって生成されるだけです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UNKNOWN">
<ShortDescription>未知のバグパターン</ShortDescription>
<LongDescription>未知のバグパターンです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
警告が記録されたのに SpotBugs はこのバグパターンの説明を見つけることができなかったので警告について説明できません。
これは SpotBugs かその設定のバグの場合だけで発生させるべきです。
または解析プラグインを使用して生成されるなら，プラグインは現在ロードされていません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="AM_CREATES_EMPTY_ZIP_FILE_ENTRY">
<ShortDescription>空の ZIP ファイルエントリの作成</ShortDescription>
<LongDescription>空の ZIP ファイルエントリを作成しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>putNextEntry</code> メソッドを呼び出して， <code>closeEntry</code> メソッドをすぐにを呼び出しています。
これは空の ZIP ファイルエントリになります。
エントリデータは <code>putNextEntry</code> メソッドと <code>closeEntry</code> メソッドの呼び出しの間で ZIP ファイルに書き込むべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="AM_CREATES_EMPTY_JAR_FILE_ENTRY">
<ShortDescription>空の JAR ファイルエントリの作成</ShortDescription>
<LongDescription>空の JAR ファイルエントリを作成しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>putNextEntry</code> メソッドを呼び出して， <code>closeEntry</code> メソッドをすぐに呼び出しています。
これは空の JAR ファイルエントリになります。
エントリデータは <code>putNextEntry</code> メソッドと <code>closeEntry</code> メソッドの呼び出しの間で JAR ファイルに書き込むべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IMSE_DONT_CATCH_IMSE">
<ShortDescription>疑わしい IllegalMonitorStateException のキャッチ</ShortDescription>
<LongDescription>IllegalMonitorStateException のキャッチは疑わしいです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>IllegalMonitorStateException</code> は，一般的に設計上の欠陥 (ロックを保持していないオブジェクトで <code>wait</code> メソッドまたは <code>notify</code> メソッドを呼び出す) の場合にだけスローされます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FL_MATH_USING_FLOAT_PRECISION">
<ShortDescription>浮動小数点精度を使用した計算をしている</ShortDescription>
<LongDescription>浮動小数点精度を使用して計算をしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，浮動小数点精度を使用して計算をしています。浮動小数点精度は非常に不正確です。
たとえば， <code>16777216.0f + 1.0f = 16777216.0f</code>。
その代わりに <code>double</code> の使用を検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CAA_COVARIANT_ARRAY_FIELD">
<ShortDescription>フィールドへの共変配列代入</ShortDescription>
<LongDescription>型 {2} の配列が型 {3} のフィールドに割り当てられています。</LongDescription>
<Details>
<![CDATA[
<p>
共変型の配列がフィールドに割り当てられています。
紛らわしくて，次のコードのように他の型の参照が後で配列に格納されるなら，実行時に <code>ArrayStoreException</code> を引き起こすことがあります。
</p>
<pre><code>Number[] arr = new Integer[10];
arr[0] = 1.0;
</code></pre>
<p>
作成した配列の型またはフィールド型を変更することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CAA_COVARIANT_ARRAY_LOCAL">
<ShortDescription>ローカル変数への共変配列代入</ShortDescription>
<LongDescription>型 {2} の配列が型 {3} の変数に割り当てられています。</LongDescription>
<Details>
<![CDATA[
<p>
共変型の配列がローカル変数に割り当てられています。
紛らわしくて，次のコードのように他の型の参照が後で配列に格納されるなら，実行時に <code>ArrayStoreException</code> を引き起こすことがあります。
</p>
<pre><code>Number[] arr = new Integer[10];
arr[0] = 1.0;
</code></pre>
<p>
作成した配列の型またはローカル変数型を変更することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CAA_COVARIANT_ARRAY_RETURN">
<ShortDescription>共変配列がメソッドから返される</ShortDescription>
<LongDescription>型 {2} の配列が戻り型 {3} であるメソッドから返されます。</LongDescription>
<Details>
<![CDATA[
<p>
共変型の配列がメソッドから返されます。
呼び出し元のコードが返された配列に他の型の参照を格納しようとするなら，実行時に <code>ArrayStoreException</code> を引き起こすことがあります。
</p>
<p>
作成した配列の型またはメソッドの戻り型を変更することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CAA_COVARIANT_ARRAY_ELEMENT_STORE">
<ShortDescription>おそら互換性のない要素をく共変配列に格納している</ShortDescription>
<LongDescription>型 {2} の値を要素の型が {3} の配列に格納しています。</LongDescription>
<Details>
<![CDATA[
<p>
配列に格納していてる値の型が配列型と一致していません。
実際の配列型が宣言された変数またはフィールドの型よりも狭くなっていて，この割り当てがオリジナルの配列型を満たしていないことが解析でわかっています。
この割り当ては実行時に <code>ArrayStoreException</code> を引き起こすことがあります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CN_IDIOM">
<ShortDescription>Cloneable を実装したクラスが clone メソッドを定義も使用もしていない</ShortDescription>
<LongDescription>クラス {0} は，Cloneable を実装していますが，clone メソッドを定義も使用もしていません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>Cloneable</code> を実装していますが， <code>clone</code> メソッドを定義も使用もしていません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CN_IMPLEMENTS_CLONE_BUT_NOT_CLONEABLE">
<ShortDescription>Cloneable を実装していないクラスが clone メソッドを定義している</ShortDescription>
<LongDescription>{0} は，Cloneable を実装していないのに clone メソッドを定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>Cloneable</code> を実装していないのに <code>clone</code> メソッドを定義しています。
これが OK (たとえば，サブクラスのクローンの実装を自分自身で制御したい場合です) という状況もありますが意図したことなのか確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CN_IDIOM_NO_SUPER_CALL">
<ShortDescription>clone メソッドが super.clone() を呼び出していない</ShortDescription>
<LongDescription>{1} は，super.clone() を呼び出していません。</LongDescription>
<Details>
<![CDATA[
<p>
この非 <code>final</code> クラスは， <code>super.clone()</code> を呼び出さない <code>clone</code> メソッドを定義しています。
クラス <i>A</i> がサブクラス <i>B</i> によって拡張され，サブクラス <i>B</i> が <code>super.clone()</code> を呼び出すなら，クラス <i>B</i> の <code>clone</code> メソッドは，型 <i>A</i> のオブジェクトを返す可能性が高いです。
これは <code>clone</code> のための汎用規約に違反します。
</p>
<p>
すべての <code>clone</code> メソッドが <code>super.clone()</code> を呼び出すなら <code>Object.clone()</code> が呼び出されることが保証され，常に正しい型のオブジェクトが返されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_FUTURE_KEYWORD_USED_AS_IDENTIFIER">
<ShortDescription>Java の後のバージョンのキーワードである識別子を使用している</ShortDescription>
<LongDescription>{1} は，変数名に {2} を使用していますが，Java の後のバージョンのキーワードです。</LongDescription>
<Details>
<![CDATA[
<p>
識別子は，Java の後のバージョンのキーワードとして予約されている単語です。
コードを Java の後のバージョンでコンパイルするためには変更する必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_FUTURE_KEYWORD_USED_AS_MEMBER_IDENTIFIER">
<ShortDescription>Java の後のバージョンのキーワードである識別子を使用している</ShortDescription>
<LongDescription>{1} は，Java のより最近のバージョンのキーワードと衝突します。</LongDescription>
<Details>
<![CDATA[
<p>
この識別子は，Java の後のバージョンのキーワードとして使われます。
このコードと API を参照するどんなコードも，Java の後のバージョンでコンパイルするためには変更する必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DE_MIGHT_DROP">
<ShortDescription>例外を捨てているかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，{2} を捨てているかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，例外を捨てているかもしれません。
一般的にキャッチした例外は何らかの方法で処理または報告すべきです。またはメソッドからスローすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DE_MIGHT_IGNORE">
<ShortDescription>例外を無視しているかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，{2} を無視しているかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは例外を無視しているかもしれません。
一般的に例外は何らかの方法で処理または報告すべきです。またはメソッドからスローすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DP_DO_INSIDE_DO_PRIVILEGED">
<ShortDescription>doPrivileged ブロック内で呼び出すべきメソッド</ShortDescription>
<LongDescription>{2} の呼び出しは doPrivileged ブロックの中から呼び出すべきです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはセキュリティ許可チェックが必要なメソッドを呼び出しています。
このコードにセキュリティ許可が与えられるとしても，セキュリティ許可を持たないコードによって呼び出されるなら <code>doPrivileged</code> ブロックの中で呼び出す必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DP_DO_INSIDE_DO_PRIVILEDGED"> <!-- misspelled for backward compatibility -->
<ShortDescription>Method invoked that should be only be invoked inside a doPrivileged block</ShortDescription>
<LongDescription>invocation of {2}, which should be invoked from within a doPrivileged block, in {1}</LongDescription>
<Details>
<![CDATA[
<p> This code invokes a method that requires a security permission check.
If this code will be granted security permissions, but might be invoked by code that does not
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED">
<ShortDescription>doPrivileged ブロック内で作成されるべきクラスローダ</ShortDescription>
<LongDescription>{1} は，doPrivileged ブロックの中でクラスローダ {2} を作成すべきです。</LongDescription>
<Details>
<![CDATA[
<p>
このコードはクラスローダを作成していますが，セキュリティ管理がインストールされるなら許可が必要です。
このコードがセキュリティ許可がないコードによって呼び出されるなら，クラスローダの作成は <code>doPrivileged</code> ブロックの中で行う必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS">
<ShortDescription>不変クラスのフィールドは final にすべき</ShortDescription>
<LongDescription>{0} は不変とマークされているので，{1.givenClass} は final にすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
クラスは， <code>net.jcip.annotations.Immutable</code> または <code>javax.annotation.concurrent.Immutable</code> というアノテーションが付けられています。
アノテーションのルールは，すべてのフィールドが <code>final</code> であることを義務付けます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">
<ShortDescription>Thread オブジェクトが Runnable が期待されているところに渡されている</ShortDescription>
<LongDescription>Thread オブジェクトが Runnable が期待されているところに渡されています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>Thread</code> オブジェクトが <code>Runnable</code> が期待されているメソッドへのパラメータとして渡されています。
これはかなり異常で，論理エラーを示すか，予想外の振る舞いの原因になることがあります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_COLLECTION_OF_URLS">
<ShortDescription>URL の Map や Set はひどい性能になる</ShortDescription>
<LongDescription>{1} は，URL の Map か Set を使用しているので，ひどい性能になります。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドまたはフィールドは， <code>URL</code> の <code>Map</code> か <code>Set</code> を使用しています。
<code>URL</code> の <code>equals</code> と <code>hashCode</code> は，ドメイン名の解決を行うので，ひどい性能になります。<br>
詳細は， <a href="http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html">http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html</a> を参照してください。<br>
その代わりに <code>java.net.URI</code> を使用することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_BLOCKING_METHODS_ON_URL">
<ShortDescription>URL の equals メソッドと hashCode メソッドはブロックする</ShortDescription>
<LongDescription>{2} の呼び出しはドメイン名解決のためにブロックします。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>URL</code> の <code>equals</code> メソッドと <code>hashCode</code> メソッドは，ドメイン名の解決を行うので，ひどい性能になる可能性があります。<br>
詳細は， <a href="http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html">http://michaelscharf.blogspot.com/2006/11/javaneturlequals-and-hashcode-make.html</a> を参照してください。<br>
その代わりに <code>java.net.URI</code> を使用することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_ANNOTATION_IS_NOT_VISIBLE_TO_REFLECTION">
<ShortDescription>ランタイムリテンションなしで，アノテーションの存在を調べるためにリフレクションを使用することはできない</ShortDescription>
<LongDescription>ランタイムリテンションを持たないアノテーション {3} の存在を調べるためにリフレクションを使用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
アノテーションに <code>@Retention(RetentionPolicy.RUNTIME)</code> アノテーションが付いていなければ，リフレクション (たとえば， <code>isAnnotationPresent(...)</code> メソッド) を使用して観測することができません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_EXIT">
<ShortDescription>System.exit(...) を呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，System.exit(...) を呼び出しています。これは Java 仮想マシン全体をシャットダウンさせてしまいます。</LongDescription>
<Details>
<![CDATA[
<p>
<code>System.exit(...)</code> を呼び出すことは，Java 仮想マシン全体をシャットダウンさせてしまいます。
それが適切な場合にだけ使用すべきです。
<code>System.exit(...)</code> の呼び出しは，他のコードによる呼び出しを困難か不可能にします。
その代わりに <code>RuntimeException</code> をスローすることを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_RUN_FINALIZERS_ON_EXIT">
<ShortDescription>危険なメソッド runFinalizersOnExit を呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，危険なメソッド runFinalizersOnExit を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
どんな理由があるにせよ決して <code>System.runFinalizersOnExit</code> と <code>Runtime.runFinalizersOnExit</code> を呼び出さないでください。
Java ライブラリで最も危険なメソッドの1つです。 -- Joshua Bloch
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_STRING_CTOR">
<ShortDescription>効率が悪い new String(String) コンストラクタを呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，効率が悪い new String(String) コンストラクタを呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
<code>new String(String)</code> コンストラクタの使用はメモリを浪費します。
そのようにして構築されたオブジェクトと パラメータとして渡された <code>String</code> は機能的に区別がつかないからです。
引数の <code>String</code> をそのまま使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_STRING_VOID_CTOR">
<ShortDescription>効率が悪い new String() コンストラクタを呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，効率が悪い new String() コンストラクタを呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
引数がないコンストラクタを使用して，新しい <code>java.lang.String()</code> オブジェクトを作成するとメモリを浪費します。
そのようにして作成されたオブジェクトと空の文字列定数 <code>""</code> は機能的に区別がつかないからです。
Javaは，同一の文字列定数が同じ <code>String</code> オブジェクトによって表されることを保証します。
したがって，直接空の文字列定数を使用すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_STRING_TOSTRING">
<ShortDescription>String の toString メソッドを呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，String の toString メソッドを呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
<code>String.toString()</code> を呼び出すのは冗長です。<code>String</code> を使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_GC">
<ShortDescription>明示的なガベージコレクション</ShortDescription>
<LongDescription>{1} は，ガベージコレクションを強制しています。ベンチマークコードを除いて非常に疑わしいです。</LongDescription>
<Details>
<![CDATA[
<p>
明示的にガベージコレクションを呼び出しています。ベンチマークの特定の用途を除いて非常に疑わしいです。
</p>
<p>
過去に， <code>close</code> メソッドや <code>finalize</code> メソッドでガベージコレクタを明示的に呼び出していた状況は，巨大なパフォーマンスブラックホールの原因となりました。
ガベージコレクションは高くつきます。何百，何千ものガベージコレクションを強制する状況は，システムの停滞をもたらすでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_BOOLEAN_CTOR">
<ShortDescription>効率が悪い Boolean コンストラクタを呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，効率が悪い Boolean コンストラクタを呼び出しています。その代わりに Boolean.valueOf(...) を使用してください。</LongDescription>
<Details>
<![CDATA[
<p>
<code>java.lang.Boolean</code> の新しいインスタンスを作成するとメモリを浪費します。
<code>Boolean</code> オブジェクトは不変で，2つの有用な値 (<code>Boolean.TRUE</code> と <code>Boolean.FALSE</code>) があります。
その代わりに <code>Boolean.valueOf</code> メソッド (または J2SE 5.0 のオートボクシング) を使用して <code>Boolean</code> オブジェクトを作成してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_NUMBER_CTOR">
<ShortDescription>効率が悪い Number コンストラクタを呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，効率が悪い {2} コンストラクタを呼び出しています。その代わりに {3} を使用してください。</LongDescription>
<Details>
<![CDATA[
<p>
<code>new Integer(int)</code> の使用は，常に新しいブジェクトになることが保証されています。
これに対して， <code>Integer.valueOf(int)</code> は，コンパイラ，クラスライブラリ，Java 仮想マシンで値がキャッシュされます。
キャッシュに格納された値を使用することはインスタンスの作成を回避し，コードはより高速になります。
</p>
<p>
-128から127までの値は対応するキャッシュされたインスタンスを持つことが保証されています。
そして， <code>valueOf</code> メソッドの使用は，コンストラクタを使用するより約3.5倍高速です。
定数範囲外の値は，両方のスタイルの性能は同じです。
</p>
<p>
クラスが J2SE 5.0より前の Java 仮想マシンとの互換性が不要なら， <code>Long</code> ， <code>Integer</code> ， <code>Short</code> ， <code>Character</code> ， <code>Byte</code> のインスタンスを作成するときは，オートボクシングか <code>valueOf</code> メソッドを使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_FP_NUMBER_CTOR">
<ShortDescription>効率が悪い浮動小数点 Number コンストラクタを呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，効率が悪い {2} コンストラクタを呼び出しています。その代わりに {3} を使用してください。</LongDescription>
<Details>
<![CDATA[
<p>
<code>new Double(double)</code> の使用は，常に新しいブジェクトになることが保証されています。
これに対して， <code>Double.valueOf(double)</code> は，コンパイラ，クラスライブラリ，Java 仮想マシンで値がキャッシュされます。
キャッシュに格納された値を使用することはインスタンス生成を回避し，コードはより高速になります。
</p>
<p>
クラスが J2SE 5.0より前の Java 仮想マシンとの互換性が不要なら，オートボクシングか <code>Double</code> ， <code>Float</code> の <code>valueOf</code> メソッドを使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_CONVERT_CASE">
<ShortDescription>呼び出したメソッドの Locale パラメータの使用を検討する</ShortDescription>
<LongDescription>ローカライズされていない String.toUpperCase() または String.toLowerCase() を使用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
文字列がプラットフォームのデフォルトエンコーディングを使用して大文字，小文字に変換されています。
国際文字で使われると不適切な変換になることがあります。
</p>
<ul>
<li>String.toUpperCase(Locale l)</li>
<li>String.toLowerCase(Locale l)</li>
</ul>
]]>
</Details>
</BugPattern>
<BugPattern type="BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR">
<ShortDescription>プリミティブ値が3項演算子のためにアンボクシングされて，型変換される</ShortDescription>
<LongDescription>プリミティブ型の値が3項演算子のためにアンボクシングされて，型変換されます。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ラップされたプリミティブ値は，3項演算子 (<code>b ? e1 : e2</code>) の評価の一部として，別のプリミティブ型にアンボクシングされて変換されます。
Java 言語仕様では， <code>e1</code> と <code>e2</code> がラップされた数値なら値はアンボクシングされ，共通の型へと変換/型変換されます
(たとえば， <code>e1</code> が <code>Integer</code> で， <code>e2</code> が <code>Float</code> なら <code>e1</code> はアンボクシング (<code>int</code> に変換) され， <code>float</code> に変換され，ボクシング (<code>Float</code> に変換) されます)。
JLS セクション15.25を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BX_BOXING_IMMEDIATELY_UNBOXED">
<ShortDescription>プリミティブ値がボクシングされて，すぐにアンボクシングされる</ShortDescription>
<LongDescription>プリミティブ値がボクシングされて，すぐにアンボクシングされます。{1}</LongDescription>
<Details>
<![CDATA[
<p>
プリミティブ値がボクシングされて，すぐにアンボクシングされます。
おそらくアンボクシングされた値が必要な場所で手動でボクシングをしているためです。
その結果，コンパイラにボクシングの機能を取り消すことを強制しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BX_UNBOXING_IMMEDIATELY_REBOXED">
<ShortDescription>ボクシングされた値がアンボクシングされて，すぐに再ボクシングされる</ShortDescription>
<LongDescription>ボクシングされた値がアンボクシングされて，すぐに再ボクシングされます。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ボクシングされた値がアンボクシングされて，すぐに再ボクシングされます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BX_BOXING_IMMEDIATELY_UNBOXED_TO_PERFORM_COERCION">
<ShortDescription>プリミティブ値がプリミティブ型の型変換をするためにボクシングされて，アンボクシングされる</ShortDescription>
<LongDescription>プリミティブ値がプリミティブ型の型変換をするためにボクシングされて，アンボクシングされます。{1}</LongDescription>
<Details>
<![CDATA[
<p>
プリミティブ値がコンストラクタでボクシングされて，すぐに異なるプリミティブ型に変換されます (たとえば <code>new Double(d).intValue()</code>)。
直接プリミティブ型の型変換を実行してください (たとえば <code>(int) d</code>)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_BOXED_PRIMITIVE_TOSTRING">
<ShortDescription>toString メソッドを呼び出すためだけにボクシングされたプリミティブを割り当てている</ShortDescription>
<LongDescription>toString メソッドを呼び出すためだけにボクシングされたプリミティブを割り当てています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ボクシングされたプリミティブが <code>toString</code> メソッドを呼び出すためだけに割り当てられています。
それよりもプリミティブ値を引数にとる <code>static</code> な <code>toString</code> メソッドを使用したほうが効率的です。
</p>
<table>
<tr><th>置換前</th><th>置換後</th></tr>
<tr><td><code>new Integer(1).toString()</code></td> <td><code>Integer.toString(1)</code></td></tr>
<tr><td><code>new Long(1).toString()</code></td> <td><code>Long.toString(1)</code></td></tr>
<tr><td><code>new Float(1.0).toString()</code></td> <td><code>Float.toString(1.0)</code></td></tr>
<tr><td><code>new Double(1.0).toString()</code></td> <td><code>Double.toString(1.0)</code></td></tr>
<tr><td><code>new Byte(1).toString()</code></td> <td><code>Byte.toString(1)</code></td></tr>
<tr><td><code>new Short(1).toString()</code></td> <td><code>Short.toString(1)</code></td></tr>
<tr><td><code>new Boolean(true).toString()</code></td><td><code>Boolean.toString(true)</code></td></tr>
</table>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_BOXED_PRIMITIVE_FOR_PARSING">
<ShortDescription>プリミティブを解析するためのボクシング/アンボクシング</ShortDescription>
<LongDescription>プリミティブ {1} を解析するためのボクシング/アンボクシング。</LongDescription>
<Details>
<![CDATA[
<p>
ボクシングされたプリミティブがボクシングされていないプリミティブ値を抽出するために <code>String</code> から生成されています。
<code>static parseXXX</code> メソッドを呼び出す方が効率的です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_BOXED_PRIMITIVE_FOR_COMPARE">
<ShortDescription>プリミティブが比較でボクシングされている</ShortDescription>
<LongDescription>プリミティブが {2} を呼び出すためにボクシングされています: 代わりに {3} を使用してください。</LongDescription>
<Details>
<![CDATA[
<p>
ボクシングされたプリミティブが単に <code>compareTo</code> メソッドを呼び出すために作られています。
直接プリミティブで働く <code>static compare</code> メソッド (<code>double</code> と <code>float</code> は Java 1.4から，他のプリミティブ型は Java 1.7から) を使うほうがより効率的です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_NEW_FOR_GETCLASS">
<ShortDescription>クラスオブジェクトを得るためだけにインスタンスを作成しているメソッド</ShortDescription>
<LongDescription>{1} は，クラスオブジェクトを得るためだけにインスタンスを作成しています。</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，クラスオブジェクトを得るためにインスタンスを生成して <code>getClass</code> メソッドを呼び出しています。
クラスリテラル (<code>Foo.class</code>) を使うほうが簡単です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_MONITOR_WAIT_ON_CONDITION">
<ShortDescription>Condition で呼び出された wait メソッドを監視している</ShortDescription>
<LongDescription>Condition で呼び出されたwait メソッドを監視しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>java.util.concurrent.locks.Condition</code> オブジェクトで <code>wait</code> メソッドを呼び出しています。
<code>Condition</code> オブジェクトを待機させるためには <code>Condition</code> インタフェースで定義された <code>await</code> メソッドを使用すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_01_TO_INT">
<ShortDescription>0から1の乱数値は整数値0に丸められる</ShortDescription>
<LongDescription>{1} は，0から1の乱数値を生成していますが，整数値0に丸められます。</LongDescription>
<Details>
<![CDATA[
<p>
0から1の乱数値は整数値0に丸められます。
おそらく整数に丸められる前に何か他のことによって乱数値を乗算したかったか，または <code>Random.nextInt(n)</code> メソッドを使いたかったのでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_INVALID_MIN_MAX">
<ShortDescription>Math.max と Math.min の間違った組み合わせ</ShortDescription>
<LongDescription>Math.max と Math.min の組み合わせが間違っています: このコードは常に {2} を返します。</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>Math.min(0, Math.max(100, value))</code> のような構文を使用して境界値を制限しようとしています。
しかしながら，定数の順序が間違っています。 <code>Math.min(100, Math.max(0, value))</code> とすべきです。
結果としてこのコードは常に同じ結果 （もし値が <code>NaN</code> なら <code>NaN</code>） を作り出します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_NEXTINT_VIA_NEXTDOUBLE">
<ShortDescription>整数の乱数を生成するためには nextDouble メソッド ではなく nextInt メソッドを使用する</ShortDescription>
<LongDescription>{1} は，nextDouble メソッドを使用して整数の乱数を生成しています。nextInt メソッドを使用した方が効率的です。</LongDescription>
<Details>
<![CDATA[
<p>
<code>java.util.Random</code> のインスタンス <code>r</code> で， <code>0</code> から <code>n-1</code> の乱数を生成したいのであれば， <code>(int)(r.nextDouble() * n)</code> ではなく <code>r.nextInt(n)</code> を使用します。
</p>
<p>
<code>nextInt</code> メソッドへの引数は整数でなければなりません。
たとえば，-99から0までの乱数を生成したいなら， <code>-r.nextInt(100)</code> を使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE">
<ShortDescription>SQL の Statement の execute または addBatch メソッドに定数ではない文字列を渡している</ShortDescription>
<LongDescription>{1} は，SQL の Statement の execute または addBatch メソッドに定数ではない文字列を渡しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，動的に生成されるように思われる文字列で，SQL 文 の <code>execute</code> または <code>addBatch</code> メソッドを呼び出しています。
その代わりに <code>PreparedStatement</code> を使用することを検討してください。
効率的で，SQL インジェクション攻撃に強いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SQL_PREPARED_STATEMENT_GENERATED_FROM_NONCONSTANT_STRING">
<ShortDescription>PreparedStatement が定数ではない文字列から生成されている</ShortDescription>
<LongDescription>PreparedStatement が定数ではない文字列から生成されています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは定数ではない文字列から SQL の <code>PreparedStatement</code> を作成しています。
ユーザからのチェックされていない汚染されたデータがこの文字列を作る際に使われるなら， <code>PreparedStatement</code> で予想外で望ましくない何かをするために SQL インジェクションが使われる可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_USELESS_THREAD">
<ShortDescription>デフォルトの空の run メソッドを使用して作成されたスレッド</ShortDescription>
<LongDescription>{1} は，デフォルトの空の run メソッドを使用してスレッドを作成しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>Thread</code> クラスから派生した <code>run</code> メソッドを指定していないか， <code>Runnable</code> オブジェクトを渡すことなく，スレッドを作成しています。
このスレッドは，時間の無駄です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DC_DOUBLECHECK">
<ShortDescription>フィールドのダブルチェックの可能性</ShortDescription>
<LongDescription>フィールド {2} のダブルチェックをしている可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドにはダブルチェックロッキングのインスタンスがあるかもしれません。このイディオムは，Java のメモリモデルでは正しくありません。<br>
詳細は， <a href="http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html" >http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DC_PARTIALLY_CONSTRUCTED">
<ShortDescription>部分的に初期化されたオブジェクトを暴露する可能性がある</ShortDescription>
<LongDescription>部分的に初期化されたオブジェクトを暴露する可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ダブルチェックロッキングと共に遅延初期化フィールドを使用するメソッドのようです。
フィールドが正しく <code>volatile</code> として宣言される間にオブジェクトの内部構造がフィールドに割り当てられた後で変更される可能性があります。
したがって，他のスレッドが部分的に初期化されたオブジェクトを見るかもしれません。
</p>
<p>
この問題を直すために，最初にローカル変数をオブジェクトに格納して，完全に構築した後で <code>volatile</code> フィールドを保存することを考えてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FI_FINALIZER_NULLS_FIELDS">
<ShortDescription>ファイナライザはフィールドを null にする</ShortDescription>
<LongDescription>{3} は，finalize メソッドの中で null を設定しています。{1.class}</LongDescription>
<Details>
<![CDATA[
<p>
このファイナライザは，フィールドを <code>null</code> にしています。
これは通常誤りでガベージコレクタを助けません。オブジェクトはいずれにしろガベージされます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FI_FINALIZER_ONLY_NULLS_FIELDS">
<ShortDescription>ファイナライザはフィールドを null にするだけ</ShortDescription>
<LongDescription>{1} は，フィールドを null にするだけです。</LongDescription>
<Details>
<![CDATA[
<p>
このファイナライザは，フィールドを <code>null</code> にすること以外に何もしません。
これはまったく無意味であり，オブジェクトがガベージされ，ファイナライズされ，再びガベージされることを要求しています。
<code>finalize</code> メソッドを除去すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FI_PUBLIC_SHOULD_BE_PROTECTED">
<ShortDescription>ファイナライザは public ではなく protected にすべき</ShortDescription>
<LongDescription>{1} は public です。protected にすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスの <code>finalize</code> メソッドは <code>public</code> ではなく， <code>protected</code> にすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FI_EMPTY">
<ShortDescription>空のファイナライザは削除すべき</ShortDescription>
<LongDescription>{1} は，空なので削除すべきです。</LongDescription>
<Details>
<![CDATA[
<p>
空の <code>finalize</code> メソッドは役に立たないので削除すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FI_NULLIFY_SUPER">
<ShortDescription>ファイナライザはスーパークラスのファイナライザを無効にしている</ShortDescription>
<LongDescription>{1} は，{2}.finalize() を無効にしています。これは意図したことですか？</LongDescription>
<Details>
<![CDATA[
<p>
この空の <code>finalize</code> メソッドは，明示的にスーパークラスによって定義されたどんなファイナライザの効果も無効にします。
スーパークラスのために定義されたどんなファイナライザアクションも実行されません。
これが意図したことではない場合，メソッドを削除してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FI_USELESS">
<ShortDescription>ファイナライザはスーパークラスのファイナライザを呼び出しているだけ</ShortDescription>
<LongDescription>{1} は，super.finalize() を呼び出す以外何もしないので，削除してください。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>finalize</code> メソッドは，スーパークラスの <code>finalize</code> メソッドを呼び出しているだけです。
冗長なので削除してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FI_MISSING_SUPER_CALL">
<ShortDescription>ファイナライザはスーパークラスのファイナライザを呼び出していない</ShortDescription>
<LongDescription>{1} は，super.finalize() への呼び出しが見つからないので，{2}.finalize() は呼び出されません。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>finalize</code> メソッドは，スーパークラスの <code>finalize</code> メソッドを呼び出していません。
したがって，スーパークラスのために定義されたどんなファイナライザアクションも実行されません。
<code>super.finalize()</code> の呼び出しを追加してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FI_EXPLICIT_INVOCATION">
<ShortDescription>ファイナライザの明示的な呼び出し</ShortDescription>
<LongDescription>{1} は，明示的に {2} を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには明示的にオブジェクトで <code>finalize</code> メソッドの呼び出しがあります。
ファイナライザは Java 仮想マシンによって1度だけ実行されることになっているので，これは間違った考えです。
</p>
<p>
参照によってつながった複数のオブジェクトがファイナライズ可能になると，Java 仮想マシンはすべてのオブジェクトの <code>finalize</code> メソッドを呼び出します。
おそらく異なるスレッドで同時にです。
したがって，クラス <i>X</i> の <code>finalize</code> メソッドの中から <i>X</i> によって参照されているオブジェクトの <code>finalize</code> メソッドを呼び出すのは，とりわけ間違った考えです。
なぜなら，オブジェクトが既に別のスレッドによってファイナライズされているかもしれないからです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_CHECK_FOR_OPERAND_NOT_COMPATIBLE_WITH_THIS">
<ShortDescription>equals メソッドは互換性のないオペランドをチェックしている</ShortDescription>
<LongDescription>{1} は，{2.givenClass} であるオペランドをチェックしています。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>equals</code> メソッドは，引数が互換性のない型 (すなわちスーパタイプでもなく， <code>equals</code> メソッドを定義しているクラスのスーパータイプでもサブタイプでもないクラス) なのか確かめています。
たとえば， <code>Foo</code> クラスの <code>equals</code> メソッドはそのように見えるかもしれません。
</p>
<pre><code>public boolean equals(Object o) {
if (o instanceof Foo)
return name.equals(((Foo)o).name);
else if (o instanceof String)
return name.equals(o);
else return false;
}
</code></pre>
<p>
これは対称的で推移的である <code>equals</code> メソッドを実現するのはとても難しいので，バッドプラクティスと見なされています。
プロパティがなければまったく予想していない振る舞いが起こりえます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_DONT_DEFINE_EQUALS_FOR_ENUM">
<ShortDescription>列挙型は共変な equals メソッドを定義している</ShortDescription>
<LongDescription>列挙型 {0} は，equals({0.givenClass}) を定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは列挙を定義していて，列挙の等価性はオブジェクト同一性を使用して定義されています。
列挙値のために共変な <code>equals</code> メソッドを定義することは，ひどいバッドプラクティスです。
2つの異なる列挙値が <code>equals</code> メソッドでは「等価ではない」と判定され，共変な <code>equals</code> メソッドでは「等価」と判定されるからです。
共変な <code>equals</code> メソッドを定義しないでください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_SELF_USE_OBJECT">
<ShortDescription>共変な equals メソッドを定義して，Object.equals(Object) を継承している</ShortDescription>
<LongDescription>{0} は，equals({0.givenClass}) メソッドを定義して，Object.equals(Object) を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，共変な <code>equals</code> メソッドを定義していますが， <code>equals(Object)</code> メソッドは <code>java.lang.Object</code> クラスから継承しています。
クラスは， <code>boolean equals(Object)</code> メソッドを定義すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_OTHER_USE_OBJECT">
<ShortDescription>Object.equals(Object) をオーバーライドしていない equals メソッドの定義</ShortDescription>
<LongDescription>{0}は，{1.givenClass} メソッドを定義して，Object.equals(Object) を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>equals</code> メソッドを定義していますが， <code>java.lang.Object</code> クラスの <code>equals(Object)</code> メソッドをオーバーライドしていません。
クラスは， <code>boolean equals(Object)</code> メソッドを定義すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_OTHER_NO_OBJECT">
<ShortDescription>equals(Object) メソッドをオーバーライドしていない equals メソッドの定義</ShortDescription>
<LongDescription>{0} は，equals(Object) メソッドをオーバーライドしない {1.givenClass} を定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>equals</code> メソッドを定義していますが， <code>java.lang.Object</code> クラスの <code>equals(Object)</code> メソッドをオーバーライドしていません。
その代わりに，スーパークラスから <code>equals(Object)</code> メソッドを継承して， <code>boolean equals(Object)</code> メソッドを定義すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_DOESNT_OVERRIDE_EQUALS">
<ShortDescription>スーパークラスの equals メソッドをオーバーライドしていないクラス</ShortDescription>
<LongDescription>{0} は，{2.givenClass} をオーバーライドしていません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>equals</code> メソッドを定義しているクラスを拡張してフィールドを追加していますが， <code>equals</code> メソッドを定義していません。
したがって，このクラスのインスタンスの等価性は，サブクラスと追加されたフィールドの同一性を無視します。
これが意図したことで，しかも， <code>equals</code> メソッドをオーバーライドする必要がないことを確実にしてください。
たとえ <code>equals</code> メソッドをオーバーライドする必要がないとしても，サブクラスのための <code>equals</code> メソッドが <code>super.equals(o)</code> を呼び出して結果を返すという事実を実証するためにいずれにしろ， <code>equals</code> メソッドをオーバーライドすることを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_SELF_NO_OBJECT">
<ShortDescription>共変な equals メソッドの定義</ShortDescription>
<LongDescription>{0} は，equals({0.givenClass}) メソッドを定義していますが，equals(Object) を定義していません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，共変な <code>equals</code> メソッドを定義しています。
<code>java.lang.Object</code> の <code>equals</code> メソッドを正しくオーバーライドするためには <code>equals</code> メソッドのパラメータの型は， <code>java.lang.Object</code> でなければなりません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_OVERRIDING_EQUALS_NOT_SYMMETRIC">
<ShortDescription>equals メソッドはスーパークラスの equals メソッドをオーバーライドしているが，対称的ではないかもしれない</ShortDescription>
<LongDescription>{1.class} は，{2.class.givenClass} で equals メソッドをオーバーライドしていますが，対称的ではないかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスはスーパークラスの <code>equals</code> メソッドをオーバーライドする <code>equals</code> メソッドを定義しています。
両方の <code>equals</code> メソッドは，2つのオブジェクトが等しいかどうかの判定で， <code>instanceof</code> を使用しています。
<code>equals</code> メソッドは対称的 (<code>a.equals(b) == b.equals(a)</code>) であることが重要なのでこれは危険を伴っています。
<i>B</i> が <i>A</i> のサブタイプなら <i>A</i> の <code>equals</code> メソッドは引数が <code>instanceof A</code> なのかチェックします。
そして， <i>B</i> の <code>equals</code> メソッドは引数が <code>instanceof B</code> なのかチェックします。
これらのメソッドによって定義された同値関係が対称的ではないということです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_GETCLASS_AND_CLASS_CONSTANT">
<ShortDescription>equals メソッドはサブタイプのために失敗する</ShortDescription>
<LongDescription>{1} は，サブタイプのために失敗します。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，サブクラスによる継承によって壊れる <code>equlas</code> メソッドがあります。
<code>equals</code> メソッドは，クラスリテラルを引数のクラスと比較しています (たとえば， <code>Foo</code> クラスで <code>Foo.class == o.getClass()</code> のような判定を行っています)。
<code>this.getClass() == o.getClass()</code> の方がより良いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_UNUSUAL">
<ShortDescription>異常な equals メソッド </ShortDescription>
<LongDescription>{1} は，異常な equals メソッドです。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスの <code>equals</code> メソッドは，引数の型が <code>this</code> オブジェクトの型と互換性があるこをチェックするために我々が認識しているパターンで何もしていません。
このコードは何も間違っていないかもしれませんが，レビューする価値があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_COMPARING_CLASS_NAMES">
<ShortDescription>equals メソッドはクラスオブジェクトではなくクラス名を比較している</ShortDescription>
<LongDescription>{1} は，クラスオブジェクトではなく，クラス名を比較しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，クラス名を比較することによって，2つのオブジェクトが同じクラスなのか確かめています。
異なるクラスローダによってロードされたクラスなら，同じ名前で異なるクラスがある可能性があります。
クラスオブジェクトが同じなのか確かめてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_ALWAYS_TRUE">
<ShortDescription>equals メソッドは常に true を返す</ShortDescription>
<LongDescription>{1} は，常に true を返します。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，常に <code>true</code> を返す <code>equals</code> メソッドを定義しています。
これは想像力に富むが，あまり良い方法とはいえません。さらに， <code>equals</code> メソッドが対称的ではないことを意味します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_ALWAYS_FALSE">
<ShortDescription>equals メソッドは常に false を返す</ShortDescription>
<LongDescription>{1} は，常に false を返します。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスでは，常に <code>false</code> を返す <code>equlas</code> メソッドを定義しています。
これはオブジェクトがそれ自身と等価ではないことを意味していて，このクラスの有用な <code>Map</code> や <code>Set</code> を作成できません。
より根本的に， <code>equals</code> メソッドの要件の一つである反射性を満たしていないことになります。
</p>
<p>
おそらく意図されたことは，オブジェクトはそれ自身と等価であるというオブジェクト同一性です。
これは <code>Object</code> クラスから継承される振る舞いです。
異なるスーパークラスから継承される <code>equals</code> メソッドをオーバーライドする必要があるなら次のようなコードが使えます。
</p>
<pre><code>public boolean equals(Object o) {
return this == o;
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="HSC_HUGE_SHARED_STRING_CONSTANT">
<ShortDescription>複数のクラスファイルにわたって複製されている巨大な文字列定数</ShortDescription>
<LongDescription>長さが {2} 文字の文字列定数 {1} が {3} つのクラスファイルに複製されています。</LongDescription>
<Details>
<![CDATA[
<p>
巨大な文字列定数が複数のクラスファイルにわたって複製されています。
<code>final</code> フィールドが文字列定数で初期化され，Java 言語によって他のクラスからの <code>final</code> フィールドへのすべての参照がクラスファイルにインライン化されるからです。
</p>
<p>
JDK はこのバグを解決してサイズを1MB減らすことができました。<br>
詳細は， <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6447475">JDK bug 6447475</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_ARGUMENT_MIGHT_BE_NULL">
<ShortDescription>null の引数をチェックしていないメソッド</ShortDescription>
<LongDescription>{1} は，null の引数をチェックしていません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドへのパラメータが <code>null</code> かどうか確かめるために常にチェックされるべき値として特定されました。
しかし， <code>null</code> チェックをしないで， <code>null</code> 値が利用されています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_EQUALS_SHOULD_HANDLE_NULL_ARGUMENT">
<ShortDescription>equals メソッドは null の引数をチェックしていない</ShortDescription>
<LongDescription>{1} は，null の引数をチェックしていません。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>equals(Object)</code> メソッドの実装は引数として渡されている <code>null</code> をチェックしていないので， <code>java.lang.Object.equals()</code> で定義された規約に違反しています。
すべての <code>equals</code> メソッドは引数に <code>null</code> が渡されたなら <code>false</code> を返すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_NEGATING_RESULT_OF_COMPARETO">
<ShortDescription>compareTo()/compare() の結果を無効にする</ShortDescription>
<LongDescription>{1} は，{2} の戻り値を無効にします。</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>compareTo</code> または <code>compare</code> メソッドの戻り値を無効にしています。
これは疑わしいかバッドプログラミングプラクティスです。戻り値が <code>Integer.MIN_VALUE</code> なので，戻り値を無効にすることは結果の符号を無効にしません。
結果を無効にするのではなくオペランドの順序を逆にすることによって，同じ意図した結果を得ることができます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CO_COMPARETO_RESULTS_MIN_VALUE">
<ShortDescription>compareTo()/compare() は Integer.MIN_VALUE を返す</ShortDescription>
<LongDescription>{1} は Integer.MIN_VALUE を返します。戻り値を無効にできません。</LongDescription>
<Details>
<![CDATA[
<p>
いくつかの状況下では，この <code>compareTo</code> または <code>compare</code> メソッドは <code>Integer.MIN_VALUE</code> を返します。非常に悪いプラクティスです。
<code>compareTo</code> メソッドの戻り値で重要なことは結果の符号だけです。
しかし，結果の符号を無効にすることを期待して， <code>compareTo</code> メソッドの戻り値を無効にすることがあります。
返された値が <code>Integer.MIN_VALUE</code> の場合を除いてです。 <code>Integer.MIN_VALUE</code> よりも-1を返してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CO_COMPARETO_INCORRECT_FLOATING">
<ShortDescription>compareTo()/compare() は間違って float または double 値を処理する</ShortDescription>
<LongDescription>{1} は，間違って {2} 値を処理します。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドはこのようなパターンを使用して <code>double</code> または <code>float</code> 値を比較しています ： <code>val1 > val2 ? 1 : val1 < val2 ? -1 : 0</code>。
このパターンは，-0.0 や <code>NaN</code> の値が正しく処理されたないため，不正なソート結果や破損したコレクション（比較された値がキーとして使われる場合）が生成される可能性があります。
<code>Double.compare</code> または <code>Float.compare</code> メソッドを使用して，すべての特殊なケースを正確に処理することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CO_SELF_NO_OBJECT">
<ShortDescription>共変な compareTo メソッドの定義</ShortDescription>
<LongDescription>{0} は，compareTo(Object) ではなく compareTo({0.givenClass}) メソッドを定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，共変な <code>compareTo</code> メソッドを定義しています。
<code>Comparable</code> インタフェースの <code>compareTo</code> メソッドを正しく実装するためには <code>compareTo</code> メソッドのパラメータの型は， <code>java.lang.Object</code> でなければなりません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="HE_SIGNATURE_DECLARES_HASHING_OF_UNHASHABLE_CLASS">
<ShortDescription>ハッシュ化されたコンテキストでハッシュ化できないクラスの使用がシグネチャで宣言されている</ShortDescription>
<LongDescription>{2} は，hashCode メソッドを定義していないのにハッシュ化されたコンテキストで使われています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
メソッド，フィールド，クラスは，ハッシュ可能なクラスが必要なコンテキストで，ハッシュ化できないクラスが使用される総称的なシグネチャを宣言しています。
クラスは， <code>equals</code> メソッドを宣言していますが， <code>hashCode</code> メソッドは <code>java.lang.Object</code> から継承しています。
これは「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に従っていないのでハッシュ化できません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="HE_USE_OF_UNHASHABLE_CLASS">
<ShortDescription>ハッシュデータ構造で hashCode メソッドのないクラスを使用している</ShortDescription>
<LongDescription>{2} は，hashCode メソッドを定義していないのにハッシュデータ構造で使われています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>equals(Object)</code> メソッドを定義していますが， <code>hashCode</code> メソッドを定義していません。
これは「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に従っていません。
このクラスのインスタンスはハッシュデータ構造で使われています。最重要問題を修正する必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="HE_HASHCODE_USE_OBJECT_EQUALS">
<ShortDescription>hashCode メソッドを定義して Object.equals() を使用しているクラス</ShortDescription>
<LongDescription>{0} は，hashCode メソッドを定義して，Object.equals() を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>hashCode</code> メソッドを定義していますが， <code>equals</code> メソッドは <code>java.lang.Object</code> から継承しています (オブジェクトの参照比較で等価性を判定します)。
これは「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に従っているかもしれませんが，
おそらく， <code>hashCode</code> メソッドをオーバーライドすることによって意図されたことではありません。
(<code>hashCode</code> メソッドをオーバーライドすることは，オブジェクトの同一性が単純な参照等価性よりも複雑な規約に基づくことを意味します)。
</p>
<p>
このクラスのインスタンスが <code>HashMap</code>/<code>HashTable</code> に決して代入されるだろうと思わないなら推奨される <code>hashCode</code> メソッドの実装は次のようになります。
</p>
<pre><code>public int hashCode() {
assert false : "hashCodeが呼び出されることは想定されていません。";
return 42; // 任意の定数
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_COMPARETO_USE_OBJECT_EQUALS">
<ShortDescription>compareTo(...) メソッドを定義して Object.equals() を使用しているクラス</ShortDescription>
<LongDescription>{0} は，{1.givenClass} を定義して，Object.equals() を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>compareTo(...)</code> メソッドを定義していますが， <code>equals</code> メソッドは <code>java.lang.Object</code> から継承しています。
一般的に<code>equals</code> メソッドが <code>true</code> を返す場合に限り， <code>compareTo</code> メソッドは0を返すべきです。
これが違反されるなら奇妙で予測できない失敗が <code>PriorityQueue</code> などのクラスで発生します。
J2SE 5.0では， <code>PriorityQueue.remove()</code> は <code>compareTo</code> メソッドを使用しますが，Java SE 6では， <code>equals</code> メソッドを使用します。
</p>
<p>
<code>Comparable</code> インタフェースの <code>compareTo</code> メソッドの JavaDoc を引用します。
</p>
<blockquote><p>
必須というわけではありませんが， <code>(x.compareTo(y)==0) == (x.equals(y))</code> であることが強く推奨されます。
一般的に<code>Comparable</code> インタフェースを実装しているクラスで，この条件に違反するクラスは明確にこの事実を示す必要があります。
「注:このクラスは <code>equals</code> と一貫性のない自然順序付けを持ちます」などと明示することをお勧めします。
</p></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="HE_HASHCODE_NO_EQUALS">
<ShortDescription>hashCode メソッドを定義していますが equals メソッドは定義していないクラス</ShortDescription>
<LongDescription>{0} は，hashCode メソッドを定義していますが，equals メソッドは定義していません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>hashCode</code> メソッドを定義していますが， <code>equals</code> メソッドは定義していません。
これは「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に違反するかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="HE_EQUALS_USE_HASHCODE">
<ShortDescription>equals メソッドを定義して Object.hashCode() を使用しているクラス</ShortDescription>
<LongDescription>{0} は，equals メソッドを定義して，Object.hashCode() を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>equals(Object)</code> をオーバーライドしていますが， <code>hashCode</code> メソッドは <code>java.lang.Object</code> から継承しています (同一性ハッシュコード (Java 仮想マシンによってオブジェクトに代入された任意の値) を返します)。
したがって，「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に違反するかもしれません。
</p>
<p>
このクラスのインスタンスが <code>HashMap</code>/<code>HashTable</code> に決して代入されるだろうと思わないなら推奨される <code>hashCode</code> メソッドの実装は次のようになります。
</p>
<pre><code>public int hashCode() {
assert false : "hashCodeが呼び出されることは想定されていません。";
return 42; // 任意の定数
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="HE_INHERITS_EQUALS_USE_HASHCODE">
<ShortDescription>equals メソッドを継承して Object.hashCode() を使用しているクラス</ShortDescription>
<LongDescription>{0} は，equals メソッドを継承して，Object.hashCode() を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，抽象スーパークラスから <code>equals(Object)</code> メソッドを継承して， <code>java.lang.Object</code> から <code>hashCode</code> メソッドを継承しています (同一性ハッシュコード (Java 仮想マシンによってオブジェクトに代入された任意の値) を返します)。
したがって，「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に違反するかもしれません。
</p>
<p>
<code>hashCode</code> メソッドを定義したくないまたはオブジェクトが <code>HashMap</code>/<code>Hashtable</code> に決して格納されないだろうと思っているなら <code>UnsupportedOperationException</code> をスローする <code>hashCode()</code> メソッドを定義してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="HE_EQUALS_NO_HASHCODE">
<ShortDescription>equals メソッドは定義していますが hashCode メソッドは定義していないクラス</ShortDescription>
<LongDescription>{0} は，equals メソッドを定義していますが，hashCode メソッドは定義していません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>equals(Object)</code> メソッドをオーバーライドしていますが， <code>hashCode</code> メソッドはオーバーライドしていません。
したがって，「等価なオブジェクトは等価なハッシュコードを保持する必要がある」という <code>hashCode</code> メソッドの汎用規約に違反するかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EQ_ABSTRACT_SELF">
<ShortDescription>抽象クラスは共変な equals メソッドを宣言している</ShortDescription>
<LongDescription>抽象クラス {0} は，共変な equals({0.givenClass}) メソッドを定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，共変な <code>equals</code> メソッドを定義しています。
<code>java.lang.Object</code> の <code>equals</code> メソッドを正しくオーバーライドするためには <code>equals</code> メソッドのパラメータの型は， <code>java.lang.Object</code> でなければなりません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ES_COMPARING_STRINGS_WITH_EQ">
<ShortDescription>String オブジェクトを == や != を使用して比較している</ShortDescription>
<LongDescription>String オブジェクトを == や != を使用して比較しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは参照等価性のために <code>==</code> や <code>!=</code> を使用して <code>java.lang.String</code> オブジェクトを比較しています。
両方の文字列がソースファイルの定数か， <code>String.intern()</code> を使用して正準化されていないかぎり，同じ文字列は2つの異なる <code>String</code> オブジェクトによって表されるかもしれません。
その代わりに <code>equals(Object)</code> メソッドを使用することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ES_COMPARING_PARAMETER_STRING_WITH_EQ">
<ShortDescription>String パラメータを == や != を使用して比較している</ShortDescription>
<LongDescription>String パラメータを == や != を使用して比較しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは参照等価性のために <code>==</code> や <code>!=</code> を使用して <code>java.lang.String</code> パラメータを比較しています。
文字列定数または正準化された文字列だけをメソッドに渡すことを呼び出し元に要求することは，不必要に脆弱であり，測定可能な性能の向上につながることはほとんどありません。
その代わりに <code>equals(Object)</code> メソッドを使用することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CO_ABSTRACT_SELF">
<ShortDescription>抽象クラスは共変な compareTo メソッドを定義している</ShortDescription>
<LongDescription>抽象クラス {0} は，compareTo({0.givenClass}) メソッドを定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，共変な <code>compareTo</code> メソッドを定義しています。
<code>Comparable</code> インタフェースの <code>compareTo</code> メソッドを正しく実装するためには <code>compareTo</code> メソッドのパラメータの型は， <code>java.lang.Object</code> でなければなりません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IS_FIELD_NOT_GUARDED">
<ShortDescription>並行アクセスに対してガードされていないフィールド</ShortDescription>
<LongDescription>{1.givenClass} は，並行アクセスに対してガードされていません。{2}% の確率でロックします。</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドは， <code>net.jcip.annotations.GuardedBy</code> または <code>javax.annotation.concurrent.GuardedBy</code> というアノテーションが付けられていますが，アノテーションに違反するような方法でアクセスできます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MSF_MUTABLE_SERVLET_FIELD">
<ShortDescription>可変サーブレットフィールド</ShortDescription>
<LongDescription>{1} は，可変サーブレットフィールドです。</LongDescription>
<Details>
<![CDATA[
<p>
Web サーバは，一般的にサーブレットや JSP クラスのインスタンスを1つだけ作成します (すなわち，シングルトンとして扱います)。
複数のスレッドが複数同時のリクエストに応えるためにそのインスタンスでメソッドを呼び出します。
したがって，一般に可変インスタンスフィールドは競合状態を作ります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IS2_INCONSISTENT_SYNC">
<ShortDescription>一貫性のない同期化</ShortDescription>
<LongDescription>{1} の一貫性のない同期化です。{2}% の確率でロックします。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスのフィールドは，同期化に関して一貫性なくアクセスされるように見えます。
このバグレポートは，バグパターンディテクタが次のように判断したことを示します。
</p>
<ul>
<li>クラスは，ロックされたアクセスとアンロックされたアクセスが混在していて， </li>
<li>クラスは， <code>javax.annotation.concurrent.NotThreadSafe</code> アノテーションが付けられていなくて， </li>
<li>少なくとも1つのロックされたアクセスがクラス自身のメソッドの1つによって実行され， </li>
<li>読み出しの2倍の重み付けをした書き込みで，非同期フィールドのアクセス (読み出しと書き込み) 数がすべてのアクセスのわずか1/3</li>
</ul>
<p>
このバグパターンに合致する一般的なバグは，スレッドセーフを意図したクラスでメソッドを同期化させることを忘れていることです。
</p>
<p>
「非同期アクセス」というラベルがついているノードを選択すると，ディテクタが同期化しないでフィールドにアクセスしたと信じているコードの場所を表示できます。
</p>
<p>
不正確ないろいろな原因がこのディテクタにあることに注意してください。
たとえば，ディテクタはロックを保持されるすべての状況を静的に検出できるわけではありません。
また，ディテクタがロックされたアクセスとアンロックされたアクセスの区別が正確なときでも，問題のコードは依然として正しいかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NN_NAKED_NOTIFY">
<ShortDescription>裸の notify メソッド</ShortDescription>
<LongDescription>{1} の中に裸の notify メソッドがあります。</LongDescription>
<Details>
<![CDATA[
<p>
<code>notify</code> メソッドまたは <code>notifyAll</code> メソッドへの呼び出しは可変オブジェクト状態にどんな (明らかな) 付随的な変更ももたらされませんでした。
一般的に別のスレッドが期待しているいくつかの条件が真になったので，モニタで <code>notify</code> メソッドが呼び出されます。
しかしながら，意味がある条件のために両方のスレッドに見えるヒープオブジェクトを含まなければなりません。
</p>
<p>
可変オブジェクトの状態変更が通知があるメソッドを呼び出したメソッドで起こったかもしれないので，このバグが必ずしもエラーを示すというわけではありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_EXPOSE_REP">
<ShortDescription>配列または可変オブジェクトを返すことによって内部表現を暴露するかもしれない public static メソッド</ShortDescription>
<LongDescription>{1} は，{2.givenClass} を返すことによって，内部表現を暴露するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
<code>public static</code> メソッドは，クラスの 静的な状態の一部である配列の参照を返します。
このメソッドを呼び出すどんなコードも，基底配列を自由に変更できます。
解決策は，配列のコピーを返すことです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EI_EXPOSE_REP">
<ShortDescription>可変オブジェクトへの参照を返すことによって内部表現を暴露するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，{2.givenClass} を返すことによって内部表現を暴露するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
オブジェクトのフィールドに格納された可変オブジェクトの参照を返すと，オブジェクトの内部表現を暴露します。
インスタンスが信頼できないコードによってアクセスされるなら，可変オブジェクトのチェックされていない変更がセキュリティや他の重要なプロパティを危うくするでしょう。
何か違うことをする必要があります。オブジェクトの新しいコピーを返すことは，多くの状況でより良いアプローチです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EI_EXPOSE_REP2">
<ShortDescription>可変オブジェクトへの参照を取り込むことによって内部表現を暴露するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，{2.givenClass} の中に外部の可変オブジェクトを格納することによって内部表現を暴露するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このコードはオブジェクトの内部表現に外部の可変オブジェクトの参照を格納しています。
インスタンスが信頼できないコードによってアクセスされるなら，可変オブジェクトのチェックされていない変更がセキュリティや他の重要なプロパティを危うくするでしょう。
何か違うことをする必要があります。オブジェクトのコピーを格納することは，多くの状況でより良いアプローチです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EI_EXPOSE_STATIC_REP2">
<ShortDescription>static フィールドに可変オブジェクトを格納することによって，内部の静的状態を暴露するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，staticフィールド {2} に可変オブジェクトを格納することによって，内部の静的状態を暴露するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>static</code> フィールドに外部の可変オブジェクトを格納しています。
可変オブジェクトのチェックされていない変更がセキュリティや他の重要なプロパティを危うくするでしょう。
何か違うことをする必要があります。オブジェクトのコピーを格納することは，多くの状況でより良いアプローチです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RU_INVOKE_RUN">
<ShortDescription>スレッドで run メソッドを呼び出している</ShortDescription>
<LongDescription>{1} は，スレッドで明示的に run メソッドを呼び出しています (スレッドを開始することをを意味していましたか？)。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，スレッドで 明示的に <code>run</code> メソッドを呼び出しています。
一般的にクラスは新しいスレッドで自己の <code>run</code> メソッドを呼び出してもらうために <code>Runnable</code> インタフェースを実装します。
その場合は， <code>Thread.start()</code> を呼び出すのが正しいです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SP_SPIN_ON_FIELD">
<ShortDescription>スピンロックをしているメソッド</ShortDescription>
<LongDescription>フィールド {2.givenClass} を使用してスピンロックをしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，フィールドを読み出すループで回り続けます。
コンパイラがフィールドの読み出しをループの外に出すかもしれません。コードを無限ループに変えます。
正しい同期化 (<code>wait</code>/<code>notify</code> を呼び出すように含む) を使うようにクラスを変更すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NS_DANGEROUS_NON_SHORT_CIRCUIT">
<ShortDescription>潜在的な非短絡論理の危険な使用</ShortDescription>
<LongDescription>潜在的な非短絡論理の危険な使用。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは短絡論理 (<code>&&</code> や <code>||</code>) ではなく非短絡論理 (<code>&</code> や <code>|</code>) を使用していると思われます。
さらに，左辺値によって右辺を評価したくない (例外のスローや演算が高くつく副作用があるため) と思っているのかもしれません。
非短絡論理は，左辺を知ることによって結果を推論できたとしても両側の式が評価されます。
これは効率が悪く，右辺の評価でエラーが発生するケースを左辺でガードしているなら，結果としてエラーになる可能性があります。
</p>
<p>
詳細については， <a href="https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.22.2">The Java Language Specification</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NS_NON_SHORT_CIRCUIT">
<ShortDescription>非短絡論理の疑わしい使用</ShortDescription>
<LongDescription>非短絡論理の疑わしい使用。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは短絡論理 (<code>&&</code> や <code>||</code>) ではなく非短絡論理 (<code>&</code> や <code>|</code>) を使用していると思われます。
非短絡論理は，左辺を知ることによって結果を推論できたとしても両側の式が評価されます。
これは効率が悪く，右辺の評価でエラーが発生するケースを左辺でガードしているなら，結果としてエラーになる可能性があります。
</p>
<p>
詳細については， <a href="https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.22.2">The Java Language Specification</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TLW_TWO_LOCK_WAIT">
<ShortDescription>2つ以上のロックを保持して wait メソッドを呼び出している</ShortDescription>
<LongDescription>2つ以上のロックを保持して wait メソッドを呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
2つ以上のロックを保持して，モニタで待機させるとデッドロックを引き起こすことがあります。
<code>wait</code> メソッドを呼び出すと，待機しているオブジェクトのロックを解除するだけで，その他のロックは解除しません。
これは必ずしもバグではありませんが厳密に調べる価値があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TLW_TWO_LOCK_NOTIFY" deprecated="true"> <!-- never generated -->
<ShortDescription>Notify with two locks held</ShortDescription>
<LongDescription>notify() or notifyAll*() with two locks held in {1}</LongDescription>
<Details>
<![CDATA[
<p> The code calls notify() or notifyAll() while two locks
are held. If this notification is intended to wake up a wait()
that is holding the same locks, it may deadlock, since the wait
will only give up one lock and the notify will be unable to get both locks,
and thus the notify will not succeed.
If there is also a warning about a two lock wait, the
probably of a bug is quite high.
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UW_UNCOND_WAIT">
<ShortDescription>wait メソッドの無条件呼び出し</ShortDescription>
<LongDescription>wait メソッドを無条件で呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには条件制御フローによってガードされない <code>java.lang.Object.wait()</code> の呼び出しがあります。
このコードは <code>wait</code> メソッドを呼び出す前に待機するつもりだった条件が既に満たされていないことを確かめるべきです。
どんな前の通知も無視されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UR_UNINIT_READ">
<ShortDescription>コンストラクタで初期化されていないフィールドを読み出している</ShortDescription>
<LongDescription>初期化されていないフィールド {2.name} を読み出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコンストラクタは，まだ値が代入されていないフィールドを読み出しています。
多くの場合，プログラマがコンストラクタのパラメータの代わりに誤ってフィールドを使うときに起きます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UR_UNINIT_READ_CALLED_FROM_SUPER_CONSTRUCTOR">
<ShortDescription>スーパークラスのコンストラクタから呼び出されるメソッドで初期化されていないフィールドを読み出している</ShortDescription>
<LongDescription>スーパークラスのコンストラクタから呼び出されるとき，{2.name} は {1} で初期化されません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，スーパークラスのコンストラクタで呼びされています。この時点では，クラスのフィールドはまだ初期化されていません。
</p>
<p>
これはたくさんの具象クラスを作るためです。次のクラスを検討してください。
</p>
<pre><code>abstract class A {
int hashCode;
abstract Object getValue();
A() {
hashCode = getValue().hashCode();
}
}
class B extends A {
Object value;
B(Object v) {
this.value = v;
}
Object getValue() {
return value;
}
}
</code></pre>
<p>
<code>B</code> が構築されるとき， <code>B</code> のコンストラクタが <code>value</code> に値を設定する前に， <code>A</code> クラスのコンストラクタが呼び出されます。
したがって， <code>A</code> のコンストラクタが <code>getValue</code> を呼び出すとき， <code>value</code> の初期化されていない値が読み出されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UG_SYNC_SET_UNSYNC_GET">
<ShortDescription>同期化していない get メソッド，同期化している set メソッド</ShortDescription>
<LongDescription>{1} は同期化していません，{2} は同期化しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスには類似した名前の get メソッドと set メソッドがあり，set メソッドは同期化していて，get メソッドは同期化していません。
get メソッドの呼び出し元がオブジェクトの一貫した状態を必ずしも見るというわけではないので，実行時に間違った振る舞いの原因になることがあります。
get メソッドは同期化すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IC_INIT_CIRCULARITY">
<ShortDescription>初期化が循環している</ShortDescription>
<LongDescription>{0} と {1} の間で初期化が循環しています。</LongDescription>
<Details>
<![CDATA[
<p>
バグインスタンスによって参照される2つのクラスのスタティックイニシャライザで循環が検出されました。
さまざまな予想外の振る舞いはそのような循環に起因することがあります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IC_SUPERCLASS_USES_SUBCLASS_DURING_INITIALIZATION">
<ShortDescription>スーパークラスは初期化中にサブクラスを使用している</ShortDescription>
<LongDescription>{0} の初期化は，まだ初期化されていないクラス {2} にアクセスしています。</LongDescription>
<Details>
<![CDATA[
<p>
クラスは，初期化中にサブクラスを積極的に使用しています。サブクラスはこの時点ではまだ初期化されていません。<br>
たとえば，次のコードにおいて， <code>foo</code> は <code>null</code> です。
</p>
<pre><code>public class CircularClassInitialization {
static class InnerClassSingleton extends CircularClassInitialization {
static InnerClassSingleton singleton = new InnerClassSingleton();
}
static CircularClassInitialization foo = InnerClassSingleton.singleton;
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="IT_NO_SUCH_ELEMENT">
<ShortDescription>Iterator.next() が NoSuchElementException をスローできない</ShortDescription>
<LongDescription>{1} は，NoSuchElementException をスローできません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>java.util.Iterator</code> を実装しています。
しかしながら， <code>next</code> メソッドは <code>java.util.NoSuchElementException</code> をスローできません。
<code>next</code> メソッドは，それ以上要素を返すことができないときは <code>NoSuchElementException</code> をスローするように変更すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DL_SYNCHRONIZATION_ON_SHARED_CONSTANT">
<ShortDescription>正準化した文字列の同期化</ShortDescription>
<LongDescription>正準化した文字列を同期化しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは正準化した文字列で同期化しています。
</p>
<pre><code>private static String LOCK = "LOCK";
...
synchronized(LOCK) {
...
}
...
</code></pre>
<p>
文字列定数は正準化され，Java 仮想マシンによってロードされたすべてのクラス全体で共有されます。
このコードは，他のコードがロックしている可能性があるものをロックしています。
これはブロックとデッドロックの振る舞いを診断するのが非常に奇妙で困難になる可能性があります。<br>
詳細は， <a href="http://www.javalobby.org/java/forums/t96352.html">http://www.javalobby.org/java/forums/t96352.html</a> と <a href="http://jira.codehaus.org/browse/JETTY-352">http://jira.codehaus.org/browse/JETTY-352</a> を参照してください。
</p>
<p>
CERT <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DL_SYNCHRONIZATION_ON_BOOLEAN">
<ShortDescription>Boolean の同期化</ShortDescription>
<LongDescription>Boolean を同期化しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>Boolean</code> のようなボクシングされたプリミティブ型の定数で同期化しています。
</p>
<pre><code>private static Boolean inited = Boolean.FALSE;
...
synchronized(inited) {
if (!inited) {
init();
inited = Boolean.TRUE;
}
}
...
</code></pre>
<p>
一般には2つの <code>Boolean</code> オブジェクトだけが存在しています。
このコードは他の無関係なコードと同じオブジェクトで同期化している可能性があるので，無応答やデッドロックの原因になります。
</p>
<p>
CERT <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DL_SYNCHRONIZATION_ON_UNSHARED_BOXED_PRIMITIVE">
<ShortDescription>ボクシングされたプリミティブ値の同期化</ShortDescription>
<LongDescription>{2} を同期化しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは明らかに共有されていない <code>Integer</code> のようなボクシングされたプリミティブ型で同期化しています。
</p>
<pre><code>private static final Integer fileLock = new Integer(1);
...
synchronized(fileLock) {
.. do something ..
}
...
</code></pre>
<p>
このコードは fileLock を次のように宣言するとより良くなります。
</p>
<pre><code>private static final Object fileLock = new Object();
</code></pre>
<p>
既存のコードとしては間違っていないかもしれないが，紛らわしいので将来リファクタリングすべきかもしれません。
たとえば，IntelliJ の "Remove Boxing" のようなリファクタリングは Java 仮想マシンを通して共有される正準化された <code>Integer</code> オブジェクトを使用するように置き換えてしまい，非常に紛らわしい振る舞いと潜在的デッドロックの原因になります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DL_SYNCHRONIZATION_ON_BOXED_PRIMITIVE">
<ShortDescription>ボクシングされたプリミティブの同期化</ShortDescription>
<LongDescription>{2} を同期化しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>Integer</code> のようなボクシングされたプリミティブの定数で同期化しています。
</p>
<pre><code>private static Integer count = 0;
...
synchronized(count) {
count++;
}
...
</code></pre>
<p>
<code>Integer</code> オブジェクトはキャッシュして共有できます。
他の無関係なコードと同じオブジェクトで同期化している可能性があるので，無応答やデッドロックの原因になります。
</p>
<p>
CERT <a href="https://www.securecoding.cert.org/confluence/display/java/CON08-J.+Do+not+synchronize+on+objects+that+may+be+reused">CON08-J. Do not synchronize on objects that may be reused</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ESync_EMPTY_SYNC">
<ShortDescription>空の synchronized ブロック</ShortDescription>
<LongDescription>空のsynchronizedブロックです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードには空の <code>synchronized</code> ブロックがあります。
</p>
<pre><code>synchronized() {
}
</code></pre>
<p>
空の synchronized ブロックは巧妙で正しく使用するのは困難です。
空の synchronized ブロックはわざとらしくて決して良い解決策ではありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IS_INCONSISTENT_SYNC">
<ShortDescription>一貫性のない同期化</ShortDescription>
<LongDescription>{1} の同期化には一貫性がありません。{2}% の確率でロックします。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスのフィールドは，同期化に関して一貫性のないアクセスをしているように見えます。
このバグレポートは，バグパターンディテクタが次のように判断したことを示します。
</p>
<ul>
<li>クラスにはロックされたアクセスとアンロックされたアクセスが混在していて</li>
<li>少なくとも1つのロックされたアクセスがクラス自身のメソッドの1つによって実行され， </li>
<li>読み出しの2倍の重み付けをした書き込みで，非同期フィールドのアクセス (読み出しと書き込み) 数がすべてのアクセスのわずか1/3</li>
</ul>
<p>
このバグパターンに合致する一般的なバグは，スレッドセーフを意図したクラスでメソッドを同期化するのを忘れていることです。
</p>
<p>
不正確のいろいろなソースがこのディテクタにあることに注意してください。
たとえば，ディテクタはロックを保持されるすべての状況を静的に検出できるわけではありません。
また，ディテクタがロックされたアクセスとアンロックされたアクセスの区別が正確なときでも，問題のコードはまだ正しいかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ML_SYNC_ON_FIELD_TO_GUARD_CHANGING_THAT_FIELD">
<ShortDescription>フィールドを同期化でガードしようとする無駄な試み</ShortDescription>
<LongDescription>{2.givenClass} を同期化でガードしようとする無駄な試みです。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，フィールドの同時更新に対して同期化でガードしようとしています。しかし，フィールドをガードするとフィールドではなく，フィールドが参照するオブジェクトのロックを獲得します。
これはあなたが必要とする相互排除ができないかもしれません。
他のスレッドは (他の目的のための) 参照されたオブジェクトのロックを獲得するかもしれません。<br>
このパターンの例は次のようになります。
</p>
<pre><code>private Long myNtfSeqNbrCounter = new Long(0);
private Long getNotificationSequenceNumber() {
Long result = null;
synchronized(myNtfSeqNbrCounter) {
result = new Long(myNtfSeqNbrCounter.longValue() + 1);
myNtfSeqNbrCounter = new Long(result.longValue());
}
return result;
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="ML_SYNC_ON_UPDATED_FIELD">
<ShortDescription>更新されるフィールドで同期化しているメソッド</ShortDescription>
<LongDescription>{1} は，更新されるフィールド {2.givenClass} で同期化しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，可変フィールドから参照されたオブジェクトで同期化しています。
異なるスレッドが異なるオブジェクトで同期化しているかもしれないので，有用な意味を持っている可能性が低いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_OOI_PKGPROTECT">
<ShortDescription>インタフェースから移動してパッケージプロテクテッドにすべきフィールド</ShortDescription>
<LongDescription>{1} は，インタフェースから移動してパッケージプロテクテッドにすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
インタフェースに定義された <code>static final</code> フィールドが配列や <code>Hashtable</code> などの可変オブジェクトを参照しています。
この可変オブジェクトは悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
脆弱性を回避するためにフィールドをクラスに移動して，パッケージプロテクテッドにする必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_FINAL_PKGPROTECT">
<ShortDescription>final かつパッケージプロテクテッドにすべきフィールド</ShortDescription>
<LongDescription>{1} は，final かつパッケージプロテクテッドにすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
この可変 <code>static</code> フィールドは悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
脆弱性を回避するためにフィールドを <code>final</code> および/またはパッケージプロテクテッドにします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_SHOULD_BE_REFACTORED_TO_BE_FINAL">
<ShortDescription>final ではないフィールドはリファクタリングすべき</ShortDescription>
<LongDescription>{1} は，final ではないのでリファクタリングすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
<code>final</code> ではない <code>public static</code> または <code>protected static</code> フィールドは悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
脆弱性を回避するためにフィールドを <code>final</code> にします。
しかしながら，スタティックイニシャライザには複数のフィールドへの書き込みがあるので，何らかのリファクタリングを必要とするでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_SHOULD_BE_FINAL">
<ShortDescription>final にすべきフィールド</ShortDescription>
<LongDescription>{1} は，final ではありませんが final にすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
<code>final</code> ではない <code>public static</code> または <code>protected static</code> フィールドは悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
脆弱性を回避するためにフィールドを <code>final</code> にします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_PKGPROTECT">
<ShortDescription>パッケージプロテクテッドにすべきフィールド</ShortDescription>
<LongDescription>{1} は，パッケージプロテクテッドにすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
この可変 <code>static</code> フィールドは悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
脆弱性を回避するためにフィールドをパッケージプロテクテッドにします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_MUTABLE_HASHTABLE">
<ShortDescription>可変 Hashtable のフィールド</ShortDescription>
<LongDescription>{1} は，可変 Hashtable です。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>static final</code> フィールドは <code>Hashtable</code> を参照しているので，悪意のあるコードや別のパッケージによって思いがけずアクセスされる可能性があります。
このコードは<code>Hashtable</code> の内容を自由に変更できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_MUTABLE_COLLECTION">
<ShortDescription>可変コレクションのフィールド</ShortDescription>
<LongDescription>{1} は可変コレクションです。</LongDescription>
<Details>
<![CDATA[
<p>
可変コレクションのインスタンスが <code>static final</code> フィールドに割り当てられています。
したがって，悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
脆弱性を避けるために <code>Collections.unmodifiableSet/List/Map</code> などでこのフィールドをラップすることを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_MUTABLE_COLLECTION_PKGPROTECT">
<ShortDescription>パッケージプロテクテッドにすべき可変コレクションのフィールド</ShortDescription>
<LongDescription>{1} は，パッケージプロテクテッドにすべき可変コレクションです。</LongDescription>
<Details>
<![CDATA[
<p>
可変コレクションのインスタンスが <code>static final</code> フィールドに割り当てられています。
したがって，悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
フィールドは脆弱性を避けるためにパッケージプロテクテッドにできます。
脆弱性を避けるために <code>Collections.unmodifiableSet/List/Map</code> などでこのフィールドをラップすることを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_MUTABLE_ARRAY">
<ShortDescription>可変配列のフィールド</ShortDescription>
<LongDescription>{1} は，可変配列です。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>static final</code> フィールドは配列を参照しているので，悪意のあるコードや別のパッケージによって思いがけずアクセスされる可能性があります。
このコードは配列の内容を自由に変更できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_CANNOT_BE_FINAL">
<ShortDescription>final ではないフィールドは悪意のあるコードから保護できない</ShortDescription>
<LongDescription>{1} は，final ではないので，悪意のあるコードから保護できません。 </LongDescription>
<Details>
<![CDATA[
<p>
この可変 <code>static</code> フィールドは悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
残念ながらこのような使い方は簡単に解決できません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ME_MUTABLE_ENUM_FIELD">
<ShortDescription>列挙型フィールドは public で可変である</ShortDescription>
<LongDescription>{1} フィールドは public で可変です。</LongDescription>
<Details>
<![CDATA[
<p>
可変 <code>public</code> フィールドが <code>public</code> 列挙型の中に定義されています。
したがって，フィールドは悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
可変列挙型フィールドが遅延初期化で使用されるかもしれないとしても外界へ暴露するバッドプラクティスです。
このメソッドを <code>final</code> およびパッケージプライベートとして宣言することを考えてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ME_ENUM_FIELD_SETTER">
<ShortDescription>public 列挙型メソッドが無条件にフィールドを設定する</ShortDescription>
<LongDescription>{1} は無条件にフィールド {2.name} を設定しています。</LongDescription>
<Details>
<![CDATA[
<p>
無条件に列挙型フィールドを設定している <code>public</code> 列挙型で <code>public</code> メソッドを宣言しています。
したがって，フィールドは悪意のあるコードや別のパッケージによって思いがけず変更される可能性があります。
可変列挙型フィールドが遅延初期化で使用されるかもしれないとしても外界へ暴露するバッドプラクティスです。
このメソッドを除去するかパッケージプライベートとして宣言することを考えてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD">
<ShortDescription>潜在的な継承されたメソッドなのか外部のメソッドなのかあいまいなメソッドの呼び出し</ShortDescription>
<LongDescription>潜在的な継承されたメソッドなのか外部のメソッドなのかあいまいなメソッド {2} を呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
内部クラスは，継承されたメソッドか外部クラスで定義されたメソッドなのかどちらとも解釈できるメソッドを呼び出しています。
たとえば， <code>foo(17)</code> を呼び出します。それはスーパークラスと外部のメソッドの両方で定義されています。
Java のセマンティックスでは，継承したメソッドを呼び出しますが，これは意図したことではないかもしれません。
</p>
<p>
本当に継承されたメソッドを呼び出すつもりなら <code>super</code> を付けて (例：<code>super.foo(17)</code>) 呼び出してください。
そうすれば，外部クラスのメソッドではなく継承されたメソッドを呼び出したいことがこのコードを読む人と SpotBugs に明確になります。
</p>
<p>
<code>this.foo(17)</code> を呼び出す場合は，継承されたメソッドが呼び出されます。
しかしながら，SpotBugs はクラスファイルを見るだけなので， <code>this.foo(17)</code> と <code>foo(17)</code> の呼び出しの違いを見分けることができません。
潜在的なあいまいな呼び出しについて文句を言うでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_SAME_SIMPLE_NAME_AS_SUPERCLASS">
<ShortDescription>クラス名はスーパークラスの単純名を遮るべきではない</ShortDescription>
<LongDescription>クラス名 {0} は，スーパークラス {1} の単純名を遮ります。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，スーパークラスが異なるパッケージであるということを除いて，スーパークラスと同一の単純名です (たとえば， <code>alpha.Foo</code> が <code>beta.Foo</code> を拡張します)。
これは非常に紛らわしく，参照関係を解決するために <code>import</code> 文を見なければならなかったり，スーパークラスのメソッドをオーバーライドしないで誤ってメソッドを定義する状況を作り出します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_SAME_SIMPLE_NAME_AS_INTERFACE">
<ShortDescription>クラス名は実装されたインタフェースの単純名を遮るべきではない</ShortDescription>
<LongDescription>クラス名 {0} は，実装されたインタフェース {1} の単純名を遮ります。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスまたはインタフェースは，インタフェースが異なるパッケージであるということを除いて実装された/拡張されたインタフェースと同一の単純名です (たとえば， <code>alpha.Foo</code> が <code>beta.Foo</code> を継承しているような状況です)。
これは非常に紛らわしく，参照関係を解決するために <code>import</code> 文を見なければならなかったり，スーパークラスのメソッドをオーバーライドしないで誤ってメソッドを定義する状況を作り出します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_CLASS_NAMING_CONVENTION">
<ShortDescription>クラス名は大文字から始めるべき</ShortDescription>
<LongDescription>クラス名 {0} は，大文字から始まっていません。</LongDescription>
<Details>
<![CDATA[
<p>
クラス名は，最初の文字とそれに続く各単語の最初の文字を大文字にした名詞にすべきです。
クラス名は単純でわかりやすいようにしてください。
頭文字や略語 (URLやHTMLなどのように略語がロング形式よりもはるかに広く使われている場合を除く) の使用は避けてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_METHOD_NAMING_CONVENTION">
<ShortDescription>メソッド名は小文字から始めるべき</ShortDescription>
<LongDescription>メソッド名 {1} は，小文字から始まっていません。</LongDescription>
<Details>
<![CDATA[
<p>
メソッド名は，最初の文字は小文字にし，それに続く各単語の最初の文字を大文字にした動詞にすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_FIELD_NAMING_CONVENTION">
<ShortDescription>フィールド名は小文字から始めるべき</ShortDescription>
<LongDescription>フィールド名 {1} は，小文字から始まっていません。</LongDescription>
<Details>
<![CDATA[
<p>
<code>final</code> ではないフィールドの名前は，最初の文字は小文字にし，それに続く各単語の最初の文字を大文字にすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_VERY_CONFUSING">
<ShortDescription>非常に紛らわしい名前のメソッド</ShortDescription>
<LongDescription>{1} と {3} は，非常に紛らわしいです。</LongDescription>
<Details>
<![CDATA[
<p>
参照されたメソッドは，大文字と小文字だけが異なる名前があります。
大文字と小文字が同一ならメソッドの1つが他のメソッドをオーバーライドするので，非常に紛らわしいです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_VERY_CONFUSING_INTENTIONAL">
<ShortDescription>非常に紛らわしい名前のメソッド (多分意図的)</ShortDescription>
<LongDescription>{1} と {3} のメソッドは，非常に紛らわしいです (多分意図的)。</LongDescription>
<Details>
<![CDATA[
<p>
参照されたメソッドは，大文字と小文字だけが異なる名前があります。
大文字と小文字が同一ならメソッドの1つが他のメソッドをオーバーライドするので，非常に紛らわしいです。
他のメソッドの存在から，これらのメソッドの両方の存在が意図的で，確実に混乱させていると思われます。
APIの凍結によって両方とも持たざるを得ない場合を除き，それらのうちの1つを除去しようと努力すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_WRONG_PACKAGE">
<ShortDescription>パラメータの間違ったパッケージのためにスーパークラスのメソッドをオーバーライドしていないメソッド</ShortDescription>
<LongDescription>パラメータの型 {4} がスーパークラスのパラメータの型 {5} と合致していないので，{1} はスーパークラスのメソッドをオーバーライドしていません。</LongDescription>
<Details>
<![CDATA[
<p>
パラメータの型がスーパークラスで対応するパラメータの型と正確に合致していないので，サブクラスのメソッドはスーパークラスの類似したメソッドをオーバーライドしていません。<br>
たとえば次のようなコードです。
</p>
<pre><code>import alpha.Foo;
public class A {
public int f(Foo x) { return 17; }
}
----
import beta.Foo;
public class B extends A {
public int f(Foo x) { return 42; }
}
</code></pre>
<p>
クラス <code>B</code> で定義された <code>f(Foo)</code> メソッドは，クラス <code>A</code> の <code>f(Foo)</code> メソッドをオーバーライドしていません。
これは引数の型 <code>Foo</code> が違うパッケージだからです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_WRONG_PACKAGE_INTENTIONAL">
<ShortDescription>パラメータの間違ったパッケージのためにスーパークラスのメソッドをオーバーライドしていないメソッド</ShortDescription>
<LongDescription>パラメータの型 {4} がスーパークラスのパラメータの型 {5} と合致しないので，{1} はスーパークラスのメソッドをオーバーライドしていません。</LongDescription>
<Details>
<![CDATA[
<p>
パラメータの型が正確にスーパークラスで対応するパラメータの型と合致していないので，サブクラスのメソッドはスーパークラスの類似したメソッドをオーバーライドしていません。<br>
たとえば次のようなコードです。
</p>
<pre><code>import alpha.Foo;
public class A {
public int f(Foo x) { return 17; }
}
----
import beta.Foo;
public class B extends A {
public int f(Foo x) { return 42; }
public int f(alpha.Foo x) { return 27; }
}
</code></pre>
<p>
クラス <code>B</code> で定義された <code>f(Foo)</code> メソッドは，クラス <code>A</code> の <code>f(Foo)</code> メソッドをオーバーライドしません。
これは引数の型 <code>Foo</code> が違うパッケージだからです。
</p>
<p>
この場合，サブクラスがスーパークラスのメソッドと同一のシグネチャでメソッドを定義しているので，おそらく理解できます。
しかしながら，そのようなメソッドは非常に紛らわしいです。
類似しているが同一ではないシグネチャのメソッドを除去するか，非推奨にすることを強く検討すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_CONFUSING">
<ShortDescription>紛らわしい名前のメソッド</ShortDescription>
<LongDescription>{1} と {3} は，紛らわしいです。</LongDescription>
<Details>
<![CDATA[
<p>
参照されたメソッドは，大文字と小文字だけが異なる名前があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_METHOD_CONSTRUCTOR_CONFUSION">
<ShortDescription>明らかなメソッドとコンストラクタの混乱</ShortDescription>
<LongDescription>{1} は，おそらくコンストラクタにすることを意図していました。</LongDescription>
<Details>
<![CDATA[
<p>
この正規のメソッドは定義しているクラスと同じ名前です。
これはコンストラクタを意図していた可能性が高いです。もしそうなら <code>void</code> 戻り値の宣言を除去してください。<br>
誤ってメソッドを定義したことが間違いだと気付き，適切なコンストラクタを定義したが，後方互換性のためにこのメソッドを除去できないならメソッドを非推奨にしてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_LCASE_HASHCODE">
<ShortDescription>クラスは hashcode() を定義しています。hashCode() にすべきですか?</ShortDescription>
<LongDescription>クラス {0} は，hashcode() を定義しています。hashCode() にすべきですか?</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>hashcode()</code> という名前のメソッドを定義しています。
このメソッドは， <code>java.lang.Object</code> の <code>hashCode</code> メソッドを (おそらく意図的に) オーバーライドしていません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_LCASE_TOSTRING">
<ShortDescription>クラスは tostring() を定義しています。toString() にすべきですか?</ShortDescription>
<LongDescription>クラス {0} は，tostring() を定義しています。toString() にすべきですか?</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>tostring()</code> という名前のメソッドを定義しています。
このメソッドは， <code>java.lang.Object</code> の <code>toString</code> メソッドを (おそらく意図的に) オーバーライドしていません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_BAD_EQUAL">
<ShortDescription>クラスは equal(Object) を定義しています。equals(Object) にすべきですか?</ShortDescription>
<LongDescription>クラス {0} は equal(Object) を定義しています。equals(Object) にすべきですか?</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>equal(Object)</code> という名前のメソッドを定義しています。
このメソッドは， <code>java.lang.Object</code> の <code>equals(Object)</code> を (おそらく意図的に) オーバーライドしていません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NM_CLASS_NOT_EXCEPTION">
<ShortDescription>例外クラスのように命名されているが，クラスは Exception から派生されていない</ShortDescription>
<LongDescription>例外クラスのように命名されていますが，クラス {0} は，Exception から派生されていません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，例外クラスから派生されていないのにクラス名が「Exception」で終わっています。
このクラスのユーザが混乱するでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RR_NOT_CHECKED">
<ShortDescription>InputStream.read() の戻り値を無視しているメソッド</ShortDescription>
<LongDescription>{1} は，{2} の戻り値を無視しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，複数バイトを返す可能性がある <code>java.io.InputStream.read()</code> (またはそのバリエーション) の戻り値を無視しています。
戻り値がチェックされないと呼び出し元は要求したバイト数よりも少ないバイト数を読み出した場合，正しく処理できません。
これは潜在的なバグで，多くのプログラムでは，入力ストリームからの読み出しは，通常要求した完全なデータ量を読み出しますが，散発的に失敗することがあります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SR_NOT_CHECKED">
<ShortDescription>InputStream.skip() の戻り値を無視しているメソッド</ShortDescription>
<LongDescription>{1} は，{2} の戻り値を無視しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，複数バイトをスキップする可能性がある <code>java.io.InputStream.skip()</code> の戻り値を無視しています。
戻り値がチェックされないと呼び出し元は要求したバイト数よりも少ないバイト数しかスキップしなかった場合，正しく処理できません。
これは潜在的なバグで，多くのプログラムでは，入力ストリームからのスキップは，通常要求した完全なデータ量をスキップをしますが，散発的に失敗することがあります。
しかしながら，バッファードストリーム での <code>skip</code> メソッドはバッファのデータをスキップするので要求されたバイト数のスキップは常に失敗します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_READ_RESOLVE_IS_STATIC">
<ShortDescription>readResolve メソッドが static メソッドとして宣言されている</ShortDescription>
<LongDescription>{1} は，static メソッドではなく インスタンスメソッドとして宣言すべきです。</LongDescription>
<Details>
<![CDATA[
<p>
<code>readResolve</code> メソッドが直列化機構で認識されるためには <code>static</code> メソッドとして宣言してはいけません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_PRIVATE_READ_RESOLVE_NOT_INHERITED">
<ShortDescription>サブクラスで継承できない private な readResolve メソッド</ShortDescription>
<LongDescription>サブクラスで継承できない {0} の private な readResolve メソッドです。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>private</code> な <code>readResolve</code> メソッドを定義しています。
そのため，このメソッドはサブクラスで継承できません。
これが意図したことなら間違っていないかもしれませんが確認するためにレビューすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_READ_RESOLVE_MUST_RETURN_OBJECT">
<ShortDescription>readResolve メソッドの戻り値の型が Object で宣言されていない</ShortDescription>
<LongDescription>メソッド {1} の戻り値の型は {1.returnType} ではなく Object で宣言されなければなりません。</LongDescription>
<Details>
<![CDATA[
<p>
<code>readResolve</code> メソッドが直列化機構で認識されるためには戻り値の型が <code>Object</code> で宣言されなければなりません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_TRANSIENT_FIELD_OF_NONSERIALIZABLE_CLASS">
<ShortDescription>Serializable ではないクラスの transient フィールド</ShortDescription>
<LongDescription>{1.givenClass} は，transient ですが，{0} は Serializable ではありません。</LongDescription>
<Details>
<![CDATA[
<p>
フィールドは， <code>transient</code> と宣言していますが，クラスは直列化可能ではないので，まったく効果がありません。
クラスが <code>transient</code> だったときの名残かもしれません，または直列化機構を誤解しているのかもしれません。
</p>
<p><em>このバグは特殊な<tt>reportTransientFieldOfNonSerializableClass</tt>オプションが指定されたときのみ報告されます。</em></p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_TRANSIENT_FIELD_NOT_RESTORED">
<ShortDescription>直列化復元によって設定されない transient フィールド </ShortDescription>
<LongDescription>フィールド {1} は，transient なので直列化復元によって設定されません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスには複数の場所で更新されるフィールドがあります。したがって，このクラスの状態の一部だと思われます。
しかしながら，フィールドは <code>transient</code> と宣言しているので， <code>readObject</code>/<code>readResolve</code> で値が設定されません。
クラスの直列化復元されたインスタンスにはデフォルト値が設定されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_METHOD_MUST_BE_PRIVATE">
<ShortDescription>直列化機構のために private にしなければならないメソッド</ShortDescription>
<LongDescription>メソッド {1.givenClass} は，{0} の直列化/直列化復元で呼び出されるために private にしなければなりません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>Serializable</code> インタフェースを実装して，カスタム直列化/直列化復元のためのメソッドを定義しています。
しかし，そのメソッドが <code>private</code> として宣言されていないので，直列化/直列化復元 API によって無視されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_NO_SUITABLE_CONSTRUCTOR_FOR_EXTERNALIZATION">
<ShortDescription>Externalizable なクラスが引数なしコンストラクタを定義していない</ShortDescription>
<LongDescription>{0} は，Externalizable を実装していますが，引数なしコンストラクタを定義していません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>Externalizable</code> インタフェースを実装していますが，publicな引数なしコンストラクタを定義していません。
<code>Externalizable</code> オブジェクトが直列化復元されるときは，最初にpublicな引数なしコンストラクタを呼び出すことによって構築される必要があります。
このクラスにはpublicな引数なしコンストラクタがないので，直列化と直列化復元は実行時に失敗します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_NO_SUITABLE_CONSTRUCTOR">
<ShortDescription>Serializable なクラスのスーパークラスで，引数なしコンストラクタを定義していない</ShortDescription>
<LongDescription>{0} は，Serializable を実装していますが，そのスーパークラスはアクセス可能な引数なしコンストラクタを定義していません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは <code>Serializable</code> インタフェースを実装していますが，そのスーパークラスは実装していません。
そのようなオブジェクトが直列化復元されるとき，スーパークラスのフィールドはスーパークラスの引数なしコンストラクタを呼び出すことによって初期化される必要があります。
スーパークラスには引数なしコンストラクタがないので，直列化と直列化復元は実行時に失敗します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_NO_SERIALVERSIONID">
<ShortDescription>Serializable なクラスが serialVersionUID を定義していない</ShortDescription>
<LongDescription>{0} は，Serializable を実装していますが，serialVersionUID は定義していません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは <code>Serializable</code> インタフェースを実装していますが， <code>serialVersionUID</code> フィールドを定義していません。
.class オブジェクトへの参照を追加するのと同じくらい簡単な変更でクラスに合成フィールドを追加します。
それは，残念ながら暗黙の <code>serialVersionUID</code> を変えます (たとえば， <code>String.class</code> への参照を追加すると， <code>class$java$lang$String</code> という <code>static</code> フィールドを生成します)。
また，バイトコードコンパイラへの異なるソースコードは，クラスオブジェクトまたは内部クラスを参照するために生成される合成変数のために異なる命名規則を使用するかもしれません。
バージョンを横断する <code>Serializable</code> の相互運用性を保証するために明示的に <code>serialVersionUID</code> を追加することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_COMPARATOR_SHOULD_BE_SERIALIZABLE">
<ShortDescription>Comparator は Serializable を実装していない</ShortDescription>
<LongDescription>{0} は，Comparator を実装していますが，Serializable を実装していません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは <code>Comparator</code> インタフェースを実装しています。
<code>Serializable</code> インタフェースも実装する必要があるのか検討すべきです。
コンパレータが <code>TreeMap</code> のような順序付きコレクションを構築するために使われるなら，コンパレータが直列化可能な場合だけ， <code>TreeMap</code> は直列化可能です。
大部分のコンパレータがほとんど状態を持たないとしても直列化可能にすることは簡単で良い防衛的なプログラミングです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SF_SWITCH_FALLTHROUGH">
<ShortDescription>1つの case が次の case へと通り抜ける switch 文を見つけた</ShortDescription>
<LongDescription>1つの case が次の case へと通り抜ける switch 文を見つけました。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには1つの <code>case</code> が次の <code>case</code> へと通り抜ける <code>switch</code> 文があります。
通常は， <code>break</code> か <code>return</code> でこの <code>case</code> を終わらせる必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SF_SWITCH_NO_DEFAULT">
<ShortDescription>default がない switch 文を見つけた</ShortDescription>
<LongDescription>default がない switch 文を見つけました。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには <code>default</code> がない <code>switch</code> 文があります。
通常は， <code>default</code> を用意する必要があります。
</p>
<p>
解析は生成されたバイトコードを見るだけなので， <code>default</code> が <code>switch</code> 文の終わりにあって，他のケースに <code>break</code> 文が含まれていないなら誤検出のトリガーとなります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH">
<ShortDescription>switch 文のフォールスルーのために格納が無効になっている</ShortDescription>
<LongDescription>前の case からの値 {2.givenClass} が switch 文のフォールスルーのためにここで上書きされています。</LongDescription>
<Details>
<![CDATA[
<p>
前の <code>case</code> で格納された値が <code>switch</code> 文のフォールスルーのためにここで上書きされています。
前の <code>case</code> の終わりに <code>break</code> または <code>return</code> を入れるのを忘れた可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH_TO_THROW">
<ShortDescription>スローする switch 文のフォールスルーのために格納が無効になっている</ShortDescription>
<LongDescription>前の case からの値 {2.givenClass} がスローする switch 文のフォールスルーのためにここで失われています。</LongDescription>
<Details>
<![CDATA[
<p>
前の <code>case</code> で格納された値が例外がスローされる場所で， <code>switch</code> 文のフォールスルーのためにここで失われています。
前の <code>case</code> の終わりに <code>break</code> または <code>return</code> を入れるのを忘れた可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="WS_WRITEOBJECT_SYNC">
<ShortDescription>writeObject メソッドは同期化しているがその他のメソッドは同期化していないクラス</ShortDescription>
<LongDescription>{0} の writeObject メソッドは同期化していますが，その他のメソッドは同期化していません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスには同期化している <code>writeObject</code> メソッドがあります。
しかしながら，クラスのその他のメソッドは同期化していません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RS_READOBJECT_SYNC">
<ShortDescription>readObject メソッドを同期化しているクラス</ShortDescription>
<LongDescription>{0} の readObject メソッドを同期化しています。</LongDescription>
<Details>
<![CDATA[
<p>
この直列化可能クラスは同期化している <code>readObject</code> メソッド を定義しています。
直列化復元によって作成されるオブジェクトは1つのスレッドによってだけ到達可能です。
したがって， <code>readObject</code> メソッドは同期化する必要がありません。
<code>readObject</code> メソッドそのものが別のスレッドに見えるようになるオブジェクトの原因になっているなら非常に疑わしいコーディングスタイルの例です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_NONSTATIC_SERIALVERSIONID">
<ShortDescription>serialVersionUID が static ではない</ShortDescription>
<LongDescription>{1} は，static ではありません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>static</code> ではない <code>serialVersionUID</code> フィールドを定義しています。
直列化を目的としてバージョン UID を指定することを意図しているならフィールドは <code>static</code> とすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_NONFINAL_SERIALVERSIONID">
<ShortDescription>serialVersionUID が final ではない</ShortDescription>
<LongDescription>{1} は，final ではありません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>final</code> ではない <code>serialVersionUID</code> フィールドを定義しています。
直列化を目的としてバージョン UID を指定することを意図しているならフィールドは <code>final</code> とすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_NONLONG_SERIALVERSIONID">
<ShortDescription>serialVersionUID が long ではない</ShortDescription>
<LongDescription>{1} は，long ではありません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>long</code> ではない <code>serialVersionUID</code> フィールドを定義しています。
直列化を目的としてバージョン UID を指定することを意図しているならフィールドは <code>long</code> とすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_BAD_FIELD">
<ShortDescription>直列化可能クラスの非 transient で非直列化可能なインスタンスフィールド</ShortDescription>
<LongDescription>クラス {0} は，非 transient で非直列化可能なインスタンスフィールド {1.name} を定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
この直列化可能クラスは， <code>transient</code> ， <code>Serializable</code> ， <code>java.lang.Object</code> でもない非プリミティブ型のインスタンスフィールドを定義して，
<code>Externalizable</code> インタフェースまたは <code>readObject</code> メソッドと <code>writeObject</code> メソッドを実装するように見えません。
また， <code>Externalizable</code> インタフェースも実装していなくて， <code>readObject</code> メソッドも <code>writeObject</code> メソッドも定義していません。
非直列化可能オブジェクトがこのフィールドに格納されるならクラスのオブジェクトは正しく直列化復元されません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_BAD_FIELD_INNER_CLASS">
<ShortDescription>非直列化可能クラスに直列化可能な内部クラスがある</ShortDescription>
<LongDescription>{0} は，直列化可能ですが，非直列化可能クラスの内部クラスです。</LongDescription>
<Details>
<![CDATA[
<p>
この直列化可能クラスは，非直列化可能クラスの内部クラスです。
内部クラスを直列化しようとすると関連する外部クラスのインスタンスを結びつけようとするので，実行時エラーの原因になります。
</p>
<p>
できれば，内部クラスを <code>static</code> にして問題を解決すべきです。
外部クラスの直列化は動作可能かもしれませんが，内部クラスのインスタンスを直列化することは，外部クラスのインスタンスも常に直列化することを意味します。
本当に望むことですか。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_INNER_CLASS">
<ShortDescription>直列化可能な内部クラス</ShortDescription>
<LongDescription>{0} は直列化可能な内部クラスです。</LongDescription>
<Details>
<![CDATA[
<p>
この直列化可能なクラスは内部クラスです。内部クラスを直列化しようとすると関連した外部クラスのインスタンスも直列化します。
外部クラスのインスタンスは直列化可能なので失敗しません。しかし，意図していたよりももっと多くのデータを直列化するかもしれません。
できれば，内部クラスを <code>static</code> にして問題を解決すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_BAD_FIELD_STORE">
<ShortDescription>非直列化可能な値を直列化可能クラスのインスタンスフィールドに格納している</ShortDescription>
<LongDescription>非 transient フィールド {1.givenClass} に {2} を格納しています。</LongDescription>
<Details>
<![CDATA[
<p>
非直列化可能な値を直列化可能クラスの 非 <code>transient</code> フィールドに格納しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SC_START_IN_CTOR">
<ShortDescription>Thread.start() を呼び出しているコンストラクタ</ShortDescription>
<LongDescription>{1} は，{2} を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
コンストラクタがスレッドを開始しています。クラスが拡張され，サブクラスが作られるなら間違っていそうです。
なぜなら，サブクラスのコンストラクタでスレッドが開始される前にスーパークラスのスレッドが開始されてしまうためです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SS_SHOULD_BE_STATIC">
<ShortDescription>読み出されないフィールド</ShortDescription>
<LongDescription>読み出されないフィールド: {1}; このフィールドは static にすべきですか?</LongDescription>
<Details>
<![CDATA[
<p>
このクラスにはコンパイル時に静的な値に初期化されるインスタンス <code>final</code> フィールドがあります。
<code>static</code> フィールドにすることを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UUF_UNUSED_FIELD">
<ShortDescription>未使用のフィールド</ShortDescription>
<LongDescription>未使用のフィールド: {1}</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドは決して使用されません。クラスから除去することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="URF_UNREAD_FIELD">
<ShortDescription>読み出されないフィールド</ShortDescription>
<LongDescription>読み出されないフィールド: {1}</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドは決して読み出されません。クラスから除去することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UUF_UNUSED_PUBLIC_OR_PROTECTED_FIELD">
<ShortDescription>未使用の public または protected フィールド</ShortDescription>
<LongDescription>未使用の public または protected フィールド: {1}</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドは決して使用されません。
フィールドが <code>public</code> か <code>protected</code> なので，多分，それは解析の一部として見えないクラスで使用されることを意図しています。
そうでなければ，クラスから除去することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD">
<ShortDescription>読み出されない public または protected フィールド</ShortDescription>
<LongDescription>読み出されない public または protected フィールド: {1}</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドは決して読み出されません。
フィールドが <code>public</code> か <code>protected</code> なので，多分，それは解析の一部として見えないクラスで使用されることを意図しています。
そうでなければ，クラスから除去することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="QF_QUESTIONABLE_FOR_LOOP">
<ShortDescription>複雑か巧妙か間違ったインクリメントの for ループ</ShortDescription>
<LongDescription>複雑か巧妙か間違ったインクリメントの for ループです。{1} </LongDescription>
<Details>
<![CDATA[
<p>
本当にこの <code>for</code> ループが正しい変数をインクリメントしていますか？
別の変数が <code>for</code> ループによって初期化されてチェックされるように見えます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UWF_NULL_FIELD">
<ShortDescription>null に設定されるだけのフィールド</ShortDescription>
<LongDescription>null に設定されるだけのフィールド:{1}</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドに定数値 <code>null</code> を書き込みます。したがって，フィールドの読み出しは <code>null</code> を返します。
誤りをチェックしてください。役に立たないなら除去してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UWF_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">
<ShortDescription>書き込まてれいない public または protected フィールド</ShortDescription>
<LongDescription>書き込まれていない public または protected フィールド: {1}</LongDescription>
<Details>
<![CDATA[
<p>
この <code>public</code> または <code>protected</code> フィールドは書き込まれていません。このフィールドからの読み出しはデフォルト値を返します。
誤りをチェックしてください (フィールドは初期化すべきでしたか？)。役に立たないなら除去してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UWF_UNWRITTEN_FIELD">
<ShortDescription>書き込まれていないフィールド</ShortDescription>
<LongDescription>書き込まれていないフィールド: {1}</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドは決して書き込まれません。このフィールドからの読み出しはデフォルト値を返します。
誤りをチェックしてください (フィールドは初期化すべきでしたか？)。役に立たないなら除去してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ST_WRITE_TO_STATIC_FROM_INSTANCE_METHOD">
<ShortDescription>インスタンスメソッドから static フィールドへの書き込み</ShortDescription>
<LongDescription>インスタンスメソッド {1} から static フィールド {2} に書き込みをしています。</LongDescription>
<Details>
<![CDATA[
<p>
このインスタンスメソッドは， <code>static</code> フィールドに書き込みをしています。
複数のインスタンスが操作されているなら，正しくさせるのは難しいです。一般的にバッドプラクティスです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_LOAD_OF_KNOWN_NULL_VALUE">
<ShortDescription>null とわかっている値のロード</ShortDescription>
<LongDescription>null とわかっている値をロードしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ここで参照されている変数は，以前に <code>null</code> なのかチェックしているため <code>null</code> であることがわかっています。
これは有効ですが，間違いかもしれません (多分異なる変数を参照することを意図していました。あるいは，以前の <code>null</code> チェックで <code>null</code> ではないのか確かめるべきでした)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_DEREFERENCE_OF_READLINE_VALUE">
<ShortDescription>readLine メソッドの結果が null なのか確かめないで値を利用している</ShortDescription>
<LongDescription>readLine メソッドの結果が null なのか確かめないで値を利用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>readLine</code> メソッドの結果が <code>null</code> なのか確かめないで値を利用しています。
<code>readLine</code> メソッドは，それ以上読み出すテキスト行がなければ <code>null</code> を返すので， <code>NullPointerException</code> が発生します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_IMMEDIATE_DEREFERENCE_OF_READLINE">
<ShortDescription>readLine メソッドの結果をすぐに利用している</ShortDescription>
<LongDescription>readLine メソッドの結果をすぐに利用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>readLine</code> メソッドの結果をすぐに利用しています。
<code>readLine</code> メソッドは，それ以上読み出すテキスト行がなければ <code>null</code> を返すので， <code>NullPointerException</code> が発生します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_UNWRITTEN_FIELD">
<ShortDescription>書き込まれていないフィールドの読み出し</ShortDescription>
<LongDescription>書き込まれていないフィールド {2.name} を読み出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
プログラムは，決して <code>null</code> ではない値を書き込むとは思われないフィールドの値を利用しています。
フィールドが解析によって見られないメカニズムを通して初期化されないかぎり，この値を利用すると <code>NullPointerException</code> が発生します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">
<ShortDescription>書き込まれていない public または protected フィールドの読み出し</ShortDescription>
<LongDescription>書き込まれていない public または protected フィールド {2.name} を読み出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
プログラムは，決して <code>null</code> 値ではない値を書き込むと思われない <code>public</code> または <code>protected</code> フィールドの <code>null</code> 値を利用しています。
フィールドが解析によって見られないメカニズムを通して初期化されないかぎり，この値を利用すると <code>NullPointerException</code> が発生します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIC_THREADLOCAL_DEADLY_EMBRACE">
<ShortDescription>非 static 内部クラスとスレッドローカルのデッドロック</ShortDescription>
<LongDescription>{0} は，{1} とのデッドロックを回避するために static にする必要があります。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは内部クラスですが，おそらく <code>static</code> 内部クラスにすべきです。
実際には内部クラスと外部クラスのスレッドローカルとの間にデッドロックの深刻な危険性があります。
内部クラスが <code>static</code> ではないので，外部クラスへの参照を保持します。
スレッドローカルに内部クラスのインスタンスの参照があるなら，内部と外部のインスタンスの両方が到達可能になり，ガベージされません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIC_INNER_SHOULD_BE_STATIC">
<ShortDescription>static 内部クラスにすべき</ShortDescription>
<LongDescription>{0} は，static 内部クラスにすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは内部クラスなのにそれを作成したオブジェクトへの埋め込まれた参照を使用していません。
この参照はより大きなクラスのインスタンスを作成して，不必要に作成オブジェクトへの参照を存続しておくことがあります。
できれば，クラスは <code>static</code> にすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">
<ShortDescription>コンストラクタで初期化されていないフィールドを null チェックなしで null 値を利用している</ShortDescription>
<LongDescription>{1.givenClass} は，コンストラクタで初期化されません。{2} で null 値を利用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドは，どんなコンストラクタの中でも決して初期化されません。したがって，オブジェクトが構築された後， <code>null</code> である可能性があります。
どこかほかで，値がロードされて， <code>null</code> チェックなしで <code>null</code> 値が利用されます。
フィールドが初期化される前に利用されると <code>NullPointerException</code> が発生するので，誤りか疑わしい設計かもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIC_INNER_SHOULD_BE_STATIC_ANON">
<ShortDescription>名前付き static 内部クラスにリファクタリングできるかもしれない</ShortDescription>
<LongDescription>クラス {0} は，名前付き static 内部クラスにリファクタリングできるかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは内部クラスなのにそれを作成したオブジェクトへの埋め込まれた参照を使用していません。
この参照はより大きなクラスのインスタンスを作成して，不必要に作成オブジェクトへの参照を存続しておくことがあります。
できれば，クラスは <code>static</code> 内部クラスにすべきです。
無名内部クラスは <code>static</code> にできないので，名前付き内部クラスにリファクタリングする必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS">
<ShortDescription>static 内部クラスにリファクタリングできるかもしれない</ShortDescription>
<LongDescription>クラス {0} は，static 内部クラスにリファクタリングできるかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは内部クラスなのにそれを作成したオブジェクトへの埋め込まれた参照を使用していません。
この参照はより大きなクラスのインスタンスを作成して，不必要に長く作成オブジェクトへの参照を存続しておくかもしれません。
できれば，クラスは <code>static</code> 内部クラスにすべきです。
外部オブジェクトへの参照が内部クラスのインスタンスを構築する間必要なので内部クラスのコンストラクタに外部インスタンスへの参照を渡すようにリファクタリングする必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="WA_NOT_IN_LOOP">
<ShortDescription>wait メソッドがループの中にない</ShortDescription>
<LongDescription>wait メソッドがループの中にありません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，ループの中にない <code>java.lang.Object.wait()</code> を呼び出しています。
モニタが複数の条件のために使われるなら，呼び出し元が待機するつもりだった条件は実際には発生しないかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="WA_AWAIT_NOT_IN_LOOP">
<ShortDescription>Condition.await() がループの中にない</ShortDescription>
<LongDescription>Condition.await() がループの中にありません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，ループの中にない <code>java.util.concurrent.await()</code> (またはそのバリエーション) を呼び出しています。
オブジェクトが複数の条件のために使われるなら，呼び出し元が待機するつもりだった条件は実際には発生しないかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NO_NOTIFY_NOT_NOTIFYALL">
<ShortDescription>notifyAll メソッドではなく notify メソッドを使用している</ShortDescription>
<LongDescription>notifyAll メソッドではなく notify メソッドを使用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>notifyAll</code> メソッドではなく <code>notify</code> メソッドを呼び出しています。
モニターは，複数の条件で使われることがよくあります。
<code>notify</code> メソッドの呼び出しは1つのスレッドを起こすだけで起こされたスレッドは呼び出し元が満たした待機条件の1つではないかもしれないことを意味しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UC_USELESS_VOID_METHOD">
<ShortDescription>役に立たない空ではない void メソッド</ShortDescription>
<LongDescription>メソッド {1} は，役に立たないようです。</LongDescription>
<Details>
<![CDATA[
<p>
我々の解析は，この空ではない <code>void</code> メソッドが実際に有用な仕事を行わないことを示しています。
確認してください。おそらくそのコードが間違っているか，またはボディを完全に除去できます。
</p>
<p>
我々はできる限り誤検出を減らそうと努力しているが，いくつかのケースでは警告は間違っているかもしれません。
よくある誤検出例です。
</p>
<ul>
<li>メソッドは，副作用を持つかもしれないクラスのロードをトリガーすることを意図している</li>
<li>メソッドは，暗黙のわかりにくい例外をスローするように意図されている</li>
</ul>
]]>
</Details>
</BugPattern>
<BugPattern type="UC_USELESS_CONDITION">
<ShortDescription>条件は効果がない</ShortDescription>
<LongDescription>役に立たない条件: この時点 {2} で知られています。</LongDescription>
<Details>
<![CDATA[
<p>
この条件は前に絞られた関係している変数の値と同じ結果を常に作り出します。
おそらく何かほかのことを意味していたのか，あるいは条件を除去できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UC_USELESS_CONDITION_TYPE">
<ShortDescription>条件は変数型のために効果がない</ShortDescription>
<LongDescription>役に立たない条件: 変数型が {3} なので，常に {2} です。</LongDescription>
<Details>
<![CDATA[
<p>
この条件は関係している変数の型範囲のために同じ結果を常に作り出します。
おそらく何かほかのことを意味していたのか，あるいは条件を除去できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UC_USELESS_OBJECT">
<ShortDescription>役に立たないオブジェクトを作成した</ShortDescription>
<LongDescription>役に立たないオブジェクトをメソッド {1} の変数 {2} で格納しました。</LongDescription>
<Details>
<![CDATA[
<p>
我々の解析でオブジェクトが役に立たないことを示しています。
作成され，変更されていますが，値はメソッドの外に出ないし，副作用をもたらしません。
間違いかオブジェクトが使われることを意図していたかのどちらか，あるいは除去できます。
</p>
<p>
この解析はめったに誤検出することはありません。よくある誤検出のケースです。
</p>
<ul>
<li>暗黙のうちに曖昧な例外をスローした</li>
<li>コードを一般化してスタブとして使用された</li>
<li>弱/ソフト参照オブジェクトへの強い参照を持っていた</li>
</ul>
]]>
</Details>
</BugPattern>
<BugPattern type="UC_USELESS_OBJECT_STACK">
<ShortDescription>役に立たないオブジェクトをスタックで作成した</ShortDescription>
<LongDescription>役に立たないオブジェクトをメソッド {1} で作成しました。</LongDescription>
<Details>
<![CDATA[
<p>
このオブジェクトは副作用を持たない変更を行うために作成されています。
おそらく何かほかのことを意味していたのか，あるいはオブジェクトを除去できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RANGE_ARRAY_INDEX">
<ShortDescription>配列インデックスは範囲外</ShortDescription>
<LongDescription>配列インデックスは範囲外です: {3}</LongDescription>
<Details>
<![CDATA[
<p>
配列操作が行なわれていますが，配列インデックスが範囲外なので実行時に <code>ArrayIndexOutOfBoundsException</code> が発生するでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RANGE_ARRAY_OFFSET">
<ShortDescription>配列オフセットは範囲外</ShortDescription>
<LongDescription>配列オフセットは範囲外です: {3}</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，配列パラメータとオフセットパラメータで呼び出されていますが，オフセットは範囲外です。
実行時に <code>IndexOutOfBoundsException</code> が発生するでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RANGE_ARRAY_LENGTH">
<ShortDescription>配列の長さは範囲外</ShortDescription>
<LongDescription>配列の長さは範囲外です: {3}</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，配列パラメータと長さパラメータで呼び出されていますが，長さは範囲外です。
実行時に <code>IndexOutOfBoundsException</code> が発生するでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RANGE_STRING_INDEX">
<ShortDescription>文字列インデックスは範囲外</ShortDescription>
<LongDescription>文字列インデックスは {5} を呼び出すときに範囲外です: {3}</LongDescription>
<Details>
<![CDATA[
<p>
文字列メソッドが呼び出されていますが，指定された文字列インデックスは範囲外です。
実行時に <code>StringIndexOutOfBoundsException</code> が発生するでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_CHECK_FOR_POSITIVE_INDEXOF">
<ShortDescription>String.indexOf の結果が正かどうか確かめている</ShortDescription>
<LongDescription>String.indexOf の結果が正かどうか確かめています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは <code>String.indexOf</code> を呼び出して結果が正かどうか確かめています。
結果が負かどうか確かめるほうがはるかに一般的です。チェックされる部分文字列が <code>String</code> の先頭以外の場所で出現するときだけ正になります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_DONT_JUST_NULL_CHECK_READLINE">
<ShortDescription>readLine メソッドの結果を null ではないのか確かめた後で捨てている</ShortDescription>
<LongDescription>{1} は，readLine メソッドの結果を null ではないのか確かめた後で捨てています。</LongDescription>
<Details>
<![CDATA[
<p>
<code>readLine</code> メソッドの戻り値を <code>null</code> ではないのか確かめた後で捨てています。
ほとんどすべての状況で，結果が <code>null</code> ではないなら戻り値を使用したいでしょう。
再び <code>readLine</code> メソッドを呼び出すと異なる行が得られます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_RETURN_VALUE_IGNORED_INFERRED">
<ShortDescription>メソッドは戻り値を無視しています。これは間違いではないですか?</ShortDescription>
<LongDescription>{2.givenClass} の戻り値を無視しています，これは間違いではないですか? {1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはメソッドを呼び出して，戻り値を無視しています。
戻り値は，メソッドが呼び出される型と同じ型です。そして，我々の解析から戻り値が重要であるかもしれないように見えます （たとえば， <code>String.toLowerCase()</code> の戻り値を無視するような）。
</p>
<p>
我々は，戻り値を無視することがメソッド本体の単純な解析から悪い考えかもしれないと推測しています。
このメソッドの戻り値を無視することが重要であるか許容できるかどうかに関して，SpotBugs に指示する <code>@CheckReturnValue</code> アノテーションが使えます。
</p>
<p>
戻り値を無視することが間違いではないか決めるために厳密に調査してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_RETURN_VALUE_IGNORED_NO_SIDE_EFFECT">
<ShortDescription>副作用がないメソッドの戻り値は無視される</ShortDescription>
<LongDescription>副作用がない {2.givenClass} の戻り値は無視されます。</LongDescription>
<Details>
<![CDATA[
<p>
このコードはメソッドを呼び出して戻り値を無視しています。
しかしながら，解析はメソッド (もしあればサブクラスの実装も含む) が戻り値以外の効果をもたらさないことを示しています。
この呼び出しは除去できます。
</p>
<p>
我々は，できる限り誤検出を減らそうとしていますが，いくつかのケースではこの警告が間違っているかもしれません。
よくある誤検出です。
</p>
<ul>
<li>メソッドは，オーバライドされ解析対象外の他のプロジェクトで副作用がもたらされるように設計されている</li>
<li>メソッドは，副作用をもたらすかもしれないクラスローダをトリガーするように呼び出されている</li>
<li>メソッドは，例外を取得するために呼び出されている</li>
</ul>
<p>
我々の仮定が正しくないと感じるなら，SpotBugs にこのメソッドの戻り値が無視されることを許容するように指示する <code>@CheckReturnValue</code> アノテーションを使用することができます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_RETURN_VALUE_IGNORED">
<ShortDescription>戻り値を無視しているメソッド</ShortDescription>
<LongDescription>{2.givenClass} の戻り値を無視しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドの戻り値はチェックすべきです。
この警告の共通の原因は，オブジェクトが更新されると思って不変オブジェクトのメソッドを呼び出すことです。<br>
たとえば次のようなコードです。
</p>
<pre><code>String dateString = getHeaderField(name);
dateString.trim();
</code></pre>
<p>
プログラマは， <code>trim</code> メソッドが <code>dateString</code> によって参照される <code>String</code> オブジェクトが更新されると思っています。
しかし， <code>String</code> オブジェクトは不変で， <code>trim</code> メソッドが新しい <code>String</code> オブジェクトを返すのに無視しています。
このコードは次のように修正すべきです。
</p>
<pre><code>String dateString = getHeaderField(name);
dateString = dateString.trim();
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_RETURN_VALUE_IGNORED_BAD_PRACTICE">
<ShortDescription>例外的戻り値を無視しているメソッド</ShortDescription>
<LongDescription>{2} の例外的戻り値を無視しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドはチェックされていない値を返しています。
戻り値は異常か予想外の実行結果を示す可能性があるのでチェックすべきです。
たとえば， <code>File.delete()</code> はファイルをうまく削除できなかったなら，例外をスローするのではなく <code>false</code> を返します。
結果をチェックしないなら例外的戻り値を返すメソッドの呼び出しで予想外の振る舞いの合図に気づきません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_CHECK_COMPARETO_FOR_SPECIFIC_RETURN_VALUE">
<ShortDescription>compareTo によって返された特定の値のコードチェック</ShortDescription>
<LongDescription>{2.givenClass} の戻り値が {3} と等しいか確かめてください。</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>compareTo</code> または <code>compare</code> メソッドを呼び出して，戻り値が特定の値（たとえば1または-1） なのか確かめています。
これらのメソッドを呼び出すときは特定のゼロ以外の値ではなく，結果の符号だけをチェックすべきです。
多数または大部分の <code>compareTo</code> と比較メソッドは-1，0または1を返しますが，いくつかは他の値を返します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_EXCEPTION_NOT_THROWN">
<ShortDescription>作成した例外をスローするのではなく捨てている</ShortDescription>
<LongDescription>{2.givenClass} をスローしていません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは例外 (またはエラー) オブジェクトを作成していますが，何もしていません。<br>
たとえば次のようなコードです。
</p>
<pre><code>if (x < 0) {
new IllegalArgumentException("x must be nonnegative");
}
</code></pre>
<p>
おそらくプログラマの意図は，作成した例外をスローすることでした。
</p>
<pre><code>if (x < 0) {
throw new IllegalArgumentException("x must be nonnegative");
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_ALWAYS_NULL">
<ShortDescription>null 値を利用している</ShortDescription>
<LongDescription>{2.givenClass} の null 値を利用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ここで <code>null</code> 値を利用しようとしています。
コードが実行されると <code>NullPointerException</code> が発生します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_CLOSING_NULL">
<ShortDescription>常に null 値のオブジェクトで close メソッドを呼び出している</ShortDescription>
<LongDescription>常に null なので {2.givenClass} をクローズできません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>close</code> メソッドは，常に <code>null</code> 値のオブジェクトで呼び出されています。
この文が実行されるなら <code>NullPointerException</code> が発生します。
ここでクローズすべき何かを決してクローズしないという大きな危険性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_STORE_INTO_NONNULL_FIELD">
<ShortDescription>@Nonnull アノテーションが付けられたフィールドに null を格納している</ShortDescription>
<LongDescription>@Nonnull アノテーションが付けられたフィールド {2.givenClass} に null を格納しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>@Nonnull</code> アノテーションが付けられたフィールドに <code>null</code> かもしれない値を格納しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_ALWAYS_NULL_EXCEPTION">
<ShortDescription>null 値を例外経路で利用している</ShortDescription>
<LongDescription>{2.givenClass} の null 値を例外経路で利用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
例外経路上のここで <code>null</code> 値を利用しています。コードが実行されると <code>NullPointerException</code> が発生します。
現在の SpotBugs は実行不可能な例外経路を刈り取れていないので，誤検出かもしれないことに注意してください。
</p>
<p>
<code>switch</code> 文の <code>default</code> が多くの場合実行不可能なので SpotBugs が例外経路である <code>default</code> を検討することに注意して下さい。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_PARAMETER_MUST_BE_NONNULL_BUT_MARKED_AS_NULLABLE">
<ShortDescription>パラメータは 非 null でなければならないが null 可能としてマークされている</ShortDescription>
<LongDescription>{2} は，非 null でなければならないが null 可能としてマークされています。</LongDescription>
<Details>
<![CDATA[
<p>
このパラメータは，常に 非 <code>null</code> にすることを要求する方法で使われていますが，パラメータには明示的に <code>Nullable</code> アノテーションが付けられています。
パラメータかアノテーションのどちらかの使い方が間違っています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_ON_SOME_PATH">
<ShortDescription>null 値を利用している可能性がある</ShortDescription>
<LongDescription>{2.givenClass} の null 値を利用している可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
そこで分岐または文が実行されるなら <code>null</code> 値が利用されて <code>NullPointerException</code> が発生します。
もちろん，問題は分岐または文が実行不可能で， <code>NullPointerException</code> が決して発生する可能性がないということかもしれません。
それを決めるのは SpotBugs の能力を超えています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_ON_SOME_PATH_MIGHT_BE_INFEASIBLE">
<ShortDescription>null 値を実行不可能かもしれない分岐で利用している可能性がある</ShortDescription>
<LongDescription>{2.givenClass} の null 値を実行不可能かもしれない分岐で利用している可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
そこで分岐または文が実行されるなら， <code>null</code> 値が利用されて <code>NullPointerException</code> が発生します。
もちろん，問題は分岐または文が実行不可能で， <code>NullPointerException</code> が決して発生する可能性がないということかもしれません。
それを決めるのは SpotBugs の能力を超えています。
この値が既に <code>null</code> であることを検査したという事実からこれは明確な可能性です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_ON_SOME_PATH_EXCEPTION">
<ShortDescription>null 値を例外経路で利用している可能性がある</ShortDescription>
<LongDescription>{2.givenClass} の null 値を例外経路で利用している可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
例外経路上のここで <code>null</code> 値が利用されています。コードが実行されると <code>NullPointerException</code> を引き起こすことがあります。
現在の SpotBugs は実行不可能な例外経路を刈り取れていないので，誤検出かもしれないことに注意してください。
</p>
<p>
<code>switch</code> 文の <code>default</code> が多くの場合実行不可能なので SpotBugs が例外経路である <code>default</code> を検討することに注意して下さい。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE">
<ShortDescription>null になっている可能性があるメソッドの戻り値を利用している</ShortDescription>
<LongDescription>null になっている可能性があるメソッドの戻り値を利用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
メソッドからの戻り値を <code>null</code> チェックしないで利用しています。メソッドの戻り値は <code>null</code> なのかチェックすべきです。
コードが実行されると <code>NullPointerException</code> を引き起こすことがあります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_PARAM_DEREF_NONVIRTUAL">
<ShortDescription>非 null パラメータに null を渡している非仮想メソッドの呼び出し</ShortDescription>
<LongDescription>非仮想メソッド {2.givenClass} の 非 null パラメータに null を渡して呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>null</code> の可能性がある値が 非 <code>null</code> メソッドパラメータに渡されています。
パラメータは，常に非 <code>null</code> とすべきパラメータとしてアノテーションが付けられていたか，解析が常に <code>null</code> 値を利用することを示していました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_PARAM_DEREF_ALL_TARGETS_DANGEROUS">
<ShortDescription>メソッド呼び出しは非 null パラメータに null を渡している</ShortDescription>
<LongDescription>{2.givenClass} の 非 null パラメータに null を渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
すべての既知のターゲットメソッドが非 <code>null</code> であることをパラメータに要求する呼び出し場所で，おそらく <code>null</code> 値を渡しています。
パラメータは，常に非 <code>null</code> とすべきパラメータとしてアノテーションが付けられていたか，解析が常に <code>null</code> 値を利用することを示していました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_PARAM_DEREF">
<ShortDescription>メソッド呼び出しは非 null パラメータに null を渡している</ShortDescription>
<LongDescription>{2.givenClass} の 非 null パラメータに null を渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッド呼び出しは非 <code>null</code> メソッドパラメータに <code>null</code> 値を渡しています。
パラメータは，常に非 <code>null</code> とすべきパラメータとしてアノテーションが付けられていたか，解析が常に <code>null</code> 値を利用することを示していました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NONNULL_PARAM_VIOLATION">
<ShortDescription>メソッド呼び出しは非 null パラメータに null を渡している</ShortDescription>
<LongDescription>{2.givenClass} の 非 null パラメータに null を渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，非 <code>null</code> でなければならないメソッドのパラメータとして <code>null</code> 値を渡しています。
このパラメータは，明示的に <code>@Nonnull</code> アノテーションが付けられていたか，解析が常に <code>null</code> 値を利用することを示していました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NONNULL_RETURN_VIOLATION">
<ShortDescription>null を返すかもしれないメソッドが @Nonnull 宣言されている</ShortDescription>
<LongDescription>{1} は，null を返すかもしれないのに @Nonnull 宣言されています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>null</code> 値を返すかもしれないのにメソッド (またはスーパークラスのメソッド) の戻り値に <code>@Nonnull</code> が宣言されています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_CLONE_COULD_RETURN_NULL">
<ShortDescription>null を返すかもしれない clone メソッド</ShortDescription>
<LongDescription>{1} は，null を返すかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>clone</code> メソッドは，いくつかの条件で <code>null</code> を返すと思われます。
しかし， <code>clone</code> メソッドは決して <code>null</code> を返すのは許されません。
この経路が到達できないことを確信しているなら，代わりに <code>AssertionError</code> をスローしてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_TOSTRING_COULD_RETURN_NULL">
<ShortDescription>null を返すかもしれない toString メソッド</ShortDescription>
<LongDescription>{1} は，null を返すかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>toString</code> メソッドは，いくつかの条件で <code>null</code> を返すと思われます。
仕様を寛大に読むとこれが許されると解釈できるかもしれませんが，それはおそらく間違った考えで，他のコードが壊れる原因になる可能性があります。
<code>null</code> ではなく空の文字列，または，いくつかの他の適切な文字列を返してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_GUARANTEED_DEREF">
<ShortDescription>null 値を利用することが保証されている</ShortDescription>
<LongDescription>{2.givenClass} は，null 値を利用することが保証されています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
文または分岐が実行されるなら，この時点で値は <code>null</code> であり， <code>null</code> 値を利用する ことが保証されています (実行時例外を含むフォワードパスを除く)。
</p>
<p>
なお， <code>if (x == null) throw new NullPointerException();</code> は <code>x</code> の参照解除として扱われることに注意して下さい。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_GUARANTEED_DEREF_ON_EXCEPTION_PATH">
<ShortDescription>null 値を例外経路で利用することが保証されている</ShortDescription>
<LongDescription>{2.name} は，例外経路で null 値を利用することが保証されています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
例外経路上の文または分岐が実行されるなら，この時点で値は <code>null</code> であり， <code>null</code> 値を利用することが保証されています (実行時例外を含むフォワードパスを除く)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SI_INSTANCE_BEFORE_FINALS_ASSIGNED">
<ShortDescription>スタティックイニシャライザは，すべての static final フィールドが代入される前にインスタンスを作成する</ShortDescription>
<LongDescription>{0} のためのスタティックイニシャライザは，すべての static final フィールドが代入される前にインスタンスを作成します。</LongDescription>
<Details>
<![CDATA[
<p>
すべての <code>static final</code> フィールドが初期化される前にスタティックイニシャライザがクラスのインスタンスを作成します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="OS_OPEN_STREAM">
<ShortDescription>ストリームのクローズに失敗するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，ストリームのクローズに失敗するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，入出力ストリームオブジェクトを作成していますが，任意のフィールドに割り当てたり，クローズする可能性のある別のメソッドに渡したり，返すことはなく，メソッドからのすべての経路でクローズするように見えません。
これはファイルディスクリプタリークの原因になることがあります。
ストリームがクローズされることを確実にするために <code>finally</code> ブロックを使用することは一般的に良い考えです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="OS_OPEN_STREAM_EXCEPTION_PATH">
<ShortDescription>例外経路でストリームのクローズに失敗するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，例外経路でストリームのクローズに失敗するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，入出力ストリームオブジェクトを作成していますが，任意のフィールドに割り当てたり，クローズする可能性のある別のメソッドに渡したり，返すことはなく，メソッドからのすべての例外経路でクローズするように見えません。
これはファイルディスクリプターリークの原因になることがあります。
ストリームがクローズされることを確実にするために <code>finally</code> ブロックを使用することは一般的に良い考えです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="PZLA_PREFER_ZERO_LENGTH_ARRAYS">
<ShortDescription>null ではなく長さが0の配列を返すことを検討する</ShortDescription>
<LongDescription>{1} は，null ではなく長さが0の配列を返すべきではありませんか？</LongDescription>
<Details>
<![CDATA[
<p>
結果がないこと (すなわち，結果の空のリスト) を示すために <code>null</code> 参照ではなく長さが0の配列 を返すことは，多くの場合より良い設計です。
このように，メソッドのクライアントは明示的に <code>null</code> チェックをする必要はありません。
</p>
<p>
一方，「この質問に対する答えがない」ことを示すために <code>null</code> を使用することはおそらく適切です。
たとえば， <code>File.listFiles()</code> は，ファイルがないディレクトリを与えられた場合は空のリストを返し，ファイルがディレクトリではないなら <code>null</code> を返します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UCF_USELESS_CONTROL_FLOW">
<ShortDescription>役に立たない制御フロー</ShortDescription>
<LongDescription>役に立たない制御フローです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには分岐するのかどうかに関係なく，制御フローが同じ場所へと続く，役に立たない制御フロー文があります。<br>
たとえば，これは 空の <code>if</code> 文が原因になります。
</p>
<pre><code>if (argv.length == 0) {
// TODO: handle this case
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="UCF_USELESS_CONTROL_FLOW_NEXT_LINE">
<ShortDescription>次の行へ続くだけの役に立たない制御フロー</ShortDescription>
<LongDescription>次の行に続くだけの役に立たない制御フローです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには分岐するのかどうかに関係なく，制御フローが同じか次の行へと続く，役に立たない制御フロー文があります。<br>
多くの場合，不注意に <code>if</code> 文の本体を空文を使用したことが原因になります。
</p>
<pre><code>if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE">
<ShortDescription>既に利用していた値の null チェック</ShortDescription>
<LongDescription>既に利用していた {2.givenClass} の値を {4.lineNumber} で null チェックしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ここで値が <code>null</code> なのかチェックしていますが，既に値を利用していたので <code>null</code> である可能性はありません。
値が <code>null</code> なら以前の利用で <code>NullPointerException</code> が発生していたでしょう。
基本的に，値が <code>null</code> であることを許すのかどうかに関係なく，このコードと以前の値の利用は一致しません。
チェックは冗長か，または以前の値の利用は誤りです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE">
<ShortDescription>null とわかっている値の冗長な null チェック</ShortDescription>
<LongDescription>null とわかっている値 {2} の冗長な null チェックがあります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには <code>null</code> とわかっている値の冗長な <code>null</code> チェックがあります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE">
<ShortDescription>null ではないことがわかっている値の冗長な null チェック</ShortDescription>
<LongDescription>null ではないことがわかっている値 {2} の冗長な null チェックがあります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには <code>null</code> ではないことがわかっている値の冗長な <code>null</code> チェックがあります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES">
<ShortDescription>2つの null 値の冗長な比較</ShortDescription>
<LongDescription>2つの null 値の冗長な比較があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには両方とも明らかに <code>null</code> とわかっている2つの参照の冗長な比較があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_COMPARISON_OF_NULL_AND_NONNULL_VALUE">
<ShortDescription>非 null 値と null 値との冗長な比較</ShortDescription>
<LongDescription>非 null 値と null 値との冗長な比較があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには <code>null</code> ではないことがわかっている参照と <code>null</code> とわかっている別の参照との比較があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_CHECKED_NULL_COMPARISON" deprecated="true"> <!-- deprecated in favor of two separate RCN_ patterns -->
<ShortDescription>Redundant comparison to null of previously checked value</ShortDescription>
<LongDescription>Redundant comparison to null of previously checked {2} in {1}</LongDescription>
<Details>
<![CDATA[
<p> This method contains a redundant comparison of a reference value
to null. Two types of redundant comparison are reported:
</p>
<ul>
<li> Both values compared are definitely null</li>
<li> One value is definitely null and the other is definitely not null</li>
</ul>
<p> This particular warning generally indicates that a
value known not to be null was checked against null.
While the check is not necessary, it may simply be a case
of defensive programming.</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UL_UNRELEASED_LOCK">
<ShortDescription>すべての経路でロックが解除されないメソッド</ShortDescription>
<LongDescription>{1} は，すべての経路でロックが解除されません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，JSR-166(java.util.concurrent) のロックを獲得していますが，メソッドからのすべての経路で解除していません。
一般的に JSR-166 のロックを使用するための正しいイディオムは次のようになります。
</p>
<pre><code>Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="UL_UNRELEASED_LOCK_EXCEPTION_PATH">
<ShortDescription>すべての例外経路でロックが解除されないメソッド</ShortDescription>
<LongDescription>{1} は，すべての例外経路でロックが解除されません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，JSR-166(java.util.concurrent) のロックを獲得していますが，メソッドからのすべての例外経路で解除していません。
一般的に JSR-166 のロックを使用するための正しいイディオムは次のようになります。
</p>
<pre><code>Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="RC_REF_COMPARISON">
<ShortDescription>疑わしい参照比較</ShortDescription>
<LongDescription>{2} の参照比較は疑わしいです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>==</code> または <code>!=</code> 演算子を使用して2つの参照値を比較しています。
一般的にこの型のインスタンスを比較する正しい方法は <code>equals</code> メソッドです。
等価で識別可能なインスタンスを作成する可能性がありますが異なるオブジェクトなので <code>==</code> で比較しないでください。
一般的に参照によって比較されるべきではないクラスの例は， <code>java.lang.Integer</code> ， <code>java.lang.Float</code> などです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RC_REF_COMPARISON_BAD_PRACTICE">
<ShortDescription>定数の疑わしい参照比較</ShortDescription>
<LongDescription>{2} 定数の参照比較は疑わしいです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，参照値を <code>==</code> または <code>!=</code> 演算子を使用して定数と比較しています。
一般的にこの型のインスタンスを比較する正しい方法は <code>equals</code> メソッドです。
等価で識別可能なインスタンスを作成する可能性がありますが異なるオブジェクトなので <code>==</code> で比較しないでください。
一般的に参照によって比較されるべきではないクラスの例は， <code>java.lang.Integer</code> ， <code>java.lang.Float</code> などです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RC_REF_COMPARISON_BAD_PRACTICE_BOOLEAN">
<ShortDescription>Boolean 値の疑わしい参照比較</ShortDescription>
<LongDescription>Boolean 値の疑わしい参照比較です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>==</code> または <code>!=</code> 演算子を使用して2つの <code>Boolean</code> 値を比較しています。
一般的には2つの <code>Boolean</code> 値 (<code>Boolean.TRUE</code> と <code>Boolean.FALSE</code>) だけですが，
<code>new Boolean(b)</code> コンストラクタを使用して他の <code>Boolean</code> オブジェクトを作成する可能性があります。
そのようなオブジェクトを回避することは最高です。
しかし，それらが存在するなら， <code>Boolean</code> オブジェクトの等価性をチェックするために <code>.equals(...)</code> ではなく <code>==</code> または <code>!=</code> を使用しているなら異なる結果をもたらします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EC_UNRELATED_TYPES_USING_POINTER_EQUALITY">
<ShortDescription>参照等価性を使用して異なる型を比較している</ShortDescription>
<LongDescription>{2.givenClass} を {3.givenClass} と比較するために参照等価性を使用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは異なる型と思われる2つの参照を比較するために参照等価性を使用しています。
この比較の結果は，常に <code>false</code> です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EC_UNRELATED_TYPES">
<ShortDescription>equals メソッドを呼び出して異なる型を比較している</ShortDescription>
<LongDescription>{3.simpleClass}.equals({2.simpleClass}) を呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，異なるクラス型の2つの参照で <code>equals(Object)</code> メソッドを呼び出していて，解析が実行時に異なるクラスのオブジェクトになることを示唆しています。
さらに，呼び出されるであろう <code>equals</code> メソッドの検査では，この呼び出しは常に <code>false</code> を返します。
あるいは， <code>equals</code> メソッドが対称 (<code>Object</code> クラスの <code>equals</code> のための契約に必要な性質) ではないことのどちらかを示唆しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EC_UNRELATED_INTERFACES">
<ShortDescription>equals メソッドを呼び出して異なる型のインタフェースを比較している</ShortDescription>
<LongDescription>{3.simpleClass}.equals({2.simpleClass}) を呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，どちらも他方のサブタイプではない無関係なインタフェース型の2つの参照で <code>equals(Object)</code> メソッドを呼び出しています。
そして，両方のインタフェースを実装する既知の非抽象クラスがありません。
したがって比較されている2つのオブジェクトは実行時に同じクラスのメンバである可能性が低いです (いくつかのアプリケーションクラスが解析できなかったか，動的クラスローディングが実行時に起こることができた場合を除く)。
<code>equals</code> メソッドの規約によると，異なるクラスのオブジェクトは常に等しくないとして比較すべきです。
したがって， <code>java.lang.Object.equals(Object)</code> によって定義される規約によれば，この比較の結果は実行時に常に <code>false</code> になります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EC_UNRELATED_CLASS_AND_INTERFACE">
<ShortDescription>equals メソッドを呼び出して無関係のクラスとインタフェースを比較している</ShortDescription>
<LongDescription>{3.simpleClass}.equals({2.simpleClass}) を呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，一方がクラスで他方がインタフェースである2つの参照で <code>equals(Object)</code> メソッドを呼び出しています。
クラスは，そのクラスの非抽象サブクラスも含めてインタフェースを実装していません。
したがって比較されている2つのオブジェクトは実行時に同じクラスのメンバである可能性が低いです (いくつかのアプリケーションクラスが解析できなかったか，動的クラスローディングが実行時に起こることができた場合を除く)。
<code>equals</code> メソッドの規約によると，異なるクラスのオブジェクトは常に等しくないとして比較すべきです。
したがって， <code>java.lang.Object.equals(Object)</code> によって定義される規約によれば，この比較の結果は実行時に常に <code>false</code> になります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EC_NULL_ARG">
<ShortDescription>equals(null) の呼び出し</ShortDescription>
<LongDescription>equals(null) の呼び出し。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>null</code> 値の引数を渡して <code>equals(Object)</code> を呼び出しています。
<code>equals</code> メソッドの規約によると，この呼び出しは常に <code>false</code> を返すはずです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MWN_MISMATCHED_WAIT">
<ShortDescription>不整合な wait メソッド</ShortDescription>
<LongDescription>不整合な wait メソッドです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，オブジェクトで明らかにロックを保持することなく， <code>Object.wait()</code> を呼び出しています。
保持されるロックがない状態で， <code>wait</code> メソッドを呼び出すことは， <code>IllegalMonitorStateException</code> をスローすることになります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MWN_MISMATCHED_NOTIFY">
<ShortDescription>不整合な notify メソッド</ShortDescription>
<LongDescription>不整合な notify メソッドです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，オブジェクトで明らかにロックを保持することなく <code>Object.notify()</code> や <code>Object.notifyAll()</code> を呼び出しています。
保持されるロックがない状態で， <code>notify</code> メソッドや <code>notifyAll</code> メソッドを呼び出すことは， <code>IllegalMonitorStateException</code> をスローすることになります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_LOCAL_SELF_ASSIGNMENT_INSTEAD_OF_FIELD">
<ShortDescription>フィールドへの代入ではなくローカル変数への自己代入</ShortDescription>
<LongDescription>フィールドへの代入ではなく，{2} の自己代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドにはローカル変数の自己代入があり，ローカル変数とフィールドが同じ名前です。<br>
たとえば次のようなコードです。
</p>
<pre><code> int foo;
public void setFoo(int foo) {
foo = foo;
}
</code></pre>
<p>
そのような代入は役に立ちません。そうではなく，フィールドに代入するつもりでしたか？
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_LOCAL_SELF_ASSIGNMENT">
<ShortDescription>ローカル変数の自己代入</ShortDescription>
<LongDescription>{2} の自己代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドにはローカル変数の自己代入があります。<br>
たとえば次のようなコードです。
</p>
<pre><code>public void foo() {
int x = 3;
x = x;
}
</code></pre>
<p>
そのような代入は役に立たないので，論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_FIELD_SELF_ASSIGNMENT">
<ShortDescription>フィールドの自己代入</ShortDescription>
<LongDescription>フィールド {2.givenClass} の自己代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドにはフィールドの自己代入があります。<br>
たとえば次のようなコードです。
</p>
<pre><code>int x;
public void foo() {
x = x;
}
</code></pre>
<p>
そのような代入は役に立たないので，論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_FIELD_DOUBLE_ASSIGNMENT">
<ShortDescription>フィールドの二重代入</ShortDescription>
<LongDescription>フィールド {2.givenClass} の二重代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドにはフィールドの二重代入があります。<br>
たとえば次のようなコードです。
</p>
<pre><code>int x,y;
public void foo() {
x = x = 17;
}
</code></pre>
<p>
フィールドに2回代入することは役に立たないので，論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_LOCAL_DOUBLE_ASSIGNMENT">
<ShortDescription>ローカル変数の二重代入</ShortDescription>
<LongDescription>ローカル変数 {2} の二重代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドにはローカル変数の二重代入があります。<br>
たとえば次のようなコードです。
</p>
<pre><code>public void foo() {
int x,y;
x = x = 17;
}
</code></pre>
<p>
変数に同じ値を2回代入することは役に立たないので，論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_FIELD_SELF_COMPUTATION">
<ShortDescription>フィールドの無意味な自己演算 (たとえば，x & x)</ShortDescription>
<LongDescription>{2.givenClass} とそれ自身との無意味な自己演算です。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，フィールドと同じフィールドへの別の参照との無意味な計算を実行しています (たとえば， <code>x & x</code> または <code>x - x</code>)。
この計算の性質のため，演算は意味をなすとは思われないので，論理エラーかタイプミスかもしれません。
計算をチェックしてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_LOCAL_SELF_COMPUTATION">
<ShortDescription>変数の無意味な自己演算 (たとえば，x & x)</ShortDescription>
<LongDescription>{2} とそれ自身との無意味な自己演算です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，ローカル変数と同じ変数への別の参照との無意味な計算を実行しています (たとえば， <code>x & x</code> または <code>x - x</code>)。
この計算の性質のため，演算は意味をなすとは思われないので，論理エラーかタイプミスかもしれません。
計算をダブルチェックしてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_FIELD_SELF_COMPARISON">
<ShortDescription>フィールドとそれ自身との自己比較</ShortDescription>
<LongDescription>{2.givenClass} とそれ自身との自己比較です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，フィールドをそれ自身と比較しています。論理エラーかタイプミスかもしれません。
正しいものを比較していることを確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_LOCAL_SELF_COMPARISON">
<ShortDescription>ローカル変数とそれ自身との自己比較</ShortDescription>
<LongDescription>{2} とそれ自身との自己比較です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，ローカル変数をそれ自身と比較しています。論理エラーかタイプミスかもしれません。
正しいものを比較していることを確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_LONG_BITS_TO_DOUBLE_INVOKED_ON_INT">
<ShortDescription>int に対して Double.longBitsToDouble() を呼び出している</ShortDescription>
<LongDescription>int に対して Double.longBitsToDouble() を呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>Double.longBitsToDouble()</code> の呼び出しで，32ビット int 値が引数として渡されています。
これはほぼ間違いなく意図したことではなく，意図した結果を出す可能性は低いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_ARGUMENTS_WRONG_ORDER">
<ShortDescription>逆にされたメソッド引数</ShortDescription>
<LongDescription>{2.name} の呼び出しのための間違った順序の引数。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッド呼び出しへの引数は，順序が間違っているように見えます。
たとえば，呼び出し <code>Preconditions.checkNotNull("message", message)</code> は，引数を予約しました。チェックされる値は第一引数です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_RANDOM_USED_ONLY_ONCE">
<ShortDescription>Random オブジェクトが作成され1度しか使われない</ShortDescription>
<LongDescription>Random オブジェクトが生成され，1度しか使われていません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>java.util.Random</code> オブジェクトを作成して1つの乱数を生成するために使用して捨てています。
これはあまり良くない品質の乱数を作り出し，効率が悪いです。
できれば， <code>Random</code> オブジェクトを1つだけ作成して保存されるようにコードを書き直してください。
そして，毎回新しい乱数は既存の <code>Random</code> オブジェクトを呼び出して取得することが必要です。
</p>
<p>
生成された乱数が推測可能ではないことが重要なら，乱数ごとに新しい <code>Random</code> オブジェクトを作成してはいけません (値はあまりに簡単に推測可能です)。
その代わりに <code>java.security.SecureRandom</code> の使用を強く検討すべきです (そして必要とされる乱数ごとに新しい <code>SecureRandom</code> のオブジェクトを作成することを回避します)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_ABSOLUTE_VALUE_OF_RANDOM_INT">
<ShortDescription>符号付き整数の乱数の絶対値を計算する間違った試み</ShortDescription>
<LongDescription>符号付き整数の乱数の絶対値を計算する間違った試みです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは符号付き整数の乱数を生成して絶対値を計算しています。
乱数ジェネレータで返される数が <code>Integer.MIN_VALUE</code> なら結果は同様に負です (<code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code> なので)。
(同じ問題は <code>long</code> 値でも同様に起きます)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_ABSOLUTE_VALUE_OF_HASHCODE">
<ShortDescription>符号付き32ビットハッシュコードの絶対値を計算する間違った試み</ShortDescription>
<LongDescription>符号付き32ビットハッシュコードの絶対値を計算する間違った試みです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはハッシュコードを生成して絶対値を計算しています。
ハッシュコードが <code>Integer.MIN_VALUE</code> なら結果は同様に負です (<code>Math.abs(Integer.MIN_VALUE) == Integer.MIN_VALUE</code> なので)。
</p>
<p>
文字列の2^32個に1個は <code>Integer.MIN_VALUE</code> のハッシュコードを持っていて，「polygenelubricants」，「GydZG_」，「DESIGNING WORKHOUSES」が該当します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_REM_OF_RANDOM_INT">
<ShortDescription>符号付き32ビット整数の乱数の剰余</ShortDescription>
<LongDescription>符号付き32ビット整数の乱数の剰余を計算しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは符号付き整数の乱数を生成して別の値を法とする剰余を計算しています。
乱数は負になり，剰余演算の結果も負になります。これが意図したことであることを確実にしてください。
その代わりに <code>Random.nextInt(int)</code> の使用を強く検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_REM_OF_HASHCODE">
<ShortDescription>ハッシュコードの剰余は負かもしれない</ShortDescription>
<LongDescription>ハッシュコードの剰余は負かもしれません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはハッシュコードを計算して別の値を法とする剰余を計算しています。
ハッシュコードは負になり，剰余演算の結果も負なります。
</p>
<p>
計算結果が負ではないことを確認したいなら，コードを変更する必要があるかもしれません。
除数が2の累乗であることがわかっているなら，代わりにビット演算を使用できます (すなわち， <code>x.hashCode()%n</code> の代わりに <code>x.hashCode()&(n-1)</code> を使用してください)。
これはおそらく，剰余を計算するより高速です。
除数が2の累乗であるということをわかっていないなら，剰余演算の結果の絶対値を取得してください (すなわち <code>Math.abs(x.hashCode()%n)</code>)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="INT_BAD_COMPARISON_WITH_NONNEGATIVE_VALUE">
<ShortDescription>負ではない値と負の定数またはゼロとの間違った比較</ShortDescription>
<LongDescription>負ではない値 と {2} との間違った比較です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは負ではないことが保証されている値と負の定数またはゼロとを比較しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="INT_BAD_COMPARISON_WITH_SIGNED_BYTE">
<ShortDescription>符号付きバイトの間違った比較</ShortDescription>
<LongDescription>符号付きバイト と {2} との間違った比較です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
符号付バイトのとりうる値の範囲は-128～127です。その範囲外で符号付バイトを値と比較することは無意味で間違っていそうです。
符号付きバイト <code>b</code> を範囲が0～255の符号なしバイトに変換するには <code>0xff & b</code> を使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="INT_BAD_COMPARISON_WITH_INT_VALUE">
<ShortDescription>int 値と long 定数との間違った比較</ShortDescription>
<LongDescription>int 値と {2} との間違った比較です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはint 値と int 値として表される値の範囲外の long 定数を比較しています。
この比較は無意味で，おそらく間違っています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="INT_VACUOUS_BIT_OPERATION">
<ShortDescription>整数値の無意味なビットマスク演算</ShortDescription>
<LongDescription>{3} の無意味な {2} 演算です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
どんな有用な仕事もしない整数ビット演算 (AND，OR，XOR) です (たとえば <code>v & 0xffffffff</code>)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="INT_VACUOUS_COMPARISON">
<ShortDescription>整数値の無意味な比較</ShortDescription>
<LongDescription>整数値の無意味な比較です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
常に同じ値を返す整数の比較があります (たとえば <code>x <= Integer.MAX_VALUE</code>)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="INT_BAD_REM_BY_1">
<ShortDescription>1を法とする整数の剰余</ShortDescription>
<LongDescription>1を法とする整数の剰余を計算しています。{1} </LongDescription>
<Details>
<![CDATA[
<p>
どんな式 <code>(exp % 1)</code> も常に0を返すことが保証されています。
そうではなく， <code>(exp & 1)</code> または <code>(exp % 2)</code> を意味していましたか？
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_IOR_OF_SIGNED_BYTE">
<ShortDescription>符号付きバイト値のビット論理和</ShortDescription>
<LongDescription>符号付きバイト値のビット論理和を計算しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ロードしたバイト値 (たとえば，バイト配列からロードされた値や戻り値がバイト型のメソッドから返された値) とビット論理和を実行しています。
ビット演算を実行する前にバイト値は32ビットまで符号拡張されます。
したがって， <code>b[0]</code> の値が <code>0xff</code> で， <code>x</code> の初期値が <code>0</code> だとすると，
<code>((x << 8) | b[0])</code> は， <code>0xff</code> が符号拡張で <code>0xffffffff</code> になるので，結果として <code>0xffffffff</code> が得られます。
</p>
<p>
特に，バイト配列を <code>int</code> にパックする次のようなコードはひどく間違っています。
</p>
<pre><code>int result = 0;
for(int i = 0; i < 4; i++) {
result = ((result << 8) | b[i]);
}
</code></pre>
<p>
その代わりに次のようなイディオムは動作します。
</p>
<pre><code>int result = 0;
for(int i = 0; i < 4; i++) {
result = ((result << 8) | (b[i] & 0xff));
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_ADD_OF_SIGNED_BYTE">
<ShortDescription>符号付きバイト値のビット加算</ShortDescription>
<LongDescription>符号付きバイト値のビット加算を計算をしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
バイト値と明らかに下位8ビットがあるとわかっている値を加算しています。
ビット演算を実行する前にバイト配列からロードされた値は32ビットまで符号拡張されます。
したがって， <code>b[0]</code> の値が <code>0xff</code> で， <code>x</code> の初期値が <code>0</code> だとすると，
<code>((x << 8) + b[0])</code> は， <code>0xff</code> が符号拡張で <code>0xffffffff</code> になるので，結果として <code>0xffffffff</code> が得られます。
</p>
<p>
特に，バイト配列を <code>int</code> にパックする次のようなコードはひどく間違っています。
</p>
<pre><code>int result = 0;
for(int i = 0; i < 4; i++)
result = ((result << 8) + b[i]);
</code></pre>
<p>
その代わりに次のようなイディオムは動作します。
</p>
<pre><code>int result = 0;
for(int i = 0; i < 4; i++)
result = ((result << 8) + (b[i] & 0xff));
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_AND">
<ShortDescription>互換性のないビットマスク</ShortDescription>
<LongDescription>(e & {2} == {3}) の互換性のないビットマスクは，不変の結果をもたらします。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>(e & C)</code> 形式の式を <code>D</code> と比較しています。
定数 <code>C</code> の特定の値と <code>D</code> ために常に等しくないことを比較します。論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_SIGNED_CHECK">
<ShortDescription>ビット演算の符号をチェックする</ShortDescription>
<LongDescription>ビット演算の符号をチェックしてください。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>((event.detail & SWT.SELECTED) > 0)</code> のような式で比較しています。
ビット演算をより大きい演算子で比較することは，予想外の結果 (もちろん， <code>SWT.SELECTED</code> の値による) の原因になる可能性があります。
<code>SWT.SELECTED</code> が負数であるなら，これはバグの候補です。
<code>SWT.SELECTED</code> が負ではないとしても， <code>> 0</code> の代わりに <code>!= 0</code> を使用することが良いプラクティスであると思われます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_SIGNED_CHECK_HIGH_BIT">
<ShortDescription>負数を含むビット演算の符号をチェックする</ShortDescription>
<LongDescription>{2} を含むビット演算の符号をチェックしてください。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>CONSTANT</code> が負数のときに <code>((val & CONSTANT) > 0)</code> のようなビット演算式で比較しています。
ビット演算をより大きい演算子で比較することは，予想外の結果の原因になる可能性があります。比較は期待したようになりません。
<code>> 0</code> の代わりに <code>!= 0</code> を使用することが良いプラクティスです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_AND_ZZ">
<ShortDescription>((...) & 0) == 0 なのか確かめている</ShortDescription>
<LongDescription>((...) & 0) == 0 なのか確かめています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>(e & 0)</code> 形式の式を0と比較しています。それは，常に等価であることを比較します。論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_IOR">
<ShortDescription>互換性のないビットマスク</ShortDescription>
<LongDescription>(e | {2} == {3}) の互換性のないビットマスクは，不変の結果をもたらします。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>(e | C)</code> 形式の式を <code>D</code> と比較しています。
定数 <code>C</code> と <code>D</code> の特定の値のために常に等しくないことを比較します。論理エラーかタイプミスかもしれません。
</p>
<p>
通常，このバグは，ビットセットで帰属関係のテストを実行したいコードで発生します。
しかし，ビット論理積演算子 (<code>&</code>) の代わりにビット論理和演算子 (<code>|</code>) を使用しています。
</p>
<p>
こうしたバグは <code>(e & (A | B)) == C</code> が意図されている間に <code>((e & A) | B) == C</code> のように解析される <code>(e & A | B) == C</code> のような式で現れるかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="LI_LAZY_INIT_INSTANCE" deprecated="true"> <!-- never generated? -->
<ShortDescription>Incorrect lazy initialization of instance field</ShortDescription>
<LongDescription>Incorrect lazy initialization of instance field {2} in {1}</LongDescription>
<Details>
<![CDATA[
<p> This method contains an unsynchronized lazy initialization of a non-volatile field.
Because the compiler or processor may reorder instructions,
threads are not guaranteed to see a completely initialized object,
<em>if the method can be called by multiple threads</em>.
You can make the field volatile to correct the problem.
For more information, see the
<a href="http://www.cs.umd.edu/~pugh/java/memoryModel/">Java Memory Model web site</a>.
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="LI_LAZY_INIT_STATIC">
<ShortDescription>static フィールドの間違った遅延初期化</ShortDescription>
<LongDescription>static フィールド {2} の間違った遅延初期化。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには <code>volatile</code> ではない <code>static</code> フィールドの非同期な遅延初期化があります。
コンパイラやプロセッサが命令を並べ替えるかもしれないので，メソッドが複数のスレッドによって呼び出されるなら，スレッドは完全に初期化されたオブジェクトを参照することは保証されません。
この問題を修正するためにフィールドを <code>volatile</code> にできます。<br>
詳細は， <a href="http://www.cs.umd.edu/~pugh/java/memoryModel/">Java Memory Model web site</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="LI_LAZY_INIT_UPDATE_STATIC">
<ShortDescription>更新される static フィールドの間違った遅延初期化</ShortDescription>
<LongDescription>更新される static フィールド {2} の間違った遅延初期化。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには <code>static</code> フィールドの非同期な遅延初期化があります。
フィールドが設定されると，その場所に格納されているオブジェクトはさらに更新またはアクセスされます。フィールドの設定は，他のスレッドにすぐに見えます。
フィールドを設定するメソッドのさらなるアクセスがオブジェクトの初期化に役立つなら，
完全に初期化されるまで他のスレッドが格納されたオブジェクトにアクセスすることを防がないかぎり，非常に深刻なマルチスレッドバグがあります。
</p>
<p>
たとえメソッドが複数のスレッドによって決して呼び出されないと確信していても，
フィールドに設定する値が完全に設定/初期化されるまで， <code>static</code> フィールドを設定しないほうが良いかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="JLM_JSR166_LOCK_MONITORENTER">
<ShortDescription>Lock で同期化している</ShortDescription>
<LongDescription>{2} で同期化しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>java.util.concurrent.locks.Lock</code> を実装したオブジェクトで同期化しています。
そのようなオブジェクトは <code>synchronized (...)</code> 構文よりも <code>acquire()</code>/<code>release()</code> を使用してロックとロックの解除をします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="JML_JSR166_CALLING_WAIT_RATHER_THAN_AWAIT">
<ShortDescription>util.concurrent 抽象化でモニタスタイルの wait メソッドを使用している</ShortDescription>
<LongDescription>{3.name} ではなく {2.name} を呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>await()</code> メソッド， <code>signal</code> メソッド， <code>signalAll</code> メソッドを提供するオブジェクト
(たとえば，util.concurrent の <code>Condition</code> オブジェクト) で， <code>wait</code> メソッド， <code>notify</code> メソッド， <code>notifyAll</code> メソッドを呼び出しています。
これはおそらくあなたが望むことではなく，たとえそれを望むとしても，他の開発者が非常に混乱することを理解して，設計を変更することを検討すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="JLM_JSR166_UTILCONCURRENT_MONITORENTER">
<ShortDescription>java.util.concurrent のインスタンスで同期化している</ShortDescription>
<LongDescription>{2} で同期化しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，java.util.concurrent パッケージのクラス (またはサブクラス) のインスタンスで同期化しています。
これらのクラスのインスタンスは， <code>synchronized</code> による同期とは違う独自の並行制御メカニズムを持っています。
たとえば， <code>AtomicBoolean</code> で同期しても，他のスレッドが <code>AtomicBoolean</code> を変更することを防げません。
</p>
<p>
そのようなコードは正しいかもしれませんが，将来コードを維持しなければならない人々を混乱させるかもしれないので慎重にレビューし文書化すべきです，
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UPM_UNCALLED_PRIVATE_METHOD">
<ShortDescription>private メソッドは決して呼び出されない</ShortDescription>
<LongDescription>{1} は，決して呼び出されません。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>private</code> メソッドは，決して呼び出されません。
メソッドがリフレクションによって呼び出されるかもしれないが，決して使われないなら除去すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UMAC_UNCALLABLE_METHOD_OF_ANONYMOUS_CLASS">
<ShortDescription>呼び出し不可能なメソッドが無名クラスで定義されている</ShortDescription>
<LongDescription>呼び出し不可能なメソッド {1} が無名クラスで定義されています。</LongDescription>
<Details>
<![CDATA[
<p>
この無名クラスは，直接呼び出されないスーパークラスのメソッドをオーバーライドしていないメソッドを定義しています。
他のクラスのメソッドが無名クラスで宣言されたメソッドを直接呼び出せないので，このメソッドは呼び出し不可能だと思われます。
メソッドは単にデッドコードであるかもしれません。しかし，メソッドがスーパークラスで宣言されるメソッドをオーバーライドすることを意図した可能性もあります。
そして，タイプミスまたは他の誤りのためにメソッドは，実際には意図しているメソッドをオーバーライドしません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ODR_OPEN_DATABASE_RESOURCE">
<ShortDescription>データベースリソースのクローズに失敗するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，{2.excludingPackage} のクローズに失敗するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，データベースリソース (たとえば，データベースコネクションや行セット) を作成していますが，どんなフィールドにも代入していないか，他のメソッドにも渡していないか，戻り値にもしていません。
そして，メソッドからのすべての経路でオブジェクトをクローズするように見えません。
メソッドからのすべての経路でデータベースリソースのクローズが失敗すると性能低下になることがあります。
データベースとの通信で問題があるアプリケーションの原因になる可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ODR_OPEN_DATABASE_RESOURCE_EXCEPTION_PATH">
<ShortDescription>例外経路でデータベースリソースのクローズに失敗するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，例外経路でデータベースリソースのクローズに失敗するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，データベースリソース (たとえば，データベースコネクションや行セット) を作成していますが，どんなフィールドにも代入していないか，他のメソッドにも渡していないか，戻り値にもしていません。
そして，メソッドからのすべての例外経路でオブジェクトをクローズするように見えません。
メソッドからのすべての経路でデータベースリソースのクローズが失敗すると性能低下になることがあります。
データベースとの通信で問題があるアプリケーションの原因になる可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SBSC_USE_STRINGBUFFER_CONCATENATION">
<ShortDescription>ループの中で + を使用して文字列を連結しているメソッド</ShortDescription>
<LongDescription>{1} は，ループの中で + を使用して文字列を連結しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，ループの中で + を使用して <code>String</code> を構築していると思われます。
各々の繰り返しにおいて， <code>String</code> は <code>StringBuffer</code>/<code>StringBuilder</code> に変換，追加され， <code>String</code> へ変換されます。
各々の繰り返しで文字列が再コピーされ，増大すると繰り返しの数で二次コストの原因になる可能性があります。
</p>
<p>
<code>StringBuffer</code> (または J2SE 5.0の <code>StringBuilder</code>) を明示的に使うとより良い性能を得られます。
</p>
<p>
たとえば，
</p>
<pre><code>// This is bad
String s = "";
for (int i = 0; i < field.length; ++i) {
s = s + field[i];
}
// This is better
StringBuffer buf = new StringBuffer();
for (int i = 0; i < field.length; ++i) {
buf.append(field[i]);
}
String s = buf.toString();
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="IIL_PREPARE_STATEMENT_IN_LOOP">
<ShortDescription>ループの中で prepareStatement を呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，ループの中で不変の引数で prepareStatement を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，ループの中で <code>Connection.prepareStatement</code> に不変の引数を渡して呼び出しています。
<code>PreparedStatement</code> を複数回実行する必要があるなら，それぞれのループの繰り返しで再生成する理由がありません。
ループの外に呼び出しを移動します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IIL_ELEMENTS_GET_LENGTH_IN_LOOP">
<ShortDescription>ループの中で NodeList.getLength() を呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，ループの中で getElementsByTagName の戻り値のために NodeList.getLength() を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，ループの中で <code>NodeList.getLength()</code> を呼び出し， <code>NodeList</code> は， <code>getElementsByTagName</code> の呼び出しによって作られます。
<code>NodeList</code> は長さを格納しませんが，毎回とても最適ではない方法で計算されます。
ループの前に変数に長さを格納することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IIL_PATTERN_COMPILE_IN_LOOP">
<ShortDescription>ループの中で Pattern.compile を呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，ループの中で不変の定数で Pattern.compile を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，ループの中で <code>Pattern.compile</code> に不変の定数を渡して呼び出しています。
<code>Pattern</code> を複数回使用する必要があるなら，それぞれのループの繰り返しでコンパイルする理由がありません。
ループの外に呼び出しを移動するか <code>static final</code> フィールドにします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IIL_PATTERN_COMPILE_IN_LOOP_INDIRECT">
<ShortDescription>ループの中で正規表現をコンパイルしているメソッド</ShortDescription>
<LongDescription>{1} は，ループの中で正規表現のコンパイルをしています。</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，ループの中で同じ正規表現を生成しているので，繰り返しごとにコンパイルされます。
ループの外で <code>Pattern.compile</code> を使用して正規表現をプリコンパイルするのが最適でしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IIO_INEFFICIENT_INDEX_OF">
<ShortDescription>String.indexOf(String) の非効率的な使用</ShortDescription>
<LongDescription>{1} は，String.indexOf(int) の代わりに String.indexOf(String) を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>String.indexOf()</code> に長さ1の文字列定数を渡しています。<code>String.indexOf()</code> の整数実装を使うほうが効率的です。
たとえば， <code>myString.indexOf(".")</code> の代わりに <code>myString.indexOf('.')</code> を呼び出します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IIO_INEFFICIENT_LAST_INDEX_OF">
<ShortDescription>String.lastIndexOf(String) の非効率的な使用</ShortDescription>
<LongDescription>{1} は，String.lastIndexOf(int) の代わりに String.lastIndexOf(String) を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>String.lastIndexOf()</code> に長さ1の文字列定数を渡しています。<code>String.lastIndexOf()</code> の整数実装を使うほうが効率的です。
たとえば， <code>myString.lastIndexOf(".")</code> の代わりに <code>myString.lastIndexOf('.')</code> を呼び出します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ITA_INEFFICIENT_TO_ARRAY">
<ShortDescription>長さが0の配列の引数で toArray メソッドを使用しているメソッド</ShortDescription>
<LongDescription>{1} は，長さが0の配列の引数で Collection.toArray() を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>Collection</code> 派生クラスの </code>toArray</code> メソッドを使用して長さが0の配列の引数を渡しています。
<code>myCollection.toArray(new Foo[myCollection.size()])</code> を使用するほうがより効率的です。
渡される配列がコレクションの要素のすべてを格納できるくらいの大きさなら，設定されて，そのまま返されます。
これは結果として返す2番目の配列 (リフレクションによって) を作成する必要を回避します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IRA_INEFFICIENT_REPLACEALL">
<ShortDescription>replaceAll(String regex, String replacement) の引数に正規表現を使用していないメソッド</ShortDescription>
<LongDescription>{1} は， replaceAll(String regex, String replacement) の引数に正規表現を使用していません。</LongDescription>
<Details>
<![CDATA[
<p>このメソッドは， <code>replaceAll(String regex, String replacement)</code> の引数に正規表現を使用していません。
正規表現が不要な場合は、 <code>myString.replace(CharSequence target, CharSequence replacement)</code> を使用するほうがより効率的です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IJU_ASSERT_METHOD_INVOKED_FROM_RUN_METHOD">
<ShortDescription>run メソッドでの JUnit アサーションは JUnit によって通知されない</ShortDescription>
<LongDescription>{1} での JUnit アサーションは JUnit によって通知されません。</LongDescription>
<Details>
<![CDATA[
<p>
<code>run</code> メソッドで JUnit アサーションが実行されています。失敗した JUnit アサーションは例外をスローします。
したがって，この例外がテストメソッドを実行したスレッド以外のスレッドで発生するなら，例外はスレッドを終了させますが，テストの失敗になりません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IJU_SETUP_NO_SUPER">
<ShortDescription>TestCase は super.setup() を呼び出さない setUp メソッドを実装している</ShortDescription>
<LongDescription>TestCase {0} は，super.setup() を呼び出さない setUp メソッドを定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
JUnit の <code>TestCase</code> クラスで， <code>setUp</code> メソッドを実装しています。
<code>setUp</code> メソッドは， <code>super.setUp()</code> を呼び出すべきなのにそうしていません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IJU_TEARDOWN_NO_SUPER">
<ShortDescription>TestCase は super.tearDown() を呼び出さない tearDown メソッドを実装している </ShortDescription>
<LongDescription>TestCase {0} は，super.tearDown() を呼び出さない tearDown メソッドを実装しています。</LongDescription>
<Details>
<![CDATA[
<p>
JUnit の <code>TestCase</code> クラスで， <code>tearDown</code> メソッドを実装しています。
<code>tearDown</code> メソッドは， <code>super.tearDown()</code> を呼び出すべきなのにそうしていません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IJU_SUITE_NOT_STATIC">
<ShortDescription>TestCase は 非 static な suite メソッドを実装している</ShortDescription>
<LongDescription>TestCase {0} は，非 static な suite メソッドを実装しています。</LongDescription>
<Details>
<![CDATA[
<p>
JUnit の <code>TestCase</code> クラスで， <code>suite</code> メソッドを実装しています。
<code>suite</code> メソッドは <code>static</code> として宣言すべきなのにそうしていません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IJU_BAD_SUITE_METHOD">
<ShortDescription>TestCase は suite メソッドの間違った宣言をしている</ShortDescription>
<LongDescription>TestCase {0} は，suite メソッドの間違った宣言をしています。</LongDescription>
<Details>
<![CDATA[
<p>
JUnit の <code>TestCase</code> クラスで， <code>suite</code> メソッドを実装しています。
しかしながら， <code>suite</code> メソッドは，
</p>
<pre><code>public static junit.framework.Test suite()
</code></pre>
<p>か</p>
<pre><code>public static junit.framework.TestSuite suite()
</code></pre>
<p>
のどちらかを宣言する必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IJU_NO_TESTS">
<ShortDescription>TestCase はテストがない </ShortDescription>
<LongDescription>TestCase {0} は，テストがありません。</LongDescription>
<Details>
<![CDATA[
<p>
JUnit の <code>TestCase</code> クラスで，どんなテストメソッドも実装していません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BOA_BADLY_OVERRIDDEN_ADAPTER">
<ShortDescription>スーパークラスの Adapter で実装されるメソッドを誤ってオーバーライドしているクラス</ShortDescription>
<LongDescription>クラス {0} は，スーパークラス の Adapter で実装されるメソッド {1} を誤ってオーバーライドしています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，スーパークラスで実装されているメソッドをオーバーライドしています。
スーパークラスは，java.awt.event や javax.swing.event パッケージで定義されているリスナを実装する <code>Adapter</code> です。
その結果，イベントが発生するときこのメソッドは呼び出されません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BRSA_BAD_RESULTSET_ACCESS" deprecated="true"> <!-- deprecated in favor of SQL_BAD_RESULTSET_ACCESS -->
<ShortDescription>Method attempts to access a result set field with index 0</ShortDescription>
<LongDescription>{1} attempts to access a result set field with index 0</LongDescription>
<Details>
<![CDATA[
<p> A call to getXXX or updateXXX methods of a result set was made where the
field index is 0. As ResultSet fields start at index 1, this is always a mistake.</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SQL_BAD_RESULTSET_ACCESS">
<ShortDescription>インデックスが0で ResultSet にアクセスしようとしているメソッド</ShortDescription>
<LongDescription>{1} は，インデックスが0で ResultSet にアクセスしようとしています。</LongDescription>
<Details>
<![CDATA[
<p>
インデックスが0で， <code>ResultSet</code> の <code>getXXX</code> ， <code>updateXXX</code> メソッドを呼び出しています。
<code>ResultSet</code> のインデックスは1から開始するので，これは常に間違いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SQL_BAD_PREPARED_STATEMENT_ACCESS">
<ShortDescription>インデックスが0で PreparedStatement にアクセスしようとしているメソッド</ShortDescription>
<LongDescription>{1} は，インデックスが0で PreparedStatement にアクセスしようとしています。</LongDescription>
<Details>
<![CDATA[
<p>
インデックスが0で， <code>PreparedStatement</code> の <code>setXXX</code> メソッドを呼び出しています。
インデックスは1から開始するので，これは常に間違いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIO_SUPERFLUOUS_INSTANCEOF">
<ShortDescription>instanceof 演算子を使用した不必要な型チェック</ShortDescription>
<LongDescription>{1} は，静的に判定される instanceof 演算子を使用して不必要な型チェックをしています。</LongDescription>
<Details>
<![CDATA[
<p>
オブジェクトが要求する型であるかどうかにかかわらず，静的に判定される <code>instanceof</code> 演算子を使用して型チェックをしています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BAC_BAD_APPLET_CONSTRUCTOR">
<ShortDescription>初期化されていない AppletStub に依存する間違ったアプレットコンストラクタ</ShortDescription>
<LongDescription>間違ったアプレットコンストラクタは，初期化されていない AppletStub に依存しています。</LongDescription>
<Details>
<![CDATA[
<p>
このコンストラクタは， <code>AppletStub</code> に依存する親アプレットでメソッドを呼び出しています。
このアプレットの <code>init</code> メソッドが呼び出されるまで <code>AppletStub</code> は初期化されないので，これらのメソッドは正しく機能しません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EC_ARRAY_AND_NONARRAY">
<ShortDescription>equals メソッドを使用して配列と非配列を比較している</ShortDescription>
<LongDescription>{3.simpleClass}.equals({2.simpleClass}) を呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，配列と配列だと思われない参照を比較するために <code>.equals(Object o)</code> を呼び出しています。
比較されているものが違う型なら等しくないことであることが保証されているので，比較はほぼ間違いなく誤りです。
たとえそれらが両方とも配列だったとしても，配列の <code>equals</code> メソッドは2つの配列が同じオブジェクトだと決定するだけです。
配列の内容を比較するためには <code>java.util.Arrays.equals(Object[], Object[])</code> を使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EC_BAD_ARRAY_COMPARE">
<ShortDescription>配列の equals メソッド呼び出しは == と等価である</ShortDescription>
<LongDescription>{2.simpleClass} を比較するために .equals を使用していますが，== と等価です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，配列で <code>.equals(Object o)</code> を呼び出しています。
配列は， <code>Object</code> の <code>equals</code> メソッドをオーバーライドしないので，配列で <code>equals</code> メソッドを呼び出すことはアドレスを比較することと同じです。
配列の内容を比較するためには <code>java.util.Arrays.equals(Object[], Object[])</code> を使用してください。
配列のアドレスを比較するために明示的に <code>==</code> を使用して参照等価性をチェックすることは，それほど紛らわしくないでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EC_INCOMPATIBLE_ARRAY_COMPARE">
<ShortDescription>equals(...) メソッドを使用して互換性のない配列を比較している</ShortDescription>
<LongDescription>{2.simpleClass} と {3.simpleClass} を比較するために equals メソッドを使用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，互換性のない型の配列を比較するために <code>.equals(Object o)</code> を呼び出しています (たとえば， <code>String[]</code> と <code>StringBuffer[]</code> ， <code>String[]</code> と <code>int[]</code>) 。
それらは，決して等価ではありません。
さらに， <code>equals(...)</code> を使用してが配列を比較すると，同じ配列なのか確かめるだけで，配列の内容は無視されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="STI_INTERRUPTED_ON_CURRENTTHREAD">
<ShortDescription>interrupted メソッドを呼び出すために不要な currentThread メソッドを呼び出している</ShortDescription>
<LongDescription>{1} は，interrupted メソッドを呼び出すために不要な currentThread メソッドを呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>interrupted</code> メソッドを呼び出すために <code>Thread.currentThread()</code> を呼び出しています。
<code>interrupted</code> メソッドは <code>static</code> メソッドなので， <code>Thread.interrupted()</code> を使用するほうが単純明解です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="STI_INTERRUPTED_ON_UNKNOWNTHREAD">
<ShortDescription>スレッドインスタンスで static Thread.interrupted() を呼び出している</ShortDescription>
<LongDescription>{1}は，スレッドインスタンスで static Thread.interrupted() を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，カレントスレッドではない <code>Thread</code> オブジェクトであるように見える <code>Thread</code> オブジェクトで <code>Thread.interrupted()</code> を呼び出しています。
<code>interrupted</code> メソッドは <code>static</code> なので，作成者が意図したこととは異なるオブジェクトで呼び出されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IP_PARAMETER_IS_DEAD_BUT_OVERWRITTEN">
<ShortDescription>メソッドで読み取られずに上書きされているパラメータ</ShortDescription>
<LongDescription>{1} へのパラメータ {2} は，読み取られずに上書きされています。</LongDescription>
<Details>
<![CDATA[
<p>
このパラメータの初期値は無視され，ここで上書きされています。
これは多くの場合，パラメータへの書き込みが呼び出し元に戻されるという誤った考えを示しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DLS_DEAD_LOCAL_STORE_SHADOWS_FIELD">
<ShortDescription>フィールドを遮るローカル変数への無効な代入</ShortDescription>
<LongDescription>同じ名前のフィールではなく，{2} への無効な代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この命令は，ローカル変数に値を代入していますが，値は読み出されないか以降の命令でも使われません。
多くの場合，計算された値が決して使われないので，これは誤りを示します。
フィールドがローカル変数と同じ名前です。そうではなく，フィールドに代入するつもりでしたか？
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DLS_DEAD_LOCAL_STORE">
<ShortDescription>ローカル変数への無効な代入</ShortDescription>
<LongDescription>{2} への無効な代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この命令はローカル変数に値を代入していますが，値は読み出されないか以降の命令でも使われません。
多くの場合，計算された値が決して使われないので，これは誤りを示します。
</p>
<p>
Sun の javac コンパイラが <code>final</code> なローカル変数のためにしばしば無効な格納を生成することに注意してください。
SpotBugs は，バイトコードベースのツールなので誤検出をなくす簡単な方法がありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DLS_DEAD_LOCAL_STORE_IN_RETURN">
<ShortDescription>return 文に役に立たない代入がある</ShortDescription>
<LongDescription>{1} からの return 文に役に立たない代入があります。</LongDescription>
<Details>
<![CDATA[
<p>
この文は， <code>return</code> 文でローカル変数に代入をしています。この代入は効果がありません。
この文が正しいことを確かめてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DLS_DEAD_LOCAL_INCREMENT_IN_RETURN">
<ShortDescription>return 文に無駄なインクリメントがある</ShortDescription>
<LongDescription>{1} からの return に無駄なインクリメントがあります。</LongDescription>
<Details>
<![CDATA[
<p>
<code>return x++;</code> のような <code>return</code> 文があります。
接頭辞インクリメント/デクリメントは 式の値に影響を与えないので，インクリメント/デクリメントは効果がありません。
この文が正しいことを確かめてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DLS_DEAD_STORE_OF_CLASS_LITERAL">
<ShortDescription>クラスリテラルの無効な代入</ShortDescription>
<LongDescription>{3}.class の無効な代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この命令は変数にクラスリテラルを代入していますが，決して使われません。<br>
<a href="http://www.oracle.com/technetwork/java/javase/compatibility-137462.html#literal">The behavior of this differs in Java 1.4 and in Java 5</a><br>
J2SE 1.4 およびそれ以前のバージョンでは， <code>Foo.class</code> への参照は <code>Foo</code> のためのスタティックイニシャライザが既に実行されていないなら実行することを強制します。
J2SE 5.0 ではそうしません。
</p>
<p>
より多くの詳細と例と J2SE 5.0 のクラスの強制的な初期化の方法の提案は Sun の <a href="http://www.oracle.com/technetwork/java/javase/compatibility-137462.html#literal">article on Java SE compatibility</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DLS_DEAD_LOCAL_STORE_OF_NULL">
<ShortDescription>ローカル変数への無効な null 代入</ShortDescription>
<LongDescription>{2} への無効な null 代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはローカル変数に <code>null</code> を代入していますが代入された値は読み出されていません。
この代入はガベージコレクタを手伝うために導入されたのかもしれませんが，Java SE 6 ではもはや必要とされないか有用ではありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MF_METHOD_MASKS_FIELD">
<ShortDescription>フィールドを隠す変数を定義しているメソッド</ShortDescription>
<LongDescription>{1} は，フィールド {2.givenClass} を隠す変数を定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，このクラスまたはスーパークラスのフィールドと同じ名前でローカル変数を定義しています。
フィールドから初期化されていない値を読み出す，初期化されていないフィールドをそのままにしておくか，または両方を引き起こすかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MF_CLASS_MASKS_FIELD">
<ShortDescription>スーパークラスのフィールドを隠すフィールドを定義しているクラス</ShortDescription>
<LongDescription>フィールド {1.givenClass} は，スーパークラス {2.class} のフィールドを隠しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，スーパークラスの可視インスタンスフィールドと同じ名前でフィールドを定義しています。
これは紛らわしくて，メソッドがフィールドを更新するかアクセスするなら，間違いを指摘するかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="WMI_WRONG_MAP_ITERATOR">
<ShortDescription>entrySet イテレータではなく効率が悪い keySet イテレータを使用している</ShortDescription>
<LongDescription>{1} は，entrySet イテレータではなく効率が悪い keySet イテレータを使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>keySet</code> イテレータから取り出されたキーを使用して，マップエントリの値にアクセスしています。
<code>Map</code> の <code>entrySet</code> イテレータを使用したほうが <code>Map.get(key)</code> ルックアップを回避するのでより効率的です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ISC_INSTANTIATE_STATIC_CLASS">
<ShortDescription>static メソッドだけを提供するクラスの不必要なインスタンス化</ShortDescription>
<LongDescription>{1} は，static メソッドだけを提供するクラスを不必要にインスタンス化しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>static</code> メソッドだけを提供するクラスのオブジェクトを作成しています。
このオブジェクトは作成する必要はありません。修飾子として直接クラス名を使用する <code>static</code> メソッドにアクセスしてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="REC_CATCH_EXCEPTION">
<ShortDescription>例外がスローされないのに例外をキャッチしている</ShortDescription>
<LongDescription>例外がスローされないのに例外をキャッチしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，例外オブジェクトをキャッチする <code>try-catch</code> ブロックを使用していますが，例外は <code>try</code> ブロックの中でスローされません。また，実行時例外は明示的にキャッチされません。
それぞれの <code>catch</code> ブロックが同一である多くの例外型をキャッチすることの短縮形として <code>try { ... } catch (Exception e) { something }</code> を使用することが共通のバグパターンです。
しかし，この構文は誤って実行時例外も同様にキャッチするので，潜在的なバグを隠します。
</p>
<p>
より良いアプローチは，明示的にキャッチするよりもスローされる特定の例外をスローします。
または，次に示すように明示的に <code>RuntimeException</code> をキャッチ，再スローして，非実行時例外をキャッチします。
</p>
<pre><code>try {
...
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
... deal with all non-runtime exceptions ...
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="FE_TEST_IF_EQUAL_TO_NOT_A_NUMBER">
<ShortDescription>NaN への等価性のための絶望的なテスト</ShortDescription>
<LongDescription>NaN への等価性のための絶望的なテストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは浮動小数点が特別な非数値と等価であるか確かめています (たとえば <code>if (x == Double.NaN)</code>)。
しかしながら， <code>NaN</code> の特別な意味のため，値は <code>NaN</code> と等価ではありません。
したがって， <code>x == Double.NaN</code> は常に <code>false</code> と評価します。
<code>x</code> という値が特別な非数値であるかどうか確かめるためには <code>Double.isNaN(x)</code> を使用します (または <code>x</code> が浮動小数点精度であるなら <code>Float.isNaN(x)</code>)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FE_FLOATING_POINT_EQUALITY">
<ShortDescription>浮動小数点の等価性のためのテスト</ShortDescription>
<LongDescription>浮動小数点の等価性のためのテストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この演算は，等価性のために2つの浮動小数点値を比較しています。
浮動小数点の計算は丸めを伴うかもしれないので計算された <code>float</code> と <code>double</code> の値は正確ではないかもしれません。
通貨のような正確でなければならない値のために <code>BigDecimal</code> のような固定精度型を使用することを検討してください。
正確である必要がない値のためにいくつかの範囲の中で等価性のために比較することを検討してください。
たとえば， <code>if (Math.abs(x - y) < .0000001)</code>。<br>
詳細は Java 言語仕様4.2.4を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UM_UNNECESSARY_MATH">
<ShortDescription>定数値で Math クラスの static メソッドを呼び出しているメソッド</ShortDescription>
<LongDescription>メソッドは，定数値で Math クラスの static メソッドを呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，定数値で <code>java.lang.Math</code> の <code>static</code> メソッドを呼び出しています。
このメソッドの結果は静的に判定でき，より高速で，ときには定数を使用するほうがより正確です。<br>
検出されるメソッドは，次のとおりです。
</p>
<table>
<tr><th>メソッド</th> <th>パラメータ</th></tr>
<tr><td><code>abs</code></td> <td>-any-</td></tr>
<tr><td><code>acos</code></td> <td>0.0 or 1.0</td></tr>
<tr><td><code>asin</code></td> <td>0.0 or 1.0</td></tr>
<tr><td><code>atan</code></td> <td>0.0 or 1.0</td></tr>
<tr><td><code>atan2</code></td> <td>0.0</td></tr>
<tr><td><code>cbrt</code></td> <td>0.0 or 1.0</td></tr>
<tr><td><code>ceil</code></td> <td>-any-</td></tr>
<tr><td><code>cos</code></td> <td>0.0</td></tr>
<tr><td><code>cosh</code></td> <td>0.0</td></tr>
<tr><td><code>exp</code></td> <td>0.0 or 1.0</td></tr>
<tr><td><code>expm1</code></td> <td>0.0</td></tr>
<tr><td><code>floor</code></td> <td>-any-</td></tr>
<tr><td><code>log</code></td> <td>0.0 or 1.0</td></tr>
<tr><td><code>log10</code></td> <td>0.0 or 1.0</td></tr>
<tr><td><code>rint</code></td> <td>-any-</td></tr>
<tr><td><code>round</code></td> <td>-any-</td></tr>
<tr><td><code>sin</code></td> <td>0.0</td></tr>
<tr><td><code>sinh</code></td> <td>0.0</td></tr>
<tr><td><code>sqrt</code></td> <td>0.0 or 1.0</td></tr>
<tr><td><code>tan</code></td> <td>0.0</td></tr>
<tr><td><code>tanh</code></td> <td>0.0</td></tr>
<tr><td><code>toDegrees</code></td> <td>0.0 or 1.0</td></tr>
<tr><td><code>toRadians</code></td> <td>0.0</td></tr>
</table>
]]>
</Details>
</BugPattern>
<BugPattern type="CD_CIRCULAR_DEPENDENCY">
<ShortDescription>クラス間の循環依存関係のテスト</ShortDescription>
<LongDescription>クラス {0} は，他のクラスと循環依存関係があります。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，他のクラスと循環依存関係があります。
それぞれが他のクラスの正確な構築に依存していて，クラスの構築を難しくしています。
難しい依存関係を断つためにインタフェースの使用を検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RI_REDUNDANT_INTERFACES">
<ShortDescription>スーパークラスと同じインタフェースを実装しているクラス</ShortDescription>
<LongDescription>クラス {0} は，スーパークラスと同じインタフェースを実装しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，スーパークラスによっても実装されるインタフェースを実装することを宣言しています。
スーパークラスがインタフェースを実装するので，これは冗長です。デフォルトですべてのサブクラスもこのインタフェースを実装します。
このクラスが作成されてから継承階層が変わったことを指摘するかもしれません。インタフェースの実装の所有権を考慮すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MTIA_SUSPECT_STRUTS_INSTANCE_FIELD">
<ShortDescription>Struts Action を拡張したクラスでのインスタンス変数の使用</ShortDescription>
<LongDescription>Struts Action クラスを拡張したクラス {0} で，インスタンス変数を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
Struts Action クラスを拡張したクラスで，インスタンス変数を使用しています。
Struts Action クラスの1つのインスタンスだけが Struts フレームワークによって作成され，マルチスレッドによって使われるので，このパラダイムは極めて問題があり，推奨できません。
ローカル変数を使用することだけを検討してください。
モニタを除いて書き込まれるインスタンスフィールドだけが報告されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MTIA_SUSPECT_SERVLET_INSTANCE_FIELD">
<ShortDescription>Servlet クラスを拡張したクラスでのインスタンス変数の使用</ShortDescription>
<LongDescription>Servlet クラスを拡張したクラス {0} で，インスタンス変数を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
<code>Servlet</code> クラスを拡張したクラスで，インスタンス変数を使用しています。
<code>Servlet</code> クラスの1つのインスタンスだけが Java EE フレームワークによって作成され，マルチスレッドによって使われるので，このパラダイムは極めて問題があり，推奨できません。
ローカル変数を使用することだけを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="PS_PUBLIC_SEMAPHORES">
<ShortDescription>公開インタフェースで同期化とセマフォを暴露するクラス</ShortDescription>
<LongDescription>クラス {0} は，公開インタフェースで同期化とセマフォを暴露しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，自分自身 (<code>this</code> 参照) で， <code>wait</code> メソッド， <code>notify</code> メソッド， <code>notifyAll</code> メソッド とともに同期化しています。
このクラスを使用するクライアントクラスは，同期化のためのオブジェクトとしてこのクラスのインスタンスをさらに使用するかもしれません。
2つのクラスが同期化のために同じオブジェクトを使用するので，マルチスレッドの正確性は疑わしいです。
公開参照で同期化もセマフォメソッドの呼び出しもすべきではありません。
同期化の制御には内部の公開されないメンバ変数を使用することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ICAST_INTEGER_MULTIPLY_CAST_TO_LONG">
<ShortDescription>整数乗算の結果を long にキャストしている</ShortDescription>
<LongDescription>整数乗算の結果を long にキャストしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは次のように整数の乗算を実行してから結果を <code>long</code> に変換しています。
</p>
<pre><code>long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; }
</code></pre>
<p>
<code>long</code> を使用して乗算をすれば，結果がオーバーフローするという可能性を回避できます。<br>
たとえば次のように修正できます。
</p>
<pre><code>long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; }
</code></pre>
<p>
または
</p>
<pre><code>static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; }
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="ICAST_INT_2_LONG_AS_INSTANT">
<ShortDescription>int 値を long に変換して絶対時間として使用している</ShortDescription>
<LongDescription>int 値 を long に変換して，{2} への絶対時間として渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは32ビット int 値を64ビット long 値に変換して，絶対時間値を必要とするメソッドパラメータに渡しています。
絶対時間値は，「エポック」（すなわち，1970年1月1日，00:00:00 GMT）としてわかっている標準的な基準時間からのミリ秒数です。<br>
たとえば，エポックからの秒を <code>Date</code> へ変換することを意図した次のメソッド はひどく壊れています。
</p>
<pre><code>Date getDate(int seconds) { return new Date(seconds * 1000); }
</code></pre>
<p>
乗算は32ビット演算を使用して，64ビット値に変換されます。
32ビット値は，64ビットに変換されて，絶対時間値を表すために使用されるとき，1969年12月と1970年1月の日付しか表せません。
</p>
<p>
上記のメソッドの正しい実装は次のとおりです。
</p>
<pre><code>// 失敗，2037年後の日付
Date getDate(int seconds) { return new Date(seconds * 1000L); }
// より良い，すべての日付で動作する
Date getDate(long seconds) { return new Date(seconds * 1000); }
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="ICAST_INT_CAST_TO_FLOAT_PASSED_TO_ROUND">
<ShortDescription>整数値を float にキャストして Math.round() に渡している</ShortDescription>
<LongDescription>整数値を float にキャストして，Math.round() に渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは整数値を <code>float</code> 精度浮動小数点に変換してから，その結果を <code>Math.round()</code> に渡して引数に最も近い <code>int</code>/<code>long</code> を返します。
整数を <code>float</code> に変換すると小数部がない数値が得られるので，この演算は常にノーオペレーションになります。
<code>Math.round()</code>に渡される値を生成した演算が浮動小数点演算を使用して実行することを意図した可能性が高いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ICAST_INT_CAST_TO_DOUBLE_PASSED_TO_CEIL">
<ShortDescription>整数値を double にキャストして Math.ceil() に渡している</ShortDescription>
<LongDescription>整数値を double にキャストして，Math.ceil() に渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは整数値 (たとえば， <code>int</code> や <code>long</code>) を倍精度浮動小数点に変換してから，その結果を <code>Math.ceil()</code> に渡しています。
整数を <code>double</code> に変換すると小数部がない数値が得られるので，この演算は常にノーオペレーションになります。
<code>Math.ceil()</code>に渡される値を生成した演算が倍精度浮動小数点演算を使用して実行することを意図した可能性が高いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ICAST_IDIV_CAST_TO_DOUBLE">
<ShortDescription>整数の除算の結果を double または float にキャストしている</ShortDescription>
<LongDescription>整数の除算の結果を double または float にキャストしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは整数の除算の結果を <code>double</code> または <code>float</code> にキャストしています。
整数で除算をすることは，ゼロに最も近い整数値まで結果を切り捨てます。
結果が <code>double</code> にキャストされたという事実は，この精度が維持されるべきだったことを示唆しています。
おそらく意味されたことは，除算を実行する前にオペランドの1つまたは両方を <code>double</code> にキャストすることでした。<br>
次に例を示します。
</p>
<pre><code>int x = 2;
int y = 5;
// Wrong: yields result 0.0
double value1 = x / y;
// Right: yields result 0.4
double value2 = x / (double) y;
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION">
<ShortDescription>HttpSession への非直列化可能オブジェクトの格納</ShortDescription>
<LongDescription>非直列化可能オブジェクト {2} を HttpSession に格納しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>HttpSession</code> に非直列化可能オブジェクトを格納していると思われます。
このセッションが不活性化されるか移行したなら，エラーを招きます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_NONSERIALIZABLE_OBJECT_WRITTEN">
<ShortDescription>ObjectOutput に書き込まれる非直列化可能オブジェクト</ShortDescription>
<LongDescription>非直列化可能オブジェクト {2} が ObjectOutput に書き込まれています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>ObjectOutput.writeObject</code> に非直列化可能オブジェクトを渡していると思われます。
このオブジェクトが本当に非直列化可能なら，エラーを招きます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_USES_NEWLINE">
<ShortDescription>書式文字列は \n よりも %n を使用すべき</ShortDescription>
<LongDescription>書式文字列は，\n よりも %n を使用すべきです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この書式文字列は改行文字 (<code>\n</code>) が含まれています。
一般的に書式文字列には <code>%n</code> を使用することがより望ましいです。<code>%n</code> は，プラットフォーム特有の行セパレータを作り出します。
Java 15 複数行テキスト ブロック
<code>String value = """
first line%n\
second line%n\
""";</code>
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_PRIMITIVE_ARRAY_PASSED_TO_OBJECT_VARARG">
<ShortDescription>可変長引数を期待しているメソッドにプリミティブ型の配列を渡している</ShortDescription>
<LongDescription>可変長引数のメソッド {3} に {2} を渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは可変長引数をとるメソッドにプリミティブ型の配列を渡しています。
これはプリミティブ型の配列を保持するために長さが1の配列を作成してメソッドに渡します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_EQUALS_METHOD_SHOULD_WORK_FOR_ALL_OBJECTS">
<ShortDescription>equals メソッドは引数の型を仮定すべきではない</ShortDescription>
<LongDescription>{0} のための equals メソッドは，引数の型が {0.givenClass} だと仮定しています。</LongDescription>
<Details>
<![CDATA[
<p>
<code>equals(Object o)</code> メソッドは， <code>o</code> の型についてどんな仮定もするべきではありません。
<code>o</code> が <code>this</code> と同じ型ではないなら単に <code>false</code> を返すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_BAD_CAST_TO_ABSTRACT_COLLECTION">
<ShortDescription>抽象コレクションへの疑わしいキャスト</ShortDescription>
<LongDescription>Collection から抽象クラス {3} への疑わしいキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>Collection</code> を抽象コレクションにキャストしています (たとえば <code>List</code> ， <code>Set</code> ， <code>Map</code>)。
オブジェクトがキャストする型であるということが保証されていることを確認してください。
必要とするコレクションの反復処理ができるなら <code>Set</code> または <code>List</code> にキャストする必要はありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_IMPOSSIBLE_CAST_PRIMITIVE_ARRAY">
<ShortDescription>プリミティブ型の配列を含んでいる不可能なキャスト</ShortDescription>
<LongDescription>プリミティブ型の配列を含んでいる不可能なキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このキャストは，常に <code>ClassCastException</code> をスローします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_IMPOSSIBLE_CAST">
<ShortDescription>不可能なキャスト</ShortDescription>
<LongDescription>{2} から {3} への不可能なキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このキャストは，常に <code>ClassCastException</code> をスローします。
SpotBugs は， <code>instanceof</code> チェックから型情報を調査して，メソッドからの戻り値とフィールドからロードされた値の型について，より多くの正確な情報を使用します。
したがって，宣言された変数の型にはより多くの正確な情報があるかもしれないしれません。
また，キャストが常に実行時例外をスローするのかを決定するために利用する可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_IMPOSSIBLE_DOWNCAST">
<ShortDescription>不可能なダウンキャスト</ShortDescription>
<LongDescription>{2} から {3} への不可能なダウンキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このキャストは，常に <code>ClassCastException</code> をスローします。
解析は，キャストしている値の正確な型がわかっていると信じていて，サブタイプへダウンキャストしようとする試みは， <code>ClassCastException</code> のスローによって常に失敗します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY">
<ShortDescription>toArray メソッドの結果の不可能なダウンキャスト</ShortDescription>
<LongDescription>{3} への toArray メソッドの結果の不可能なダウンキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>toArray</code> メソッドの呼び出し結果を <code>Object[]</code> ではなく具体的な型のコレクションでキャストしています。
</p>
<pre><code>String[] getAsArray(Collection<String> c) {
return (String[]) c.toArray();
}
</code></pre>
<p>
これは通常 <code>ClassCastException</code> をスローして失敗します。
ほとんどすべてのコレクションの <code>toArray</code> メソッドは， <code>Object[]</code> を返します。
<code>Collection</code> オブジェクトは宣言された総称型コレクションの参照がないので，本当に何もできません。
コレクションから特定の型の配列を得る正しい方法は， <code>c.toArray(new String[]);</code> または <code>c.toArray(new String[c.size()]);</code> (後者はわずかにより効率的です) を使用することです。
これに対する1つの共通の知られている例外があります。
<code>Arrays.asList(...)</code>によって返されるリストの <code>toArray()</code> メソッドは共変型配列を返します。
たとえば， <code>Arrays.asArray(new String[] { "a" }).toArray()</code> は <code>String []</code> を返します。
SpotBugs はそのようなケースを検出して抑止しようとしますが，見落としているかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_INSTANCEOF">
<ShortDescription>null とわかっている値をその型のインスタンスなのか確かめている</ShortDescription>
<LongDescription>null とわかっている値を {2} のインスタンスなのか確かめています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
チェックされている値が <code>null</code> であることが保証されているので， <code>instanceof</code> は常に <code>false</code> を返します。
これは安全で，誤解や論理エラーを指摘していないことを確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_NULL_INSTANCEOF" deprecated="true"> <!-- deprecated in favor of NP_NULL_INSTANCEOF -->
<ShortDescription>A known null value is checked to see if it is an instance of a type</ShortDescription>
<LongDescription>A known null value is checked to see if it is an instance of {2} in {1}</LongDescription>
<Details>
<![CDATA[
<p>
This instanceof test will always return false, since the value being checked is guaranteed to be null.
Although this is safe, make sure it isn't
an indication of some misunderstanding or some other logic error.
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_IMPOSSIBLE_INSTANCEOF">
<ShortDescription>常に false を返す instanceof</ShortDescription>
<LongDescription>{2} が {3} である可能性がないので，instanceof は常に false を返します。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この <code>instanceof</code> は常に <code>false</code> を返します。これは安全で，誤解や論理エラーを指摘していないことを確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_VACUOUS_INSTANCEOF">
<ShortDescription>常に true を返す instanceof</ShortDescription>
<LongDescription>{2} は {3} のインスタンスなので instanceof は常にすべての非 null 値に対して true を返します。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>instanceof</code> は常に <code>true</code> を返します (テストしている値が <code>null</code> ではないかぎり)。
これは安全で，誤解や論理エラーを指摘していないことを確認してください。
本当に <code>null</code> なのか値をテストしたいなら，多分， <code>instanceof</code> ではなく <code>null</code> テストをしたほうが良く，より明確になります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_UNCONFIRMED_CAST">
<ShortDescription>未チェック/未確認のキャスト</ShortDescription>
<LongDescription>{2} から {3} への未チェック/未確認のキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このキャストはチェックされていません。すべての型のインスタンスをキャストする型へキャストできるわけではありません。
プログラムのロジックがこのキャストが失敗しないことを確実に確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_UNCONFIRMED_CAST_OF_RETURN_VALUE">
<ShortDescription>メソッドからの戻り値の未チェック/未確認のキャスト</ShortDescription>
<LongDescription>{2} からの {3} 戻り値への未チェック/未確認のキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはメソッドの戻り値の未確認のキャストを実行しています。
コードは，キャストが安全であることが保証されるようにメソッドを呼び出しているかもしれませんが，SpotBugs はキャストが安全であることを検証できません。
プログラムのロジックがこのキャストが失敗しないことを確実に確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_BAD_CAST_TO_CONCRETE_COLLECTION">
<ShortDescription>具象コレクションへの疑わしいキャスト</ShortDescription>
<LongDescription>{2} から {3} への疑わしいキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは抽象コレクション (たとえば， <code>Collection</code> ， <code>List</code> ， <code>Set</code>) を特定の具象実装 (たとえば， <code>ArrayList</code> ， <code>HashSet</code>) にキャストしています。
これは正しくないかもしれません。そして，将来の時点で他の具象実装への切り替えをとても困難にするので，脆弱なコードになるかもしれません。
そうするための特別な理由がないかぎり抽象コレクションクラスを使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RE_POSSIBLE_UNINTENDED_PATTERN">
<ShortDescription>正規表現のために使われている "." または "|"</ShortDescription>
<LongDescription>正規表現で "." または "|" を使用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>String</code> 機能が呼び出されていて， <code>.</code> または <code>|</code> が引数として正規表現を取るパラメータに渡されています。
これは意図したことですか?
たとえば
</p>
<ul>
<li><code>s.replaceAll(".", "/")</code> は，すべての文字が '/' 文字に置換された <code>String</code> を返す</li>
<li><code>s.split(".")</code> は，常に長さが0の <code>String</code> 配列を返す</li>
<li><code>"ab|cd".replaceAll("|", "/")</code> は，"/a/b/|/c/d/" を返す</li>
<li><code>"ab|cd".split("|")</code> は，6個の要素がある配列を返す: [, a, b, |, c, d]</li>
</ul>
]]>
</Details>
</BugPattern>
<BugPattern type="RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">
<ShortDescription>正規表現のための無効な構文</ShortDescription>
<LongDescription>正規表現のための無効な構文です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは正規表現の構文によると無効である正規表現を使用しています。
この文が実行されるとき <code>PatternSyntaxException</code> をスローします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RE_CANT_USE_FILE_SEPARATOR_AS_REGULAR_EXPRESSION">
<ShortDescription>正規表現のために使われている File.separator</ShortDescription>
<LongDescription>File.separator が正規表現のために使われています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは正規表現が必要な場所で， <code>File.separator</code> を使用しています。
これは <code>File.separator</code> がバックスラッシュである Windows プラットフォームでは失敗します。
バックスラッシュは正規表現ではエスケープ文字として解釈されます。
その他の選択肢としては， <code>File.separator</code> の代わりに <code>File.separatorChar=='\\' ? "\\\\" : File.separator</code> を使用できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DLS_OVERWRITTEN_INCREMENT">
<ShortDescription>上書きされたインクリメント</ShortDescription>
<LongDescription>上書きされたインクリメントです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはインクリメント演算 (たとえば， <code>i++</code>) を実行してすぐに上書きしています。
たとえば， <code>i = i++</code> は元の値をインクリメントした値で上書きします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ICAST_QUESTIONABLE_UNSIGNED_RIGHT_SHIFT">
<ShortDescription>符号なし右シフトを short/byte にキャストしている</ShortDescription>
<LongDescription>符号なし右シフトを short/byte にキャストしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは符号なしキャストの実行結果を <code>short</code> または <code>byte</code> にキャストしています。結果の上位ビットは捨てられます。
上位ビットが捨てられるので，符号付きと符号なし右シフト (シフトのサイズによって) との違いがないかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BSHIFT_WRONG_ADD_PRIORITY">
<ShortDescription>シフト演算の正しくない構文解析の可能性がある</ShortDescription>
<LongDescription>シフト演算の正しくない構文解析の可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
コードは <code>(x << 8 + y)</code> のような演算を行います。
これは正しいかもしれませんが，おそらく <code>(x << 8) + y</code> を行うことを意図していました。
しかし，シフト演算は優先順位が低いので，実際には <code>x << (8 + y)</code> として構文解析されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ICAST_BAD_SHIFT_AMOUNT">
<ShortDescription>32ビット int の-31から31の範囲を超えた量によるシフト</ShortDescription>
<LongDescription>32ビット int を {2} ビットでシフトしました。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは32ビット int の-31から31の範囲を超えた量でシフトを実行しています。
これの効果は，どのくらいシフトするのかを決めるために整数値の下位5ビット (32で割った余り) を使用することです (たとえば，40ビットでシフトすることは8ビットでシフトすることと同じで，32ビットでシフトすることは0ビットでシフトすることと同じです)。
これはおそらく期待されたことではなく，少なくとも紛らわしいです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IM_MULTIPLYING_RESULT_OF_IREM">
<ShortDescription>整数剰余の結果の整数乗算</ShortDescription>
<LongDescription>整数剰余の結果の整数乗算。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは整数剰余の結果に整数定数を乗算しています。
紛らわしい演算子の優先順位がないことを確実にしてください。
たとえば， <code>i % 60 * 1000</code> は， <code>i % (60 * 1000)</code> ではなく <code>(i % 60) * 1000</code> となります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_INVOKING_HASHCODE_ON_ARRAY">
<ShortDescription>配列で hashCode メソッドを呼び出している</ShortDescription>
<LongDescription>配列で hashCode メソッドを呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは配列で <code>hashCode</code> メソッドを呼び出しています。
配列で <code>hashCode</code> メソッドを呼び出すことは， <code>System.identityHashCode</code> と同じ値を返すので，内容と配列の長さを無視します。
配列 <code>a</code> の内容によるハッシュコードを必要とするなら， <code>java.util.Arrays.hashCode(a)</code> を使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_INVOKING_TOSTRING_ON_ARRAY">
<ShortDescription>配列で toString メソッドを呼び出している</ShortDescription>
<LongDescription>{2.givenClass} で toString メソッドを呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは配列で <code>toString</code> メソッドを呼び出しています。「[C@16f0472」のようなかなり役に立たない結果を生成します。
<code>Arrays.toString()</code> を使用して，配列の内容を読み取り可能な文字列に変換することを検討してください。<br>
『Programming Puzzlers』の第3章，パズル12を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_INVOKING_TOSTRING_ON_ANONYMOUS_ARRAY">
<ShortDescription>名前のない配列で toString メソッドを呼び出している</ShortDescription>
<LongDescription>名前のない配列で toString メソッドを呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは無名の配列で <code>toString</code> メソッドを呼び出しています。「[C@16f0472」のようなかなり役に立たない結果を生成します。
<code>Arrays.toString()</code> を使用して，配列の内容を読み取り可能な文字列に変換することを検討してください。<br>
『Programming Puzzlers』の第3章，パズル12を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IM_AVERAGE_COMPUTATION_COULD_OVERFLOW">
<ShortDescription>平均の計算はオーバーフローする可能性がある</ShortDescription>
<LongDescription>平均の計算は，オーバーフローする可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは除算か符号付き右シフトを使用して2つの整数の平均を計算して，結果を配列の添字として使用しています。
平均値が非常に大きいならオーバーフローする可能性があります (結果として負の平均の計算になる)。
結果が負ではないことを意図していたなら，その代わりに符号なし右シフトを使用できます。
つまり， <code>(low+high)/2</code> ではなく <code>(low+high) >>> 1</code> を使用してください。
</p>
<p>
このバグは，二分探索とマージソートの多くの以前の実装で存在します。
Martin Buchholz が <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6412541">JDK ライブラリのバグを発見して修正しています</a>。
Joshua Bloch が <a href="http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html">バグパターンとして公表しました</a>。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IM_BAD_CHECK_FOR_ODD">
<ShortDescription>負数で機能しない奇数チェック</ShortDescription>
<LongDescription>負数で機能しない奇数チェックです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは <code>x % 2 == 1</code> を使用して値が負数なのか確かめていますが，負数 (たとえば， <code>(-5) % 2 == -1</code>) なので機能しません。
奇数チェックを意図しているなら， <code>(x & 1) == 1</code> または <code>x % 2 != 0</code> を使用することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_HARDCODED_ABSOLUTE_FILENAME">
<ShortDescription>ハードコードされた絶対パス名への参照がある</ShortDescription>
<LongDescription>ハードコードされた絶対パス名への参照があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはハードコードされた絶対パス名を使用して <code>File</code> オブジェクトを構築しています (たとえば <code>new File("/home/dannyc/workspace/j2ee/src/share/com/sun/enterprise/deployment");</code>)。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_BAD_MONTH">
<ShortDescription>月のための間違った定数値</ShortDescription>
<LongDescription>間違った月の値 {2} を {3} に渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはメソッドに0から11の範囲外の月定数値を渡しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_USELESS_SUBSTRING">
<ShortDescription>substring(0) の呼び出しは元の値を返す</ShortDescription>
<LongDescription>{1} は，元の値を返す substring(0) を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
このコードは文字列で <code>substring(0)</code> を呼び出していますが，元の値を返します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_CALLING_NEXT_FROM_HASNEXT">
<ShortDescription>hasNext メソッドで next メソッドを呼び出している</ShortDescription>
<LongDescription>{1} は，{2.givenClass} を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
<code>hasNext</code> メソッドは， <code>next</code> メソッドを呼び出しています。
<code>hasNext</code> メソッドは，イテレータの状態を変更することになっていないので，ほぼ確実に間違っています。
<code>next</code> メソッドがイテレータの状態を変更することになっています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SWL_SLEEP_WITH_LOCK_HELD">
<ShortDescription>ロックを保持して Thread.sleep() を呼び出しているメソッド</ShortDescription>
<LongDescription>{1} は，ロックを保持して Thread.sleep() を呼び出しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，ロックを保持して， <code>Thread.sleep()</code> を呼び出しています。
他のスレッドがロックを獲得するために待機しているかもしれないので，ひどい性能とスケーラビリティ，またはデッドロックの原因になるかもしれません。
ロックで <code>wait</code> メソッドを呼び出すことはかなり良い考えで，ロックを解除して他のスレッドが実行するのを許可します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DB_DUPLICATE_BRANCHES">
<ShortDescription>2つの分岐のために同じコードを使用しているメソッド</ShortDescription>
<LongDescription>{1} は，2つの分岐のために同じコードを使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，条件分岐の2つの分岐を実装するために同じコードを使用しています。これがコーディングミスではないことを確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DB_DUPLICATE_SWITCH_CLAUSES">
<ShortDescription>switch 文の2つの case のために同じコードを使用しているメソッド</ShortDescription>
<LongDescription>{1} は，switch 文の2つの case のために同じコードを使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>switch</code> 文の2つの <code>case</code> を実装するために同じコードを使用しています。
複製コードの <code>case</code> かもしれないし，コーディングミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IMA_INEFFICIENT_MEMBER_ACCESS">
<ShortDescription>所有クラスの private メンバ変数にアクセスしているメソッド</ShortDescription>
<LongDescription>{1} は，所有クラスの private メンバ変数にアクセスしています。</LongDescription>
<Details>
<![CDATA[
<p>
この内部クラスのメソッドは，所有クラスの <code>private</code> メンバ変数への読み書きか，所有クラスの <code>private</code> メソッドを呼び出しています。
コンパイラはこの <code>private</code> メンバにアクセスするための特別なメソッドを生成しなければなりないので，効率を悪化させる原因になります。
メンバ変数またはメソッドの保護を緩和することは，コンパイラが正常なアクセスとして扱うのを許可します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="XFB_XML_FACTORY_BYPASS">
<ShortDescription>XMLインタフェースの特定の実装のインスタンスを作成しているメソッド</ShortDescription>
<LongDescription>{1} は，XMLインタフェースの特定の実装のインスタンスを作成しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，XMLインタフェースの特定の実装のインスタンスを作成しています。
提供されたファクトリクラスを使用してオブジェクトを作成して実行時に実装を変更できるようにすることが望ましいです。<br>
詳細は，次を参照してください。
</p>
<ul>
<li><code>javax.xml.parsers.DocumentBuilderFactory</code></li>
<li><code>javax.xml.parsers.SAXParserFactory</code></li>
<li><code>javax.xml.transform.TransformerFactory</code></li>
<li><code>org.w3c.dom.Document.createXXXX</code></li>
</ul>
]]>
</Details>
</BugPattern>
<BugPattern type="USM_USELESS_SUBCLASS_METHOD">
<ShortDescription>親クラスのメソッドに過剰に委譲しているメソッド</ShortDescription>
<LongDescription>{1} は，親クラスのメソッドに過剰に委譲しています。</LongDescription>
<Details>
<![CDATA[
<p>
この派生メソッドは，単に受け取られる正確なパラメータを渡している同じスーパークラスのメソッドを呼び出すだけです。
このメソッドは，付加価値が与えられないので除去できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="USM_USELESS_ABSTRACT_METHOD">
<ShortDescription>実装されたインタフェースで既に定義された抽象メソッド</ShortDescription>
<LongDescription>抽象メソッド {1} は，実装されたインタフェースで既に定義されています。</LongDescription>
<Details>
<![CDATA[
<p>
この抽象メソッドは，この抽象クラスによって実装されるインタフェースで既に定義されています。
このメソッドは，付加価値が与えられないので除去できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="CI_CONFUSED_INHERITANCE">
<ShortDescription>final なクラスが protected フィールドを宣言している</ShortDescription>
<LongDescription>クラス {0} は，final なのに protected フィールド {1} が宣言されています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>final</code> と宣言されていますが，フィールドは <code>protected</code> と宣言されています。
クラスは <code>final</code> なので派生できません。<code>protected</code> の使用は紛らわしいです。
フィールドのためのアクセス修飾子は，フィールドの真の用途を表すため， <code>private</code> か <code>public</code> に変更すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">
<ShortDescription>論理式で boolean リテラル値を代入しているメソッド</ShortDescription>
<LongDescription>{1} は，論理式で boolean リテラル値を代入しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは， <code>if</code> または <code>while</code> の式の中の <code>boolean</code> 変数に <code>boolean</code> リテラル値 (<code>true</code> または <code>false</code>) を代入しています。
おそらく，これは <code>=</code> による代入ではなく， <code>==</code> を使用して論理比較をすることになっていました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VR_UNRESOLVABLE_REFERENCE">
<ShortDescription>解決できないクラス，メソッドへの参照</ShortDescription>
<LongDescription>{0} による {1} への解決できない参照。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは，解析されているライブラリに対して解決されないクラスまたはメソッドを参照しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="GC_UNCHECKED_TYPE_IN_GENERIC_CALL">
<ShortDescription>検査されない型への総称呼び出し</ShortDescription>
<LongDescription>型 {3.givenClass} が期待されているところに与えられた型 Object の検査されない引数。{1}</LongDescription>
<Details>
<![CDATA[
<p>
総称型パラメータからの特定の型が予想される <code>Object</code> 型をコンパイルするとき，総称型コレクションメソッドへの呼び出しは引数を渡します。
したがって，標準の Java 型システムも静的解析もパラメータとして渡されているオブジェクトが適切な型かどうかに関する有用な情報を提供できません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="GC_UNRELATED_TYPES">
<ShortDescription>型パラメータとメソッド引数に関係がない</ShortDescription>
<LongDescription>{2.givenClass} は，期待された引数の型 {3.givenClass} と互換性がありません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
総称型コレクションメソッドへの呼び出しにコレクションのパラメータとは互換性のないクラスの引数があります (すなわち，引数の型は総称型引数に対応するスーパタイプでもサブタイプでもありません)。
したがって，コレクションにはここで使用されたメソッド引数と等価であるどんなオブジェクトも含まれていません。
多分間違った値がメソッドに渡されています。
一般的に2つの無関係なクラスのインスタンスは等価ではありません。
たとえば， <code>Foo</code> と <code>Bar</code> クラスがサブタイプによって関係がないなら， <code>Foo</code> のインスタンスは <code>Bar</code> のインスタンスと等価のはずがありません。
その他の問題で対称的ではない <code>equals</code> メソッドになる可能性が高いです。
たとえば， <code>Foo</code> が <code>String</code> と等価であるように <code>Foo</code> クラスを定義するなら， <code>String</code> は <code>String</code> だけと等価であるので， <code>equals</code> メソッドは対称的ではありません。
</p>
<p>
まれに，非対称 <code>equals</code> メソッドを定義して，まだ，何とかそれらのコードを機能させています。
APIのどれも文書化していないか，保証もしていないが， <code>Collection<String></code> に <code>Foo</code> があるかどうか調べたいなら，
引数の <code>equals</code> メソッド (たとえば， <code>Foo</code>クラスの <code>equals</code> メソッド) を使用して等価性をチェックします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_COLLECTIONS_SHOULD_NOT_CONTAIN_THEMSELVES">
<ShortDescription>コレクションは自分自身を含めるべきではない</ShortDescription>
<LongDescription>コレクションは，{2.givenClass} への呼び出しで自分自身を含めるべきはない。</LongDescription>
<Details>
<![CDATA[
<p>
この総称型コレクションメソッドへの呼び出しはコレクションに自分自身が含まれている場合 (たとえば， <code>s.contains(s)</code> が <code>true</code>) にだけ意味があります。
これが本当だとは思えないし，もし本当なら問題の原因になります (たとえば，無限再帰になっているハッシュコードの計算)。
間違ったパラメータが渡されている可能性が高いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_VACUOUS_SELF_COLLECTION_CALL">
<ShortDescription>コレクションへの無意味な呼び出し</ShortDescription>
<LongDescription>コレクション c に対して c.{2.name}(c) を呼び出すことは意味がありません。</LongDescription>
<Details>
<![CDATA[
<p>
この呼び出しは意味がありません。
どんなコレクション <code>c</code> も <code>c.containsAll(c)</code> を呼び出すことは常に <code>true</code> であるべきです。
そして， <code>c.retainAll(c)</code> は効果があるはずがありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="PZ_DONT_REUSE_ENTRY_OBJECTS_IN_ITERATORS">
<ShortDescription>繰り返しでエントリオブジェクトを再利用しない</ShortDescription>
<LongDescription>{0} は Iterator と Map.Entry の両方があります。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは， <code>Iterator</code> と <code>Map.Entry</code> で基底 <code>Map</code> のビューを返すことを許可された両方の <code>entrySet</code> メソッドがあります。
この巧妙なアイデアは， <code>Map</code> 実装で使用されましたが，厄介なコーディングミスの可能性を取り込みました。
<code>Map m</code> が <code>entrySet</code> のためのそのような反復子を返すならば， <code>c.addAll(m.entrySet())</code> はひどく間違っているでしょう。
OpenJDK 1.7 の すべての <code>Map</code> 実装はこれを回避するために書き直されました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_ENTRY_SETS_MAY_REUSE_ENTRY_OBJECTS">
<ShortDescription>エントリセットの要素を加えることは，Entry オブジェクトの再利用のために失敗するかもしれない</ShortDescription>
<LongDescription>エントリセットの要素を加えることは，{2.simpleClass} の再利用のために失敗するかもしれません。{1} の Entry オブジェクト</LongDescription>
<Details>
<![CDATA[
<p>
<code>entrySet</code> メソッドは，一つの <code>Entry</code> オブジェクトを再利用し，反復中に返される基底 <code>Map</code> のビューを返すことが許可されています。
Java 1.6 の時点で， <code>IdentityHashMap</code> と <code>EnumMap</code> の両方がそうしました。
そのような <code>Map</code> を通して繰り返すとき，エントリ値は次の繰り返しへ進むまでが有効です。
たとえば， <code>addAll</code> メソッドにそのような <code>entrySet</code> を渡そうと試みるのは，ひどく間違っているでしょう。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_USING_REMOVEALL_TO_CLEAR_COLLECTION">
<ShortDescription>コレクションを消去するために removeAll メソッドを使用しない</ShortDescription>
<LongDescription>コレクションを消去するために removeAll メソッドを使用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
コレクション <code>c</code> からすべての要素を除去したいなら， <code>c.removeAll(c)</code> ではなく <code>c.clear</code> を使用してください。
コレクションを消去するために <code>c.removeAll(c)</code> を呼び出すことは，それほど明確ではなく，タイプミスからの誤りに影響されやすく，効率的ではなく，いくつかのコレクションでは， <code>ConcurrentModificationException</code> をスローするかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="STCAL_STATIC_CALENDAR_INSTANCE">
<ShortDescription>static Calendar フィールド</ShortDescription>
<LongDescription>{1} は，java.util.Calendar 型の static フィールドです。それはスレッドセーフではありません。</LongDescription>
<Details>
<![CDATA[
<p>
たとえ JavaDoc にそれに関する手がかりがないとしても， <code>Calendar</code> はマルチスレッドでの使用は本質的に安全でありません。
正しい同期化をしないでスレッド境界の向こうで1つのインスタンスを共有することは，アプリケーションの動作が不安定になります。
JDK 5.0に比べて JDK 1.4 のほうが問題が表面化するように思われ，おそらく <code>sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate()</code> の <code>ArrayIndexOutOfBoundsExceptions</code> や <code>IndexOutOfBoundsExceptions</code> がランダムに発生します。
</p>
<p>
直列化問題も経験するかもしれません。
</p>
<p>
インスタンスフィールドを使用することを推奨します。
</p>
<p>
詳細については， <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6231579">JDK Bug #6231579</a> や <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6178997">JDK Bug #6178997</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="STCAL_INVOKE_ON_STATIC_CALENDAR_INSTANCE">
<ShortDescription>static Calendar の呼び出し</ShortDescription>
<LongDescription>static な java.util.Calendar のメソッドを呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
たとえ JavaDoc にそれに関する手がかりがないとしても， <code>Calendar</code> はマルチスレッドでの使用は本質的に安全ではありません。
ディテクタは， <code>static</code> フィールドから得られた <code>Calendar</code> のインスタンスの呼び出しを発見しました。
これは疑わしく見えます。
</p>
<p>
詳細については， <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6231579">JDK Bug #6231579</a> や <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6178997">JDK Bug #6178997</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="STCAL_STATIC_SIMPLE_DATE_FORMAT_INSTANCE">
<ShortDescription>static DateFormat フィールド</ShortDescription>
<LongDescription>{1} は，java.text.DateFormat 型の static フィールドです。それはスレッドセーフではありません。</LongDescription>
<Details>
<![CDATA[
<p>
JavaDoc に書かれているように <code>DateFormat</code> はマルチスレッドでの使用は本質的に安全ではありません。
正しい同期化をしないでスレッド境界の向こうで1つのインスタンスを共有することは，アプリケーションの動作が不安定になります。
</p>
<p>
直列化問題も経験するかもしれません。
</p>
<p>
インスタンスフィールドを使用することを推奨します。
</p>
<p>
詳細については， <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6231579">JDK Bug #6231579</a> や <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6178997">JDK Bug #6178997</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE">
<ShortDescription>static DateFormat の呼び出し</ShortDescription>
<LongDescription>static な java.text.DateFormat のメソッドを呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
JavaDoc に書かれているように <code>DateFormat</code> はマルチスレッドでの使用は本質的に安全ではありません。
ディテクタは， <code>static</code> フィールドから得られた <code>DateFormat</code> のインスタンスの呼び出しを発見しました。
これは疑わしく見えます。
</p>
<p>
詳細については， <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6231579">JDK Bug #6231579</a> や <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6178997">JDK Bug #6178997</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_COMPARING_VALUES_WITH_INCOMPATIBLE_TYPE_QUALIFIERS">
<ShortDescription>互換性のない型修飾子による比較値</ShortDescription>
<LongDescription>型修飾子アノテーション {2.simpleName} が付けられた値がその修飾子がない値と等価性のために比較されています。</LongDescription>
<Details>
<![CDATA[
<p>
型修飾子アノテーションを指定した値がその修飾子のない値と比較しています。
</p>
<p>
より正確に， <code>when=ALWAYS</code> を指定した型修飾子アノテーションが付けられた値が同じ型修飾子で <code>when=NEVER</code> を指定する値と比較しています。
</p>
<p>
たとえば， <code>@NonNegative</code> は型修飾子アノテーション <code>@Negative(when=When.NEVER)</code> の略称とします。
次のコードは <code>return</code> 文が <code>@NonNegative</code> 値を要求するが， <code>@Negative</code> としてマークされている値を受け取るのでこの警告を生成します。
</p>
<pre><code>public boolean example(@Negative Integer value1, @NonNegative Integer value2) {
return value1.equals(value2);
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_ALWAYS_VALUE_USED_WHERE_NEVER_REQUIRED">
<ShortDescription>型修飾子アノテーションが付けられた値がその修飾子を付けてはならない値を必要とする場所で使われている</ShortDescription>
<LongDescription>型修飾子アノテーション {2.simpleName} が付けられた値がその修飾子を付けてはならない値を必要とする場所で使われています。</LongDescription>
<Details>
<![CDATA[
<p>
型修飾子アノテーションが付けられた値がその修飾子を付けてはならない値を必要とする場所で使われています。
</p>
<p>
より正確に， <code>when=ALWAYS</code> を指定した型修飾子アノテーションが付けられた値が到達することが保証されているか同じ型修飾子で <code>when=NEVER</code> を指定する場所で使用しています。
</p>
<p>
たとえば， <code>@NonNegative</code> は型修飾子アノテーション <code>@Negative(when=When.NEVER)</code> の略称とします。
次のコードは <code>return</code> 文が <code>＠NonNegative</code> 値を要求するが <code>＠Negative</code> としてマークされている値を受け取るのでこの警告を生成します。
</p>
<pre><code>public @NonNegative Integer example(@Negative Integer value) {
return value;
}
</code></pre>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_UNKNOWN_VALUE_USED_WHERE_ALWAYS_STRICTLY_REQUIRED">
<ShortDescription>型修飾子がない値が修飾子を必要とする場所で使われている</ShortDescription>
<LongDescription>{2.simpleName} アノテーションを必要とする場所で型修飾子がない値が使われています。</LongDescription>
<Details>
<![CDATA[
<p>
値が型修飾子アノテーションを必要とする方法で使われています。型修飾子は厳密なので，ツールは適切なアノテーションを指定していない値を拒絶します。
</p>
<p>
厳密なアノテーションを持つように値を矯正するには，戻り値に厳密なアノテーションを付ける識別関数を定義してください。
これはアノテーションが付けられていない値を厳密な型修飾子アノテーションを持つ値に変える唯一の方法です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_NEVER_VALUE_USED_WHERE_ALWAYS_REQUIRED">
<ShortDescription>型修飾子アノテーションが付けられていない値がその修飾子が付けられた値を必要とする場所で使われている</ShortDescription>
<LongDescription>型修飾子アノテーション {2.simpleName} が付けられていない値がその修飾子が付けられた値を必要とする場所で使われています。</LongDescription>
<Details>
<![CDATA[
<p>
型修飾子アノテーションが付けられていない値がその修飾子が付けられた値を必要とする場所で使われています。
</p>
<p>
より正確に， <code>when=NEVER</code> を指定した型修飾子アノテーションが付けられた値が同じ型修飾子で <code>when=ALWAYS</code> を指定する場所で使用されています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_MAYBE_SOURCE_VALUE_REACHES_ALWAYS_SINK">
<ShortDescription>型修飾子を付けていないかもしれない値がその型修飾子を必要とする方法で常に使われている</ShortDescription>
<LongDescription>{2.simpleName} アノテーションを付けていないかもしれない値がその型修飾子を必要とする方法で常に使われています。</LongDescription>
<Details>
<![CDATA[
<p>
型修飾子によって示された値のインスタンスではない可能性としてアノテーションが付けられた値です。
値は，その型修飾子によって示された値を必要とする方法で使われることが保証されています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_MAYBE_SOURCE_VALUE_REACHES_NEVER_SINK">
<ShortDescription>型修飾子を付けているかもしれない値がその型修飾子を禁止する方法で常に使われている</ShortDescription>
<LongDescription>{2.simpleName} アノテーションを付けているかもしれない値がその型修飾子を禁止する方法で常に使われています。</LongDescription>
<Details>
<![CDATA[
<p>
型修飾子によって示された値のインスタンスである可能性としてアノテーションが付けられた値です。
値は，その型修飾子によって示された値を禁止する方法で使われることが保証されています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_NEVER_SINK">
<ShortDescription>値は型修飾子を必要としないが，不明としてマークされている</ShortDescription>
<LongDescription>値は，{2.simpleName} を必要としませんが，明示的に {2.simpleName} に関して不明としてアノテーションが付けられています。</LongDescription>
<Details>
<![CDATA[
<p>
値は，型修飾子によって示された値ではないことを必要とする方法で使われています。
しかし，値はどこでその型修飾子がいるのか禁止されていのるかわからないと述べている明示的なアノテーションがあります。
使い方かアノテーションのどちらかが間違っています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_EXPLICIT_UNKNOWN_SOURCE_VALUE_REACHES_ALWAYS_SINK">
<ShortDescription>値は型修飾子を必要としているが，不明としてマークされている</ShortDescription>
<LongDescription>値は，常に {2.simpleName} を必要としていますが，明示的に {2.simpleName} に関して不明としてアノテーションが付けられています。</LongDescription>
<Details>
<![CDATA[
<p>
値は，常に型修飾子によって示された値であることを必要とする方法で使われています。
しかし，値はどこでその型修飾子が必要なのかわからないと述べている明示的なアノテーションがあります。
使い方かアノテーションのどちらかが間違っています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IO_APPENDING_TO_OBJECT_OUTPUT_STREAM">
<ShortDescription>オブジェクト出力ストリームへの追加は失敗に終わる</ShortDescription>
<LongDescription>オブジェクト出力ストリームへの追加は失敗に終わります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードはファイルを追加モードで開いて，オブジェクト出力ストリームの中で結果をラップしています。
これはファイルに格納された既存のオブジェクト出力ストリームに追加できないでしょう。
オブジェクト出力ストリームに追加したいなら，オブジェクト出力ストリームを開いておく必要があります。
</p>
<p>
追加モードでファイルを開き，オブジェクト出力ストリームで書き込むことができる唯一の状況は，
ファイルを読み出すときにランダムアクセスモードで開き，追加を開始するところまでバイトオフセットをシークすると計画した場合です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="WL_USING_GETCLASS_RATHER_THAN_CLASS_LITERAL">
<ShortDescription>クラスリテラルではなく getClass で同期化している</ShortDescription>
<LongDescription>クラスリテラルではなく getClass で同期化しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このインスタンスメソッドは， <code>this.getClass()</code> で同期化しています。
このクラスがサブクラス化されるなら，サブクラスはおそらく意図したことではないサブクラスのためにクラスオブジェクトで同期化します。
たとえば， <code>java.awt.Label</code> の次のコードを検討してください。
</p>
<pre><code>private static final String base = "label";
private static int nameCounter = 0;
String constructComponentName() {
synchronized (getClass()) {
return base + nameCounter++;
}
}
</code></pre>
<p>
<code>Label</code> のサブクラスは同じサブクラスで同期化しません。データレースを生じさせます。
代わりに，このコードは <code>Label.class</code> で同期化すべきです。
</p>
<pre><code>private static final String base = "label";
private static int nameCounter = 0;
String constructComponentName() {
synchronized (Label.class) {
return base + nameCounter++;
}
}
</code></pre>
<p>
Jason Mehrens によって寄贈されたバグパターン
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="OBL_UNSATISFIED_OBLIGATION">
<ShortDescription>ストリームやリソースのクリーンアップに失敗するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，{2} のクリーンアップに失敗するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，ストリーム，データベースオブジェクト，またはクリーンアップ操作を明示的に必要としている他のリソースのクリーンアップ (クローズする，片付ける) に失敗するかもしれません。
</p>
<p>
一般的にメソッドがストリープや他のリソースを開いたなら，メソッドはストリームやリソースがメソッドが戻る前にクリーンアップされることを確認するために <code>try-finally</code> ブロックを使用すべきです。
</p>
<p>
このバグパターンは，OS_OPEN_STREAM と ODR_OPEN_DATABASE_RESOURCE と基本的に同じですが異なる (そして，うまくいけばより良い) 静的解析技術に基づいています。
私たちは，このバグパターンの有効性についてのフィードバックを得ることに関心があります。
どちらかの方法でフィードバックを送ってください。
</p>
<ul>
<li><a href="https://github.com/spotbugs/spotbugs/blob/master/CONTRIBUTING.md">問題の報告</a></li>
<li><a href="https://github.com/spotbugs/discuss/issues?q=">メーリングリスト</a></li>
</ul>
<p>
特に，このバグパターンの誤検出抑制探索法は詳細にわたって調整されていないので，誤検出についてのレポートは我々の助けになります。
</p>
<p>
解析技術の説明は，Weimer と Necula による <i>Finding and Preventing Run-Time Error Handling Mistakes</i> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="OBL_UNSATISFIED_OBLIGATION_EXCEPTION_EDGE">
<ShortDescription>チェック例外でストリームやリソースのクリーンアップに失敗するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は，チェック例外で {2} のクリーンアップに失敗するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは，ストリーム，データベースオブジェクト，またはクリーンアップ操作を明示的必要としている他のリソースのクリーンアップ (クローズする，片付ける) に失敗するかもしれません。
</p>
<p>
一般的にメソッドがストリープや他のリソースを開いたなら，メソッドはストリームやリソースがメソッドが戻る前にクリーンアップされることを確認するために <code>try-finally</code> ブロックを使用すべきです。
</p>
<p>
このバグパターンは，OS_OPEN_STREAM と ODR_OPEN_DATABASE_RESOURCE と基本的に同じですが異なる (そして，うまくいけばより良い) 静的解析技術に基づいています。
私たちは，このバグパターンの有効性についてのフィードバックを得ることに関心があります。
どちらかの方法でフィードバックを送ってください。
</p>
<ul>
<li><a href="https://github.com/spotbugs/spotbugs/blob/master/CONTRIBUTING.md">問題の報告</a></li>
<li><a href="https://github.com/spotbugs/discuss/issues?q=">メーリングリスト</a></li>
</ul>
<p>
特に，このバグパターンの誤検出抑制探索法は詳細にわたって調整されていないので，誤検出についてのレポートは我々の助けになります。
</p>
<p>
解析技術の説明は，Weimer と Necula による <i>Finding and Preventing Run-Time Error Handling Mistakes</i> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FB_UNEXPECTED_WARNING">
<ShortDescription>SpotBugs からの予期しない/望ましくない警告</ShortDescription>
<LongDescription>予期しない/望ましくない {2} SpotBugs 警告。{1}</LongDescription>
<Details>
<![CDATA[
<p>
SpotBugs は， <code>@NoWarning</code> アノテーションが付けられたことにより予期しない/望ましくない警告を生成しました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FB_MISSING_EXPECTED_WARNING">
<ShortDescription>失われた SpotBugs からの予期した/望ましい警告</ShortDescription>
<LongDescription>失われた予期した/望ましい {2} SpotBugs 警告。{1}</LongDescription>
<Details>
<![CDATA[
<p>
SpotBugs は， <code>@ExpectedWarning</code> アノテーションが付けられたことにより予期した/望ましい警告が生成されませんでした。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_RETURN_VALUE_OF_PUTIFABSENT_IGNORED">
<ShortDescription>putIfAbsent の戻り値は無視されて putIfAbsent に渡した値は再利用された</ShortDescription>
<LongDescription>putIfAbsent の戻り値は無視されたが，{4} は再利用されました。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>putIfAbsent</code> メソッドは，1つの値が与えられたキー (非存在が成功するかどうかの第一の値) と関連することを確認するために使われます。
戻り値を無視して，渡された値への参照を保持するなら，マップ内のキーに関連付けられていない値を保持する危険性があります。
どれを使用するかが重要で，マップに格納されていないものを使うとプログラムは正しく動作しません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE">
<ShortDescription>ロガーの変更は OpenJDK の弱参照が原因で潜在的に失われる</ShortDescription>
<LongDescription>ロガーの変更は失われる可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
OpenJDK は，潜在的非互換性を取り入れました。特に， <code>java.util.logging.Logger</code> は振る舞いが変更されています。
強参照を使用する代わりに弱参照を内部的に使用しています。
これは妥当な変更ですが，残念ながらいくつかのコードは古い振る舞いに依存しています。ロガーの構成を変更すると，ロガーへの参照が削除されます。
これは，ガベージコレクタが自由にそのメモリを再利用できることを意味します。つまり，ロガーの構成が失われます。<br>
たとえば，次を検討してください。
</p>
<pre><code>public static void initLogging() throws Exception {
Logger logger = Logger.getLogger("edu.umd.cs");
logger.addHandler(new FileHandler()); // ロガーの構成の変更
logger.setUseParentHandlers(false); // 別のロガーの構成の変更
}
</code></pre>
<p>
ロガーの参照は，メソッドの終わり (メソッドは脱出しません) で失われるので，
<code>initLogging</code> の呼び出しの後でガベージコレクションの循環があるなら，ロガー構成は失われます (なぜなら <code>Logger</code> は弱参照を保持するだけなので)。
</p>
<pre><code>public static void main(String[] args) throws Exception {
initLogging(); // ファイルハンドラーをロガーに追加する
System.gc(); // ロガーの構成が失われる
Logger.getLogger("edu.umd.cs").info("Some message"); // 期待したようにファイルに記録されません
}
</code></pre>
<p>
Ulf Ochsenfahrt と Eric Fellheimer
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="AT_OPERATION_SEQUENCE_ON_CONCURRENT_ABSTRACTION">
<ShortDescription>並行抽象の呼び出しシーケンスはアトミックではないかもしれない</ShortDescription>
<LongDescription>{2} の呼び出しシーケンスは，アトミックではないかもしれません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードには並行抽象化 （たとえば，並行ハッシュマップ） の呼び出しシーケンスがあります。
これらの呼び出しはアトミックに実行されません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DM_DEFAULT_ENCODING">
<ShortDescription>デフォルトエンコーディングへの依存</ShortDescription>
<LongDescription>デフォルトエンコーディングへの依存を発見しました。{1}: {2}</LongDescription>
<Details>
<![CDATA[
<p>
<code>byte</code> から <code>String</code> (または <code>String</code> から <code>byte</code>) への変換で，デフォルトプラットフォームエンコーディングが適切だと仮定するメソッドの呼び出しを発見しました。
これはアプリケーションの振る舞いがプラットフォーム間で異なる原因となります。代替 API を使用して，文字セット名または <code>Charset</code> オブジェクトを明示的に指定して下さい。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_METHOD_PARAMETER_RELAXING_ANNOTATION">
<ShortDescription>メソッドはパラメータに nullness アノテーションを強化している</ShortDescription>
<LongDescription>メソッド {1} は，祖先メソッドの要件を緩和する nullness アノテーションをオーバーライドしています。</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，オーバーライドするメソッドの契約を常に実装すべきです。
したがって，メソッドが <code>@Nullable</code> としてマークされるパラメーターを取るならば，サブクラスでパラメーターを <code>@Nonnull</code> にしてメソッドをオーバーライドすべきでありません。
そうすると，メソッドが <code>null</code> パラメータを処理する必要があるという契約に違反します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_METHOD_PARAMETER_TIGHTENS_ANNOTATION">
<ShortDescription>メソッドはパラメータに nullness アノテーションを強化している</ShortDescription>
<LongDescription>メソッド {1} は，互換性がない方法で nullness アノテーションのパラメータ {2} をオーバーライドしています。</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，オーバーライドするメソッドの契約を常に実装すべきです。
したがって，メソッドが <code>@Nullable</code> としてマークされるパラメーターを取るならば，サブクラスでパラメーターを <code>@Nonnull</code> にしてメソッドをオーバーライドすべきでありません。
そうすると，メソッドが <code>null</code> パラメータを処理する必要があるという契約に違反します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_METHOD_RETURN_RELAXING_ANNOTATION">
<ShortDescription>メソッドは戻り値の nullness アノテーションを緩和している</ShortDescription>
<LongDescription>メソッド {1} は，互換性がない方法で戻り値の nullness アノテーションをオーバーライドしています。</LongDescription>
<Details>
<![CDATA[
<p>
メソッドは，オーバーライドするメソッドの契約を常に実装すべきです。
したがって，メソッドが <code>@Nonnull</code> 値を返すようにアノテーションが付けられているならば，サブクラスでメソッドが <code>@Nullable</code> または <code>@CheckForNull</code> 値を返すようにアノテーションが付けられたメソッドをオーバーライドすべきでありません。
そうすると，メソッドが <code>null</code> を返すべできではないという契約に違反します。
</p>
]]>
</Details>
</BugPattern>
<!--
**********************************************************************
BugCodes
**********************************************************************
-->
<BugCode abbrev="FS">書式文字列の問題</BugCode>
<BugCode abbrev="SKIPPED">スキップした解析</BugCode>
<BugCode abbrev="IL">無限ループ</BugCode>
<BugCode abbrev="VO">volatile の使用</BugCode>
<BugCode abbrev="UI">安全ではない継承</BugCode>
<BugCode abbrev="FL">浮動小数点精度の使用</BugCode>
<BugCode abbrev="TEST">プロトタイプと未完成のバグパターンのテスト</BugCode>
<BugCode abbrev="IMSE">疑わしい IllegalMonitorStateException のキャッチ</BugCode>
<BugCode abbrev="CN">クローン可能イディオムの間違った実装</BugCode>
<BugCode abbrev="CAA">共変配列代入</BugCode>
<BugCode abbrev="AT">原子性違反の可能性</BugCode>
<BugCode abbrev="FI">ファイナライザの間違った使用</BugCode>
<BugCode abbrev="ES">== や != を使用している文字列の等価性チェック</BugCode>
<BugCode abbrev="ML">更新されるフィールドで同期化 (可変ロック)</BugCode>
<BugCode abbrev="UG">同期化していない get メソッド，同期化している set メソッド</BugCode>
<BugCode abbrev="IO">入出力の問題</BugCode>
<BugCode abbrev="IC">初期化の循環</BugCode>
<BugCode abbrev="SI">疑わしいスタティックイニシャライザ</BugCode>
<BugCode abbrev="MSF">可変サーブレットフィールド</BugCode>
<BugCode abbrev="IS">一貫性のない同期化</BugCode>
<BugCode abbrev="Eq">equals() の実装に関する問題</BugCode>
<BugCode abbrev="Co">compareTo() の実装に関する問題</BugCode>
<BugCode abbrev="HE">等価なオブジェクトは，等価なハッシュコードを持たなければならない</BugCode>
<BugCode abbrev="AM">APIの誤用</BugCode>
<BugCode abbrev="Dm">疑わしいメソッドの使用</BugCode>
<BugCode abbrev="Bx">疑わしいプリミティブ値のボクシング</BugCode>
<BugCode abbrev="UR">コンストラクタで未初期化フィールドの読み出し</BugCode>
<BugCode abbrev="RR">InputStream.read() の戻り値の無視</BugCode>
<BugCode abbrev="NN">裸の notify()</BugCode>
<BugCode abbrev="UW">無条件の wait()</BugCode>
<BugCode abbrev="SP">スピンロック</BugCode>
<BugCode abbrev="DC">ダブルチェックパターン</BugCode>
<BugCode abbrev="Wa">ループの中にない wait()</BugCode>
<BugCode abbrev="No">notifyAll() ではなく notify() を使用している</BugCode>
<BugCode abbrev="DE">捨てられたか無視された例外</BugCode>
<BugCode abbrev="Ru">run() の呼び出し</BugCode>
<BugCode abbrev="It">イテレータの間違った定義</BugCode>
<BugCode abbrev="SnVI">Version ID のない直列化可能クラス</BugCode>
<BugCode abbrev="Se">直列化可能クラスの間違った定義</BugCode>
<BugCode abbrev="WS">writeObject() は同期化しているが，その他のメソッドは同期化していない</BugCode>
<BugCode abbrev="RS">readObject() を同期化している</BugCode>
<BugCode abbrev="SC">Thread.start() を呼び出すコンストラクタ</BugCode>
<BugCode abbrev="MS">可変 static フィールド</BugCode>
<BugCode abbrev="ME">可変列挙型フィールド</BugCode>
<BugCode abbrev="EI">内部表現を暴露するかもしれない配列を返すメソッド</BugCode>
<BugCode abbrev="Nm">紛らわしいメソッド名</BugCode>
<BugCode abbrev="SS">static にすべき読み出されないフィールド</BugCode>
<BugCode abbrev="UuF">未使用フィールド</BugCode>
<BugCode abbrev="UrF">読み出されないフィールド</BugCode>
<BugCode abbrev="UwF">書き込まれないフィールド</BugCode>
<BugCode abbrev="SIC">static にできる内部クラス</BugCode>
<BugCode abbrev="TLW">2つのロックを保持する wait()</BugCode>
<BugCode abbrev="RANGE">範囲チェック</BugCode>
<BugCode abbrev="RV">メソッドからの戻り値の間違った使用</BugCode>
<BugCode abbrev="LG">Logger の問題</BugCode>
<BugCode abbrev="IA">あいまいな呼び出し</BugCode>
<BugCode abbrev="HSC">巨大な文字列定数</BugCode>
<BugCode abbrev="HRS">HRS 脆弱性</BugCode>
<BugCode abbrev="PT">パストラバーサル</BugCode>
<BugCode abbrev="XSS">XSS 脆弱性</BugCode>
<BugCode abbrev="NP">null値 の利用</BugCode>
<BugCode abbrev="NOISE">偽のランダム警告</BugCode>
<BugCode abbrev="RpC">条件テストの繰り返し</BugCode>
<BugCode abbrev="OS">すべての経路でクローズされないストリーム</BugCode>
<BugCode abbrev="PZLA">結果がないことを示すために null より長さ0の配列を選ぶ</BugCode>
<BugCode abbrev="UCF">役に立たない制御フロー</BugCode>
<BugCode abbrev="RCN">null への冗長な比較</BugCode>
<BugCode abbrev="UL">すべての経路で解除されないロック</BugCode>
<BugCode abbrev="RC">疑わしい参照等価性の使用</BugCode>
<BugCode abbrev="EC">互換性のない型による等価性比較</BugCode>
<BugCode abbrev="MWN">ミスマッチの wait() か notify()</BugCode>
<BugCode abbrev="SA">役に立たない自己演算</BugCode>
<BugCode abbrev="INT">疑わしい整数式</BugCode>
<BugCode abbrev="BIT">疑わしいビット演算式</BugCode>
<BugCode abbrev="LI">同期化されていない遅延初期化</BugCode>
<BugCode abbrev="JLM">java.util.concurrent オブジェクトの同期化</BugCode>
<BugCode abbrev="UPM">決して呼び出されない private メソッド</BugCode>
<BugCode abbrev="UMAC">無名クラスの呼び出しできないメソッド</BugCode>
<BugCode abbrev="EI2">可変オブジェクトへの参照の格納</BugCode>
<BugCode abbrev="NS">疑わしい非短絡論理演算子の使用</BugCode>
<BugCode abbrev="ODR">すべての経路でクローズされないデータベースリソース</BugCode>
<BugCode abbrev="SBSC">ループの中で + 演算子を使用した文字列連結</BugCode>
<BugCode abbrev="IIL">ループの外に移動できる非効率なコード</BugCode>
<BugCode abbrev="IIO">非効率な String.indexOf(String) または String.lastIndexOf(String) の使用</BugCode>
<BugCode abbrev="ITA">効率が悪い collection.toArray(new Foo[0]) の使用</BugCode>
<BugCode abbrev="SW">Swing コーディング規約</BugCode>
<BugCode abbrev="IJU">誤って実装された JUnit TestCase</BugCode>
<BugCode abbrev="BOA">間違ってオーバーライドされた Adapter</BugCode>
<BugCode abbrev="SF">switch 文のフォールスルー</BugCode>
<BugCode abbrev="SIO">不必要な instanceof</BugCode>
<BugCode abbrev="BAC">間違ったアプレットのコンストラクタ</BugCode>
<BugCode abbrev="UOE">Object.equals() を使用する</BugCode>
<BugCode abbrev="STI">疑わしい Thread.interrupted()</BugCode>
<BugCode abbrev="DLS">ローカル変数への無効な代入</BugCode>
<BugCode abbrev="IP">無視されたパラメータ</BugCode>
<BugCode abbrev="MF">隠されたフィールド</BugCode>
<BugCode abbrev="WMI">効率が悪い Map イテレータ</BugCode>
<BugCode abbrev="ISC">インスタンス化された static クラス</BugCode>
<BugCode abbrev="REC">RuntimeException の捕捉</BugCode>
<BugCode abbrev="FE">浮動小数点の等価性テスト</BugCode>
<BugCode abbrev="UM">定数に関する不必要な Math</BugCode>
<BugCode abbrev="UC">役に立たないコード</BugCode>
<BugCode abbrev="CNT">既知の定数の雑な値</BugCode>
<BugCode abbrev="CD">循環依存関係</BugCode>
<BugCode abbrev="RI">冗長なインタフェース</BugCode>
<BugCode abbrev="MTIA">マルチスレッドでのインスタンスアクセス</BugCode>
<BugCode abbrev="PS">公開セマフォ</BugCode>
<BugCode abbrev="BSHIFT">間違ったシフト</BugCode>
<BugCode abbrev="ICAST">整数値からのキャスト</BugCode>
<BugCode abbrev="RE">正規表現</BugCode>
<BugCode abbrev="SQL">潜在的 SQL 問題</BugCode>
<BugCode abbrev="WL">間違ったオブジェクトでロックしている可能性がある</BugCode>
<BugCode abbrev="ESync">空の synchronized ブロック</BugCode>
<BugCode abbrev="QF">疑わしい for ループ</BugCode>
<BugCode abbrev="VA">可変長引数の問題</BugCode>
<BugCode abbrev="BC">オブジェクト参照の間違ったキャスト</BugCode>
<BugCode abbrev="IM">疑わしい整数計算</BugCode>
<BugCode abbrev="ST">static フィールドの誤用</BugCode>
<BugCode abbrev="JCIP">net.jcip アノテーションの違反</BugCode>
<BugCode abbrev="USELESS_STRING">役に立たない/無益な文字列生成</BugCode>
<BugCode abbrev="DMI">疑わしいメソッド呼び出し</BugCode>
<BugCode abbrev="PZ">Joshua Bloch と Neal Gafter による『Java Puzzlers』に影響を受けた警告</BugCode>
<BugCode abbrev="SWL">ロックを保持する sleep</BugCode>
<BugCode abbrev="J2EE">Java EE のエラー</BugCode>
<BugCode abbrev="DB">複製された分岐</BugCode>
<BugCode abbrev="IMA">効率が悪いメンバアクセス</BugCode>
<BugCode abbrev="XFB">XML ファクトリの迂回</BugCode>
<BugCode abbrev="USM">役に立たないサブクラスメソッド</BugCode>
<BugCode abbrev="CI">紛らわしい継承</BugCode>
<BugCode abbrev="QBA">疑わしい Boolean 代入</BugCode>
<BugCode abbrev="VR">バージョン互換性の問題</BugCode>
<BugCode abbrev="DP">doPrivileged の使用</BugCode>
<BugCode abbrev="GC">疑わしい総称型コレクションメソッドの呼び出し</BugCode>
<BugCode abbrev="STCAL">Calendar，DateFormat の static 使用</BugCode>
<BugCode abbrev="TQ">型修飾子アノテーションの一貫性のない使用</BugCode>
<BugCode abbrev="OBL">ストリームまたはリソースをクリーンアップする責務が満たされていない</BugCode>
<BugCode abbrev="FB">SpotBugs はメソッドで期待された警告を出さない</BugCode>
<BugCode abbrev="DL">共有オブジェクトを意図的でなくロックすることによる潜在的デッドロック</BugCode>
<BugCode abbrev="JUA">JUnitアサーションの問題</BugCode>
</MessageCollection>