プログラムの「枠組み」を提供するライブラリ。
ライブラリの一種。「パーツ」ではなく、「枠組み」を提供する。
　
フレームワークを利用するプログラムは、フレームワークの「外壁」となるクラスや「隙間」を埋めるクラスを作成する。
フレームワークは、どの機能も共通で利用する共通部分を提供する。プログラムには様々な機能でも共通して使用する部分があり、その部分をフレームワークによって処理する。
そして、機能によって異なるクラスのみを作成する。具体的には、フレームワークで使用されているクラスをオーバーライドしたり、XMLファイル等を使用して登録を行い、作成したクラスがフレームワークから使用されるようにする。
　
フレームワークを使用することで、数多くのメリットがある。
共通部分にフレームワークのクラスを使用することで、プログラムを重複して作成する無駄を省き、複数のプログラマーが作成する際の質の平均化を促進する。
作成するクラスは全体の一部分となるため、全体の工数が下がり、必要とする知識も少なくて済むため、プログラムの製作が簡易になる。
　
ただし、フレームワークはそれぞれ強い癖があり、まずはその癖を理解する必要がある。
フレームワークに接続するクラスはフレームワークのルールに従う必要があり、そのルールをまず理解する必要がある。それは単純なルールではなく、概念的に難しい場合もあるため、担当する全てのプログラマーが理解するための時間が必要となる。
また、フレームワークには得意な分野、不得意な分野があり、フレームワーク内部のプログラムをカスタマイズできない場合、「一から作ればできたことがフレームワークではできない」ことも多い。
そのため、フレームワークの導入には、そのフレームワークに対する十分な知識が必要となる。知識なく不用意に導入すると痛い目にあう。
だが逆に、その知識を誰も得ようとしないため、現場ではフレームワークの導入に消極的になりがちであり、効率な作業の妨げともなっている。
　
Javaのフレームワークとして最も有名なものとしては、Webアプリケーション用フレームワーク「Struts」だろう。Struts以外にも、Jakartaプロジェクトにはいくつかのフレームワークがある。
また、J2SEのコレクションを「コレクションフレームワーク」と言い、これもフレームワークの一種となっている。
　
ただし、この「コレクションフレームワーク」の例からも分かるとおり、フレームワークとライブラリの境界は曖昧である。フレームワークとしての機能を持つライブラリも多いため、「フレームワーク」という名前が付けられていても、フレームワークがメインの機能とは限らない場合も多い。

「やっぱフレームワークって言ったらStrutsだよね」
「フレームワークのお手本みたいなもんだからな」
「ってゆーかコレクションフレームワークはフレームワークじゃないでしょ」
「そうなのか？」
「むしろAWTやSwingの方がフレームワークっぽいんだけど。MFCっぽいし」
「MFCってなんだ食べもんかそれ」
「くっ……」