Plain Old Java Object (POJO) は、あるJavaオブジェクトがEJB（特にEJB 3より前のEJB）のように特殊なものではなく、ごく普通のJavaオブジェクトであることを強調した名称。設計はシンプルであればあるほど良いと主張する人たちが好んで使用する。
概要
編集2000年9月にマーティン・ファウラーとレベッカ・パーソンズ、ジョシュ・マッケンジーがこの用語を使い始めた。「システムに普通のオブジェクトを使うことに強い抵抗を持つ人が多いのはなぜかと考えたとき、それは単純なオブジェクトに良い名前がついていないのが原因だという結論に達した。そこで我々が名前をつけたら、それがとても流行りだした。」[1] この命名法は、テレフォニーにおけるPOTS (Plain Old Telephone Service) や、C++で書かれているがC言語の機能しか使わないPODS (Plain Old Data Structures) など、高級な新機能を使わない技術に対する既存の用語と同じパターンに従っている。
この用語が広く受け入れられた背景には、複雑で特殊なオブジェクトフレームワークと対照的な、一般的で理解しやすい用語が求められていたことがあると思われる。この用語は、JavaBeansとEnterprise JavaBeansの名前が衝突しているJava "bean"用語よりも魅力的である。JavaBeansは、厳格な命名規約を持つシリアライズ可能なPOJOであるとほぼ言える一方、Enterprise JavaBeansは単一クラスではなく、まったくのコンポーネントモデルである（ただしEJB 3以降は差が減っている）。
POJOの概念は、明らかにPOJOという用語より前から存在する。なぜなら、オブジェクトクラスの自然なありさまとは、何ら特別なものではないからである。この用語の功績は、何らかのフレームワークを使う利点がその複雑さを補ってあまりあるかどうかということを開発者に考えさせるという点にある。シンプルな設計の方が優れている場合もあるということを思い出させる明確な用語がなくては、複雑なフレームワークが十分な理由のないままシステムアーキテクチャに含まれてしまいやすい。POJOによる設計が一般的になるにつれて、大規模フレームワークの機能の一部はPOJOでも実現できることが明らかになってきており、実際に必要な機能領域に対する選択肢は増えている。HibernateとSpringがその例である。
曖昧さの可能性
編集2005年11月時点で、"POJO"という用語は主に、いかなる（主要な）Javaオブジェクトモデル、規約、フレームワーク（たとえばEJB）にも従わないJavaオブジェクトを指して使われている。しかし、モデルやフレームワークが将来的に変化する可能性や、またこのような分類自体が文脈に依存するという事実を考慮すると、その定義は本質的に不安定で曖昧である。
厳密に言えば、POJOは全てのJavaオブジェクトを指す用語とも言える。この解釈に基づけば、POJOに関連する記述は全てのJavaオブジェクトに例外なく当てはまらなければならない。しかし、多くの人はこの意見に反対している。
EJB 3の仕様はPOJOプログラミングモデルであることを宣言しており、EJB3 Session BeanをPOJOとして記述している。ただし、通常はアノテーションを必要とする。
