ゆっちのＢｌｏｇ

NetBeans 6.7 M3 をインストールして使うにあたって Maven が標準装備になったので使ってみた。

使うといっても初めからあるものを動かすだけなのでコードは一行も書きません。

それでも Maven をネット上の情報を斜め読みしたくらいの知識しかない私はみごとにつぼにはまりました（＾＾；

新規プロジェクトで [ Maven ] → [ Maven プロジェクト ] を選択します。

初めてなので Maven クイックスタート原型(1.0) を選択しました。

面倒なのでデフォルトのまま [ 完了 ]

うっ！　Maven インストールしてないよ（＾＾；

このまま [ 了解 ] ボタンを押してもいいみたいだけど・・・

やっぱインストールしよっ！

Maven をインストール完了

パスが通っているか確認OK！

オプション設定をします。

これで Maven がインストールされてないって怒られないし余計な気遣いをさせることもなくなるはず。

で、先ほどの新規プロジェクトを同様に作ったら BUILD SUCCESSFUL と 表示された（＾＾）

ファイル構成は Maven そのものになってます。

プロジェクトツリーは解りやすいようにシンプルになってますね。

ソースコードはそれぞれこのようになってます。

失敗しないテストが素敵だったりしますね。

それではプロジェクトを実行してみます。

ガ━━(=￣□￣=)━━ン!!

やっぱりつぼにはまった！

何でだろうと思いプロジェクトのプロパティを調べると

コンパイルカテゴリの設定で [ テストの実行のみ ] がデフォルトで設定されてました。

これを [ アプリケーションとテスト両方の実行 ] に変更します。

おお！　動いた！！

初めての Maven ちょっと躓いたけど無事にビルド、実行できました。

以上、Maven の凄いテクノロジーを一切使わない初体験でした。

凄いテクノロジーとはプロジェクトで使用するライブラリなどをネットワーク越しに自動ダウンロードしたり、依存関係を自動解決してくれたりですよね。

また、推移的依存関係も自動解決してくれるし、スコープによって細かな依存関係を設定できたりするようです。

まだまだ凄いところはあるようですが Maven 触りだしたばかりの私には良く解りません。

いつの間にか日本語に訳されていたチュートリアル NetBeans IDE での Junit テストの記述　を この前ビルドした NetBeans6.7 で試してみました。

JUnit4 だけですけど。。

とりあえず綺麗に動きました。

以前、「へびのぬけがら」のTakakura-san が日本語を正確に判定できてないとレポートされていましたので試してみました。

まず、失敗はちゃんと判定されてるようです。

判定はあってるけど差異がはっきりしてませんね。

TestResults ウィンドウと併用すればわかるけど・・・ これってバグなのかなぁ？それとも仕様？

次にテストが成功するようにコードを修正

そして、ドキドキしながら　Run Again をポチッと押します。

テストは成功！

 

NetBeans 6.5 と比べると華やかになってます。

これでテスト成功、失敗の時に音が鳴ると楽しいかなと思ったりします。

JDK7 のリリース予定が発表されました。

NetBeans 7 と同時リリースだそうです。

これにより Java の EoD が飛躍的に向上するそうです。

注目のクロージャはジェームス・ゴスリン氏が強くプッシュしていたが JDK7 には間に合わないそうだ。

遅れた理由はクロージャが利用するコードがキモいとの意見が大半をしめ、改善策を模索中だそうだ。

確かに　=>　とか　==>  は無いだろうと思う。

しかし、キモいのを我慢してでも新しい物には興味があるのが本音だろう。

そこで NetBeans 7 にクロージャのライブラリが先行投資され利用可能となる。（＾＾）

あまり評判が良くなかった NIO は NIO2 となり非常に便利な機能を備えて JDK7 に搭載されます。

すでに JDK7 の最新ビルド build52 に統合されてます。

Garbage-First GC は絶対にメモリーリークを許さない凶悪なガーベッジコレクタです。

Sun 社長兼 CEO のジョナサン・ジョアルツ氏はポニーテールを揺らしながら JDK7 & NetBeans 7 を Windows 7 上で動かせばフィーバーだと一部の日本人にしか解らないコメントをした。

Effective Java の「廃れたオブジェクトの参照を取り除く」と言う項目を実際に確認してみます。

この記事を読むまではこういったことが起こっているとは知りませんでした。

