いいえ、TrueZIP7はJSE7を必要としません。ホームページのドキュメントとしては、JSE6で十分です。ただし、一部の機能はJSE 7でのみ使用可能であるため（TrueZIPパスモジュールなど）、ランタイムテストが実行されます。
正しいクラスローダーの実装では、NoClassDefFoundErrorが表示されることはありません。ただし、一部の環境では、仕様で義務付けられている遅延クラスのロードにもかかわらず、熱心なクラスのロードを行うクラスローダーの実装が壊れています。そうして初めて、NoClassDefFoundErrorが発生します。
別の注意点として、プロジェクトのEclipseライセンスに注意してください。パッチを適用してこれを本当に修正したい場合（この設計の理由であるjava.io.Fileとjava.nio.file.Pathの間に循環依存関係があるため、修正できません）、このフォークを公開する必要があります。
付録：
Java 6のJava言語仕様、第12.2.1章「ロードプロセス」には次のように書かれています。
ClassLoaderの異なるサブクラスは、異なるロードポリシーを実装する場合があります。特に、クラスローダーは、クラスとインターフェイスのバイナリ表現をキャッシュしたり、予想される使用法に基づいてそれらをプリフェッチしたり、関連するクラスのグループを一緒にロードしたりする場合があります。たとえば、古いバージョンがクラスローダーによってキャッシュされているために、クラスの新しくコンパイルされたバージョンが見つからない場合、これらのアクティビティは実行中のアプリケーションに対して完全に透過的ではない可能性があります。ただし、プリフェッチまたはグループロードなしで発生した可能性のあるプログラム内のポイントでのみロードエラーを反映するのは、クラスローダーの責任です。
英語は私の母国語ではありませんが、最後の文から、未使用のクラスを熱心にロードできなかったという理由だけでクラスローダーがスローされない限り、熱心なクラスのロードはOKであると考えています。したがって、TFile.toPath（）がjava.nio.file.Pathを返す必要があるためにクラスローダーがスローされた場合、このメソッドを呼び出すことはありませんが、これはクラスローダーの問題であると考えます。余談ですが、TFile.toPath（）はUnsupportedOperationExceptionをスローします。詳細についてはJavadocを確認してください。
別のルートを選択したかったのですが、java.io.File.toPath（）とjava.nio.file.Path.toFile（）の間の循環依存により、選択の余地がありませんでした。