非常に唐突なのですが、あるメソッドに対して、データの受け渡しを考える場合、普通は，ハッシュマップ（項目名が必要ない場合はVector)か、XMLが検討されると思います。
富士通のJ2EEフレームワークである、InterStageにおいても、Beanとのやり取りに、XMLとハッシュマップが検討され、ハッシュマップになったというのが、どこかのマニュアルに書いてあったと思います（ごめん、どのマニュアルだったか、思い出せない）
そこには、HashMapのほうが、当時は「良く使われているから」という話でしたが、実は、それ以外にも、大きな優位性があります。
それは、XMLの場合、インスタンスだけでは、項目名（タグ名）と値だけしか表現できません。もし、その値の型を表現したければ、それ以外のところに型を持つか、属性として、型をあらわす属性を持たないといけません。
それに対し、HashMapの場合には、値を格納するクラスの型が取得できます。
つまり、HashMap のgetで取り出した値のgetClass()をすれば、クラス名が分かります。
instanceOf演算子によって、クラスによる振り分け処理が出来たりします。
この、HashMapの場合、値を格納するクラスが取得できるということに、どれだけのメリットがあるのか？ということなのですが、例えば、データベースアクセスのようなとき、便利です。
検索結果を、HashMap１個につき、１レコード、検索条件をHashMap1個につき１And条件とします（orで結ぶ場合、orの分、ハッシュマップができる）。
SQL文を書く場合、Where句は、
Stringであれば、''でくくる
数値であればそのまま
日付はＤＢによって記述が違う
という特徴があります。これらについて、ハッシュマップの値の型をみれば、振り分けられます。
したがって、あらかじめ、各テーブルの項目の型をしらなくても、HashMapなら、SQL文が作れます。ということは、テーブルに依存しない汎用的なSQL作成クラスが作れるということです（＝１つのアクセスクラスでＯＫ）。
現実的には、ＤＢに、しんふぉうぇあを使う場合、SQL文で、日本語のところはNCという言葉がつきます（例： item1 = NC'ある' ） このような場合、渡された値が日本語かどうかをチェックしてもＯＫですが、ncharというクラスをつくり、そこに値をセットし、ハッシュマップに入れてもＯＫです。nchar型がきたとき、しんふぉうえあだったら、NCをつけ、そうでないＤＢのときには付けないといった使い分けが出来ます。
つまり、型をみて、処理を切り分けることができるということです。
ちなみにさらに、リフレクションを使うと、型によって、必要な処理をプラグインで行うことができるということになります。
また、自分でクラスを作る場合には、その中に、値以外の、いろんな属性値を作ることが出来ます。やる気になれば（必要ないと思うけど）仕様書の内容、まるまる入れることもできるわけです。
ただし、これはHashMapの専売特許というわけではなくて、XMLでも、属性値に、型や、その他の事項を盛り込むことで、可能ではあります。
アクセス
トータル
ランキング
