FindBugsはJavaの学習を支援します

静的コードアナライザーは、不注意によるエラーを見つけるのに役立ちます。 しかし、はるかに興味深いのは、彼らが無意識のうちに犯した間違いを修正するのを助けることです。 言語の公式ドキュメントにすべてが書かれていても、すべてのプログラマーがこれを注意深く読んだという事実ではありません。 そしてプログラマーは理解することができます：あなたはすべての文書を読むために拷問されます。



この点で、静的アナライザーは、あなたの隣に座ってあなたがコードを書くのを見る経験豊富な友人のようなものです。 彼はあなたに「コピーしたときに間違えた」と言うだけでなく、「いいえ、あなたはそのように書くことはできません。自分でドキュメントを見てください」と言います。 そのような同志は、あなたが本当にあなたの仕事で遭遇するものだけを伝え、あなたが決して必要としないものについては黙っているので、ドキュメント自体よりも便利です。



この投稿では、FindBugs静的アナライザーの使用について学んだJavaの複雑さについて説明します。 おそらく、あなたにとって予期しないことが起こるでしょう。 すべての例は投機的ではなく、実際のコードに基づいていることが重要です。

三項演算子？：

三項演算子ほど簡単なものはないようですが、落とし穴があります。 デザインに根本的な違いはないと思った

Type var = condition ? valTrue : valFalse;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして

 Type var; if(condition) var = valTrue; else var = valFalse;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

繊細さがあることがわかりました。 三項演算子は複雑な式の一部である可能性があるため、その結果はコンパイル段階で定義された特定の型でなければなりません。 したがって、if-formの真の条件下では、コンパイラーはvalTrueを直ちにType型にキャストし、三項演算子の形式で、最初に一般的な型valTrueおよびvalFalseを導き（valFalseが評価されないという事実にもかかわらず）、次に結果を型に導きますタイプ。 プリミティブ型とその上のラッパー（整数、ダブルなど）が式に含まれる場合、強制規則は完全に自明ではありません。すべての規則はJLS 15.25で詳細に説明されています。 いくつかの例を見てみましょう。

 Number n = flag ? new Integer(1) : new Double(2.0);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フラグが設定されている場合、nで何が起こりますか？ 値が1.0のDoubleオブジェクト。 オブジェクトを作成する私たちの不器用な試みは、コンパイラにとってばかげています。 2番目と3番目の引数は異なるプリミティブ型のラッパーであるため、コンパイラはそれらを展開し、より正確な型（この場合はdouble）に導きます。 そして、割り当てのために三項演算子を実行した後、ボクシングが再び実行されます。 基本的に、コードはこれと同等です。

 Number n; if( flag ) n = Double.valueOf((double) ( new Integer(1).intValue() )); else n = Double.valueOf(new Double(2.0).doubleValue());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンパイラの観点から見ると、コードには問題がなく、問題なくコンパイルできます。 しかし、FindBugsは警告を出します。

BX_UNBOXED_AND_COERCED_FOR_TERNARY_OPERATOR：プリミティブ値はボックス化されておらず、TestTernary.mainの三項演算子に対して強制されます（文字列[]）



ラップされたプリミティブ値は、条件付き三項演算子（b？E1：e2演算子）の評価の一部として、ボックス化されずに別のプリミティブ型に変換されます。 Javaのセマンティクスでは、e1とe2がラップされた数値である場合、値はボックス化されず、共通タイプに変換/強制されます（たとえば、e1がInteger型で、e2がFloat型である場合、e1はunboxedに変換され、浮動小数点値、およびボックス化JLSセクション15.25を参照してください。

もちろん、FindBugsはInteger.valueOf（1）が新しいInteger（1）よりも効率的であると警告していますが、誰もがすでにそれを知っています。



または、次のような例：

 Integer n = flag ? 1 : null;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フラグが設定されていない場合、作成者はnにnullを入れたいと考えています。 うまくいくと思いますか？ はい しかし、複雑にしましょう：

 Integer n = flag1 ? 1 : flag2 ? 2 : null;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

