 |
この定義は，様々な可能性を含む。
ビルダツールは，ウェブページビルダ，視覚アプリケーションビルダ，GUIレイアウトビルダ， 又はサーバアプリケーションビルダを含んでもよい。“ビルダツール”は，単に， 複合文書の部品としてのビーンを含む文書エディタのこともある。
Java Beansは，ボタン，スライダなどのGUI要素であったり， データベースビューア，データ送りなどの 高機能ビジュアルソフトウェア部品であったりする。GUIをもたず， アプリケーションビルダを使って視覚的に構成されることもある。
ビルダツールには，完全に視覚的にJava Beansの結合などの操作ができるものもある。 ユーザが，ビーンズの集合を制御したり，相互に作用したりする Java クラスを書くことも可能とする。 高位のスクリプトを容易に記述可能な単純スクリプト言語も提供可能とする。
Java Beansは，様々な機能をサポートするが，次に示す典型的で統一した特徴をもつ。
ビーンズが，ビルダツールとしてだけではなく，プログラマの使用も可能とする点に， 注意すること。イベント，属性及び永続性の主要APIは，プログラマにも，ビルダツールにも， 正しく作動するために設計された。
ビーンズの多くは，アプリケーションビルダにおいても， 最終的に構成されたアプリケーションにおいても，強力な可視的機能をもっている。
しかし，これは必ずしも要求されない。
例えば，JDBCデータベースアクセスAPIは，JDBCが，本質的にプログラムに基づいたAPIであって，
視覚操作のために直接提供されるものではないので，ビーンとしてよりもクラスライブラリとして，
提供するほうが意味がある。しかし，JDBCの上にそれを使ったデータベースアクセスビーンズを書くことは，
意味のあることとなる。例えば，カスタム時に，ユーザが select 文を構成するのを助ける
“select”ビーンを書き，アプリケーション実行時には，JDBCを使って select
文を実行し， その結果を表示するかもしれない。
特性(propoerty) については，7.でその詳細を示す。基本的に，特性とは， ビーンに関連する名前が付いた属性であって，ビーン上の適切なメソッドを呼び出すことによって， 読み取ったり，書き込んだりできる。例えば，ビーンにその前面色を表現する“前面”特性がある かもしれない。この特性は，メソッド“Color getForground( )”によって読み出され， メソッド“void setForground(Color c)”によって値を変える。
Java Beanがエクスポートする メソッド(method) は， 通常のJavaメソッドそのものであって， 他の部品から，又はスクリプト環境から呼び出すことができる。ビーンの公開メソッドは， デフォルトでエクスポートされるが，公開メソッドの部分集合だけをエクスポートする選択を 可能とする(8.5 を参照。)。
イベント(event) については，6.でより詳細に示す。 イベントは，何らかの出来事が起こったことを，
ある部品から別の部品に知らせる方法を提供する。新しい AWT イベントモデルでは，
イベントリスナオブジェクトをイベントソースに対し登録することができる。
何か出来事が起こったことをイベントソースが検出したときに， イベントリスナオブジェクトの適当なメソッドを呼び出す。
第一に，ビーンは，ビルダツールの内部で実行できなければならない。 これを，通常，設計環境(design environment)という。この設計環境内では， ビーンが，アプリケーションビルダに設計情報を与えたり，エンドユーザがビーンの見かけ 及び振舞いをカスタム化(customize)可能することが重要となる。
第二に，ビーンは，アプリケーション内部で実行時に使用可能でなければならない。 この環境においては，設計情報及びカスタム化はそれほど必要とされない。
設計時情報及び部品の設計時カスタム化コードは，潜在的には，大量でもよい。 例えば，部品作成者が，一連の選択を通じてユーザを案内する， ウィザード式カスタマイザを提供すれば，そのカスタム化コードは，簡単に， そのビーンのためには実行時コードを小さくできるかもしれない。そのため， ビーンの設計時と実行時とを明確に分離し，設計時コードをすべてもたずとも， ビーンを実行できるとすることが望ましい。
例えば，設計時インタフェース(8.及び 9.で示す)は，実行時インタフェース
(8.及び9.以外で示す)とは別のクラスとできる。
特に，Java Beanが信頼されないアプレットの部品として動作する場合は， 標準アプレットセキュリティの制限を受けるため，任意のファイルの読取り若しくは書込み， 又は任意のネットワークホストへの接続は，許されない。しかし，Java Beanが， スタンドアローン型Javaアプリケーションの部品として，又は信頼された (署名のある)アプレットの部品として実行される場合は， 通常のJavaアプリケーションとして処理され， ファイル及びネットワークホストに通常どおりアクセスできる。
一般に，Java Bean開発者は信頼されないアプレットの部品としてビーンズを実行できる設計とする ことを勧める。ビーンズAPIで，これが行われるのは，主に次の場合とする。
例えば，コンテナがJavaアプリケーションならば，包含されるビーンは，そのコンテナと同じ
Java仮想計算機で実行される。コンテナがJavaアプリケーションでない場合は，
Java Beanは，アプリケーションと直接に関連したJava仮想計算機内で実行する。
(通常，この仮想計算機は，アプリケーションと同じアドレス空間で実行している。)
分散システムを設計する主要部分は，局所処理と遠隔処理との間の分離を， 工学的に達成することにある。局所処理は，単一計算機との高速通信が可能となる利点がある。 一方，遠隔アクセスは，呼出し時間が長く，様々な通信障害が起こる可能性がある。 分散システム設計者は，細心の注意を払って，遠隔相互作用の数を最小化し， 様々な種類のデータキャッシュ及び更新バッチを用いて，遠隔トラフィックを減らす， 遠隔インタフェースを設計する。
分散システム作成者は，ネットワークサーバに応答する知的フロントエンドとして動作する ビーンズを設計するのがよい。すべてのビーンズAPIを， ネットワークを越えて作動する設計とするのではなく，主に， 相互作用が安価な仮想計算機内で使用できるビーンズAPIに焦点をあてる。 さらに，ビーンズ開発者が，ネットワークサーバに接続し返せるための代替機構を提供する。
すべてのJavaプラットフォームで，Java Beans開発者が利用できる， 基本ネットワークアクセス機構は，次の三つとする。
|
分散処理には，ネットワーク内でオブジェクトを移送する解決策もある。 例えば，経費処理ビーンは，ユーザのワークステーションで生成され，
ネットワークを回って， 様々な中間サーバ及び他のいろいろなワークステーションで審査され，
その上で，勘定支払サーバに送られ，最終支払処理される。 この例では，ビーンは，生存期間中のある時点では，GUIの見かけを示すが，
別の場合には，サーバアプリケーション内で見えない状態のまま実行される。
GUI表現を取らない，不可視ビーンズを実装することもできる。 これらのビーンズも，メソッド呼出し，イベント発生，永続状態保存などができる。 これは，標準特性シート及びカスタマイザ(9.参照)を用いた，GUIビルダで編集可能とする。
これらの不可視ビーンズは，GUIアプリケーション内での共用資源として， 又はサーバアプリケーション作成時に全くGUI見かけをもたない部品として 使用する。
不可視ビーンズは，アプリケーションビルダツール内で視覚的に表現され， そのビーンの構成を決めるGUIカスタマイザを備えていることもある。
どこでインスタンスが生成されるかによって，ビーンズは，GUI見かけで実行されたり，
又はGUI見かけなしに実行されたりする。サーバにおいて実行される場合は，目に見えないが，
ユーザのデスクトップで動作する場合は，GUI見かけを示すビーンもある。
ビーンがマルチスレッドの下で，適切に振る舞うことを保証するのは， Java
beanの開発者の責任とする。単純なビーンズに対しては，これは， 単に，メソッドをすべて“synchronized”にすることで処理できる。
一般に，Java国際化モデルでは，現デフォルトロケール(java.util.Locale.getDefault) を使用して，適切な文字列をすべて内部的にロケール化するのは， 個々のパッケージの責任とし，さらに，適切にロケール化した文字列を公開APIに渡す。 例えば，フランス語圏での“rouge”などのロケール化された色名の生成は， メソッドColor.toString()の責任であって，ロケール独立の文字列“red”を取り， それをロケール化するのはクライアントの責任とはしない。
Java Beansにとって特に問題なのは，イベント，メソッド及び特性の名前付けとする。 一般に，Javaプログラムは，ロケール独立の プログラム化した 名前によって，プログラムとして動作すると期待する。
ただし，クラスFeatureDescriptorがサポートする“表示名”及び“短ヘルプ” の二つの文字列が例外となる。これらは，ロケール化された文字列を設定することが望ましい。
例えば，Java Beanは，ロケール独立な名前を“hello”とするメソッドを， エクスポートすることがあるが，その表示名は，グラスゴー地方では“heyJimmie” としてロケール化される。ビルダツールは，スクリプト環境でも使用できる， このロケール化された表示名“heyJimmie”をユーザに提示する。 しかし，生成されたJavaコードは，すべてロケール独立のメソッド名“hello” を使用しなければならない。
同様に，ロケール独立のプログラム名“cursorColour”をもつ特性は， メソッドgetCursorColour及びsetCursorColourでアクセスされるが，
米国ではロケール化されて表示名が“cursorColor”となっていてよい。 特性が，特性シートなどを通じて人に提示される場合は，
“cursorColor”と名前付けされてよいが，メソッド自体としては， そのロケール独立名
getCursorColour 及び setCursorColour を用いる。
協調動作するオブジェクトの集合としてのビーンズをサポートする理由は， ビーンに，その実装の一部としていくつかの別のクラスを使用可能とすることに ある。Java言語はただ一つの実装継承だけをサポートするので，与えられた Javaオブジェクトは，ただ一つのJavaクラスを“extend”できるだけとなる。 しかし，ビーンを構成するときに，いくつかの既存のクラスを利用できると 便利な場合がある。
そこで，ビーンのビューを，与えられた型として表現する“型ビュー(type view)” の概念を提供する。Java Beans 1.0では，与えられたビーンの型ビューは，すべて， 単に，同じオブジェクトの違うJavaオブジェクト型への違うキャストを表現する。 しかし，Java Beansの将来の版では，ビューの違う型ビューは，違うJavaオブジェクト によって実装可能とする。
ここに示す規則は，現在記述されている Beans 及びコンテナが，問題なく， 将来のJava Beans実装へと確実に移行するために設計されている。
Java言語レベルでは，型ビューは，Javaインタフェース又はクラスとして， 表現される。しかし，ビーンにおける様々な型ビューの間をたどるには， メソッド Beans.getInstanceOf 及び Beans.isInstanceOf (10.4 参照) を使用しなければならない。
Java ビーンの違った型ビューにアクセスするために， Java キャストを使ってはならない。
例えば，型 X のビーン x をもち，それを型“java.awt.Component”として 見たいならば，次のとおりにするのがよい。
java.awt.Component c = (java.awt.Component) Beans.getInstanceOf(x, java.awt.Component.class);これで，ビーンの“java.awt.Component”の型ビューを，“X”の型ビューとは違った Javaオブジェクトで実装してもよいとする，将来への発展が可能となる。
プログラマは，次のことに注意しなければならない。