[Overview]
以下の理由からOGNLに依存しないようにもできるようにしたい：

　o 将来的な展開を考えたときにOGNLには依存しない方がいいかも
　o DBFluteで使っているOGNLの機能はかなり限定的である
　o OGNLを外せばdbflute-runtime.jarは完全に非依存ライブラリとなる ※1
　o 複雑な判定はExParameterBeanにプロパティとして定義する方が安全
　o 自前でやることでエラーメッセージをもっと詳細に出せる

※1: commons-loggingには依存(ここはデファクトということで勘定に含めず)

複雑な判定はExParameterBeanにプロパティとして実装するのをポリシーとする。
パラメータコメント上で頑張るよりもExParameterBeanに実装する方が
はるかに安全なためである。
サポートする構文をしっかりドキュメントに明記すること。

[Specification]
DBFluteが現状OGNLを利用している箇所は外だしSQLのIFコメントのみである。
(ParenBindVariableNodeはそれ自体利用されていない --> 新バージョンで削除)
その中で主に利用されているのは：

// プロパティの値・メソッドの値の比較 {==, !=, >, <, >=, <=}
/*IF pmb.memberId != null*/
/*IF pmb.getMemberName() == null*/
/*IF pmb.memberId < 3*/
/*IF pmb.birthdate > date '2009/09/30'*/
/*IF pmb.memberName == 'Pixy'*/
/*IF pmb.existsPurchase == true*/
/*IF pmb.memberId >= pmb.displayOrder*/

// boolean値プロパティ・メソッド
/*IF pmb.existsPurchase*/
/*IF pmb.isExistsPurchase()*/

// boolean値プロパティ・メソッドの否定「!」
/*IF !pmb.existsPurchase*/
/*IF !pmb.isExistsPurchase()*/

// AND条件「&&」
/*IF pmb.memberId != null && pmb.memberName != null*/

// OR条件「||」
/*IF pmb.memberId == null || pmb.memberName == null*/

※他にパターンがないか要調査

複雑な判定はExParameterBeanにというポリシーから以下のものはサポートしない：
　o AND条件「&&」とOR条件「||」の併用
　o 括弧「()」によるスコープ定義
　o 引数ありメソッドの呼び出し

[Supplement]
処理スピードを考慮すること。キャッシュのスレッドセーフを考慮すること。
(OGNLは内部でリフレクション情報をキャッシュ)
--> TnBeanDescを使えば自然とOKかな！？

DBFLUTE-525のパラメータコメントのチェックで、
サポートしない構文をチェックできたらいいかも！？
それと同時に移行すればユーザが影響範囲を検知しやすい。
--> というかOGNLを外さないとDBFLUTE-525がやりづらいことが判明

[Milestone]
まずは、独自のパースクラスを作って、
単体テストレベルで完全に仕上げる。
サポートパターンの議論がまとまって、キリの良いバージョンで反映。