Javadoc ではこうなってるのでてっきり綺麗さっぱりな状態になってるとかってに思ってました。（＾＾；

また、ネット上にある Stack 関係の記事でもほとんどこの廃れたオブジェクト参照を取り除くことはしてないですね。

では、廃れたオブジェクト参照が残るコードを

上記のコードは Effective Java  に載っていたものを元にほんの少しだけ変更をくわえてあります。

確認のため NetBeans 6.7M2 を使ってみます。

elements の値を確認するために新規ウォッチポイントを設定します。

elements を右クリックして新規ウォッチポイントを・・　あれれ？　新規観察に変わってますね（＾＾；

新規観察ウィンドウが出ますのでウォッチ表現を設定して [ 了解 ] ボタンを押します。

次にブレークポイントを設定します。

ここでは pop() メソッドで 戻り値の result に elements [--saize] から値を渡し、その後 elements [size] オブジェクトは削除されると期待してました。

つまり、ブレークポイントでプログラムが止まった時の elements [size] の値は null だろうと・・・

では、確認のためにプロジェクトをデバッグしてみます。

あらら・・・　elements [2] の値が残ってます。

続行します。

出力ウィンドウにはちゃんと　羊が　２匹と表示されてます。

この時点では elements [2],elements [1] は null になっていてほしい・・・

続行させます。

出力ウィンドウには期待通りの結果が出てます。

続行させます。

とうとう　elements [] は削除されることはありまでんでした。

このようにもう使われることのないオブジェクト参照のことを廃れたオブジェクト参照というようです。

Java 言語の利点の一つであるガーベッジコレクタで回収されることもありません。

もったいない！（by 矢沢永吉

この問題を解決するために pop() メソッドに

35 行目のコードを追加し elements [] に null を設定します。

 

デバッグを実行します。

今度はちゃんと elements [2] が null に変わってます。

続行します。

出力は前回と同様に期待通りの動作のままです。

続行します。

続行します。

これで期待通りの動きとなりました。

Javadoc のオブジェクトを削除という意味は何なのだろうか？

とりあえず確認完了です。（＾＾）

下記 Java プログラムの実行結果は？

package inctest;

/**
*
* @author Yucchi
*/
public class Main {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        // TODO code application logic here
        int i , j;
        i = 1;
        j = 1;
        System.out.println(“++i * 2 = ” + ++i * 2);
        System.out.println(“j++ * 2 = ” + j++ * 2);
    }

}

これはプリインクリメントとポストインクリメントの違いを理解してないと間違います。

なんで今さらこんなことを？

NetBeans 7.0 開発版で出力ウィンドウのフォントサイズが変更できる機能を確認したかっただけです。（＾＾；

Windows だと出力ウィンドウのフォントサイズが小さくて悲しかったけど NetBeans 7.0 では遂に普通の大きさから異常な大きさまで変化させることが可能となる。

int 型は 4 バイトなので 32 ビットですよね。

従って 2 の 32 乗通りの表現が可能。

そのうち符号に 1 ビット。

マイナス 2 の 31 乗から、プラス　2 の 31 乗から 1 を引いた範囲まで。

何故、正の範囲がマイナスの絶対値じゃないのか疑問に思ったが純粋無垢な私は素直にそういうものなんだと今まで思っていた。

ひょんなことからこの謎が解けた。

だからどうってことはないけど一応・・・覚え書きということで（＾＾；

Java の int 型の正の整数は 0 から始まるからだそうです。

int 型に限らず正負を扱う型はそうなるんでしょうね。

これってプログラマーの常識なんでしょうけど肉体労働者の私にとってはショックでした。

数学的に 0 は正でも負でもない特殊な存在だからです。

本当に今さら忘れていた疑問が解けて少しうれしい自分が可愛いと思う今日この頃です。（爆

今さらですけど JDK1.5 から採用された Autoboxing / Auto-Unboxing って便利ですよね。

しかし Effective Java 第２版を読みかけて、この便利な機能のおかげで知らないうちにとんでもないミスを犯す可能性があることを知りました。

本に載っていたコードはたった一文字、小文字であるべき所を大文字で記述してしまったため恐ろしく遅いプログラムとなってしまうということです。

私のような未熟者がやりそうなことです。

以下に Effective Java に載っていたサンプルプログラムを元に少し変更したコードを載せます。

package dotubo;

