hudson.plugins.findbugs.messages_ja.xml Maven / Gradle / Ivy
<?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>コア FindBugs プラグイン</ShortDescription>
<Details>
<![CDATA[
<p>
このプラグインには、すべての標準的な FindBugs ディテクタがあります。
</p>
]]>
</Details>
</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>
<!-- これを変えたら 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 チェックなど。
より多くの誤検出を受け入れました。
FindBugs の以前のバージョンでは、このカテゴリは 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.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>
このディテクタは、共有された組込み定数 (たとえば、String) の同期化を探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SynchronizeAndNullCheckField">
<Details>
<![CDATA[
<p>
このディテクタは、同期化されたフィールドを null チェックしているコード探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CheckImmutableAnnotation">
<Details>
<![CDATA[
<p>
このディテクタは、net.jcip.annotations.Immutable としてアノテーションが付けられたクラスのルール違反を探します。
</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>
このディテクタは、edu.umd.cs.findbugs.annotations.NoteSuppressWarnings アノテーションの使い方に基づく警告を抑止します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteAnnotationRetention">
<Details>
<![CDATA[
<p>
このディテクタは、Retention アノテーションを記録します。
</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.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>
このディテクタは、メソッド、フィールド、パラメータで @NonNull アノテーションを探します。
null かもしれない値が null でない値だけが使われるべき文脈で使われたときに FindNullDeref ディテクタで使われます。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteUnconditionalParamDerefs">
<Details>
<![CDATA[
<p>
このディテクタは、どのパラメータが無条件で null 値を利用するのかを決定するために、アプリケーションのすべてのメソッドを解析します。
この情報は、null 値がメソッドに渡されるかもしれない呼び出し場所を発見するために、後の解析パスで使われます。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NoteNonnullReturnValues">
<Details>
<![CDATA[
<p>
このディテクタは、どのメソッドが常に null でない値を返すかを決定するアプリケーションで、すべてのメソッドを解析します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BooleanReturnNull">
<Details>
<![CDATA[
<p>
このディテクタは、明示的に null 値を返す戻り型が Boolean のメソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BadUseOfReturnValue">
<Details>
<![CDATA[
<p>
このディテクタは、メソッドの戻り値が null でないのかチェックされた後に捨てられるケースを探します。
</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>
このディテクタは、volatile フィールドの使い方でバグパターンを探します。
</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のキーワードである assert や enum を名前として使用していないことをチェックします。
</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>
このディテクタは、クラスのフィールドを null にするファイナライザを探します。
どんな方法でもフィールドを null にすることは効果がなく、ガベージコレクタの助けになりません。
</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.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>
null の参照解除のためのノイズが多いディテクタです。コードの問題を見つける方法として使用するのではく、警告の妥当性または予測能力の実験でコントロールとして役に立つことを意図としました。
</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>
このディテクタは、doPrivileged ブロックの中で実行するべきコードを探します。
</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>
このディテクタは、フォールスルーがある switch 文を探します。
</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>
このディテクタは、IllegalMonitorStateException をキャッチする try-catch ブロックを探します。
</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>
このディテクタは、Cloneable クラスを書くためのイディオムの違反を探します。
</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>
このディテクタは、null とわかっている値のロードを探します。
</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>
このディテクタは、引数のない String コンストラクタのような無意味なメソッドの呼び出しを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.NumberConstructor">
<Details>
<![CDATA[
<p>
このディテクタは、Number コンストラクタのプリミティブ型の引数による呼び出しを探します。
</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>
このディテクタは、イテレータクラスの定義方法の問題を探します。
</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>
このディテクタは、== や != 演算子を使用している String オブジェクトの比較を探します。
</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>
このディテクタは、悪意のあるコードによって変更されるかもしれない static フィールドを探します。
</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>
このディテクタは、Serializable クラスの実装で潜在的な問題を探します。
</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>
このディテクタは、間違った for ループを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.ExplicitSerialization" >
<Details>
<![CDATA[
<p>
このディテクタは、このクラスが本当に直列化されるという証拠として readObject と writeObject を介して明示的な直列化を探します。
</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.FindNullDeref">
<Details>
<![CDATA[
<p>
このディテクタは、<code>NullPointerException</code> が発生するかもしれない場所を探します。
また、null に対する参照値の冗長な比較を探します。
</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>
このディテクタは、メソッドから脱出しないで、メソッドからのすべての経路でクローズされるように見えない入出力ストリームオブジェクトを探します。
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.PreferZeroLengthArrays">
<Details>
<![CDATA[
<p>
このディテクタは、配列か明示的に null 参照を返すメソッドを探します。
長さが0の配列を返すことは、この文脈において null 参照を返すより好ましいです。
</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(<code>java.util.concurrent</code>) のロックを獲得したのにメソッドからのすべての経路で解除されないロックを探します。
</p>
<p>
中速ディテクタです。
</p>
<p>
このディテクタを使用するために、補助クラスパスに <code>java.util.concurrent</code> パッケージ (またはパッケージ自体の解析) が必要であることに注意してください。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.FindRefComparison">
<Details>
<![CDATA[
<p>
このディテクタは、2つの参照値を == や != 演算子で比較している場所を探します。
<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>
このディテクタは、空の synchronized ブロックを探します。
</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>
このディテクタは、フィールドが volatile でない怠惰なフィールドの初期化を探します。
</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>
このディテクタは、決して呼び出されない private メソッドを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.StringConcatenation">
<Details>
<![CDATA[
<p>
このディテクタは、ループの中で + を使用している文字列連結を探します。
</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.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>の getXXX または setXXX メソッドの呼び出しを探します。
<code>ResultSet</code> の列インデックス番号は1で始まるので、これは常に間違いです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.SuperfluousInstanceOf">
<Details>
<![CDATA[
<p>
このディテクタは、判定が静的に行われる可能性がある instanceof 演算子を使用している型チェックを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.BadAppletConstructor">
<Details>
<![CDATA[
<p>
このディテクタは、Applet スタブに依存する親 Applet でメソッドを呼び出す Applet コンストラクタを探します。
このスタブは <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>
このディテクタは、switch 文で定数文字列以外の何かが引数として渡される 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>
このディテクタは、static メソッドしか定義していないクラスのオブジェクトを作成しているコードを探します。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.RuntimeExceptionCapture">
<Details>
<![CDATA[
<p>
このディテクタは、ブロックの中のコードが例外をスローしないのに例外をキャッチする catch 節を探します。
</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> の static メソッドを呼び出すコードを探します。
その代わりに定数を使用する方がより高速で、ときにはより正確です。
</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>
このディテクタは、同期化して <em>this</em> に対して <code>wait</code> メソッド、<code>notify</code> メソッド、<code>notifyAll</code> メソッドを使用する public クラスを探します。
これは public クラスの同期化実装を暴露することになります。public クラスの利用者は、利用者のクラスで public クラスのインスタンスを同期化オブジェクトとして使うかもしれません。
これはベース実装に大惨事をもたらします。
</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>
このディテクタは、整数除算の結果が double にキャストされる場所を探します。
多くの場合、意味されたことは、整数オペランドを double にキャストしてから除算を実行することでした。
</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.FindNonSerializableValuePassedToWriteObject">
<Details>
<![CDATA[
<p>
このディテクタは、<code>ObjectOutput</code> の <code>writeObject</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つの分岐に同じコードがあるために分岐が無効になっている if/else または switch 文を探します。
これは2つの分岐に同じコードをコピー & ペーストしていることが片方の分岐の間違ったロジックの原因になります。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.InefficientMemberAccess">
<Details>
<![CDATA[
<p>
このディテクタは、所有クラスの private フィールドに書き込んでいる内部クラスを探します。
この場合、コンパイラは必ずこのフィールドへ書き込むことに使われるアクセッサーメソッドを生成します。
可視性を protected に緩和することは、直接書き込むことを可能にします。
</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>
このディテクタは、protected メンバを宣言する final クラスを探します。
このクラスは派生させることができないので、protected メンバの使用は正しくありません。
アクセス権は、メンバの正しい意図を表すために、public か private に変更するべきです。
</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>
このディテクタは、どのメソッドが null を返すのかを決定してファイルに保存します。
結果ファイルは、null 参照解除ディテクタの精度を向上させるために後続のパスで使われるかもしれません。
これはトレーニングパスなので警告は報告されません。
</p>
<p>
低速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.TrainUnconditionalDerefParams">
<Details>
<![CDATA[
<p>
このディテクタは、どのメソッドが null 値のパラメータを無条件で利用するのかを決定してファイルに保存します。
結果ファイルは、 null 参照解除ディテクタの精度を向上させるために後続のパスで使われるかもしれません。
これはトレーニングパスなので警告は報告されません。
</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>
このディテクタは、@NonNull と @PossiblyNull アノテーションを集めて、データベースに保存します。
</p>
<p>
高速ディテクタです。
</p>
]]>
</Details>
</Detector>
<Detector class="edu.umd.cs.findbugs.detect.CheckCalls">
<Details>
<![CDATA[
<p>
このディテクタは、FindBugs でメソッド呼び出しの解決をデバッグするためにあります。
</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 バイトコード解析フレームワークを使用した FindBugs ディテクタを書く方法を示しているコード例です。
</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> の呼び出しは常に false を返すことになります。
</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> (サブクラスも) の static フィールドについて警告します。
</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 アノテーションをチェックします。
このディテクタは、FindBugs をテストするためだけに使われます。
</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>
このディテクタは、ユーザのデフォルトプラットホームエンコーディングを使用して、バイトから String (またはString からバイト) に変換するメソッドの呼び出しをチェックします。
これは、アプリケーションの振る舞いがプラットホーム間で異なる原因となります。
</p>
]]>
</Details>
</Detector>
<!--
**********************************************************************
BugPatterns
**********************************************************************
-->
<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進数の数にうまく変換されない double 値から BigDecimal を作成しています。
たとえば、Java で new BigDecimal(0.1) と書くと0.1と正確に等しい BigDecimal (スケールが1で、スケールなしの値が1) が作成されると思うかもしれませんが
実際には、0.1000000000000000055511151231257827021181583404541015625と等しくなります。
</p>
<p>
おそらくBigDecimal.valueOf(double d) メソッドの使用が望ましいです。BigDecimal(たとえば、BigDecimal.valueOf(0.1) は0.1を与えます) を作成するためには double の文字列表現を使用します。
</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="http://java.sun.com/javase/ja/6/docs/ja/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="http://java.sun.com/javase/ja/6/docs/ja/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>
FindBugs は、HRS の最も露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しない、より多くの脆弱性があるでしょう。
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>
FindBugs は、HRS のもっとも露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しない、より多くの脆弱性があるでしょう。
HRS を心配するなら、商用の静的解析ツールかペンテストツールの使用を真剣に検討するべきです。
</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>
FindBugs は、XSS のもっとも露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しない、より多くの脆弱性があるでしょう。
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>
FindBugs は、XSS のもっとも露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しない、より多くの脆弱性があるでしょう。
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>
FindBugs は、XSS のもっとも露骨で自明なケースだけを探します。
FindBugs が何かを発見したならほぼ間違いなく FindBugs が報告しない、より多くの脆弱性があるでしょう。
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://java.sun.com/developer/JDCTechTips/2003/tt1208.html#1">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>
これは配列に volatile 参照を宣言しています。それはあなたが望むものではないかもしれません。
配列への volatile 参照は、配列への参照の読み出し、書き込みは volatile として扱われますが、配列要素は volatile として扱われません。
配列要素を volatile として扱いたいのであれば、J2SE 5.0で提供された <code>java.util.concurrent</code> パッケージのアトミック配列クラスを使用する必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VO_VOLATILE_INCREMENT">
<ShortDescription>volatile フィールドへのインクリメントはアトミックではない</ShortDescription>
<LongDescription>volatile フィールド {2} をインクリメントしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、volatile フィールドをインクリメントしています。
volatile フィールドのインクリメントは、アトミックではありません。
複数のスレッドが同時にフィールドをインクリメントすると、インクリメントが失われる可能性があります。
</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>
Boolean.TRUE、Boolean.FALSE、null を返すメソッドは事故が起こるのを待っているようなものです。
まるで論理型の値を返すかのように、このメソッドは呼び出される可能性があります。
そして、コンパイラは Boolean 値のオートアンボクシングを挿入します。
null 値が返されるなら <code>NullPointerException</code> が発生することになります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_SYNC_AND_NULL_CHECK_FIELD">
<ShortDescription>同じフィールドでの同期化と null チェック</ShortDescription>
<LongDescription>フィールド {2.givenClass} は、同期化して null チェックしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
フィールドは同期化しているので、おそらく null ではないと思われます。
null のフィールドを同期化すると <code>NullPointerException</code> がスローされるので、null チェックは無意味になります。
別のフィールドで同期化した方がよいです。
</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>
警告が記録されたのに FindBugs はこのバグパターンの説明を見つけることができなかったので警告について説明できません。
これは FindBugs かその設定のバグの場合だけで発生させるべきです。
または解析プラグインを使用して生成されるなら、プラグインは現在ロードされていません。
</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>。
その代わりに double の使用を検討してください。
</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>
この非 final クラスは、<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>
このコードは、セキュリティ許可チェックが必要なメソッドを呼び出しています。
このコードにセキュリティ許可が与えられるとしても、セキュリティ許可がないコードによって呼び出されるなら doPrivileged ブロック内で行う必要があります。
</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>
このコードはクラスローダを作成していますが、セキュリティマネージャがインストールされているなら権限が必要です。
このコードがセキュリティ権限がないコードによって呼び出されるなら、クラスローダの作成は doPrivileged ブロック内で行う必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="JCIP_FIELD_ISNT_FINAL_IN_IMMUTABLE_CLASS">
<ShortDescription>不変クラスのフィールドは final にすべき</ShortDescription>
<LongDescription>{0} は不変とマークされているので、{1.givenClass} は final にすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
クラスには、net.jcip.annotations.Immutable アノテーションが付けられています。
Immutable アノテーションのルールは、すべてのフィールドを final にすることを義務づけます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_THREAD_PASSED_WHERE_RUNNABLE_EXPECTED">
<ShortDescription>Thread オブジェクトが Runnable が期待されているところに渡されている</ShortDescription>
<LongDescription>Thread オブジェクトが Runnable が期待されているところに渡されています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
Threadオブジェクトが Runnable が期待されているメソッドへのパラメータとして渡されています。
これはかなり異常で、論理エラーを示すか、予想外の振る舞いの原因になるかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_COLLECTION_OF_URLS">
<ShortDescription>URL の Map や Set はひどい性能になる可能性がある</ShortDescription>
<LongDescription>{1} は、URL の Map か Set を使用しているので、ひどい性能になる可能性があります。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドまたはフィールドは、URL の <code>Map</code> か <code>Set</code> を使用しています。
URL の <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>
URL の <code>quals</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> の呼び出しはコードが他のコードによって呼び出されることを困難か不可能にします。
その代わりに RuntimeException をスローすることを検討してください。
</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>java.lang.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</code> オブジェクトを作成するために、<code>Boolean.valueOf</code> メソッド (または J2SE 5.0 のオートボクシング) を使用してください。
</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>
</p>
<ul>
<li>String.toUpperCase(Locale l)</li>
<li>String.toLowerCase(Locale l)</li>
</ul>
</p>
]]>
</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> メソッドを呼び出すために、プリミティブ型のラッパクラスのインスタンスを作成しています。
それよりもプリミティブ値を引数にとる static な <code>toString</code> メソッドを使用した方が効率的です。
</p>
<table>
<tr><th>置換前</th><th>置換後</th></tr>
<tr><td>new Integer(1).toString()</td><td>Integer.toString(1)</td></tr>
<tr><td>new Long(1).toString()</td><td>Long.toString(1)</td></tr>
<tr><td>new Float(1.0).toString()</td><td>Float.toString(1.0)</td></tr>
<tr><td>new Double(1.0).toString()</td><td>Double.toString(1.0)</td></tr>
<tr><td>new Byte(1).toString()</td><td>Byte.toString(1)</td></tr>
<tr><td>new Short(1).toString()</td><td>Short.toString(1)</td></tr>
<tr><td>new Boolean(true).toString()</td><td>Boolean.toString(true)</td></tr>
</table>
]]>
</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_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 メソッドに定数でない文字列を渡している</ShortDescription>
<LongDescription>{1} は、SQL の Statement の execute メソッドに定数でない文字列を渡しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、動的に生成されるように思われる文字列で、 SQL の <code>Statement</code> の <code>execute</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> を作成しています。
ユーザからのチェックされていない、汚染されたデータがこの文字列を作る際に使われるなら、PreparedStatement で予想外で望ましくない何かをするために 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="FI_FINALIZER_NULLS_FIELDS">
<ShortDescription>ファイナライザはフィールドを null にする</ShortDescription>
<LongDescription>{3} は、finalize メソッドの中で null を設定しています。{1.class}</LongDescription>
<Details>
<![CDATA[
<p>
このファイナライザは、フィールドを null にしています。
これは通常誤りでガベージコレクタを助けません。オブジェクトはいずれにしろガベージされます。
]]>
</Details>
</BugPattern>
<BugPattern type="FI_FINALIZER_ONLY_NULLS_FIELDS">
<ShortDescription>ファイナライザはフィールドを null にするだけ</ShortDescription>
<LongDescription>{1} は、フィールドを null にするだけです。</LongDescription>
<Details>
<![CDATA[
<p>
このファイナライザは、フィールドを null にすること以外は何もしません。
これはまったく無意味であり、オブジェクトがガベージされ、ファイナライズされ、再びガベージされることを要求しています。
<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> メソッドは public ではなく、protected にすべきです。
</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>
<blockquote><pre>
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;
}
</pre></blockquote>
<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} は、{1.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>
このクラスは、常に true を返す <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>
このクラスでは、常に false を返す <code>equlas</code> メソッドを定義しています。
これは、オブジェクトがそれ自身と等価ではないことを意味していて、このクラスの有用な Map や Set を作成できません。
より根本的に、<code>equals</code> メソッドの要件一つである反射性を満たしていないことになります。
</p>
<p>
おそらく意図されたことは、オブジェクトはそれ自身と等価であるというオブジェクト同一性です。
これは <code>Object</code> クラスから継承される振る舞いです。
異なるスーパークラスから継承される <code>equals</code> メソッドをオーバーライドする必要があるなら以下のようなコードが使えます。
</p>
<blockquote><pre>
public boolean equals(Object o) {
return this == o;
}
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="HSC_HUGE_SHARED_STRING_CONSTANT">
<ShortDescription>複数のクラスファイルにわたって複製されている巨大な文字列定数</ShortDescription>
<LongDescription>長さが {2} 文字の文字列定数 {1} が {3} つのクラスファイルに複製されています。</LongDescription>
<Details>
<![CDATA[
<p>
巨大な文字列定数が複数のクラスファイルにわたって複製されています。
final フィールドが文字列定数で初期化され、Java言語によって他のクラスからの final フィールドへのすべての参照がクラスファイルにインライン化されるからです。
</p>
<p>
JDK はこのバグを解決してサイズを1MB減らすことができました。<br>
詳細は、<a href="http://bugs.sun.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>
このメソッドへのパラメータが null かどうか確かめるために常にチェックされるべき値として特定されました。
しかし、null チェックをしないで、null 値が利用されています。
</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> メソッドの実装は引数として渡されている null をチェックしていないので、<code>java.lang.Object.equals()</code> で定義された規約に違反しています。
すべての <code>equals</code> メソッドは引数に null が渡されたなら false を返すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_NEGATING_RESULT_OF_COMPARETO">
<ShortDescription>compareTo()/compare() の結果を無効にする</ShortDescription>
<LongDescription>{1} は、{2} の戻り値を無効にします。</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、compareTo または compare メソッドの戻り値を無効にします。
これは疑わしいか間違ったプログラミングプラクティスです、戻り値が Integer.MIN_VALUE なので、戻り値を無効にすることは結果の符号を無効にしません。
結果を無効にするのではなくオペランドの順序を逆にすることによって、同じ意図した結果を得ることができます。
</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>
場合によっては、この compareTo または compare メソッドは Integer.MIN_VALUE を返します。それは、非常に間違ったプラクティスです。
compareTo メソッドの戻り値は結果の符号だけが重要なのです。
しかし、compareTo メソッドの戻り値を無効にすることがあります。これが結果の符号を無効にすると予想します。
戻り値が Integer.MIN_VALUE である場合を除きそうなります。Integer.MIN_VALUE よりも-1を返しなさい。
</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>
このクラスのインスタンスが HashMap/HashTable に決して代入されるだろうと思わないなら、
推奨される <code>hashCode</code> メソッドの実装は以下のようになります。
</p>
<blockquote><pre>
public int hashCode() {
assert false : "hashCodeが呼び出されることは想定されていません。";
return 42; // 適当な値
}
</pre></blockquote>
]]>
</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> メソッドが true を返す場合に限り、<code>compareTo</code> メソッドは0を返すべきです。
これが違反されるなら奇妙で予測できない失敗が PriorityQueue などのクラスで発生します。
J2SE 5.0では、<code>PriorityQueue.remove()</code> は <code>compareTo</code> メソッドを使用しますが、Java SE 6では、<code>equals</code> メソッドを使用します。
<p>
Comparable インタフェースの compareTo メソッドの 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>
このクラスのインスタンスが HashMap/HashTable に決して代入されるだろうと思わないなら、推奨される <code>hashCode</code> メソッドの実装は以下のようになります。
</p>
<blockquote><pre>
public int hashCode() {
assert false : "hashCodeが呼び出されることは想定されていません。";
return 42; // 適当な値
}
</pre></blockquote>
]]>
</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> メソッドを定義したくない、またはオブジェクトが HashMap/Hashtable に決して格納されないだろうと思っているなら <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>java.lang.String</code> オブジェクトを比較しています。
両方の文字列がソースファイルの定数か、<code>String.intern()</code> を使用して正準化されていない限り、同じ文字列は2つの異なる String オブジェクトによって表されるかもしれません。
その代わりに <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>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> アノテーションが付けられていますが、
アノテーションに違反すると思われる方法でアクセスされる可能性があります。
</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>少なくとも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>
public static メソッドは、クラスの 静的な状態の一部である配列の参照を返します。
このメソッドを呼び出すどんなコードも、基底配列を自由に変更できます。
解決策は、配列のコピーを返すことです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EI_EXPOSE_REP">
<ShortDescription>可変オブジェクトへの参照を返すことによって内部表現を暴露するかもしれないメソッド</ShortDescription>
<LongDescription>{1} は、{2.givenClass} を返すことによって内部表現を暴露するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
オブジェクトのフィールドのうちの1つに格納された可変オブジェクトの参照を返すと、オブジェクトの内部表現を暴露します。
インスタンスが信頼できないコードによってアクセスされるなら、可変オブジェクトのチェックされていない変更がセキュリティや他の重要なプロパティを危うくするでしょう。
何か違うことをする必要があります。オブジェクトの新しいコピーを返すことは、多くの状況でより良いアプローチです。
]]>
</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>
このコードは、static フィールドに外部の可変オブジェクトを格納しています。
可変オブジェクトのチェックされていない変更がセキュリティや他の重要なプロパティを危うくするでしょう。
何か違うことをする必要があります。オブジェクトのコピーを保存することは、多くの状況でより良いアプローチです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RU_INVOKE_RUN">
<ShortDescription>スレッドで run メソッドを呼び出している</ShortDescription>
<LongDescription>{1} は、スレッドで明示的に run メソッドを呼び出しています (start メソッドを意味していましたか？)。</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>
このメソッドは、フィールドを読み出すループで回り続けます。
コンパイラがフィールドの読み出しをループの外に出すかもしれません。コードを無限ループに変えます。
正しい同期化 (wait/notify を呼び出すように含む) を使うようにクラスを変更するべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NS_DANGEROUS_NON_SHORT_CIRCUIT">
<ShortDescription>潜在的な非短絡論理の危険な使用</ShortDescription>
<LongDescription>潜在的な非短絡論理の危険な使用。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、短絡論理 (&& や ||) ではなく非短絡論理 (& や |) を使用していると思われます。
さらに、左辺値によって右辺を評価したくない (例外のスローや演算が高くつく副作用があるため) と思っているのかもしれません。
非短絡論理は、左辺の結果がわかっていて推論できるときでも、両側の式が評価されます。
左辺が右辺の評価でエラーを発生させるケースをガードするなら効率が悪く、エラーになる可能性があります。
</p>
<p>
詳細については、<a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#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>
このコードは、短絡論理 (&& や ||) ではなく非短絡論理 (& や |) を使用していると思われます。
非短絡論理は、左辺の結果がわかっていて推論できるときでも、両側の式が評価されます。
左辺が右辺の評価でエラーになるケースをガードするなら効率が悪くエラーになる可能性があります。
</p>
詳細については、<a href="http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#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>
<blockquote><pre>
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;
}
}
</pre></blockquote>
<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> は null です。
</p>
<blockquote><pre>
public class CircularClassInitialization {
static class InnerClassSingleton extends CircularClassInitialization {
static InnerClassSingleton singleton = new InnerClassSingleton();
}
static CircularClassInitialization foo = InnerClassSingleton.singleton;
}
</pre></blockquote>
]]>
</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>
<blockquote><pre>
private static String LOCK = "LOCK";
synchronized(LOCK) {
...
}
</pre></blockquote>
<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>
]]>
</Details>
</BugPattern>
<BugPattern type="DL_SYNCHRONIZATION_ON_BOOLEAN">
<ShortDescription>Boolean の同期化</ShortDescription>
<LongDescription>Boolean を同期化しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
<code>Boolean</code> のようなボクシングされたプリミティブ型の定数で同期化しています。
</p>
<blockquote><pre>
private static Boolean inited = Boolean.FALSE;
synchronized(inited) {
if (!inited) {
init();
inited = Boolean.TRUE;
}
}
</pre></blockquote>
<p>
通常は2つの <code>Boolean</code> オブジェクトだけが存在しています。
このコードは他の無関係なコードと同じオブジェクトで同期化している可能性があるので、無応答やデッドロックの原因になります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DL_SYNCHRONIZATION_ON_UNSHARED_BOXED_PRIMITIVE">
<ShortDescription>ボクシングされたプリミティブ値の同期化</ShortDescription>
<LongDescription>{2} を同期化しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、明らかに共有されていない <code>Integer</code> のようなボクシングされたプリミティブ型で同期化しています。
</p>
<blockquote><pre>
private static final Integer fileLock = new Integer(1);
synchronized(fileLock) {
.. do something ..
}
</pre></blockquote>
<p>
このコードは、 fileLock を以下のように宣言するとより良くなります。
</p>
<blockquote><pre>
private static final Object fileLock = new Object();
</pre></blockquote>
<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>
このコードは、Integer のようなボクシングされたプリミティブ型の定数で同期化しています。
</p>
<blockquote><pre>
private static Integer count = 0;
synchronized(count) {
count++;
}
</pre></blockquote>
<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>
このコードには、空の synchronized ブロックがあります。
</p>
<blockquote><pre>
synchronized() {
}
</pre></blockquote>
<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>
<blockquote><pre>
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;
}
</pre></blockquote>
]]>
</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>
インタフェースに定義された final static フィールドは、配列や Hashtable などの可変オブジェクトを参照しています。
この可変オブジェクトは、悪意のあるコードや別のパッケージからの事故によって変更される可能性があります。
これを解決するために、フィールドはクラスへ移動する必要があり、脆弱性を回避するためにパッケージプロテクテッドにすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_FINAL_PKGPROTECT">
<ShortDescription>final かつパッケージプロテクテッドにすべきフィールド</ShortDescription>
<LongDescription>{1} は、final かつパッケージプロテクテッドにすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
この可変 static フィールドは、悪意のあるコードや別のパッケージからの事故によって変更される可能性があります。
フィールドは、脆弱性を回避するために final またはパッケージプロテクテッドにすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_SHOULD_BE_FINAL">
<ShortDescription>final にすべきフィールド</ShortDescription>
<LongDescription>{1} は final ではありませんが、final にすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
この可変 static フィールドは、悪意のあるコードや別のパッケージからの事故によって変更される可能性があります。
フィールドは、脆弱性を回避するために final にすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_PKGPROTECT">
<ShortDescription>パッケージプロテクテッドにすべきフィールド</ShortDescription>
<LongDescription>{1} は、パッケージプロテクテッドにすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
この可変 static フィールドは、悪意のあるコードや別のパッケージからの事故によって変更される可能性があります。
フィールドは、脆弱性を回避するためにパッケージプロテクテッドにすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_MUTABLE_HASHTABLE">
<ShortDescription>可変 Hashtable のフィールド</ShortDescription>
<LongDescription>{1} は、可変 Hashtable です。</LongDescription>
<Details>
<![CDATA[
<p>
この final static フィールドは、Hashtable を参照しているので、悪意のあるコードや別のパッケージからの事故によってアクセスされる可能性があります。
このコードは、Hashtable のコンテンツを自由に変更できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_MUTABLE_ARRAY">
<ShortDescription>可変配列のフィールド</ShortDescription>
<LongDescription>{1} は、可変配列です。</LongDescription>
<Details>
<![CDATA[
<p>
この final static フィールドは、配列を参照しているので、悪意のあるコードや誤って別のパッケージからアクセスされる可能性があります。
このコードは、配列のコンテンツを自由に変更できます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="MS_CANNOT_BE_FINAL">
<ShortDescription>final でないフィールドは悪意のあるコードから保護できない</ShortDescription>
<LongDescription>{1} は、final でないので、悪意のあるコードから保護できません。 </LongDescription>
<Details>
<![CDATA[
<p>
この可変 static フィールドは、悪意のあるコードや別のパッケージからの事故によって変更される可能性があります。
残念ながらこのような使い方は簡単に解決できません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IA_AMBIGUOUS_INVOCATION_OF_INHERITED_OR_OUTER_METHOD">
<ShortDescription>継承されたメソッドなのか外部のメソッドなのかあいまいなメソッドの呼び出し</ShortDescription>
<LongDescription>継承されたメソッドなのか外部のメソッドなのかあいまいなメソッド {2} を呼び出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
内部クラスは、継承されたメソッドか外部クラスで定義されたメソッドなのかどちらとも解釈できるメソッドを呼び出しています。
Java の仕様上は継承したメソッドを呼び出しますが、これは意図したことではないかもしれません。
本当に継承されたメソッドを呼び出すつもりなら super を付けて (例：super.foo(17)) 呼び出してください。
そうすれば、外部クラスのメソッドではなく継承されたメソッドを呼び出したいことがこのコードを読む人と FindBugs に明確になります。
</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> を拡張します)。
これは非常に紛らわしく、参照関係を解決するために import 文を見なければならなかったり、スーパークラスに存在するメソッドを誤ってオーバーライドしてしまったりする状況を作り出します。
</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> を継承しているような状況です)。
これは非常に紛らわしく、参照関係を解決するために import 文を見なければならなかったり、スーパークラスに存在するメソッドを誤ってオーバーライドしてしまったりする状況を作り出します。
</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>
final でないフィールドの名前は、最初の文字は小文字にし、それに続く各単語の最初の文字を大文字にすべきです。
</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>
<blockquote><pre>
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; }
}
</pre></blockquote>
<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>
たとえば、以下のようなコードです。
<blockquote><pre>
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; }
}
</pre></blockquote>
<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>
この正規のメソッドは、定義しているクラスと同じ名前です。
これはコンストラクタを意図していた可能性が高いです。もしそうなら void 戻り値の宣言を除去してください。
このメソッドを定義したことが偶然間違っているとわかり、正しいコンストラクタを定義したが、下位互換性のためにこのメソッドを取り除くことができないなら、メソッドを非推奨にしてください。
</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> メソッドが直列化機構で認識されるためにはstatic メソッドとして宣言してはいけません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_PRIVATE_READ_RESOLVE_NOT_INHERITED">
<ShortDescription>サブクラスで継承できない private な readResolve メソッド</ShortDescription>
<LongDescription>サブクラスで継承できない {0} の private な readResolve メソッドです。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは、private な <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>
フィールドは、transient と宣言していますが、クラスは直列化可能ではないので、まったく効果がありません。
これはクラスが transient だったときの名残かもしれません、あるいは直列化機構を誤解しているのかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_TRANSIENT_FIELD_NOT_RESTORED">
<ShortDescription>直列化復元によって設定されない transient フィールド </ShortDescription>
<LongDescription>フィールド {1} は、transient なので直列化復元によって設定されません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスには、複数の場所で更新されるフィールドがあります。したがって、このクラスの状態の一部であると思われます。
しかしながら、フィールドは transient と宣言しているので、 readObject/readResolve で設定されません。
クラスの直列化復元されたインスタンスにはデフォルト値が設定されます。
</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> インタフェースを実装して、カスタム直列化/直列化復元のためのメソッドを定義しています。
しかし、そのメソッドが private として宣言されていないので、直列化/直列化復元 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> インタフェースを実装しているのに、引数なしコンストラクタは定義していません。
Externalizable オブジェクトが直列化復元されるときは、最初に引数なしコンストラクタを呼び出すことによって構築される必要があります。
このクラスには引数なしコンストラクタがないので、直列化と直列化復元は実行時に失敗します。
</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 オブジェクトへの参照を追加するのと同じくらい簡単な変更でクラスに合成フィールドを追加します。
それは、残念ながら暗黙の serialVersionUID を変えます (たとえば、<code>String.class</code> への参照を追加すると、<code>class$java$lang$String</code> という static フィールドを生成します)。
また、バイトコードコンパイラへの異なるソースコードは、クラスオブジェクトまたは内部クラスに参照のために生成される合成変数のために、異なる命名規則を使用するかもしれません。
バージョンを横断する Serializable の相互運用性を保証するために、明示的に、serialVersionUID を追加することを検討してください。
</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つの case が次の case へと通り抜ける switch 文があります。
通常、break か return でこの case を終わらせる必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SF_SWITCH_NO_DEFAULT">
<ShortDescription>default がない switch 文を発見した</ShortDescription>
<LongDescription>default がない switch 文を発見しました。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには、default がない switch 文があります。
通常、default を用意する必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SF_DEAD_STORE_DUE_TO_SWITCH_FALLTHROUGH">
<ShortDescription>switch 文のフォールスルーのために格納が無効になっている</ShortDescription>
<LongDescription>前の case からの値 {2.givenClass} が switch 文のフォールスルーのためにここで上書きされています。</LongDescription>
<Details>
<![CDATA[
<p>
前の case で格納された値が switch 文のフォールスルーのためにここで上書きされています。
前の case の終わりに break または return を置くのを忘れた可能性があります。
</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>
前の case で格納された値が例外がスローされる場所で、switch 文のフォールスルーのためにここで失われています。
前の case の終わりに break または return を置くのを忘れた可能性があります。
</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>
このクラスは、static でない <code>serialVersionUID</code> フィールドを定義しています。
直列化を目的としてバージョン UID を指定することを意図しているならフィールドは static とすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_NONFINAL_SERIALVERSIONID">
<ShortDescription>serialVersionUID が final ではない</ShortDescription>
<LongDescription>{1} は、 final ではありません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは、final でない <code>serialVersionUID</code> フィールドを定義しています。
直列化を目的としてバージョン UID を指定することを意図しているならフィールドは final とすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_NONLONG_SERIALVERSIONID">
<ShortDescription>serialVersionUID が long ではない</ShortDescription>
<LongDescription>{1} は、long ではありません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは、long でない <code>serialVersionUID</code> フィールドを定義しています。
直列化を目的としてバージョン UID を指定することを意図しているならフィールドは long とすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_BAD_FIELD">
<ShortDescription>直列化可能クラスの非 transient で非直列化可能なインスタンスフィールド</ShortDescription>
<LongDescription>クラス {0} は、非 transient で非直列化可能なインスタンスフィールド {1.name} を定義しています。</LongDescription>
<Details>
<![CDATA[
<p>
この直列化可能クラスは、transient、Serializable、<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>
できれば、内部クラスを static にして問題を解決するべきです。
外部クラスを直列化可能にすることで動作するかもしれないが、内部クラスのインスタンスを直列化することは外部クラスも常に直列化することを意味します。
本当に望むことですか。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_INNER_CLASS">
<ShortDescription>直列化可能な内部クラス</ShortDescription>
<LongDescription>{0} は直列化可能な内部クラスです。</LongDescription>
<Details>
<![CDATA[
<p>
この直列化可能なクラスは、内部クラスです。
内部クラスを直列化しようとすると関連した外部クラスのインスタンスも直列化します。
外部クラスのインスタンスは直列化可能なので失敗しませんが、意図したことよりもっとずっと多くのデータを直列化するかもしれません。
できれば、内部クラスを static にして問題を解決するべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SE_BAD_FIELD_STORE">
<ShortDescription>非直列化可能な値を直列化可能クラスのインスタンスフィールドに格納している</ShortDescription>
<LongDescription>非 transient フィールド {1.givenClass} に {2} を格納しています。</LongDescription>
<Details>
<![CDATA[
<p>
非直列化可能な値を直列化可能クラスの 非 transient フィールドに格納しています。
</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>
このクラスには、コンパイル時に静的な値に初期化されるインスタンス final フィールドがあります。
static フィールドにすることを検討してください。
</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>
このフィールドは決して使用されません。
フィールドは、public か protected なので、たぶん、それは解析の一部として見えないクラスで使用されることを意図しています。
そうでなければ、クラスから除去することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="URF_UNREAD_PUBLIC_OR_PROTECTED_FIELD">
<ShortDescription>読み出されない public または protected フィールド</ShortDescription>
<LongDescription>読み出されない public または protected フィールド: {1}</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドは決して読み出されません。
フィールドは、public か protected なので、たぶん、それは解析の一部として見えないクラスで使用されることを意図しています。
そうでなければ、クラスから除去することを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="QF_QUESTIONABLE_FOR_LOOP">
<ShortDescription>複雑か巧妙か間違ったインクリメントの for ループ</ShortDescription>
<LongDescription>複雑か巧妙か間違ったインクリメントの for ループです。{1} </LongDescription>
<Details>
<![CDATA[
<p>
本当にこの for ループが正しい変数をインクリメントしていますか？
別の変数が for ループによって初期化されて、チェックされるように見えます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UWF_NULL_FIELD">
<ShortDescription>null に設定されるだけのフィールド</ShortDescription>
<LongDescription>null に設定されるだけのフィールド:{1}</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドに定数値 null を書き込みます。したがって、フィールドの読み出しは null を返します。
誤りをチェックしてください。使わないなら除去してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UWF_UNWRITTEN_PUBLIC_OR_PROTECTED_FIELD">
<ShortDescription>書き込まてれいない public または protected フィールド</ShortDescription>
<LongDescription>書き込まれていない public または protected フィールド: {1}</LongDescription>
<Details>
<![CDATA[
<p>
この public または protected フィールドは書き込まれていません。このフィールドからの読み出しはデフォルト値を返します。
誤りをチェックしてください (フィールドは初期化するべきでしたか？)。使わないなら除去してください。
</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>
このインスタンスメソッドは、static フィールドに書き込みをしています。
複数のインスタンスが操作されているなら、正しくさせるのは難しいです。通常、間違ったプラクティスです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_LOAD_OF_KNOWN_NULL_VALUE">
<ShortDescription>null とわかっている値のロード</ShortDescription>
<LongDescription>null とわかっている値をロードしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ここで参照されている変数は、以前に null なのかチェックしているため null であることがわかっています。
これは有効かもしれないし、間違いかもしれません (たぶん、異なる変数を参照することを意図してました、あるいは以前の null チェックで、 null でないのか確かめるべきでした)。
</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> メソッドの結果が null なのか確かめないで値を利用しています。
<code>readLine</code> メソッドは、それ以上読み出すテキスト行がなければ null を返すので、<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> メソッドは、それ以上読み出すテキスト行がなければ null を返すので、<code>NullPointerException</code> が発生します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_UNWRITTEN_FIELD">
<ShortDescription>書き込まれていないフィールドの読み出し</ShortDescription>
<LongDescription>書き込まれていないフィールド {2.name} を読み出しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
プログラムは、決して null でない値を書き込むとは思われないフィールドの値を利用しています。
この値を利用すると <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>
プログラムは、決して null 値でない値を書き込むと思われない public または protected フィールドの null 値を利用しています。
フィールドが解析によって見られない機構を通して初期化されない限り、この値を利用すると <code>NullPointerException</code> が発生します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIC_THREADLOCAL_DEADLY_EMBRACE">
<ShortDescription>非 static 内部クラスとスレッドローカルのデッドロック</ShortDescription>
<LongDescription>{0} は、{1} とのデッドロックを回避するために static にする必要があります。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは内部クラスですが、おそらく static 内部クラスにすべきです。
実際には、内部クラスと外部クラスのスレッドローカルとの間にデッドロックの深刻な危険性があります。
内部クラスが static でないので、外部クラスへの参照を保持します。
スレッドローカルに内部クラスのインスタンスの参照があるなら、内部と外部のインスタンスの両方が到達可能になり、ガベージされません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIC_INNER_SHOULD_BE_STATIC">
<ShortDescription>static 内部クラスにすべき</ShortDescription>
<LongDescription>{0} は、static 内部クラスにすべきです。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは内部クラスなのにそれを作成したオブジェクトへの埋め込まれた参照を使用していません。
この参照はより大きなクラスのインスタンスを作成して、必要以上に長い間作成オブジェクトへの参照を存続しておくかもしれません。
できれば、クラスは static にすべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UWF_FIELD_NOT_INITIALIZED_IN_CONSTRUCTOR">
<ShortDescription>コンストラクタで初期化されていないフィールドを null チェックなしで null 値を利用している</ShortDescription>
<LongDescription>{1.givenClass} は、コンストラクタで初期化されません。{2} で null 値を利用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このフィールドは、どんなコンストラクタの中でも決して初期化されません。したがって、オブジェクトが構築された後、null である可能性があります。
どこかほかで、値がロードされて、null チェックなしで null 値が利用されます。
フィールドが初期化される前に利用されると <code>NullPointerException</code> が発生するので、誤りか疑わしい設計かもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIC_INNER_SHOULD_BE_STATIC_ANON">
<ShortDescription>名前付き static 内部クラスにリファクタリングできるかもしれない</ShortDescription>
<LongDescription>クラス {0} は、名前付き static 内部クラスにリファクタリングできるかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは内部クラスなのにそれを作成したオブジェクトへの埋め込まれた参照を使用していません。
この参照はより大きなクラスのインスタンスを作成して、必要以上に長く作成オブジェクトへの参照を存続しておくかもしれません。
できれば、クラスは static 内部クラスにすべきです。
無名内部クラスは static にできないので、名前付き内部クラスにリファクタリングする必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIC_INNER_SHOULD_BE_STATIC_NEEDS_THIS">
<ShortDescription>static 内部クラスにリファクタリングできるかもしれない</ShortDescription>
<LongDescription>クラス {0} は、static 内部クラスにリファクタリングできるかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは内部クラスなのにそれを作成したオブジェクトへの埋め込まれた参照を使用していません。
この参照はより大きなクラスのインスタンスを作成して、必要以上に長く作成オブジェクトへの参照を存続しておくかもしれません。
できれば、クラスは static 内部クラスにすべきです。
外部オブジェクトへの参照が内部クラスのインスタンスを構築する間必要なので内部クラスのコンストラクタに外部インスタンスへの参照を渡すようにリファクタリングする必要があります。
</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="RV_CHECK_FOR_POSITIVE_INDEXOF">
<ShortDescription>String.indexOf の結果が正かどうか確かめている</ShortDescription>
<LongDescription>String.indexOf の結果が正かどうか確かめています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは <code>String.indexOf</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> メソッドの戻り値を null でないのか確かめた後で捨てています。
ほとんどすべての状況で、結果が null でないなら戻り値を使用したいでしょう。
再び <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>
我々は、戻り値を無視することがメソッド本体の単純な解析から悪い考えかもしれないと推測しています。
このメソッドの戻り値を無視することが重要であるか許容できるかどうかに関して、FindBugs に指示する @CheckReturnValue アノテーションが使えます。
</p>
<p>
戻り値を無視することが間違いではないか決めるために、厳密に調査してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_RETURN_VALUE_IGNORED">
<ShortDescription>戻り値を無視しているメソッド</ShortDescription>
<LongDescription>{2.givenClass} の戻り値を無視しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドの戻り値はチェックするべきです。
この警告の共通の原因は、オブジェクトが更新されると思って不変オブジェクトのメソッドを呼び出すことです。<br>
たとえば、以下のようなコードです。
</p>
<blockquote><pre>
String dateString = getHeaderField(name);
dateString.trim();
</pre></blockquote>
<p>
プログラマは、<code>trim</code> メソッドが <code>dateString</code> によって参照される String オブジェクトが更新されると思っています。
しかし、String オブジェクトは不変で、<code>trim</code> メソッドが新しい String オブジェクトを返すのに無視しています。
このコードは、以下のように修正するべきです。
</p>
<blockquote><pre>
String dateString = getHeaderField(name);
dateString = dateString.trim();
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_RETURN_VALUE_IGNORED_BAD_PRACTICE">
<ShortDescription>例外的戻り値を無視しているメソッド</ShortDescription>
<LongDescription>{2} の例外的戻り値を無視しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、チェックされていない値を返しています。
戻り値は異常か予想外の実行結果を示す可能性があるのでチェックするべきです。
たとえば、<code>File.delete()</code> はファイルをうまく削除できなかったなら、例外をスローするのではなく false を返します。
結果をチェックしないなら例外的戻り値を返すメソッドの呼び出しで予想外の振る舞いの合図に気づきません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_CHECK_COMPARETO_FOR_SPECIFIC_RETURN_VALUE">
<ShortDescription>compareTo によって返された特定の値のコードチェック</ShortDescription>
<LongDescription>{2.givenClass} の戻り値が {3} と等しいか確かめてください。</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、compareTo か比較メソッドを呼び出して、戻り値が特定の値（たとえば1または-1） なのか確かめています。
これらのメソッドを呼び出すときは特定のゼロ以外の値ではなく、結果の符号だけをチェックするべきです。
多数または大部分の compareTo と比較メソッドは-1、0または1を返しますが、いくつかは他の値を返します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RV_EXCEPTION_NOT_THROWN">
<ShortDescription>作成した例外をスローするのではなく捨てている</ShortDescription>
<LongDescription>{2.givenClass} をスローしていません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、例外 (またはエラー) オブジェクトを作成しているのに何もしていません。<br>
たとえば、以下のようなコードです。
</p>
<blockquote><pre>
if (x < 0) {
new IllegalArgumentException("x must be nonnegative");
}
</pre></blockquote>
<p>
おそらくプログラマの意図は、作成した例外をスローすることでした。
</p>
<blockquote><pre>
if (x < 0) {
throw new IllegalArgumentException("x must be nonnegative");
}
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_ALWAYS_NULL">
<ShortDescription>null 値を利用している</ShortDescription>
<LongDescription>{2.givenClass} の null 値を利用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ここで null 値を利用しようとしています。
コードが実行されると <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> メソッドは、常に null 値のオブジェクトで呼び出されています。
この文が実行されるなら <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>
@NonNull アノテーションが付けられたフィールドに null かもしれない値を格納しています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_ALWAYS_NULL_EXCEPTION">
<ShortDescription>null 値を例外経路で利用している</ShortDescription>
<LongDescription>{2.givenClass} の null 値を例外経路で利用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
例外経路上のここで null 値を利用しています。
コードが実行されると <code>NullPointerException</code> が発生します。
現在の FindBugs は実行不可能な例外経路を取り除いていないので、誤検出かもしれないことに注意してください。
</p>
<p>
switch 文の default が多くの場合実行不可能なので FindBugs が例外経路である default を検討することに注意して下さい。
</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>
このパラメータは、null 値を許容しないことを要求する方法で常に使われていますが、パラメータには明示的に null 値を許容するアノテーションが付けられています。
パラメータかアノテーションのどちらかの使い方が間違っています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_ON_SOME_PATH">
<ShortDescription>null 値を利用している可能性がある</ShortDescription>
<LongDescription>{2.givenClass} の null 値を利用している可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
そこで分岐または文が実行されるなら null 値が利用されて <code>NullPointerException</code> が発生します。
もちろん、問題は分岐または文が実行不可能で、<code>NullPointerException</code> が決して発生する可能性がないということかもしれません。
それを決めるのは FindBugs の能力を超えています。
</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>
分岐または文が実行されるなら、null 値が利用されて <code>NullPointerException</code> が発生します。
もちろん、問題は分岐または文が実行不可能で、<code>NullPointerException</code> が決して発生する可能性がないということかもしれません。
それを決めるのは FindBugs の能力を超えています。
この値がすでに null であることを検査されたという事実からこれは確かな可能性です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_ON_SOME_PATH_EXCEPTION">
<ShortDescription>null 値を例外経路で利用している可能性がある</ShortDescription>
<LongDescription>{2.givenClass} の null 値を例外経路で利用している可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
例外経路上のここで null 値が利用されています。
コードが実行されると <code>NullPointerException</code> が発生するかもしれません。
現在の FindBugs は実行不可能な例外経路を取り除かないので、誤検出かもしれないことに注意してください。
</p>
<p>
switch 文の default が多くの場合実行不可能なので FindBugs が例外経路である default を検討することに注意して下さい。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_ON_SOME_PATH_FROM_RETURN_VALUE">
<ShortDescription>null になっている可能性があるメソッドの戻り値を利用している</ShortDescription>
<LongDescription>null になっている可能性があるメソッドの戻り値を利用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
メソッドからの戻り値を null チェックしないで利用しています。メソッドの戻り値は null なのかチェックするべきです。
コードが実行されると <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>
おそらく、 null 値を許容しないメソッドパラメータに null 値を渡しています。
パラメータは、常に非 null であるべきパラメータとしてアノテーションが付けられていたか、または解析が常に null 値を利用すると示していました。
</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>
おそらく、すべての知られているターゲットメソッドが非 null であることを要求する呼び出し場所で null 値を渡しています。
パラメータは、常に非 null であるべきパラメータとしてアノテーションが付けられていたか、または解析が常に null 値を利用すると示していました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_PARAM_DEREF">
<ShortDescription>メソッド呼び出しは非 null パラメータに対して null を渡している</ShortDescription>
<LongDescription>{2.givenClass} の 非 null パラメータに対して null を渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッド呼び出しは非 null メソッドパラメータに対して null 値を渡しています。
パラメータは、常に非 null であるべきパラメータとしてアノテーションが付けられていたか、または解析が常に null 値を利用すると示していました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NONNULL_PARAM_VIOLATION">
<ShortDescription>メソッド呼び出しは非 null パラメータに対して null を渡している</ShortDescription>
<LongDescription>{2.givenClass} の 非 null パラメータに対して null を渡しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、非 null でなければならないメソッドのパラメータとして、null 値を渡しています。
このパラメータは、@Nonnull として明示的にアノテーションが付けられていたか、または解析が常に null 値を利用すると示していました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NONNULL_RETURN_VIOLATION">
<ShortDescription>null を返すかもしれないメソッドが @NonNull 宣言されている</ShortDescription>
<LongDescription>{1} は、null を返すかもしれないのに @NonNull 宣言されています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、null 値を返すかもしれないのにメソッド (またはスーパークラスのメソッド) の戻り値に @NonNull が宣言されています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_CLONE_COULD_RETURN_NULL">
<ShortDescription>null を返すかもしれない clone メソッド</ShortDescription>
<LongDescription>{1} は、null を返すかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
この <code>clone</code> メソッドはいくつかの条件で null を返すと思われます。
しかし、<code>clone</code> メソッドは決して null を返すのは許されません。
この経路が到達できないことを確信しているなら、その代わりに <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> メソッドはいくつかの条件で null を返すと思われます。
仕様を寛大に読むとこれが許されると解釈できるかもしれませんが、それはおそらく間違った考えで、他のコードが壊れる原因になる可能性があります。
null ではなく空の文字列またはいくつかの他の適切な文字列を返してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_GUARANTEED_DEREF">
<ShortDescription>null 値を利用することが保証されている</ShortDescription>
<LongDescription>{2.givenClass} は、null 値を利用することが保証されています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
文または分岐が実行されるなら、この時点で値は null であり、null 値を利用する (フォワードパスで実行時例外を伴うこと以外は) ことが保証されています。
</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>
例外経路上の文または分岐が実行されるなら、この時点で値は null であり、null 値を利用する (フォワードパスで実行時例外を伴うこと以外は) ことが保証されています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SI_INSTANCE_BEFORE_FINALS_ASSIGNED">
<ShortDescription>スタティックイニシャライザは、すべての static final フィールドが代入される前にインスタンスを作成する</ShortDescription>
<LongDescription>{0} のためのスタティックイニシャライザは、すべての static final フィールドが代入される前にインスタンスを作成します。</LongDescription>
<Details>
<![CDATA[
<p>
すべての static finalフィールドが初期化される前に、スタティックイニシャライザはクラスのインスタンスを作成します。
</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>
結果がないこと (すなわち、結果の空のリスト) を示すために null 参照ではなく長さが0の配列 を返すことは、多くの場合より良い設計です。
</p>
<p>
他方では、「この質問に対する答えがない」ことを示すために、null を使うことはおそらく適切です。
たとえば、<code>File.listFiles()</code> は、ファイルがないディレクトリを与えられた場合は空のリストを返し、ファイルがディレクトリでないなら null を返します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UCF_USELESS_CONTROL_FLOW">
<ShortDescription>役に立たない制御フロー</ShortDescription>
<LongDescription>役に立たない制御フローです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには、分岐するのかどうかに関係なく、制御フローが同じ場所へと続く、役に立たない制御フロー文があります。<br>
たとえば、これは 空の <code>if</code> 文が原因になります。
<blockquote><pre>
if (argv.length == 0) {
// TODO: handle this case
}
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="UCF_USELESS_CONTROL_FLOW_NEXT_LINE">
<ShortDescription>次の行へ続くだけの役に立たない制御フロー</ShortDescription>
<LongDescription>次の行に続くだけの役に立たない制御フローです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには、分岐するのかどうかに関係なく、制御フローが同じか次の行へと続く、役に立たない制御フロー文があります。<br>
多くの場合、不注意に <code>if</code> 文の本体を空文を使用したことが原因になります。
</p>
<blockquote><pre>
if (argv.length == 1);
System.out.println("Hello, " + argv[0]);
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_NULLCHECK_WOULD_HAVE_BEEN_A_NPE">
<ShortDescription>すでに利用していた値の null チェック</ShortDescription>
<LongDescription>すでに利用していた値を {4.lineNumber} の {2.givenClass} で null チェックしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
ここで値が null なのかチェックしていますが、すでに値を利用していたので null である可能性はありません。
値が null なら以前の利用で <code>NullPointerException</code> が発生していたでしょう。
基本的に、この値が null であることを許すのかどうかに関係なく、このコードと以前の値の利用は一致しません。
チェックは冗長か、または以前の値の利用は誤りです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_NULLCHECK_OF_NULL_VALUE">
<ShortDescription>null とわかっている値の冗長な null チェック</ShortDescription>
<LongDescription>null とわかっている値 {2} の冗長な null チェックがあります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには、null とわかっている値の冗長な null チェックがあります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_NULLCHECK_OF_NONNULL_VALUE">
<ShortDescription>null でないことがわかっている値の冗長な null チェック</ShortDescription>
<LongDescription>null でないことがわかっている値 {2} の冗長な null チェックがあります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには null でないことがわかっている値の冗長な null チェックがあります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RCN_REDUNDANT_COMPARISON_TWO_NULL_VALUES">
<ShortDescription>2つの null 値の冗長な比較</ShortDescription>
<LongDescription>2つの null 値の冗長な比較があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには、両方とも明らかに null とわかっている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>
このメソッドには、null でないことがわかっている参照と null とわかっている別の参照との比較があります。
</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(<code>java.util.concurrent</code>) のロックを獲得しているのにメソッドからのすべての経路で解除していません。
通常、JSR-166のロックを使用するための正しいイディオムは以下のようになります。
</p>
<blockquote><pre>
Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="UL_UNRELEASED_LOCK_EXCEPTION_PATH">
<ShortDescription>すべての例外経路でロックが解除されないメソッド</ShortDescription>
<LongDescription>{1} は、すべての例外経路でロックが解除されません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、JSR-166(<code>java.util.concurrent</code>) のロックを獲得しているのにメソッドからのすべての例外経路で解除していません。
通常、JSR-166のロックを使用するための正しいイディオムは以下のようになります。
</p>
<blockquote><pre>
Lock l = ...;
l.lock();
try {
// do something
} finally {
l.unlock();
}
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="RC_REF_COMPARISON">
<ShortDescription>疑わしい参照比較</ShortDescription>
<LongDescription>{2} の参照比較は疑わしいです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、 == または != 演算子を使用して2つの参照値を比較しています。
この型のインスタンスを比較する正しい方法は、通常 <code>equals</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>equals</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>
このメソッドは、== または != 演算子を使用して2つの Boolean 値を比較しています。
通常は2つの Boolean 値 (<code>Boolean.TRUE</code> と <code>Boolean.FALSE</code>) だけですが、
<code>new Boolean(b)</code> コンストラクタを使用して他の Boolean オブジェクトを作成する可能性があります。
そのようなオブジェクトを回避することは最高です。
しかし、それらが存在するなら、Boolean オブジェクトの等価性をチェックするために <code>.equals(...)</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つの参照を比較するために参照等価性を使用しています。
この比較の結果は、常に false です。
</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> メソッドを呼び出しています。
したがって、比較されている2つのオブジェクトは実行時に同じクラスのメンバである可能性が低いです (いくつかのアプリケーションクラスが解析できなかったか、動的クラスローディングが実行時に起こることができた場合を除く)。
<code>equals</code> メソッドの規約によると、異なるクラスのオブジェクトは常に等しくないとして比較するべきです。
したがって、<code>java.lang.Object.equals(Object)</code> によって定義される規約によれば、この比較の結果は実行時に常に false になります。
</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> によって定義される規約によれば、この比較の結果は実行時に常に false になります。
</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> によって定義される規約によれば、この比較の結果は実行時に常に false になります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="EC_NULL_ARG">
<ShortDescription>equals(null) の呼び出し</ShortDescription>
<LongDescription>equals(null) の呼び出し。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、 null 値の引数を渡して <code>equals(Object)</code> を呼び出しています。
<code>equals</code> メソッドの規約によると、この呼び出しは常に false を返すはずです。
</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>
<blockquote><pre>
int foo;
public void setFoo(int foo) {
foo = foo;
}
</pre></blockquote>
<p>
そのような代入は役に立ちません。そうではなく、フィールドに代入するつもりでしたか？
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_LOCAL_SELF_ASSIGNMENT">
<ShortDescription>ローカル変数の自己代入</ShortDescription>
<LongDescription>{2} の自己代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには、ローカル変数の自己代入があります。<br>
たとえば、以下のようなコードです。
</p>
<blockquote><pre>
public void foo() {
int x = 3;
x = x;
}
</pre></blockquote>
<p>
そのような代入は役に立たないので、論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_FIELD_SELF_ASSIGNMENT">
<ShortDescription>フィールドの自己代入</ShortDescription>
<LongDescription>フィールド {2.givenClass} の自己代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには、フィールドの自己代入があります。<br>
たとえば、以下のようなコードです。
</p>
<blockquote><pre>
int x;
public void foo() {
x = x;
}
</pre></blockquote>
<p>
そのような代入は役に立たないので、論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_FIELD_DOUBLE_ASSIGNMENT">
<ShortDescription>フィールドの二重代入</ShortDescription>
<LongDescription>フィールド {2.givenClass} の二重代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには、フィールドの二重代入があります。<br>
たとえば、以下のようなコードです。
</p>
<blockquote><pre>
int x,y;
public void foo() {
x = x = 17;
}
</pre></blockquote>
<p>
フィールドに2回代入することは役に立たないので、論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_LOCAL_DOUBLE_ASSIGNMENT">
<ShortDescription>ローカル変数の二重代入</ShortDescription>
<LongDescription>ローカル変数 {2} の二重代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドには、ローカル変数の二重代入があります。<br>
たとえば、以下のようなコードです。
</p>
<blockquote><pre>
public void foo() {
int x,y;
x = x = 17;
}
</pre></blockquote>
<p>
変数に同じ値を2回代入することは役に立たないので、論理エラーかタイプミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_FIELD_SELF_COMPUTATION">
<ShortDescription>フィールドの無意味な自己演算 (たとえば、 x & x)</ShortDescription>
<LongDescription>{2.givenClass} とそれ自身との無意味な自己演算です。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、フィールドと同じフィールドへの別の参照との無意味な計算を実行しています (たとえば、x & x または x - x)。
この計算の性質のため、演算は意味をなすとは思われないので、論理エラーかタイプミスかもしれません。
計算をチェックしてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SA_LOCAL_SELF_COMPUTATION">
<ShortDescription>変数の無意味な自己演算 (たとえば、x & x)</ShortDescription>
<LongDescription>{2} とそれ自身との無意味な自己演算です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、ローカル変数と同じ変数への別の参照との無意味な計算を実行しています (たとえば、x & x または x - x)。
この計算の性質のため、演算は意味をなすとは思われないので、論理エラーかタイプミスかもしれません。
計算をチェックしてください。
</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.givenClass} とそれ自身との自己比較です。{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> なので)。
(同じ問題は long 値でも同様に起きます)。
</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>
特に、バイト配列 int にパックする以下のようなコードはひどく間違っています。
</p>
<blockquote><pre>
int result = 0;
for(int i = 0; i < 4; i++) {
result = ((result << 8) | b[i]);
}
</pre></blockquote>
<p>
その代わりに、以下のようなイディオムは動作します。
</p>
<blockquote><pre>
int result = 0;
for(int i = 0; i < 4; i++) {
result = ((result << 8) | (b[i] & 0xff));
}
</pre></blockquote>
]]>
</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>
特に、バイト配列 int にパックする以下のようなコードはひどく間違っています。
</p>
<blockquote><pre>
int result = 0;
for(int i = 0; i < 4; i++)
result = ((result << 8) + b[i]);
</pre></blockquote>
<p>
その代わりに、以下のようなイディオムは動作します。
</p>
<blockquote><pre>
int result = 0;
for(int i = 0; i < 4; i++)
result = ((result << 8) + (b[i] & 0xff));
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_AND">
<ShortDescription>互換性のないビットマスク</ShortDescription>
<LongDescription>(e & {2} == {3}) の互換性のないビットマスクは、一定の結果をもたらします。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、<i>(e & C)</i> 形式の式を <i>D</i> と比較しています。
定数 <i>C</i> と <i>D</i> の特定の値と常に等しくないことを比較します。論理エラーかタイプミスかもしれません。
</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> が負ではないとしても、'> 0' の代わりに '!= 0' を使うことは良いプラクティスと思われます。
</p>
<p>
Boris Bokowski
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_SIGNED_CHECK_HIGH_BIT">
<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> が負ではないとしても、'> 0' の代わりに '!= 0' を使うことは良いプラクティスと思われます。
</p>
<p>
Boris Bokowski
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BIT_AND_ZZ">
<ShortDescription>((...) & 0) == 0 なのか確かめている</ShortDescription>
<LongDescription>((...) & 0) == 0 なのか確かめています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、<i>(e & 0)</i> 形式の式を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> と比較しています。
定数 <i>C</i> と <i>D</i> の特定の値と常に等しくないことを比較します。論理エラーかタイプミスかもしれません。
</p>
<p>
典型的に、このバグは、ビットセットで帰属関係のテストを実行したいコードで発生します。
しかし、ビット論理積演算子 ("&") の代わりにビット論理和演算子 ("|") を使用しています。
</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>
このメソッドには、volatile でない static フィールドの非同期な遅延初期化があります。
コンパイラやプロセッサが命令を並べ替えるかもしれないので、メソッドが複数のスレッドによって呼び出されるかもしれないなら、
スレッドは完全に初期化されたオブジェクトを見るとは保証されていません。
フィールドにアクセスした際に、中途半端に初期化されたインスタンスが見えてしまう危険があります。
この問題を修正するために、フィールドを volatile にできます。<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>
このメソッドには、static フィールドの非同期な遅延初期化があります。
フィールドが設定されたあと、その場所に格納されるオブジェクトはさらに更新されるかアクセスされます。
それが設定されるとすぐに、そのフィールドの設定は他のスレッドに見えます。
フィールドを設定するさらなるアクセスがオブジェクトを初期化するのに役に立つなら、
それが完全に初期化されるまでどんな他のスレッドも格納されたオブジェクトにアクセスするのを防がない限り、非常に深刻なマルチスレッドバグがあります。
</p>
<p>
たとえメソッドが複数のスレッドによって決して呼び出されないと確信していても、
それは、フィールドに設定している値が完全にデータを読み込まれるか初期化されるまで、 static フィールドを設定しない方が良いかもしれません。
</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 の Condition オブジェクト) で、<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> の使用とは違う互換性のないそれら自身の同時制御メカニズムを持っています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="UPM_UNCALLED_PRIVATE_METHOD">
<ShortDescription>private メソッドは決して呼び出されない</ShortDescription>
<LongDescription>{1} は、決して呼び出されません。</LongDescription>
<Details>
<![CDATA[
<p>
この private メソッドは、決して呼び出されません。
メソッドがリフレクションによって呼び出されるかもしれないが、決して使われないなら除去するべきです。
</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>
<blockquote><pre>
// 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();
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="ITA_INEFFICIENT_TO_ARRAY">
<ShortDescription>長さが0の配列の引数で toArray メソッドを使用しているメソッド</ShortDescription>
<LongDescription>{1} は、長さが0の配列の引数で Collection.toArray() を使用しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、Collection 派生クラスの </code>toArray</code> メソッドを使用して長さが0の配列の引数を渡しています。
<code>myCollection.toArray(new Foo[myCollection.size()])</code> を使用する方がより効率的です。
渡される配列がコレクションの要素のすべてを格納できるくらいの大きさなら、データが読み込まれて、そのまま返されます。
これは、結果として返す2番目の配列 (リフレクションによって) を作成する必要を回避します。
</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 の TestCase クラスで、<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 の TestCase クラスで、<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 の TestCase クラスで、<code>suite</code> メソッドを実装しています。
<code>suite</code> メソッドは static として宣言するべきなのにそうしていません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IJU_BAD_SUITE_METHOD">
<ShortDescription>TestCase は suite メソッドの間違った宣言をしている</ShortDescription>
<LongDescription>TestCase {0} は、suite メソッドの間違った宣言をしています。</LongDescription>
<Details>
<![CDATA[
<p>
JUnit の TestCase クラスで、<code>suite</code> メソッドを実装しています。
しかしながら、<code>suite</code> メソッドは
</p>
<pre>public static junit.framework.Test suite()</pre>
<p>か</p>
<pre>public static junit.framework.TestSuite suite()</pre>
<p>
のどちらかを宣言する必要があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IJU_NO_TESTS">
<ShortDescription>TestCase はテストがない </ShortDescription>
<LongDescription>TestCase {0} は、テストがありません。</LongDescription>
<Details>
<![CDATA[
<p>
JUnit の TestCase クラスで、どんなテストメソッドも実装していません。
</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 パッケージで定義されているリスナを実装する Adapter です。
その結果、イベントが発生するときこのメソッドは呼び出されません。
</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>Method {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> の getXXX、updateXXX メソッドを呼び出しています。
<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> の setXXX メソッドを呼び出しています。
インデックスは1から開始するので、これは常に間違いです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="SIO_SUPERFLUOUS_INSTANCEOF">
<ShortDescription>instanceof 演算子を使用した不必要な型チェック</ShortDescription>
<LongDescription>メソッド {1} は、静的に確定している可能性があるのに instanceof 演算子を使用して不必要な型チェックをしています。</LongDescription>
<Details>
<![CDATA[
<p>
オブジェクトが要求する型であるかどうかにかかわらず、静的に確定している可能性があるのに instanceof 演算子を使用して型チェックをしています。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BAC_BAD_APPLET_CONSTRUCTOR">
<ShortDescription>初期化されていない AppletStub に依存する間違ったアプレットコンストラクタ</ShortDescription>
<LongDescription>間違ったアプレットコンストラクタは、初期化されていない AppletStub に依存しています。</LongDescription>
<Details>
<![CDATA[
<p>
このコンストラクタは、AppletStub に依存する親アプレットでメソッドを呼び出しています。
このアプレットの <code>init</code> メソッドが呼び出されるまで AppletStub は初期化されないので、これらのメソッドは正しく機能しません。
</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> メソッドは、static メソッドです。<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>
このメソッドは、カレントスレッドでない Thread オブジェクトであるように見える Thread オブジェクトで <code>Thread.interrupted()</code> を呼び出しています。
<code>interrupted</code> メソッドは static で、作成者が意図したこととは異なるオブジェクトで呼び出されます。
</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 コンパイラが final なローカル変数のためにしばしば無効な格納を生成することに注意してください。
FindBugs は、バイトコードベースのツールなので誤検出をなくす簡単な方法がありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DLS_DEAD_LOCAL_STORE_IN_RETURN">
<ShortDescription>return 文に役に立たない代入がある</ShortDescription>
<LongDescription>{1} からの return 文に役に立たない代入があります。</LongDescription>
<Details>
<![CDATA[
<p>
この文は、return 文でローカル変数に代入をしています。この代入は効果がありません。
この文が正しいことを確かめてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DLS_DEAD_STORE_OF_CLASS_LITERAL">
<ShortDescription>クラスリテラルの無効な代入</ShortDescription>
<LongDescription>{3}.class の無効な代入です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この命令は変数にクラスリテラルを代入しているのに決して使われません。<br>
<a href="//java.sun.com/j2se/1.5.0/compatibility.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="//java.sun.com/j2se/1.5.0/compatibility.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>
このコードはローカル変数に null を代入しているのに代入された値は読み出されていません。
この代入はガベージコレクタを手伝うために導入されたのかもしれませんが、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>
このメソッドは、keySet イテレータから取り出されたキーを使用して、マップエントリの値にアクセスしています。
Map の entrySet イテレータを使用した方が <code>Map.get(key)</code> ルックアップを回避するのでより効率的です。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ISC_INSTANTIATE_STATIC_CLASS">
<ShortDescription>static メソッドだけを提供するクラスの不必要なインスタンス化</ShortDescription>
<LongDescription>メソッド {1} は、static メソッドだけを提供するクラスを不必要にインスタンス化しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは、static メソッドだけを提供するクラスのオブジェクトを作成しています。
このオブジェクトは作成する必要はありません。修飾子として直接クラス名を使用する static メソッドにアクセスしてください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="REC_CATCH_EXCEPTION">
<ShortDescription>例外がスローされないのに例外をキャッチしている</ShortDescription>
<LongDescription>例外がスローされないのに例外をキャッチしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、例外オブジェクトをキャッチする try-catch ブロックを使用しているのに例外は try ブロックの中でスローされません。また、実行時例外は明示的にキャッチされません。
それぞれの catch ブロックが同一である多くの例外型をキャッチすることの短縮形として <code>try { ... } catch (Exception e) { something }</code> を使用することが共通のバグパターンです。
しかし、この構文は誤って実行時例外も同様にキャッチするので、潜在的なバグを隠します。
</p>
]]>
</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> は常に false と評価します。
<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つの浮動小数点値を比較しています。
浮動小数点の計算は丸めを伴うかもしれないので、計算された float と double の値は正確ではないかもしれません。
通貨のような正確でなければならない値のために、<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>
このメソッドは、定数値で java.lang.Math の static メソッドを呼び出しています。
このメソッドの結果は、静的に確定している可能性があり、より高速で、ときには定数を使用する方がより正確です。<br>
検出されるメソッドは、以下の通りです。
</p>
<table>
<tr>
<th>メソッド</th> <th>パラメータ</th>
</tr>
<tr>
<td>abs</td> <td>-any-</td>
</tr>
<tr>
<td>acos</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>asin</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>atan</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>atan2</td> <td>0.0</td>
</tr>
<tr>
<td>cbrt</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>ceil</td> <td>-any-</td>
</tr>
<tr>
<td>cos</td> <td>0.0</td>
</tr>
<tr>
<td>cosh</td> <td>0.0</td>
</tr>
<tr>
<td>exp</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>expm1</td> <td>0.0</td>
</tr>
<tr>
<td>floor</td> <td>-any-</td>
</tr>
<tr>
<td>log</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>log10</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>rint</td> <td>-any-</td>
</tr>
<tr>
<td>round</td> <td>-any-</td>
</tr>
<tr>
<td>sin</td> <td>0.0</td>
</tr>
<tr>
<td>sinh</td> <td>0.0</td>
</tr>
<tr>
<td>sqrt</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>tan</td> <td>0.0</td>
</tr>
<tr>
<td>tanh</td> <td>0.0</td>
</tr>
<tr>
<td>toDegrees</td> <td>0.0 or 1.0</td>
</tr>
<tr>
<td>toRadians</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>
Servletクラスを拡張したクラスで、インスタンス変数を使用しています。
Servlet クラスの1つのインスタンスだけが Java EE フレームワークによって作成され、マルチスレッドによって使われるので、このパラダイムは極めて問題があり推奨できません。
ローカル変数を使うことだけを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="PS_PUBLIC_SEMAPHORES">
<ShortDescription>公開インタフェースで同期化とセマフォを暴露するクラス</ShortDescription>
<LongDescription>クラス {0} は、公開インタフェースで同期化とセマフォを暴露しています。</LongDescription>
<Details>
<![CDATA[
<p>
このクラスは、それ自身 (this 参照) で、 <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>
このコードは、以下のように整数の乗算を実行してから結果を long に変換しています。
</p>
<blockquote><pre>
long convertDaysToMilliseconds(int days) { return 1000*3600*24*days; }
</pre></blockquote>
<p>
long を使用して乗算をすれば、結果がオーバーフローするという可能性を回避できます。<br>
たとえば、以下のように修正できます。
</p>
<blockquote><pre>
long convertDaysToMilliseconds(int days) { return 1000L*3600*24*days; }
</pre></blockquote>
<p>
または
</p>
<blockquote><pre>
static final long MILLISECONDS_PER_DAY = 24L*3600*1000;
long convertDaysToMilliseconds(int days) { return days * MILLISECONDS_PER_DAY; }
</pre></blockquote>
]]>
</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>
たとえば、次のメソッド（Date にエポックから秒を変換することを意図した）は、ひどく壊れています。
</p>
<blockquote><pre>
Date getDate(int seconds) { return new Date(seconds * 1000); }
</pre></blockquote>
<p>
乗算は32ビット演算を使用して、64ビット値に変換されます。
32ビット値は、64ビットに変換されて、絶対時間値を表すために使用されるとき、1969年12月と1970年1月の日付しか表せません。
</p>
<p>
上記のメソッドのための正しい実装は、以下の通りです。
</p>
<blockquote><pre>
// 失敗、2037年後の日付
Date getDate(int seconds) { return new Date(seconds * 1000L); }
// より良い, すべての日付で動作する
Date getDate(long seconds) { return new Date(seconds * 1000); }
</pre></blockquote>
]]>
</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>
このコードは、整数値を float 精度浮動小数点に変換してからその結果を <code>Math.round()</code> に渡して引数に最も近い int/long を返します。
整数を float に変換すると小数部がない数値が得られるので、この演算は常にノーオペレーションになります。
<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>
このコードは、整数値 (たとえば、int や long) を倍精度浮動小数点に変換してからその結果を <code>Math.ceil()</code> に渡しています。
整数を double に変換すると小数部がない数値が得られるので、この演算は常にノーオペレーションになります。
<code>Math.ceil()</code>に渡される値を生成した演算が倍精度浮動小数点演算を使用して実行することを意図した可能性が高いです。
]]>
</Details>
</BugPattern>
<BugPattern type="ICAST_IDIV_CAST_TO_DOUBLE">
<ShortDescription>整数の除算の結果を double または float にキャストしている</ShortDescription>
<LongDescription>整数の除算の結果を double または float にキャストしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは 整数の除算の結果を double または float にキャストしています。
整数で除算をすることは、ゼロに最も近い整数値まで結果を切り捨てます。
結果が double にキャストされたという事実は、この精度が維持されるべきだったことを示唆しています。
おそらく意味されたことは、除算を実行する前にオペランドの1つまたは両方を double にキャストすることでした。<br>
以下に例を示します。
</p>
<blockquote><pre>
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;
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="J2EE_STORE_OF_NON_SERIALIZABLE_OBJECT_INTO_SESSION">
<ShortDescription>HttpSession への非直列化可能オブジェクトの格納</ShortDescription>
<LongDescription>非直列化可能オブジェクト {2} を HttpSession に格納しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、HttpSession に非直列化可能オブジェクトを格納していると思われます。
このセッションが不活性化されるか移行したなら、エラーを招きます。
</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_NO_PREVIOUS_ARGUMENT">
<ShortDescription>書式文字列ための前の引数がない</ShortDescription>
<LongDescription>書式文字列の引数 {2} の前の引数がありません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この書式文字列は、前の書式指示子の引数が再利用されるようにするために「相対インデックス ("<")」を指定しています。
しかしながら、前の引数がありません。
たとえば、<code>formatter.format("%<s %s", "a", "b")</code> が実行されると MissingFormatArgumentException をスローします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_USES_NEWLINE">
<ShortDescription>書式文字列は \n よりも %n を使用するべき</ShortDescription>
<LongDescription>書式文字列は、\n よりも %n を使用するべきです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
この書式文字列には、改行文字 (\n) が含まれています。
一般に書式文字列には %n を使用することがより望ましいです。%n は、プラットホーム特有の行セパレータを作り出します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_BAD_CONVERSION">
<ShortDescription>与えられた引数の型は書式指示子に合致しません</ShortDescription>
<LongDescription>引数の型 {3} は、書式指示子 {4} によって扱えません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
引数の1つは、対応する書式指示子と互換性がありません。その結果、実行されるときに実行時例外を生成します。
たとえば、<code>String.format("%d", "1")</code> は、文字列 "1" が書式指示子 "%d" と互換性がないので例外を生成します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_BAD_CONVERSION_TO_BOOLEAN">
<ShortDescription>Boolean でない引数を ％b 書式指示子を使用してフォーマットしている</ShortDescription>
<LongDescription>Boolean でない引数を ％b 書式指示子を使用してフォーマットしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
Boolean 型でない引数を %b 書式指示子でフォーマットしています。これは例外をスローしません。
その代わりに null でない値では true 、null では false を出力します。
書式文字列のこの機能は奇妙で意図したことではないかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_BAD_CONVERSION_FROM_ARRAY">
<ShortDescription>書式文字列を使用して役に立たない方法で配列をフォーマットしている</ShortDescription>
<LongDescription>役に立たない方法で引数の型 {3} をフォーマットしています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
書式文字列でフォーマットされている引数の1つは配列です。
これは [I@304282 のようなかなり役に立たない書式を使用してフォーマットされます。それは配列のコンテンツを表示しません。
フォーマットで扱う前に <code>Arrays.asList(...)</code> を使用して配列をラップすることを検討してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_ARG_MISMATCH">
<ShortDescription>書式文字列への引数の数と書式指示子の数が一致していない</ShortDescription>
<LongDescription>書式文字列は "{3}" によって呼び出されている書式文字列メソッド {2} は、書式指示子の数が {4} なのに 引数の数は {5} です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
可変長引数による書式文字列メソッドが呼び出されていますが渡された引数の数と書式文字列の中の % 書式指示子の数が一致していません。
これはおそらく作成者の意図したことではありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_EXPECTED_MESSAGE_FORMAT_SUPPLIED">
<ShortDescription>printf スタイルの書式が期待されているところで MessageFormat が与えられている</ShortDescription>
<LongDescription>{2} は、prntf スタイルの書式を必要としていますが MessageFormat によって呼び出されています。</LongDescription>
<Details>
<![CDATA[
<p>
Java の printf 書式文字列と引数のリストを期待するメソッドが呼び出されています。
しかしながら、書式文字列にはどんな書式指示子 (たとえば、%s) もなくて、メッセージフォーマットの要素 (たとえば、{0}) があります。
printf スタイルの書式文字列が必要なときに、MessageFormat の文字列を与えている可能性が高いです。
実行時に、すべての引数は無視され、書式文字列は正確にフォーマットされずに返されます。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_EXTRA_ARGUMENTS_PASSED">
<ShortDescription>書式文字列で実際に使われるより、多くの引数が渡されている</ShortDescription>
<LongDescription>書式文字列 {3} によって呼び出されている書式文字列メソッド {2} は、書式指示子の数が {4} なのに 引数の数は {5} です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
可変長引数による書式文字列メソッドが呼び出されていますが書式文字列で実際に使われるより多くの引数が渡されています。
これは実行時例外の原因とはなりませんが、コードはフォーマットされた文字列に含まれることを意図した情報を黙って省略しているかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_ILLEGAL">
<ShortDescription>無効な書式文字列</ShortDescription>
<LongDescription>無効な書式文字列 "{3}" です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
書式文字列は構文的に無効です。この文が実行されると実行時例外が発生します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_MISSING_ARGUMENT">
<ShortDescription>書式文字列は足りない引数を参照している</ShortDescription>
<LongDescription>書式文字列 "{3}" は 引数が {5} 必要なのに {6} だけしか与えられていません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
書式文字列で書式指示子を満たすために十分な引数が渡されていません。この文が実行されると実行時例外が発生します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="VA_FORMAT_STRING_BAD_ARGUMENT">
<ShortDescription>書式指示子へ渡している引数に互換性がない</ShortDescription>
<LongDescription>書式指示子 {4} は、対応する引数と互換性がありません。{1}</LongDescription>
<Details>
<![CDATA[
<p>
書式指示子は、対応する引数と互換性がありません。
たとえば、<code>System.out.println("%d\n", "hello");</code> の %d 書式指示子は数値の引数を必要としますが数値ではなく文字列が渡されています。
この文が実行されると実行時例外が発生します。
</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> と同じ型でないなら単に false を返すべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_BAD_CAST_TO_ABSTRACT_COLLECTION">
<ShortDescription>抽象コレクションへの疑わしいキャスト</ShortDescription>
<LongDescription>Collection から抽象クラス {3} への疑わしいキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、Collection を抽象コレクションにキャストしています (たとえば、<code>List</code>、<code>Set</code>、<code>Map</code>)。
オブジェクトがキャストする型であると保証されることを確認してください。
必要とするコレクションの反復処理ができるなら Set または List にキャストする必要はありません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_IMPOSSIBLE_CAST_PRIMITIVE_ARRAY">
<ShortDescription>プリミティブ型の配列を含んでいる不可能なキャスト</ShortDescription>
<LongDescription>プリミティブ型の配列を含んでいる不可能なキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このキャストは、常にClassCastException をスローします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_IMPOSSIBLE_CAST">
<ShortDescription>不可能なキャスト</ShortDescription>
<LongDescription>{2} から {3} への不可能なキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このキャストは、常に ClassCastException をスローします。
FindBugs は、instanceof チェックから型情報を調査して、メソッドからの戻り値とフィールドからロードされた値の型について、より多くの正確な情報を使用します。
したがって、宣言された変数の型にはより多くの正確な情報があるかもしれないしれません。
そして、キャストが常に実行時例外をスローするのか判定するために使用する可能性があります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_IMPOSSIBLE_DOWNCAST">
<ShortDescription>不可能なダウンキャスト</ShortDescription>
<LongDescription>{2} から {3} への不可能なダウンキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このキャストは、常に ClassCastException をスローします。
解析は、キャストしている値の正確な型がわかっていると信じています。
そして、サブタイプへダウンキャストしようとする試みは、ClassCastException のスローによって常に失敗します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_IMPOSSIBLE_DOWNCAST_OF_TOARRAY">
<ShortDescription>toArray メソッドの結果の不可能なダウンキャスト</ShortDescription>
<LongDescription>{3} への toArray メソッドの結果の不可能なダウンキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、以下のように、<code>Object[]</code> より特定の型のコレクションで <code>toArray</code> メソッドを呼び出す結果をキャストしています。
</p>
<blockquote><pre>
String[] getAsArray(Collection<String> c) {
return (String[]) c.toArray();
}
</pre></blockquote>
<p>
これは通常、ClassCastException をスローして失敗します。
ほとんどすべてのコレクションの <code>toArray</code> メソッドは、<code>Object[]</code> を返します。
Collection オブジェクトは宣言された総称型コレクションの参照がないので、本当に何もできません。
コレクションから特定の型の配列を得る正しい方法は、<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> を返します。
FindBugs はそのようなケースを検出して抑止しようとしますが、いくつか見落とすかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="NP_NULL_INSTANCEOF">
<ShortDescription>null とわかっている値をその型のインスタンスなのか確かめている</ShortDescription>
<LongDescription>null とわかっている値を {2} のインスタンスなのか確かめています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
チェックされている値が null であることが保証されているので、instanceof は常に faluse を返します。
これは安全で、誤解や論理エラーを指摘していないことを確認してください。
</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>
この instanceof は常に false を返します。これは安全で、誤解や論理エラーを指摘していないことを確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_VACUOUS_INSTANCEOF">
<ShortDescription>常に true を返す instanceof</ShortDescription>
<LongDescription>{2} は {3} のインスタンスなので instanceof は常にすべての非 null 値に対して true を返します。</LongDescription>
<Details>
<![CDATA[
<p>
この instanceof は常に true を返します (テストしている値が null でない限り)。
これは安全で、誤解や論理エラーを指摘していないことを確認してください。
本当に null なのか値をテストしたいなら、たぶん、instanceof ではなく null テストをした方が良く、より明確になります。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_UNCONFIRMED_CAST">
<ShortDescription>未チェック/未確認のキャスト</ShortDescription>
<LongDescription>{2} から {3} への未チェック/未確認のキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このキャストはチェックされていません。
すべての型のインスタンスがキャストした型にキャストできるというわけではありません。
プログラムのロジックが確実にこのキャストが失敗しないことを確認してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="BC_BAD_CAST_TO_CONCRETE_COLLECTION">
<ShortDescription>具象コレクションへの疑わしいキャスト</ShortDescription>
<LongDescription>{2} から {3} への疑わしいキャストです。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは抽象コレクション (たとえば、Collection、List、Set) を特定の具象実装 (たとえば、ArrayList、HashSet) にキャストしています。
これは正しくないかもしれません。
そして、将来の時点で他の具象実装への切り替えをとても困難にするので、脆弱なコードになるかもしれません。
そうするために特別な理由がない限り抽象コレクションクラスを使用してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RE_POSSIBLE_UNINTENDED_PATTERN">
<ShortDescription>正規表現のために使われている "."</ShortDescription>
<LongDescription>正規表現で "." を使用しています。{1}</LongDescription>
<Details>
<![CDATA[
<p>
String メソッドが呼び出されていて、"." が引数として正規表現を取るパラメータに渡されています。
これは、意図したことですか?
たとえば、<code>s.replaceAll(".", "/")</code> はあらゆる文字が "/" 文字に置き換えられた文字列を返します。
また、<code>s.split(".")</code> は常に長さが0の String の配列を返します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="RE_BAD_SYNTAX_FOR_REGULAR_EXPRESSION">
<ShortDescription>正規表現のための無効な構文</ShortDescription>
<LongDescription>正規表現のための無効な構文です。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、正規表現の構文によると無効である正規表現を使用しています。
この文が実行されるとき PatternSyntaxException をスローします。
</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>
このコードは、符号なしキャストの実行結果を short または byte にキャストしています。結果の上位ビットは捨てられます。
上位ビットが捨てられるので、符号付き、符号なし右シフトの (シフトのサイズによって) 違いがないかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="ICAST_BAD_SHIFT_AMOUNT">
<ShortDescription>32ビット int の0から31の範囲を超えた量によるシフト</ShortDescription>
<LongDescription>32ビット int を {2} ビットでシフトしました。{1}</LongDescription>
<Details>
<![CDATA[
<p>
このコードは、32ビット int の0から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>
このコードは、整数剰余の結果に整数定数を乗算しています。
紛らわしい演算子の優先順位がないことを確実にしてください。
たとえば、i % 60 * 1000 は、i % (60 * 1000) ではなく (i % 60) * 1000 となります。
</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> メソッドを呼び出すことは、System.identityHashCode と同じ値を返すので、コンテンツと配列の長さを無視します。
配列 <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.sun.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>
このコードは、ハードコードされた絶対パス名を使用して File オブジェクトを構築しています (たとえば、<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>
このメソッドは、switch 文の2つの case を実装するために同じコードを使用しています。
重複コードの case かもしれないし、コーディングミスかもしれません。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="IMA_INEFFICIENT_MEMBER_ACCESS">
<ShortDescription>所有クラスの private メンバー変数にアクセスしているメソッド</ShortDescription>
<LongDescription>メソッド {1} は、所有クラスの private メンバー変数にアクセスしています。</LongDescription>
<Details>
<![CDATA[
<p>
この内部クラスのメソッドは、所有クラスの private メンバー変数への読み書きか、所有クラスの private メソッドを呼び出しています。
コンパイラはこの private メンバーにアクセスするために特別なメソッドを生成しなければなりないので、効率を悪化させる原因になります。
メンバー変数またはメソッドの保護を緩和することは、コンパイラが通常のアクセスとして扱うのを許可します。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="XFB_XML_FACTORY_BYPASS">
<ShortDescription>XMLインタフェースの特定の実装のインスタンスを作成しているメソッド</ShortDescription>
<LongDescription>メソッド {1} は、XMLインタフェースの特定の実装のインスタンスを作成しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、XMLインタフェースの特定の実装のインスタンスを作成しています。
実装が実行時に変更できるように、これらのオブジェクトを作成するために提供されたファクトリクラスを使うことが望ましいです。<br>
詳細は、以下を参照してください。
</p>
<ul>
<li>javax.xml.parsers.DocumentBuilderFactory</li>
<li>javax.xml.parsers.SAXParserFactory</li>
<li>javax.xml.transform.TransformerFactory</li>
<li>org.w3c.dom.Document.create<i>XXXX</i></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>
このクラスは、final と宣言されていますが、フィールドは protected と宣言されています。
クラスは fainal なので派生できません。、protected の使用は紛らわしいです。
フィールドのためのアクセス修飾子は、フィールドの真の用途を表すため、 private か public に変更するべきです。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="QBA_QUESTIONABLE_BOOLEAN_ASSIGNMENT">
<ShortDescription>論理式で boolean リテラル値を代入しているメソッド</ShortDescription>
<LongDescription>メソッド {1} は、論理式で boolean リテラル値を代入しています。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、if または while の式の中の boolean 変数に boolean リテラル値 (true または false) を代入しています。
おそらく、これは = による代入ではなく、== を使用して論理比較をすることになっていました。
</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>
総称型パラメータからの特定の型が予想される Object 型をコンパイルするとき、総称型コレクションメソッドへの呼び出しは引数を渡します。
したがって、標準の 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> が true だとして) 場合にだけ意味があります。
これは true である可能性が低くて、もし true なら問題の原因になります (たとえば、無限再帰になっているハッシュコードの計算)。
間違ったパラメータが渡されている可能性が高いです。
</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> を呼び出すことは常に true であるべきです。
そして、<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>
このクラスは、Iterator と Map.Entry で基底 Map のビューを返すことを許可された両方の entrySet メソッドがあります。
この巧妙なアイデアは、Map 実装で使用されましたが、厄介なコーディング間違いの可能性を取り込みました。
Map <code>m</code> が entrySet のためのそのような反復子を返すならば、<code>c.addAll(m.entrySet())</code> はひどく間違っていくでしょう。
OpenJDK 1.7 の すべての Map 実装はこれを回避するために書き直されました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="DMI_ENTRY_SETS_MAY_REUSE_ENTRY_OBJECTS">
<ShortDescription>エントリセットの要素を加えることは、Entry オブジェクトの再利用のために失敗するかもしれない</ShortDescription>
<LongDescription>エントリセットの要素を加えることは、{2.simpleClass} の再利用のために失敗するかもしれません。{1} の Entry オブジェクト</LongDescription>
<Details>
<![CDATA[
<p>
entrySet メソッドは、一つの Entry オブジェクトを再利用し、反復中に返される基底 Map のビューを返すことが許可されています。
Java 1.6 の時点で、IdentityHashMap と EnumMap の両方がそうしました。
そのような Map を通して繰り返すとき、エントリ値は次の繰り返しへ進むまでが有効です。
たとえば、addAll メソッドにそのような entrySet を渡そうとすると、物事はひどく間違っていくでしょう。
</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 にそれに関する手がかりがないとしても、Calendar はマルチスレッドでの使用は本質的に安全でありません。
正しい同期化をしないでスレッド境界の向こうで1つのインスタンスを共有することは、アプリケーションの誤動作になります。
JDK 5.0に比べて JDK 1.4 の方が問題が表面化するように思われ、おそらく sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate() の ArrayIndexOutOfBoundsExceptions や IndexOutOfBoundsExceptions がランダムに発生します。
直列化問題も経験するかもしれません。インスタンスフィールドを使うことを推奨します。<br>
詳細については、<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> や <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun 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 にそれに関する手がかりがないとしても、Calendar はマルチスレッドでの使用は本質的に安全ではありません。
ディテクタは、static フィールドから得られた Calendar のインスタンスの呼び出しを発見しました。
これは疑わしく見えます。
詳細については、<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> や <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun 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 に書かれているように、DateFormat はマルチスレッドでの使用は本質的に安全ではありません。
正しい同期化をしないでスレッド境界の向こうで1つのインスタンスを共有することは、アプリケーションの誤動作になります。
JDK 5.0に比べて JDK 1.4 の方が問題が表面化するように思われ、おそらく sun.util.calendar.BaseCalendar.getCalendarDateFromFixedDate() の ArrayIndexOutOfBoundsExceptions や IndexOutOfBoundsExceptions がランダムに発生します。
直列化問題も経験するかもしれません。インスタンスフィールドを使うことを推奨します。<br>
詳細については、<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> や <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a> を参照してください。
]]>
</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 に書かれているように、DateFormat はマルチスレッドでの使用は本質的に安全ではありません。
ディテクタは、static フィールドから得られた DateFormat のインスタンスの呼び出しを発見しました。
これは疑わしく見えます。
詳細については、<a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6231579">Sun Bug #6231579</a> や <a href="http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6178997">Sun Bug #6178997</a> を参照してください。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_ALWAYS_VALUE_USED_WHERE_NEVER_REQUIRED">
<ShortDescription>型修飾子を付けられた値がその修飾子を付けてはならない値を必要とする場所で使われている</ShortDescription>
<LongDescription>型修飾子 {2} を付けられた値がその修飾子を付けてはならない値を必要とする場所で使われています。</LongDescription>
<Details>
<![CDATA[
<p>
型修飾子アノテーションを付けられた値がそのアノテーションを付けてはならない値を必要とする場所で使われています。
</p>
<p>
より正確に、when=ALWAYS を指定している型修飾子アノテーションが付けられた値は、到達することが保証されているか同じ型修飾子が when=NEVER を指定するところで使用します。
</p>
<p>
たとえば、@NonNegative が型修飾子アノテーション @Negative(when=When.NEVER) の略称だとします。
以下のコードは、return 文が ＠NonNegative 値を必要とするが ＠Negative としてマークされている引数を受け取るのでこの警告を生成します。
</p>
<blockquote><pre>
public @NonNegative Integer example(@Negative Integer value) {
return value;
}
</pre></blockquote>
]]>
</Details>
</BugPattern>
<BugPattern type="TQ_NEVER_VALUE_USED_WHERE_ALWAYS_REQUIRED">
<ShortDescription>型修飾子を付けていない値がその修飾子が付く値を必要とする場所で使われている</ShortDescription>
<LongDescription>型修飾子 {2.simpleName} を付けていない値がその修飾子が付く値を必要としている場所で使われています。</LongDescription>
<Details>
<![CDATA[
<p>
型修飾子アノテーションを付けていない値がそのアノテーションが付いた値を必要とする場所で使われています。
</p>
<p>
より正確に、when=NEVER を指定している型修飾子アノテーションが付けられた値が同じ型修飾子が when=ALWAYS を指定する場所で使用しています。
</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> で同期化しています。
このクラスがサブクラス化されるなら、サブクラスはおそらく意図したことではないサブクラスのためにクラスオブジェクトで同期化します。
たとえば、java.awt.Label の以下のコードを検討してください。
</p>
<blockquote><pre>
private static final String base = "label";
private static int nameCounter = 0;
String constructComponentName() {
synchronized (getClass()) {
return base + nameCounter++;
}
}
</pre></blockquote>
<p>
<code>Label</code> のサブクラスは同じサブクラスで同期化しません。データレースを生じさせます。
その代わりに、このコードは、<code>Label.class</code> で同期化するべきです。
</p>
<blockquote><pre>
private static final String base = "label";
private static int nameCounter = 0;
String constructComponentName() {
synchronized (Label.class) {
return base + nameCounter++;
}
}
</pre></blockquote>
<p>
Jason Mehrens によって寄贈されたバグパターン
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="OBL_UNSATISFIED_OBLIGATION">
<ShortDescription>ストリームやリソースのクリーンアップに失敗するかもしれないメソッド</ShortDescription>
<LongDescription>メソッド {1} は、{2} のクリーンアップに失敗するかもしれません。</LongDescription>
<Details>
<![CDATA[
<p>
このメソッドは、ストリーム、データベースオブジェクト、または明示的にクリーンアップ操作を必要としている他のリソースのクリーンアップ (クローズする、処分する) に失敗するかもしれません。
</p>
<p>
通常、メソッドがストリープや他のリソースを開いたなら、メソッドはストリームやリソースがメソッドが戻る前にクリーンアップされることを確認するために、try/finally ブロックを使用するべきです。
</p>
<p>
このバグパターンは、OS_OPEN_STREAM と ODR_OPEN_DATABASE_RESOURCE と基本的に同じですが異なる (そして、うまくいけばより良い) 静的解析技術に基づいています。
私たちは関心があるのがこのバグパターンの有用性についてのフィードバックを得ることです。
どちらかの方法でフィードバックを送ってください。
</p>
<ul>
<li>send email to [email protected]</li>
<li>file a bug report: <a href="http://findbugs.sourceforge.net/reportingBugs.html">http://findbugs.sourceforge.net/reportingBugs.html</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>FindBugs からの予期しない/望ましくない警告</ShortDescription>
<LongDescription>予期しない/望ましくない {2} FindBugs 警告。{1}</LongDescription>
<Details>
<![CDATA[
<p>
FindBugs は、@NoWarning アノテーションによって、予期しない/望ましくない警告を生成しました。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="FB_MISSING_EXPECTED_WARNING">
<ShortDescription>失われた FindBugs からの予期した/望ましい警告</ShortDescription>
<LongDescription>失われた予期した/望ましい {2} FindBugs 警告。{1}</LongDescription>
<Details>
<![CDATA[
<p>
FindBugs は、@ExpectedWarning によって、予期した/望ましい警告が生成されませんでした。
</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つの値が与えられたキー (非存在が成功するかどうかの第一の値) と関連することを確認するために使われます。
戻り値を無視して中で渡される値への参照を保持するなら、マップのキーと関連する1つではない値を保持する危険性を冒します。
どれを使用するかが重要であり、マップに格納できないものを使用すると、プログラムは誤った振る舞いをします。
</p>
]]>
</Details>
</BugPattern>
<BugPattern type="LG_LOST_LOGGER_DUE_TO_WEAK_REFERENCE">
<ShortDescription>ロガーの変更は OpenJDK の弱参照が原因で潜在的に失われる</ShortDescription>
<LongDescription>ロガーの変更は失われる可能性があります。{1}</LongDescription>
<Details>
<![CDATA[
<p>
OpenJDK は、潜在的非互換性を取り入れました。特に、java.util.logging.Logger は振る舞いが変更されています。
強参照を使用する代わりに、現在、内部的に弱参照を使用しています。
それは理にかなった変更ですが、残念ながらいくつかのコードは古い振る舞いに依存しています。
ロガーの構成を変更するとき、ロガーへの参照を捨てます。
つまり、ガベージコレクタはそのメモリを回収できます。それは、ロガーの構成が失われることを意味します。
たとえば、以下を検討してください。
</p>
<blockquote><pre>
public static void initLogging() throws Exception {
Logger logger = Logger.getLogger("edu.umd.cs");
logger.addHandler(new FileHandler()); // ロガーの構成の変更
logger.setUseParentHandlers(false); // 別のロガーの構成の変更
}
</pre></blockquote>
<p>
ロガーの参照は、メソッドの終わり (メソッドは脱出しません) で失われるので、
<code>initLogging</code> の呼び出しの後でガベージコレクションの循環があるなら、ロガー構成は失われます (なぜなら Logger は弱参照を保持するだけなので)。
.</p>
<blockquote><pre>
public static void main(String[] args) throws Exception {
initLogging(); // ファイルハンドラーをロガーに追加する
System.gc(); // ロガーの構成が失われる
Logger.getLogger("edu.umd.cs").info("Some message"); // 期待したようにファイルに記録されません
}
</pre></blockquote>
<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>
バイトから String (またはStringからバイト) への変換で、デフォルトプラットホームエンコーディングが適切であると仮定するメソッドの呼び出しを発見しました。
これは、アプリケーションの振る舞いがプラットホーム間で異なる原因となります。代替 API を使用して、明示的に文字セット名または Charset オブジェクトを指定して下さい。
</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="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="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="RV">メソッドからの戻り値の間違った使用</BugCode>
<BugCode abbrev="LG">Logger の問題</BugCode>
<BugCode abbrev="IA">あいまいな呼び出し</BugCode>
<BugCode abbrev="HSC">巨大な文字列定数</BugCode>
<BugCode abbrev="HRS">HRS 脆弱性</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="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="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">FindBugs はメソッドで期待された警告を出しませんでした</BugCode>
<BugCode abbrev="DL">共有オブジェクトを意図的でなくロックすることによる潜在的デッドロック</BugCode>
</MessageCollection>
© 2015 - 2025 Weber Informatics LLC | Privacy Policy