大した違いはないようです。 ただし、現在、両方のフラグがクリアされている場合、この行はNullPointerExceptionをスローします。 右三項演算子のオプションはintおよびnullであるため、結果の型は整数です。 左側のオプションはintおよびIntegerであるため、Javaルールに従って、結果はintになります。 これを行うには、例外をスローするintValueを呼び出してボックス化解除を実行する必要があります。 コードはこれと同等です：

 Integer n; if( flag1 ) n = Integer.valueOf(1); else { if( flag2 ) n = Integer.valueOf(Integer.valueOf(2).intValue()); else n = Integer.valueOf(((Integer)null).intValue()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

FindBugsは、エラーを疑うのに十分な2つのメッセージを表示します。

BX_UNBOXING_IMMEDIATELY_REBOXED：ボックス化された値はボックス化解除され、すぐにTestTernary.mainで再ボックス化されます（文字列[]）

NP_NULL_ON_SOME_PATH：TestTernary.mainでのnullのnullポインター逆参照の可能性（String []）

実行された場合、null値が間接参照されることを保証するステートメントの分岐があり、コードの実行時にNullPointerExceptionが生成されます。

さて、このトピックの最後の例：

 double[] vals = new double[] {1.0, 2.0, 3.0}; double getVal(int idx) { return (idx < 0 || idx >= vals.length) ? null : vals[idx]; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

当然のことながら、このコードは機能しません。プリミティブ型を返す関数はどのようにnullを返すことができますか？ 問題なくコンパイルできるのは驚くべきことです。 さて、なぜコンパイルするのか-あなたはすでに理解しています。

日付形式

Javaで日付と時刻をフォーマットするには、DateFormatインターフェースを実装するクラスを使用することをお勧めします。 たとえば、次のようになります。

 public String getDate() { return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

多くの場合、クラスは同じ形式を再利用します。 多くの人が最適化のアイデアを思いつきます。共通のインスタンスを使用できるたびにフォーマットオブジェクトを作成するのはなぜですか？

 private static final DateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); public String getDate() { return format.format(new Date()); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それはとても美しくてクールですが、残念ながら機能しません。 より正確に機能しますが、時々壊れます。 実際、DateFormatのドキュメントには次のように書かれています ：

日付形式は同期されません。 スレッドごとに個別の形式インスタンスを作成することをお勧めします。 複数のスレッドがフォーマットに同時にアクセスする場合、外部で同期する必要があります。

SimpleDateFormatの内部実装を見れば、これは事実です。 format（）メソッドを実行する過程で、オブジェクトはクラスのフィールドに書き込みます。そのため、2つのストリームからSimpleDateFormatを同時に使用すると、ある程度の確率で誤った結果になります。 FindBugsがこれについて書いていることは次のとおりです。

STCAL_INVOKE_ON_STATIC_DATE_FORMAT_INSTANCE：TestDate.getDate（）の静的java.text.DateFormatのメソッドの呼び出し

JavaDocが述べているように、DateFormatsは本質的にマルチスレッドでの使用には安全ではありません。 検出器は、静的フィールドを介して取得されたDateFormatのインスタンスへの呼び出しを検出しました。 これは疑わしいようです。



詳細については、 Sun Bug＃6231579およびSun Bug＃6178997を参照してください 。

BigDecimalの落とし穴

BigDecimalクラスを使用すると、任意の精度の小数を格納できることを学び、doubleのコンストラクターがあることを見て、すべてが明確で、次のように実行できると判断する人もいます。

 System.out.println(new BigDecimal(1.1));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

誰も実際にこれを行うことを禁止していません。結果は予想外のように思えるかもしれません：1.100000000000000088817841970012523233890533447265625。 これは、プリミティブdoubleがIEEE754形式で格納されているために発生します。IEEE754形式では、1.1を完全に正確に表すことはできません（バイナリ表記では、無限の周期分数が取得されます）。 したがって、1.1に近い最大値がそこに格納されます。 BigDecimal（double）のコンストラクターは、逆に正確に動作します。IEEE754の指定された数値を10進数に変換するのが理想的です（最終2進小数は常に最終10進数として表現可能です）。 1.1をBigDecimalとして正確に表示する場合は、 new BigDecimal("1.1")



またはBigDecimal.valueOf(1.1)



いずれかを記述できます。 すぐに番号を出力せずに、それに対して何らかの操作を行うと、エラーの原因がわからない場合があります。 FindBugsは警告DMI_BIGDECIMAL_CONSTRUCTED_FROM_DOUBLEを発行し、同じアドバイスを提供します。



そして、もう一つあります：

 BigDecimal d1 = new BigDecimal("1.1"); BigDecimal d2 = new BigDecimal("1.10"); System.out.println(d1.equals(d2));
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、d1とd2は同じ数値ですが、equalsはfalseを返します。これは、数値の値だけでなく、現在の順序（小数点以下の桁数）も比較するためです。 これはドキュメントに書かれていますが、equalsのようなおなじみのメソッドのドキュメントを読む人はほとんどいません。 このような問題はすぐには発生しません。 残念ながら、FindBugs自体はこれについて警告していませんが、一般的な拡張機能であるfb-contribがあり 、このバグが考慮されています。

MDM_BIGDECIMAL_EQUALS



equals（）は、2つのjava.math.BigDecimal数値を比較するために呼び出されます。 2つのBigDecimalオブジェクトは、値とスケールの両方が等しい場合にのみ等しいため、2.0は2.00と等しくないため、これは通常間違いです。 BigDecimalオブジェクトの数学的等価性を比較するには、代わりにcompareTo（）を使用します。

改行とprintf

多くの場合、Cの後にJavaに切り替えたプログラマーは、 PrintStream.printf （およびPrintWriter.printfなど）を喜んで発見します。 たとえば、Cの場合と同様に、新しいことを学ぶ必要はありません。 実際には違いがあります。 そのうちの1つは改行です。



C言語では、テキストストリームとバイナリストリームに分かれています。 テキストストリームへの文字 '\ n'の出力は、システム依存のラインフィード（Windowsでは "\ r \ n"）に自動的に変換されます。 Javaにはこのような分離はありません。正しい文字シーケンスを出力ストリームに渡す必要があります。 これは、たとえばPrintStream.printlnファミリーのメソッドによって自動的に行われます。 ただし、printfを使用する場合、書式文字列に「\ n」を渡すことは「\ n」だけであり、システム依存の改行ではありません。 たとえば、次のコードを記述します。

 System.out.printf("%s\n", "str#1"); System.out.println("str#2");
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

結果をファイルにリダイレクトすると、次のように表示されます。



したがって、1つのスレッドでラインフィードの奇妙な組み合わせを取得できます。 特に主にUnixシステムで作業している場合、エラーに長時間気付かないことがあります。 printfを使用して正しい改行を挿入するために、特殊なフォーマット文字「％n」が使用されます。 FindBugsがこれについて書いていることは次のとおりです。

VA_FORMAT_STRING_USES_NEWLINE：形式文字列はTestNewline.mainで\ nではなく％nを使用する必要があります（文字列[]）



このフォーマット文字列には、改行文字（\ n）が含まれます。 フォーマット文字列では、一般的にプラットフォーム固有の行区切り文字を生成する％nを使用する方が適切です。

おそらく一部の読者にとっては、上記のすべてが長い間知られています。 しかし、使用しているプログラミング言語の新しい機能を開く、静的アナライザーからの興味深い警告があることは間違いありません。