public class Main {

    public static void main(String[] args) {      
        System.out.println(“テスト開始\n”);
        Main m = new Main();
        m.slow();
        m.fast();
    }

    private void slow(){
        Long sum = 0L;
        for(long i = 0; i < Integer.MAX_VALUE; i++){
            sum += i;
        }
        System.out.println(“slow : ” + sum);

    }

    private void fast(){
        long sum = 0L;
        for(long i = 0; i < Integer.MAX_VALUE; i++){
            sum += i;
        }
        System.out.println(“fast : ” + sum);
    }

}

これはコンパイルも実行もできます。

ただし、slow() メソッドと fast() メソッドの処理時間が比べものにならないくらい違います。

slow() メソッドと fast() メソッドは見てのとおり微妙に一文字だけ肝心な所が違いますね。

たった一文字の間違いのために意図しない Autoboxing が働いて不必要な Long インスタンスを作ってしまいます。

NetBeans のプロファイラでこのプログラムのパフォーマンスを確認してみました。

間違っている slow() メソッドは 30224ms かかっているのに対して正しい fast() メソッドは 5561ms しかかかってません。

この違いはもの凄く大きい！です。

便利なものは正しく使わないとどつぼにはまるということですね。（＾－＾；

NetBeans の UML ツールを適当にいじってます。

昨日の Factory Method パターンを試したものに BD クラスと BD_Factory クラスを追加してみます。

今回は自分でクラス図に要素を追加し、BD クラスと BD_Factory クラスの関連も描画したいと思います。

クラス図に BD クラスを追加してみます。

パレットの[ 基本 ] よりクラスを選んでクラス図に追加します。

追加された要素にクラス名を記入します。

名前のところをダブルクリックして編集可能にし入力します。

BD とクラス名の入力が完了すると操作に自動で public コンストラクタが追加されます。

次に DISC インターフェイスを実装します。

BD 要素を選択し、ポップアップされるアイコンの集まりの中から実装アイコンを選択し DISC インターフェイスまでドラッグします。

無事に DISC インターフェイスの実装が完了すると

DISC から再定義された操作
public String play()

という操作が自動で BD 要素に追加されます。

BD_Factory クラス要素も同様にクラス図に追加します。

BD_Factory クラスは DISK_Factory クラスのサブクラスになります。

今度は BD_Factory 要素を選択し、汎化アイコンを選択、そして DISC_Factory 要素までドラッグします。

汎化操作が完了すると

[ 再定義するメソッドを選択 ] ウィンドウが表示されます。

今回は抽象メソッドだけ実装します。

これまでの操作で下図のようにクラス図が作成されました。

それではクラス図より Java コードを生成してみましょう。

BD クラスと BD_Factory クラスの要素二つを選択し、右クリックします。

ポップアップメニューより [ コードを生成... ] をクリックします。

[ コードを生成 ] ウィンドウが表示されますので確認して [ 了解 ] ボタンを押します。

新たに BD クラスと BD_Factory クラスの Java ファイルが自動生成されました。

BD クラスのコードを下記のように編集します。

BD_Factory クラスも編集します。

最後に起動クラスの Main も。

これで新たにファクトリが追加されました。

ちゃんと動くか確かめてみます。

それではプログラムを実行してみましょう。

ちゃんんと動きましたね。（＾＾）

クラス図を確認すると BD_Factory 要素から BD要素への依存関係が描画されてませんね。

リバースエンジニアリングを適用しても自動で描画されなかったので手動で描画してみます。

BD_Factory 要素から依存アイコンを選択します。

BD要素へドラッグします。

点線矢印を選択し、右クリックでポップアップメニューより [ プロパティー ] をクリックします。

[ Dependency - プロパティー ] ウィンドウが表示されます。

[ ステレオタイプ ] の右端の [ ... ] ボタンを押します。

編集画面が出ますので [ 名前 ] を creates として [ 了解 ] ボタンを押します。

これで BD クラス要素と BD_Factory クラスの依存関係も描画されました。

やっぱり便利ですね（＾＾）

UML を覚えて他の機能も試したくなります。

でも、時間が足りないですorz

ゆっくり遊びながらマイペースでいきますか。。。

 

注意　：　昨日と今日取り上げた NetBeans の UML に関する記事は私が直感的に「このように操作するんだろうなぁ」と勝手にやったことです。

