警告とヒント
さて。Eclipseでいうところのコンパイラが出すエラー/警告に関するところはNetBeansでは「ヒント」というのは昨日の日記でまとめた通りですが、今日は実際にそれぞれ設定できる内容を比較してみたいと思います。
まずは、Eclipseのエラー/警告からです。そもそもの大前提として、Eclipseの場合はチェック項目に対し、違反している場合にそれを無視するか警告するかエラーにするかを設定できます。で、実際に設定できる内容は以下の通りです。
- コード・スタイル
- 潜在的なプログラミングの問題
- 名前のシャドーイングおよび競合
- フィールド宣言が他のフィールドまたは変数を隠蔽
- ローカル変数宣言が他のフィールドまたは変数を隠蔽
- コンストラクターまたはsetterメソッド・パラメータを含む
- 型パラメータが別の型を隠蔽
- メソッドがパッケージ可視メソッドを非オーバーライド
- インターフェース・メソッドがprotectedの'Object'メソッドと競合
- 使用すべきでは無い制限されたAPI
- 不要なコード
- ローカル変数が読み取られない
- パラメータが読み取られない
- オーバーライドしたメソッドの実装を無視
- @paramタグのパラメータ記述を無視
- 未使用のインポート
- 未使用のローカルまたはprivateメンバー
- 冗長なnull検査
- 不要なelseステートメント
- 不要なキャストまたはinstanceof操作
- 不要な例外スロー宣言
- オーバーライドしたメソッドの実装を無視
- @throwsまたは@exceptionタグの例外ドキュメントを無視
- ExceptionおよびThrowableを無視
- 未使用のbreakまたはcontinueラベル
- 冗長なスーパー・インターフェース
- 総称型
- 未検査の総称型操作
- raw型の使用
- finalな型で制約された総称型パラメータ
- 注釈
日本語の文章で書かれてもいまいち意味が分かりづらいものもありますが、まぁそれはさておき、一方のNetBeansのヒントの方も、基本的にはチェック項目に対し、違反している場合にそれを無視するか警告するかエラーにするかを設定できます。警告には、単なる「警告」と「現在の行の警告」の二種類があるようですが、いまいち意味が分かりません。で、実際に設定できる内容は以下の通りです。
- インポート
- 未使用のインポート
- 禁止パッケージからのインポート
- 同じパッケージからのインポート
- スターインポート
- java.langパッケージからのインポート
- Javadoc
- Javacの標準的な警告
- オーバーライド
- 不要なキャスト
- 直列化
- フォールスルー
- 未検査
- ゼロで除算
- ifのあとの文が空
- finally
- 非推奨
- エラー修正
- 局所変数を作成
- tryとcatchで囲む
- API
- NetBeans開発
- 取り消し可能なタスクに対し、cancel()が空
- instanceOf演算子の使い方が不正
- JDK1.5以降
- @Override注釈を追加
- スーパーインターフェースとして注釈を使用しない
- 空の文
- forの後の文が空
- whileの後の文が空
- if/elseの後の文が空
- 空の文
- doの後の文が空
- 一般
- 足りないhashCodeまたはequalsを生成
- == または != を使用して文字列を比較
- 二重検査されたロック
- 自信に割り当て
- 参照から静的フィールドにアクセス
- フィールドが別のフィールドを隠蔽
- 新しい変数に戻り値を割り当て
- 間違ったパッケージ
- 局所変数がフィールドを隠蔽
- 中括弧
- If-Else文には中括弧が必要
- Do-While文には中括弧が必要
- Whileループには中括弧が必要
- Forループには中括弧が必要
どれがどれに対応するのか微妙に分かりづらいのでなんとも言えませんが、とりあえずぱっと見で目につくのは、「総称型(ジェネリックス)」「注釈(アノテーション)」「ボクシング・アンボクシング」等の、Java5からの機能に関する設定項目はかなりEclipseの方が多そうに見えます。その他は・・・うーん・・・単体で見れば微妙にEclipseの方が充実していそうな気がしないでもありませんが、checkstyleやfindbugsと組み合わせれば補えそうなので、特にNetBeansでも不自由しなさそうな気もします。
それにしても、世間一般的には「新機能への対応はNetBeansの方が早い」ようなことが言われているような気がするのですが、ことJava5周りに関しては微妙に対応が鈍い(ジェネリックス周りのコード補完が効くようになったのも最近だったような)気がするのは何故でしょう。
というか、その辺は微妙に従来NetBeansがEclipseに比べて弱いと言われてきたコーディングアシスト機能的なところなので、仕方ないと言えば仕方ないか
・・・
いやいや、仕方なくは無いか
フォーマッタとかテンプレートとかも比較してみたかったのですが、疲れてきたのでまた次回以降にします。
EclipseでやっていたことをNetBeansでやるにはその2
そんな訳で、昨日の続きです。
どうでもいいですけど、このためにGanymedeをダウンロードしてPleiadesで日本語化してみました。3.3のときからそうでしたけど、うちの4年くらい前のPowerBook G4でPleiadesを使うともっすごい遅いです。
それはさておき。
| やりたいこと | Eclipseでやるには | NetBeansでやるには |
| コードテンプレート | メニューバーからEclipse→Preferencesで設定画面を開き*1、Java→コード・スタイル→コード・テンプレートで設定 | メニューバーからツール→テンプレートで設定可能だけど、Eclipseみたいにメソッドやらコメントやらをこと細かく設定するのはムリポかも |
| ソースのフォーマット | 上記と同様に設定画面を開き、Java→コード・スタイル→フォーマッターで設定、メニューバー→ソース→フォーマット(Ctrl＋Shif＋F*2 )で実行 | メニューバーからNetBeans→環境設定*3でオプション設定画面を開き、Javaコード→整形で設定。ただし、1行の文字数等の一部の設定はオプション設定画面のエディタ→インデント設定で設定。ソース→整形でフォーマット実行 |
| コンパイラの準拠レベル(バイナリ、ソース) | 上記と同様に設定画面を開き、Java→コンパイラで全体設定可能。メニューバーからプロジェクト→プロパティ→コンパイラで、プロジェクト固有の設定可能 | プロジェクトを右クリックしてコンテキストメニューを表示し、プロパティ→ソースでプロジェクト固有の設定は可能。でも、Eclipseみたいにソースは1.4互換、バイナリは5.0互換とかは無理っぽい |
| JavaDocに関する設定 | 上記と同様に設定画面を開き、Java→コンパイラ→JavaDocで全体設定可能。メニューバーからプロジェクト→プロパティ→コンパイラ→JavaDocで、プロジェクト固有の設定可能 | 一応、オプション設定画面のJavaコード→ヒントにいくつか設定項目があるけど、「publicスコープ以上はJavaDoc必須」とかそういう設定は無さそう？ |
| 警告・エラーに関する設定 | 上記と同様に設定画面を開き、Java→コンパイラ→エラー/警告で全体設定可能。メニューバーからプロジェクト→プロパティ→コンパイラ→エラー/警告で、プロジェクト固有の設定可能 | 上述の、オプション設定画面のJavaコード→ヒントで設定可能。ただし、Eclipseみたいに各プロジェクトごとに固有の設定はムリぽ？ |
やっぱり、こういった細かいアシスト機能はこうやってちょっと並べてみただけでもムンムンとEclipseの方が気が利いてそうな気配が。まぁ、足りない部分はcheckstyleとfindbugsでなんとか補えそうな気はしますが。
次回はもう少し掘り下げて、実際にEclipseの警告/エラー機能とNetBeansのヒント機能で実際に設定できる項目とか、EclipseのフォーマッタとNetBeansの整形で実際に設定できる項目とかを比較してみたいと思います。
EclipseでやっていたことをNetBeansでやるには
だいぶ前の
↑
この日の日記で「まとめ表を作ってみよう」なんて言って放置していましたが、ようやく思い至ったのでぱっと思いついた分をまとめてみようと思います。
| プラグイン名 | 対応するNetBeansの機能・プラグイン |
| WTP | NetBeansではWeb開発機能はデフォルトバンドル。デフォルトはGlassfishだがTomcat6も問題なく使える |
| 言語パック | NetBeansはEclipseと違って基本日本語版も英語版からそんなに間隔あけずにリリースされている模様*1 |
| checkstyle | プラグインとしてCheckstyle Beans、SQEと二種類あるが、Checkstyle Beans + antが現状は良さげ |
| findbugs | プラグインとして一応SQEがあるけど、現状はantが良さげ |
| Subversive | Subversion用プラグインはNetBeans6.0からデフォルトバンドル |
| プロパティエディタ | 基本、NetBeansはデフォルトでnative2ascii要らずでプロパティファイルを編集できる・・・ような、気がするのですが情報求む |
| djUnit | Virtual Mock部分はjMockitで、カバレッジ部分はCobertura+ant or mavenで |
- 個人的にはあまり使ってなかったけどなんとなく押さえておきたいプラグイン
| 機能 | Eclipseのプラグイン | NetBeansのプラグイン |
| BTSとの連携、タスク管理 | Mylyn | 該当無し？ |
| プロファイラ | TPTPとか？ | 何やらデフォルトでついてはいる模様 |
| メトリクス | Eclipse Metrics Pluginとか？ | これもSQEに何やらついてはいる模様ですが・・・ |
- Eclipseで常日頃よく行っていた操作
| やりたいこと | Eclipseでの操作 | NetBeansでの操作 |
| 設定のインポート/エクスポート | ファイルメニュー等々から実行可能 | 無さげ？ |
| maven2プロジェクトの作成 | mvnコマンドで作成してファイルメニューからインポート | maven2プラグインを利用してIDE上で作成 |
| maven2関連のコマンドの実行 | antを通してmvnコマンドを実行 | 基本はmaven2プラグインで実行/mavenのant:antプラグインでbuild.xmlを生成してant経由でコマンドを実行する局面もありそう |
| シリアルバージョンUIDの生成 | デフォルトでIDE上から生成可能 | プラグインをインストールすればIDE上で生成可能 |
| 型を開く | Ctrl+Shift+T | Ctrl+O |
| 階層で型を開く | Ctrl+Shift+H | ALT + Shift + F12 |
| リソースを開く | Ctrl+Shift+R | SHIFT + ALT + O |
| クイック型階層 | Ctrl+T | 無いかも？ |
以下も一気にまとめようと思ったのですが、なんとなく疲れたので明日にしようと思います。
- コーディングアシスト機能
- その他
地味に、設定のインポート/エクスポートが無さそうなのは大規模ではちょいとめんどくさそうなのですが、私が見落としているだけでしょうか。
*1: 余談ですが、結局Eclipse3.3の言語パックが出なかったのにはがっかりです。
今改めて考えてみるSpringとStrutsを連携させる方法
既に書籍とかJSUGのメーリングリストとかブログ各所とかいろんな所で書かれているのであえてここで殊更に詳しくは書きませんが、大別してSpringとStrutsを連携させるには以下の三つの方法があると思います。
- ActionSupport系の機能を使う
- DelegatingActionProxy系の機能を使う
- DelegatingRequestProcessor系の機能を使う
1.の手法では、Springが提供するActionSupport系のクラスを継承してStrutsのActionを作成します。DispatchActionSupportとかMappingDispatchActionSupportとか、Strutsの各種Actionに対応する形でいくつかのActionSupportがあります。お手軽で、Actionの設定はstruts-config内で完結するので、3つの手法のうちで設定量が一番少なくてすむ反面、三つの手法のうち唯一、依存するクラス(サービス等)を注入されるのでは無く、依存するクラスを自ら取りに行くところが、やや微妙です。即ち、ありていに言えば、三つの手法で唯一
実はDIパターンになっていない
ところがミソです。Actionの管理がstruts-config内で完結している(SpringのBean定義ファイル上で管理されていない)ので、当然SpringのAOP対象外であるところも見逃せない微妙なところです。
2.の手法では、各機能ごとに実装者が作成する真の(?)ActionはSpringのBean定義ファイル上に定義し、struts-config上にはSpringが提供するDelegatingActionProxyを定義します。即ち、HTTPリクエストは一旦DelegatingActionProxyで受けて、その後DelegatingActionProxyからSpring管理の真のActionに処理が委譲される感じです。
設定イメージはこんな感じです。
<action path="/sample" type="org.springframework.web.struts.DelegatingActionProxy" name="sampleForm">
<forward name="success" path="sample.jsp" />
(略)
</action> (struts-config)
<bean name="/sample" class="jp.co.(略).web.action.SampleAction">
<property name="sampleService" ref="sampleService" />
(略)
</bean> (Bean定義ファイル)
1.の手法と違い、真のAction(例中のSampleAction)自体は「DIパターン」になっていて、ActionもSpring管理なのでAOPを適用できたり、Bean定義ファイルのいろんな設定機能(プロパティのインジェクションとか定数のインジェクションとか)を使えたり、色々機能豊富な反面、1つのActionにつき二個も設定があるのは結構面倒です。
3.の手法では、真のActionをSpring上で管理するところは2.と同じですが、struts-config上にはActionを用意せずに、RequestProcessorから直接Spring上のActionを呼び出すところが2.と違います。
ただし
struts-configに
<action path="/sample" name="sampleForm">
<forward name="success" path="sample.jsp" />
(略)
</action> (struts-config)
<bean name="/sample" class="jp.co.(略).web.action.SampleAction">
<property name="sampleService" ref="sampleService" />
(略)
</bean> (Bean定義ファイル)
Spring2.0からは、似たようなRequestProcessor系のStruts-Spring連携機能としてAutowiringRequestProcessorが追加されたようですが、ComposableRequestProcessorの機能がつかえないのは相変わらずのようです。
Spring2.5で新しく何か追加されていないかとそれらしきクラスを探してみたのですが、私のみたところ、それらしきクラスはどうも無いようです。
即ち
結論から言うと、三つの手法はそれぞれ三者三様であり、それぞれいいところも悪いところもあって、どれが一番良いと言えないというか、好みの問題的な違いと言うか、まとめると多分こんな感じです。
| 手法 | メリット | デメリット |
| 1 | 割とお手軽。設定量が少ない。 | 厳密に言うとDIではない。AOPとかも使えず、Springの機能は一番活かしづらい。 |
| 2 | 1.と違ってAOP等のSpringの機能も活かせ、3と違ってStruts1.3の機能も使える | 設定量は一番多い。 |
| 3 | 1.と違ってAOP等のSpringの機能も活かせ、2よりも若干設定量は少ない。 | Struts1.3の機能は使えない。 |
で
とても長い前フリでしたが、ようするに、私はこういう手法が欲しいと思う訳です。
- 設定量は手法1と同程度
- ActionはSpringのBean定義の管理下に置き、AOP等のSpring的な機能を活用できる
- Struts1.3の機能であるComposableRequestProcessorを活用できる
上記のうち2番目と3番目は、実のところ、Strutsの「org.apache.struts.chain.commands.servlet.CreateAction」を継承して、「DelegatingRequestProcessor」や「AutowiringRequestProcessor」と同様のAction生成ロジックを行うようにgetAction()メソッドをオーバーライドすれば、とりあえず手法3と同様の記述量で、かつStruts1.3の機能を利用できるようにはなります。
問題は、
- 設定量は手法1と同程度
これです。これを解決する手法は・・・
そう
アノテーション
です。正直なところ、私はSpringのアノテーションインジェクションについては若干懐疑的でした。設定が楽になるのはいいのですが、Spring管理下のサービスは、Spring自身にすら依存していないところが一つの謳い文句であったような気がしていたからです。ビジネスロジックにSpringが提供するアノテーションを付加して、XMLの記述が要らなくなる代わりに、ビジネスロジックがSpringに依存するようになってしまうのは正直どうかと思っていた訳です。
しかし
これがActionならば話は別です。Actionは当然ながら元々Strutsに依存しています。それが今更Springへの依存が増えたからといってどうだというのでしょう。というか、手法1でもそもそもActionがSpringに依存しているので、ビジネスロジックがSpringに依存してしまうことに比べれば、ActionがSpringに依存してしまうようになるのはたいした問題では無いというか場合によっては今まで通りです。
そんな訳で
私は第四の手法として、以下のようにStrutsとSpringを連携させるのがよいのではないだろうかという結論に達しました。
- StrutsとSpringの連携は、「org.apache.struts.chain.commands.servlet.CreateAction」を継承してAction Commandを自作して行う。
- Actionの生成ロジックは、「AutowiringRequestProcessor」と同じものが良さそうかな。
- ActionのStruts的な設定はstruts-config上で行い、ActionのSpring的な設定はアノテーションで行う。
- イメージ的にはこんな感じ。
package xxxx;
import javax.annotation.Resource;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
import org.springframework.stereotype.Controller;
@Controller(value = "sampleAction")
public class SampleAction extends Action {
private SampleService sampleService = null;
@Resource(name = "sampleService")
public void setSampleService(SampleService sampleService) {
this.sampleService = sampleService;
}
(略)
}
-
- 「value = "sampleAction"」はSampleAction自体のBean IDの定義であり、「name = "sampleService"」は注入するサービスのBean IDっぽい。
今までiBATISのことを誤解していました
結局Mercurial問題は解決しないもののOSを入れ替えてしまったので色々と環境の復元に追われている私がきましたよ。
JTerminalを入れなおしたり、finkを入れ直したり、Subversionを入れ直したり、NetBeansを設定しなおしたり、色々大変です。
全然関係無いですけど、10.4までは、起動中のアプリケーションはDoc内でなんか矢印がついていたような記憶があったのですが、10.5になってから印が消えたなーと思ったら、起動中のアプリケーションには矢印じゃなく青い光みたいのが陰っぽい感じでつくようになったんすね。ちょっぴりかっこいい。
それはさておき。
私は今までiBATISのことを誤解していました。それは、
↑
この日の日記に書いているのですが、
- resultMapの記述が面倒くさい。
と、思っていた訳です。
が
http://ibatis.apache.org/javadownloads.cgi
↑
ここのサイトの「Documentation」の「Japanese」のところを読んでみるに、
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE sqlMap
PUBLIC "-//ibatis.apache.org//DTD SQL Map 2.0//EN"
"http://ibatis.apache.org/dtd/sql-map-2.dtd">
<sqlMap namespace="Person">
<select id="getPerson" resultClass="examples.domain.Person">
SELECT
PER_ID as id,
PER_FIRST_NAME as firstName,
PER_LAST_NAME as lastName,
PER_BIRTH_DATE as birthDate,
PER_WEIGHT_KG as weightInKilograms,
PER_HEIGHT_M as heightInMeters
FROM
PERSON
WHERE
PER_ID = #value#
</select>
</sqlMap> 「上記の実例は、SQL Mapの最もシンプルな形を示しています。ResultSetのカラムとJavaBeansのプロパティ(もしくは、Mapキーなど)で名称が一致しているものを自動的にマップするSQL Mapsの機能を使っています。」
(;￣Д￣)
そんな機能があったのか・・・
↑
このJavaDocからリンクはってある、
↑
ここの解説からは、そんなことは読み取れなかったのだが・・・
ということはですね。
これくらい一々定義しなくても、
SELECT USER_ID as userId (略)
と、SQLを書けば、自動的にマッピングしてくれるという訳ですね！？
むむむ。
これに関しても、Springと組み合わせれば、
- SqlMapClientFactoryBeanを継承する
- ApplicationContextAwareをimplementsする
- afterPropertiesSet()をオーバーライドする
- ApplicationContext#getBeanNamesForType()を実行し、SqlMapClientDaoSupportを継承しているクラスのBean-IDを取得する。
- 取得したBean-IDを元にApplicationContext#getBean()を実行してインスタンスを取得する。
- 取得したインスタンスのクラス名を取得する。
- commons betwixtとPipedOutputStreamを利用し、PipedInputStreamに直接sqlMapConfigの内容を書き込む。
- PipedInputStreamを元にInputStreamResourceを生成する。
- 生成したInputStreamResourceを、SqlMapClientFactoryBeanのconfigLocationに設定する。
なんていうSqlMapClientFactoryBeanのサブクラスを作れば、物理的にsqlMapConfig.xmlを用意しなくても、アプリケーション起動時に動的にsqlMapConfig.xmlを生成できてメンテナンスが楽かも。
むむむ。
なんだか、急にSpring＋iBATISで全然鉄板のような気がしてきました。
LeopardのNetBeansでMercurial
さて。MacのNetBeansでMercurialに挫折して久しい訳ですが、なんとなく
Mac 10.4だからだめだったのかも？
と、根拠もなく思い始めました。まぁ、期待する訳でもなかったのですが、10.5にあげるいい機会かなーとも思ったので、さっそくMac 10.5とバックアップ用の外付けハードディスクを買いにいった訳です。
で
特に期待していた訳でもなかったのですが、ひょっとしたら同じことで悩んでいる人もいるのかも？と思い、「Mac 10.4 Mercurial NetBeans」でぐぐってみました。
ぐぐって1番目および2番目に私のブログが出てくるあたり、なんだか非常にマイナーなことをしている気分になってきてさらに期待薄だった訳ですが、3番目にNetBeans6.1のリリースノートが出てきたので何の気なしに眺めていました。
ら
現在、Mercurial 1.0 は、Mac 10.4 では使用できません。
と、思いっきり書いてあるじゃないですか・・・
そうですか、使えなかったんですね。
逆に言えば、Mac 10.5では使えるんですね？
そんなこんなで、wktkしながらMac10.5をインストールして、いの一番にNetBeansとMercurialをダウンロードしてインストールしてみました。
・・・
10.4のときと全く同じ動作じゃないですか・・・
やっぱり、ローカルリポジトリへのコミットの段階で既にうまくいきません。そして、相変わらずコマンドラインから
hg commit -m "commit test"
とか実行するとうまくいきます。どうやら、別段10.4が悪かった訳ではないみたいです。
振り出しに戻ってしまいました。
相変わらずMercurialはお手上げです。
NetBeansでFindBugs
先日、nbcheckstyleに代わるcheckstyle beansがあることを発見したので、実はFindBugsにもそのような新しいNetBeans用のプラグインがあるのでは無いかともう一度探してみたところ。
こんなものがあるじゃありませんか。
FindbugsどころかcheckstyleもPMDもその他色々、これ一個でSoftware Qualityは万全ですってことらしい。
なんてこったい
実は、nbcheckstyleどころかcheckstyle beansもはずれで、このSQEが当たりだったということでしょうか。
そんな訳で、さっそくcheckstyle beansを一旦アンインストールして、以下のアップデートサイトからSQEをインストールしてみることにしました。
インストール対象のプラグインは、以下の三つみたいです。
- SQE Update Center
- SQE Java
- SQE Platform
さっそくインストールして、念のためNetBeansを再起動してみたのですが・・・
さっぱり分かりません
なんだか分からないけど、Javaソースを開くたびに右下に道路標識の進入禁止みたいなアイコンがペコペコ点滅します。ダブルクリックしてみると、何やらSQEがらみのクラスが「ぬるぽ」をスローしている模様。メニューバーに現れた「Quality→Information」をクリックしても、同様に何やらヌルポを発生している模様。
なんだろう
ひょっとしてJava6以上じゃないと駄目だとかそういうことなのだろうか。それとも、
https://sqe.dev.java.net/
↑
このサイトに「SQE is now built against NetBeans 6 RC1.」とか書いてあるように、NetBeans6.1ではまだ動作しないとかなのでしょうか。
それにもまして、「オプション→Quality」のところで、FindBugsとPMDには何やらオプション設定があることは分かったのですが、checkstyleのところには「No Configuration available yet」と表示されるのみで、何も設定項目が無いように見えるのですが。
ようするに
checkstyleのチェック内容をカスタムすることは現状できないということでしょうか。
むむむ・・・
FindBugs、CheckStyle、PMD等々、品質関連のプラグインをSQE一つで全て提供というコンセプトは良いと思うのですが、チェック内容をカスタムできないというのはちょっと痛いです。
仕方が無いので、CheckStyle Beans同様今後に期待ということで、このプラグインはしばらく寝かせておいて当面の間やはりFindBugsはantかmavenでレポートを出して確認することにします。
品質関連のプラグインをオールインワンということで、ついでにJMockitやCode Coverage Pluginあたりもオールインワンされないかしら。
そういえば、品質関連といえば、NB JUnit IDE Integrationってインストールすると何ができるようになるのだろう？一応入れてみたものの、これも良くわかりません。
