Java 7 には３つの重要な目標がある。第１は Jigsaw プロジェクトを通じてJavaプラットフォームをモジュール化すること，第２はinvokeDiamic とDa Vinci Machine プロジェクトによってJVMを多言語プラットフォームへと展開すること，そして第３はJavaプログラマの直面する共通の生産性問題にProject Coinで対処することである。
Javaプラットフォームのモジュール化がもたらす利益は多大なものだ。JDKクラス内部に増え続ける相互依存性を排除してパフォーマンスを改善する。またJDKのダウンロードを，全プラットフォーム一括からサブセット単位で実行可能にしてダウンロードサイズを縮小する。さらに組込コントローラのようなメモリ量の制限されたデバイスへ，JREのサブセットをインストール可能にする。
SunはJDK7のモジュール方式の構築に並行的アプローチを採用している–それがJSR 294とJigsawである。JSR 294の主目標は，コンパイル時環境と実行時環境の一致性を向上させることにある。JSR 294はモジュールシステムをサポートするための言語仕様をJavaに追加して，クラスパスを参照している javac や JVM 自身のようなキーコンポーネントを更新し，最終的にはクラスパスの必要性を完全に取り除こうとしている。JSR294はJigsawから分離されているため，Jigsaw以外の，OSGiなどのモジュールシステムからも使用可能である。さらにGoogle GuiceやJSR299(Javaコンテキストと依存性注入)の将来バージョンのような，他の依存性処理ツールからも利用することができる。
JigsawはこのJSR294の一部分として開発された機能を利用して，Sun のJDK7 実装にモジュールシステムを構築しようとするものだ。Jigsaw自体はSun JVMの実装上の要素のひとつであって，JSRを通じて標準化される予定はなく，技術的にJavaSEの一部分という訳でもない。クラスパスはJavaホストシステムにおけるデファクト標準であってJava言語仕様の一部ではないのだが，驚いたことに，これを置き換えようとするJigsawも実は同じなのである。Jigsawを開発するために，SunはOpenJDK のオープンソースのサブプロジェクトを設立した。このサブプロジェクトもJigsawと呼ばれていて，JSR294のリファレンス実装とJigsawモジュールシステムの設計・実装の両方を行う予定である。
今年のJavaOneで行われたAlex Buckley氏のプレゼンテーションでは，JSR294とJigsawの動作方法に関する技術的詳細が解説された。特筆すべきは標準 module-info インターフェースの導入である。Javaプログラムはこれを使って，依存関係などの詳細情報を特定することができるようになる。この詳細情報にはモジュールID，アプリケーションのメインクラス，プログラムが提供するモジュールと依存するモジュール，などが含まれている。さらにオプションとしてバージョン情報も格納される。これはSunやその他の組織が将来，広く利用されているライブラリやAPIを修正する作業を容易にすることだろう。以下はBuckley氏のスライドで示された例である：
module org.planetjdk.aggregator @ 1.0 {
system jigsaw;
requires module jdom @ 1.*;
requires module tagsoup @ 1.2.*;
requires module rome @ =1.0;
requires module rome-fetcher @ =1.0;
requires module joda-time @ [1.6,2.0);
requires module java-xml @ 7.*;
requires module java-base @ 7.*;
class org.planetjdk.aggregator.Main;
}
このモジュール情報を使用してJigsawのパッケージツール(jpkg)は，プラットフォームの機能により密接に結合した配布パッケージ用のマッピングを生成できるようになる。JigsawによってJavaデスクトップアプリケーションは，Sunのサポートする各種プラットフォーム上の一級市民として認知されるようになるだろう。デスクトップJavaを活性化しようするSunの取り組みの上で，これは重要な意味を持つ。Mark Rainhold氏はJavaOneで現時点での機能をいくつか紹介し，Linux 上の Synaptic パッケージマネージャを使って簡単なアプリケーションが，基本的なJavaモジュールから始まってAWTやSwingなどのモジュールが追加されながら段階的に構築されていく様子をデモしてみせた。
OSGiのような既存のモジュールシステムを利用せずにJigsawを開発しようとするSunの決定に関しては，議論の余地が大いにある。この方法を選択した理由を明確に示すという点では，Sunの行ってきた仕事はお粗末なものだ。しかし最近のJava Posseポッドキャストで，Mark Reinhold氏とAlex Buckley氏がこの２つのアプローチの違いに関する技術的詳細を語っていて，これがSunが自身でのシステム構築を決定した理由の手がかりとなりそうだ。JigsawによってパッケージされたアプリケーションがOSGiのものよりもプラットフォームに密接に結び付いているという点以外に，２つのシステムには依存モデル上の違いがある。Sunにはパッケージを異なったモジュールに分割して，実行時に同じクラスローダでロードできるようにする必要があった - それは例えば，Java.util のようなパッケージを複数のモジュールに分割する(場合によっては，メモリ制限のあるデバイス用に別実装を用意する)場合である。これをサポートするため，Jigsawには再帰的なローカル依存，というコンセプトがある。これはつまり"Swing"モジュールが"AWT"モジュールにローカルな依存性を持ち，さらに"AWT"モジュールが"base"モジュールにローカルな依存性を持つならば，Swing，AWT，baseのランタイムモジュールは最終的に同じクラスローダになければならない，というものだ。OSGiもフラグメントの形式に関して同様のコンセプトを持っているのだが，それ自身で依存関係を表現できないという点で柔軟性に不足がある。
Enterprise Expert Group の協同議長であるEric newcomer氏は，この件について納得していない。最近のブログへのポストで彼は，Jigsawのことを"OSGiを再発明するか，何としてでもOSGiを阻止するか，あるいは自分たちでコントロールできる代用品を作るための，Sunの最後の試み"と評して，次のように書いている。
"私は今年のJavaOneには参加しなかったので，遠く離れた場所で誤った印象を持っているのかも知れませんが，私の見た限りでは，Jigsawプロジェクトの説明とデモはOSGiに関して言及していませんでした。Java 7に向けての計画についても説明されませんでした。ですから，JigsawプロジェクトがJavaのモジュール性にとって脅威となる存在か，という問いに対する返答はYESです。"
しかしながら彼以外のブロガの多くは，Sunの努力に対する好印象から，これよりも前向きな反応を見せている。その中の一人であるBram Bruneel氏は，ネィティブパッケージの生成によい印象を持った。
"..MarkはUbuntuを使って，Javaアプリケーションのパッケージングと配布に関するすばらしいデモを見せてくれました。このJDKモジュールは標準Debianパッケージとなることでしょう。それによって独自のJavaアプリケーションを作成してDebianパッケージにエクスポートし，アプリケーションの実行に必要なJavaモジュールへの依存性を定義することが可能になります。"
Alex Miller氏は，自身の会話録において，Jigsawの重要性を指摘している。
"ここにあるスコープは野心的ですーこのデモにはきわめて理路整然としたビジョンがあり，その影響範囲は私のそれまでの理解を越えた広範囲なものです。そのビジョンには私たちがコンパイルを行い，パッケージを作成し，そしてJavaアプリケーションを起動する方法の完全な再点検をも含んでいます。"
Glyn Normington氏はJava Posse ポッドキャストの内容について，次のようにコメントしている。
"技術的な詳細が明らかになったのはすばらしいことであり，OpenJDKがApache Harmonyとは異なるモジュール性の設計を採用した理由が分かるようになりました。"
Dalibor Topic氏は，ネィティブパッケージツールの可能性に特に注目しているようだ。
"モジュールの言語的コンセプトと，実装されたモジュールシステムの間にある関連を切り離すことによって，jpkgのようなツールを使って抽象的なモジュール群と実際の配布パッケージとのN:Mマッピングを生成することができるようになります。プラットフォームに対して最適な配信機構を選択できる自由には，明確な利益があります。例えばパッケージマネージャを持つプラットフォーム上でJDKを配布する最もユーザフレンドリな方法は，パッケージを利用することです。ahead-of-timeコンパイラによるネイティブコードへの変換も，プラットフォームでそれが必要ならば，大きな苦労もなく行えるようになりますーpack200やLZMA圧縮が現在のjpkgコードで行われているように，配布パッケージの生成前にモジュールに適用されるポストプロセスの１ステップとしてしまえばよいのです。１つのモジュールを透過的に２つのネイティブパッケージに分割することも，同じように簡単に実現できます。さらに，例えばJNIライブラリをアーキテクチャ依存パッケージに分割したり，複数のアーキテクチャ用のネイティブコードを伴う複雑なアプリケーション(JDKもそうですが)のダウンロードサイズを減らすことも可能です。さらにはネィティブコードに懐かしきバッファオーバフローを発見したとき，ネイティブライブラリを部分的に修正したパッケージを配布するようなことも，少し楽になるでしょう。"