間違いや、もっと簡単な操作方法があるかもしれませんのであしからず・・・

NetBeans の UML クラス図作成に「デザインパターンを適用」ってのがあります。

ちょっと面白そうなので試してみました。

シンプルな Factory Method パターンで試してみます。

Java プロジェクトを新規に作成します。

次に UML プロジェクトを作ります。

[ カテゴリ ] から UML を選択し、[ プロジェクト ] には Java プラットフォームモデルを選びます。

適当に設定します。

 

[ 図を新規作成 ] でクラス図を選択します。

今回はデザインパターンを使用するので図名はこのままで

[ モデル ] を右クリックし [ デザインパターンを適用 ] をクリックします。

デザインパターン適用ウィザードにそって必要事項を入力していきます。

GoF Design Patterns の Factory Method パターンを選びました。

要素を次のように設定しました。

ここで解るように平凡な Factory Method パターンが作られることが想像できます。

ここで [ クラス図の作成 ] チェックボックスにチェックをいれます。

デザインパターンを適用するクラス図の名前を入力します。

確認して [ 完了 ] ボタンを押します。

以上の操作で Factory Method パターンのテンプレートが作成されます。

では、interface の操作を作成します。

DISC 要素を選択し、右クリックで [ 操作を作成 ] をクリックします。

下図のように編集可能となります。

選択されている編集項目は太字で表示されます。

下図はメソッドの名前が編集可能となってます。

名前を play としました。

同様に型を編集します。

操作の編集が終われば下図のようになります。

CD 要素に[ DISC から再定義された操作 ] が自動作成されました。

それでは 作成したクラス図から Java コードを自動生成させましょう。

UML プロジェクトを右クリックして [ コードを生成... ] をクリックします。

[ コードを生成 ] ウィンドウが表示されますので [ ターゲットプロジェクト ] に最初に作った Java プロジェクトを指定します。

あとは必要に応じて入力します。

[ 了解 ] ボタンを押すと Java ファイルが自動生成されます。

自動生成された Java ファイルは以下のものです。

Main クラスのファイルは最初の Java プロジェクトで作られたものです。

それでは CD クラスのコードを下記のように編集します。

次に CD_Factory クラスも。

最後に起動クラスの Main クラスを。

これでシンプルな factory Method パターンができあがりました。

それでは実行してみましょう。

ちゃんと動きましたね（＾＾）

クラス図のレイアウトを自動レイアウトさせてみます。

[ 階層型レイアウト ] アイコンをクリックします。

レイアウトの警告がでます。

問題なければ [ はい ] ボタンを押します。

自動レイアウトされました。

うーん、、、ちょっと微妙かも（＾＾；

 

私は素人なので遊びで使ってるぶんには面白い道具の一つなのは間違いないです！

Java のようなオブジェクト指向プログラミング言語と UML は相性がいいようですね。

UML を良く知らない私でもクラス図があるとプログラムがどういう作りか解りやすいと思う。

今回はクラス図から Java コードを作ったが、NetBeans のＵＭＬ ツールは Java コードからクラス図の作成も可能なんですよね（＾＾）

本当に面白い便利なツールです！

でも、ちょっと気になるのは、同じプロジェクトを OpenSolaris 上の NetBeans でつくったら CD_Factory から CD の <<Creates>> の表記がでなかった。

なんでだろう？　まぁ、いいか（＾＾；

面白いので UML の知識が増えたらまたいじってみよう（＾＾）

NetBeans UML プラグインを日本語化しようと 日本語化 zip ファイルをダウンロードし、展開しようとしてつまづいた。

昨日の出来事です。

今日は仕事が早く終わったので試しに jar コマンドで解凍してみました。

なんと！　解凍できました（＾＾）

Windows Vista 付属の zip 解凍ツールって・・・　作りがあまいのかなぁ・・・

なにはともあれ、無事に日本語化できました（＾＾）

感謝！感激です！

以前、UML を試した時のと比べると日本語にちゃんとなってますね。

NetBeans の UML

ただ、[ モデルレポートを生成 ] だけはいただけませんね。

「すべての囲んでいる図」　って（＾＾；

英語版ではこうなってます。

私は英語が解らないのでどう訳せばいいのか見当もつきません。

日本語化 zip ファイルの提供ありがとうございました。

英語が解らない私には大変ありがたいプレゼントとなりました。（＾＾）