JavaLens

JavaLens：Java 向け AI ファーストのコード分析

コンパイラーの精度でコードを理解できるよう、Eclipse JDT を直接基盤として構築された、Java のセマンティック分析ツールを 75 種類備える MCP サーバーです。

AI エージェント向けに構築

JavaLens は、AI システムにはソースファイルを読むだけでは得られない、コンパイラーの精度に基づく分析結果が必要であるという理由から生まれました。AI が grep や Read を使ってメソッドの使用箇所を探しても、次のような区別はできません。

• メソッド呼び出しと、無関係なクラスにある同名メソッド
• フィールドの読み取りと、フィールドへの書き込み
• インターフェースの実装と、無関係なクラス
• 型へのキャストと、その型へのその他の参照

その結果、誤ったリファクタリング、使用箇所の見落とし、コードの動作に対する理解不足につながります。

コンパイラーの精度に基づく分析

JavaLens は、Eclipse IDE を支えるものと同じエンジンである Eclipse JDT を通じて、コンパイラーの精度に基づくコード分析を提供します。テキスト検索とは異なり、JDT は次の内容を理解します。

• 継承階層をまたいだ型解決
• メソッドのオーバーロードとオーバーライド
• ジェネリック型の型引数
• インポートの解決とクラスパスの依存関係
• バージョン 1.1 から Java 25 までの Java ソース（Markdown Javadoc、モジュールのインポート、コンパクトソースファイル、柔軟なコンストラクター本体）
• Lombok が生成するメンバー — バンドルされたエージェントにより、@Data のアクセサーなどが解決され、それらを使用するコードが未定義としてフラグ付けされません

例： UserService.save() のすべての呼び出し箇所を検索する場合：

方法	結果
grep "save("	orderService.save()、saveButton、コメントを含む 47 件の一致を返します
find_references	UserService.save() の呼び出しを正確に 12 件返します

AI の学習バイアスに関する警告

⚠️ AI 開発者およびユーザー向けの重要事項

AI モデルには、セマンティック分析の方が優れた結果を提供する場合でも、MCP サーバーツールよりネイティブツール（Grep、Read、LSP）を優先する学習バイアスが見られることがあります。これは次の理由によります。

1. 学習データに grep／テキスト検索のパターンが大量に含まれている
2. モデルの経験上、ネイティブツールは「常に利用可能」である
3. セマンティック分析の方が優れている場面をモデルが認識できないことがある

最良の結果を得るには：

プロジェクトの指示またはシステムプロンプトにガイダンスを追加してください（例：Claude Code 用の CLAUDE.md）。

## Code Analysis Preferences

For Java code analysis, prefer JavaLens MCP tools over text search:
- Use `find_references` instead of grep for finding usages
- Use `find_implementations` instead of text search for implementations
- Use `analyze_type` to understand a class before modifying it
- Use refactoring tools (rename_symbol, extract_method) for safe changes

Semantic analysis from JDT is more accurate than text-based search,
especially for overloaded methods, inheritance, and generic types.

JavaLens とは？

JavaLens は、AI アシスタントに Java コードベースへの深い理解をもたらす MCP サーバーです。単純なテキスト検索を超える、セマンティック分析、ナビゲーション、リファクタリング、コードインテリジェンスのツールを提供します。

LSP では不十分な理由

Language Server Protocol は IDE の自動補完や基本的なナビゲーション向けに設計されており、深いセマンティック分析を必要とする AI エージェントのワークフロー向けではありません。

機能	ネイティブ LSP	JavaLens
すべての @Annotation の使用箇所を検索	❌	✅
すべての new Type() のインスタンス化を検索	❌	✅
型へのすべてのキャストを検索	❌	✅
フィールドの読み取りと書き込みを区別	❌	✅
循環するパッケージ依存関係を検出	❌	✅
循環的複雑度を算出	❌	✅
未使用のプライベートメソッドを検索	❌	✅
null ポインターのバグの可能性を検出	❌	✅
エントリーポイントからプロジェクト全体の到達可能なデッドコードを分析	❌	✅
シンボルを推移的に実行するテストを検索	❌	✅

JavaLens は Eclipse JDT Core を OSGi 経由で直接ラップし、次の機能を提供します。

• 詳細な参照タイプ：キャスト、アノテーション、throws 節、catch ブロック、instanceof チェック、メソッド参照、型引数を個別に検索
• 読み取りと書き込みアクセスの区別：フィールドが変更される箇所と、読み取られるだけの箇所を追跡
• インデックス検索：JDT は読み込み時にインデックスを事前構築するため、シンボルや参照のクエリでソースファイルを走査しません
• 完全な AST アクセス：複雑なリファクタリングのための直接操作

インストール

前提条件

• Java 21 以降（PATH に設定するか、JAVA_HOME を設定してください）— どちらのインストール方法でも必要です。
• Node.js 18+ — 以下の npm／npx によるインストール方法を使用する場合にのみ必要です。直接ダウンロードする方法を使用する場合は不要です。

JavaLens はコンパイラーではなく、解析サーバーです。Eclipse JDT 2025-12 を使用して、バージョン 1.1 から 25 までの Java ソースコードを解析し、理解します。Java 21 が必要なのは、サーバーのランタイムとしてのみです。

GitHub Releases からインストール（推奨 — Java のみ）

Java 21 がすでにあり、Node.js がない場合は、これが最も簡単な方法です。Releases からダウンロードしてください。

プラットフォーム	ファイル
すべてのプラットフォーム	javalens.zip または javalens.tar.gz

任意の場所（例：/opt/javalens または C:\javalens）に展開します。その後、同梱の jar を使用するよう MCP クライアントを設定します。詳しくは、以下の「MCP クライアントの設定」を参照してください。

npm でインストール（Node.js 18+ が必要）

Node.js がすでにある場合、初回実行時に npx が JavaLens の配布物（約 23 MB）をダウンロードしてキャッシュします。

{
  "mcpServers": {
    "javalens": {
      "command": "npx",
      "args": ["-y", "javalens-mcp"],
      "env": {
        "JAVA_PROJECT_PATH": "/path/to/your/java/project"
      }
    }
  }
}

MCP クライアントの設定

MCP 設定（例：Claude Code の .mcp.json）に追加します。

{
  "mcpServers": {
    "javalens": {
      "command": "java",
      "args": ["-jar", "/path/to/javalens/javalens.jar", "-data", "/path/to/javalens-workspaces"]
    }
  }
}

-data 引数は、JavaLens がワークスペースのメタデータを保存する場所を指定します。詳しくは、以下の「ワークスペースの仕組み」を参照してください。

プロジェクトの自動読み込み

JAVA_PROJECT_PATH を設定すると、サーバーの起動時にプロジェクトが自動的に読み込まれます。

{
  "mcpServers": {
    "javalens": {
      "command": "java",
      "args": ["-jar", "/path/to/javalens/javalens.jar", "-data", "/path/to/javalens-workspaces"],
      "env": {
        "JAVA_PROJECT_PATH": "/path/to/your/java/project"
      }
    }
  }
}

注： プロジェクトの読み込みはバックグラウンドで非同期に行われます。プロジェクトの読み込み中も、MCP サーバーはただちに応答します。読み込み状況の確認には health_check を使用してください。読み込みが完了するまで "project.status": "loading" と表示され、準備ができると "loaded" と表示されます。

ワークスペースの仕組み

メモリー内のコードモデルとは異なり、Eclipse JDT は以下を保存するためのワークスペースディレクトリを必要とします。

• シンボルをすばやく検索するための検索インデックス
• コンパイル状態とキャッシュ
• プロジェクトのメタデータ

ワークスペースはソースの外部に作成されます

JavaLens はコードベースをクリーンな状態に保つため、ソースプロジェクトの外部にワークスペースを作成します。

Your Java Project (unchanged)
├── src/main/java/
├── pom.xml
└── (no Eclipse files added)

JavaLens Workspace (specified by -data)
└── {session-uuid}/
    ├── .metadata/          <- JDT indexes and state
    └── javalens-project/   <- Links to your source (not copies)

重要な理由：

1. 汚染なし：ソースツリーはクリーンなままです。.project や .classpath ファイルは作成されません。
2. 競合なし：干渉することなく、あらゆるビルドシステムと併用できます。
3. セッションの分離：MCP セッションごとに独自のワークスペースが割り当てられるため、並行して解析できます。

セッションのライフサイクル

1. JavaLens が起動し、一意のワークスペース {base}/{uuid}/ を作成します。
2. load_project がソースを指すリンクフォルダーを作成します。
3. JDT がプロジェクト内ではなく、ワークスペース内にインデックスを構築します。
4. セッションが終了すると、ワークスペースはクリーンアップされます。

ツール

ナビゲーション（10 個のツール）

ツール	説明
search_symbols	glob パターンで型、メソッド、フィールドを検索します
go_to_definition	シンボルの定義に移動します
find_references	シンボルのすべての使用箇所を検索します
find_implementations	インターフェース／クラスの実装を検索します
get_type_hierarchy	継承関係を取得します
get_document_symbols	ファイル内のすべてのシンボルを取得します
get_symbol_info	指定位置のシンボルの詳細情報を取得します
get_type_at_position	カーソル位置の型の詳細を取得します
get_method_at_position	カーソル位置のメソッドの詳細を取得します
get_field_at_position	カーソル位置のフィールドの詳細を取得します

詳細な参照検索（9 ツール）

これらのツールでは、LSP では利用できない JDT 独自の参照型定数を使用します。

ツール	説明
find_annotation_usages	すべての @Annotation の使用箇所を検索します
find_type_instantiations	すべての new Type() 呼び出しを検索します
find_casts	すべての (Type) expr キャストを検索します
find_instanceof_checks	すべての x instanceof Type を検索します
find_throws_declarations	シグネチャ内のすべての throws Exception を検索します
find_catch_blocks	すべての catch(Exception e) ブロックを検索します
find_method_references	すべての Type::method 式を検索します
find_type_arguments	すべての List<Type> の使用箇所を検索します
find_reflection_usage	Class.forName()、Method.invoke()、その他のリフレクション呼び出しを検索します

分析（20 ツール）

ツール	説明
get_diagnostics	コンパイルエラーと警告を取得します
validate_syntax	構文のみをすばやく検証します
get_call_hierarchy_incoming	メソッドの呼び出し元をすべて検索します
get_call_hierarchy_outgoing	メソッドが呼び出すメソッドをすべて検索します
find_field_writes	フィールドが変更される箇所を検索します
find_tests	JUnit/TestNG のテストメソッドを検出します
find_unused_code	未使用の private メンバーを検索します
find_unreachable_code	プロジェクト全体のデッドコードを検索します。プログラム全体の呼び出しグラフにおいて、すべての main メソッドまたはテストから到達できないメンバーが対象です
find_affected_tests	シンボルを直接または推移的にテストするテストを検索します。シンボルの変更後に実行すべきテストの集合です
find_possible_bugs	null のリスク、空の catch、リソースリークを検出します
get_hover_info	シンボルのドキュメント／シグネチャを取得します
get_javadoc	解析済みの Javadoc を取得します
get_signature_help	呼び出し箇所のメソッドシグネチャを取得します
get_enclosing_element	指定位置を含むメソッド／クラスを取得します
analyze_change_impact	変更の影響範囲を調べます。深さごとの直接の呼び出し箇所、またはプロジェクトグラフ全体の推移的閉包（transitive=true）を取得します
analyze_data_flow	メソッド内の変数の読み取り／書き込み／宣言を追跡します。followCalls を有効にすると、シンクへの呼び出しをまたいで null／汚染の情報を追跡します
analyze_control_flow	分岐、ループ、return／throw の箇所、ネストの深さを分析します
get_di_registrations	Spring の DI 登録（@Component、@Bean、@Autowired、@Inject）を検索します
get_jpa_model	組み立て済みの JPA エンティティモデルを取得します。テーブル、ID フィールド、解決済みの対象と mappedBy 側を含む関連を確認できます
get_http_endpoints	組み立て済みの HTTP ルートテーブルを取得します。Spring および JAX-RS のパスをクラスのプレフィックスから構成し、ハンドラーメソッドに対応付けます

複合分析（4 ツール）

複数のクエリを組み合わせて、ラウンドトリップを減らします。

ツール	説明
analyze_file	1 回の呼び出しでインポート、型、診断情報を取得します
analyze_type	メンバー、階層、使用箇所、診断情報を取得します
analyze_method	シグネチャ、呼び出し元、呼び出し先、オーバーライドを取得します
get_type_usage_summary	インスタンス化、キャスト、instanceof の件数を取得します

リファクタリング（16 個のツール）

すべてのリファクタリングツールは、変更を直接適用するのではなく、テキスト編集内容（リファクタリングによって新規ファイルを作成する場合は、その内容も含む）を返します。

ツール	説明
rename_symbol	プロジェクト全体で名前を変更します
organize_imports	インポートを並べ替えて整理します
extract_variable	式をローカル変数に抽出します
extract_method	コードブロックを新しいメソッドに抽出します
extract_constant	static final フィールドに抽出します
extract_interface	クラスのメソッドからインターフェースを作成します
extract_superclass	メンバーを新しく作成したスーパークラスに移動します
inline_variable	変数を初期化式に置き換えます
inline_method	メソッド呼び出しをメソッド本体に置き換えます
change_method_signature	パラメーター／戻り値を変更し、すべての呼び出し元を更新します
convert_anonymous_to_lambda	匿名クラスをラムダに変換します
encapsulate_field	アクセサーを生成し、フィールドへの直接アクセスをすべて書き換えます
pull_up	メンバーをスーパークラスに移動します
push_down	メンバーをサブクラスに移動します
introduce_parameter_object	メソッドのパラメーターを新しいクラスにまとめ、呼び出し元を更新します
move_type_to_new_file	ネストされた型を独立したトップレベルファイルに移動します

クイックフィックス（5 個のツール）

ツール	説明
suggest_imports	解決できない型に対するインポート候補を検索します
get_quick_fixes	指定位置の問題に適用できる修正を一覧表示します
apply_quick_fix	ID で修正を適用します（インポートの追加、削除、throws の追加、try-catch）
apply_cleanup	10 種類の JDT クリーンアップ（ループ、パターンマッチング、switch 式、テキストブロックなどへの変換）を適用し、書き換えたソースを返します
diagnose_and_fix	ファイルを診断し、各問題に対する最上位のクイックフィックス編集内容を 1 回の呼び出しで返します

メトリクス（5 個のツール）

ツール	説明
get_complexity_metrics	循環的複雑度／認知的複雑度、メソッドごとの LOC
get_dependency_graph	パッケージ／型の依存関係をノードとエッジとして表示します
find_circular_dependencies	Tarjan の SCC アルゴリズムを使用してパッケージの循環依存を検出します
find_large_classes	メソッド数／フィールド数／行数のしきい値を超える型を検索します
find_naming_violations	Java の命名規則に準拠しているか確認します

プロジェクトとインフラストラクチャ（6 個のツール）

ツール	説明
health_check	サーバーのステータスと機能
load_project	Maven／Gradle／Bazel／通常の Java プロジェクトを読み込みます
get_project_structure	パッケージ階層を取得します
get_classpath_info	クラスパスのエントリーを取得します
get_type_members	型名でメンバーを取得します
get_super_method	スーパークラス内のオーバーライドされたメソッドを検索します

使い方

基本的なワークフロー

1. load_project(projectPath="/path/to/java/project")
2. search_symbols(query="*Service", kind="Class")
3. find_references(filePath="...", line=10, column=15)
4. analyze_type(typeName="com.example.UserService")

座標系

行／列のパラメーターはすべてゼロ始まりです。

• 行 0、列 0 = ファイルの最初の文字

パスの処理

• 応答パスはデフォルトで相対パスです
• プラットフォーム間の一貫性を保つため、すべてのパスでスラッシュを使用します
• 入力パスには相対パスまたは絶対パスを指定できます

重要な注意事項

ディスクとの同期

すべての回答は、クエリ時点でディスク上のファイルと照合して検証されます。ツールのロジックが実行される前に、JavaLens は既知のソースファイルのコンテンツハッシュを計算し、編集、追加、削除を検出します（エージェントは何も報告せず、サーバーが自ら変更を検出します）。変更された箇所だけを正確に修復し、検索インデックスに修復が反映されるのを待ってから回答します。ファイルウォッチャーもバックグラウンドスレッドもありません。検証はエージェントが発行したクエリ内で同期的に行われるため、競合状態は発生しません。

エージェントのループは「編集 → クエリ」だけです。

1. Use JavaLens tools to analyze
2. Write changes to files
3. Use JavaLens tools to verify — answers already reflect the changes

load_project が必要なのは、初回使用時、応答で RELOAD_REQUIRED が報告された場合（pom.xml などのビルドファイルが変更され、クラスパスの再構築が必要な場合）、またはすべてを最初から再構築する場合だけです。検証自体に失敗した場合、クエリは未検証の回答ではなく VERIFICATION_FAILED を返します。

コスト： 検証はハッシュベースで並列に行われます。実測値は、72 ファイルのプロジェクトでクエリあたり約 2 ms、1,000 ファイルで約 25 ms、10,000 ファイルで約 180 ms です。修復コストは変更された部分だけにかかります（編集したファイル 1 つの同期は 1 秒もかかりません）。インデックス全体を再構築することはありません。

手動モード： JAVALENS_DISK_SYNC=manual を設定すると、1.5.0 より前の仕様に戻ります。回答には最後に読み込まれた時点の内容が反映され、ファイルの編集後にエージェントが load_project を呼び出します。ツールの説明と MCP の instructions フィールドには、常に現在有効な仕様が記載され、health_check は diskSync としてその状態を報告します。

リファクタリングによる編集内容の返却

リファクタリングツールはテキスト編集内容を返しますが、ファイルは変更しません。これにより、適用前に変更内容を確認できます。

セッションの分離

各 MCP セッションは、それぞれ独自のワークスペース UUID を持ち、互いに独立しています。複数のセッションで同じプロジェクトを同時に分析できます。

ビルドシステムのサポート

JavaLens は 3 つの実際のビルドシステムと、プレーンな Java ディレクトリを読み込みます。各システムは、実際のプロジェクト構成を模した合成フィクスチャ（モジュール間依存関係のあるマルチモジュールリアクター、実際の外部ライブラリ、アノテーションプロセッサ）を使い、CI でエンドツーエンドにテストされています。

システム	検出	単一モジュール	マルチモジュール／マルチプロジェクト	ビルドファイルからのコンパイラー準拠レベル	生成ソース	アノテーションプロセッサ
Maven	pom.xml	✅	✅（Maven の実効モデルが示すリアクター、../ モジュール、モジュールごとのクラスパス。リアクターモジュールは JAR ではなくソースとしてリンクされます）	✅（各モジュールに maven-compiler-plugin が適用するレベル。release が source より優先され、プラグイン設定がプロパティより優先され、親から継承されます）	✅（実効ビルドディレクトリ内にある、各モジュールの generated-sources のサブディレクトリ）	✅（<annotationProcessorPaths>。Maven のローカルリポジトリから解決されます）
Gradle	settings.gradle(.kts) / build.gradle(.kts)	✅	✅（Gradle が報告するプロジェクト、カスタム projectDir、インクルードビルド、ソースセット、クラスパス）	✅（各プロジェクトの sourceCompatibility）	✅（Gradle が報告する生成ソースディレクトリ）	✅（annotationProcessor 設定）
Bazel	MODULE.bazel / WORKSPACE.bazel / WORKSPACE	✅	✅（bazel query による Java ターゲットとそのソース。クラスパスは各ターゲットの javac アクションから取得されます）	✅（javac が実際に使用する各 javac アクションのレベル。ツールチェーンのデフォルト、.bazelrc のフラグ、ターゲットの javacopts の順です）	対象外（Bazel アクションは target/generated-sources/ ではなく bazel-bin/ に書き込みます）	✅（各 javac アクションのプロセッサーパス）
プレーン Java	src/ ディレクトリ	✅	対象外	✅（ビルドファイルがない場合は Runtime.version().feature() にフォールバックします）	対象外	対象外

JavaLens は読み込み時にビルドツール自体に問い合わせて、その応答からモデルを取得します。プロジェクトツリーには何も書き込みません。

• Maven：help:effective-pom と dependency:build-classpath を、--fail-at-end を付けて1回実行します。Maven が解決できないモジュール（通常は、同じビルド内のインストールされていないモジュールに依存するもの）は BUILD_TOOL_FAILED として示されます。それ以外のモデルは引き続き Maven のものです。非アクティブなプロファイルでのみ宣言されたモジュールや、ルート pom と同じ場所にある settings.gradle の Gradle プロジェクトは、INCLUDED_OUTSIDE_BUILD の状態でリンクされたままになります。
• **Gradle：**プロジェクト、カスタムの projectDir、インクルードされたビルド、ソースセット、生成ソースのディレクトリ、クラスパス、プロジェクトごとのレベルを報告する init スクリプトを使って1回実行します。
• **Bazel：**Java ターゲットとソースおよびビルドファイルに対する bazel query、各 javac アクションに対する bazel aquery、bazel info execution_root を、すべて --lockfile_mode=off を付けて実行します。

ツールを実行できない場合、またはモデルがないと報告された場合、JavaLens はビルドファイルをコードとして直接読み取ります（コメントと文字列は宣言として扱いません。pom は XML として、Gradle の設定ファイルと Bazel の BUILD ファイルはレキサーを通して読み取ります）。ファイルに記載がない箇所は規約に基づいてモジュールを配置し、そのような読み取りでは把握できない内容を示す BUILD_MODEL_STATIC 警告とともに、buildModel.source = static-read を報告します。

ルートの外にあるモジュールの pom を含め、ビルドが読み取るファイルに変更があると（読み込み後に作成されたファイルも含みます。gradle.properties、バージョンカタログ、buildSrc、.mvn/maven.config、.bazelrc、.bzl ファイルなど）、次のクエリはそのファイル名を示す RELOAD_REQUIRED を報告します。

load_project と health_check はどちらも、buildModel の概要（ビルドシステム、構造の取得元（build-tool、static-read、convention）、分析レベル、モジュール）と、読み込み時のすべての警告を報告します。そのため、JAVA_PROJECT_PATH を通じて自動読み込みされたプロジェクトも含め、エージェントがどこを確認しても、機能が制限された状態で読み込まれたことが分かります。警告コードは次のとおりです。

コード	意味
BUILD_TOOL_UNAVAILABLE / BUILD_TOOL_FAILED / BUILD_TOOL_TIMEOUT	ビルドツールを起動できなかった、失敗した、または時間切れになりました。メッセージには最後の出力が含まれます
BUILD_MODEL_STATIC	ビルドツールがモデルなしと報告したため、ビルドファイルを静的に読み取りました。メッセージには把握できない内容が示されます
MODULE_NOT_LOADED	宣言されたモジュールまたはサブプロジェクトが読み込まれませんでした（ディレクトリが存在しない、パスが無効）
MODULE_LAYOUT_ASSUMED	モジュールのソースルートを一般的なレイアウトに基づいて推定しました
INCLUDED_OUTSIDE_BUILD	ビルドで宣言されていない一般的なソースフォルダー、非アクティブな Maven プロファイルのモジュール、または Maven ビルドと同じ場所にある Gradle プロジェクトがリンクされたままになります
COMPILED_OUTPUT_INCLUDED	モジュールのコンパイル済み出力にソースのないクラスが含まれており、クラスパスに残ります
COMPLIANCE_LEVEL_MIXED / COMPLIANCE_LEVEL_UNKNOWN / COMPLIANCE_LEVEL_UNSUPPORTED	モジュールごとに異なるレベルが宣言されている、レベルが宣言されていない、または JDT の対応範囲外のレベルが宣言されています
APT_PROCESSOR_JARS_MISSING	宣言されたアノテーションプロセッサーの JAR が見つかりません
BAZEL_NOT_BUILT	クラスパスに必要な Bazel の出力がまだビルドされていません
INDEX_INCOMPLETE / LIBRARY_INDEX_INCOMPLETE	修復後も、JDT の検索インデックスにソースファイルまたはライブラリが不足しています。インデックスに依存するツールの応答には、不足が続く間、それらの名前が示されます
JRE_REGISTRATION_FAILED	JDT に JDK を登録できませんでした
EARLIER_PROJECT_KEPT	以前の読み込みで作成されたワークスペースプロジェクトを削除できませんでした
TIMEOUT_SECONDS_INVALID	JAVALENS_TIMEOUT_SECONDS が範囲外であるか、数値ではありません

Configuration

環境変数	説明	デフォルト
JAVA_PROJECT_PATH	起動時にプロジェクトを自動的に読み込みます	（なし）
JAVALENS_TIMEOUT_SECONDS	各ツール呼び出しの制限時間です。5～300 の整数（範囲外の値は上限または下限に丸められ、その他の値は無視されます。いずれの場合も読み込み時に TIMEOUT_SECONDS_INVALID 警告が表示されます）。制限時間を超えた呼び出しは TIMEOUT を返します。load_project と health_check は制限されません	（なし：制限なし）
JAVALENS_DISK_SYNC	strict（すべての回答をディスクと照合）または manual（編集後にエージェントが load_project を呼び出す）	strict
JAVALENS_LOG_LEVEL	TRACE/DEBUG/INFO/WARN/ERROR（大文字・小文字を区別しません）。ログは stderr に出力され、stdout には JSON-RPC のみが出力されます	INFO
JAVA_TOOL_OPTIONS	JVM オプション。大規模なプロジェクトでは -Xmx2g などを指定します	（デフォルト：eclipse.ini により 512m）
JAVALENS_LOMBOK_JAR	起動時に読み込む Lombok エージェント JAR のパスです。バンドルされている JAR より優先されます	（バンドル版）
JAVALENS_MAVEN_ARGS	モデルを読み込む Maven 実行に追加する引数です。例：-Pextras -Dskip.x=true（シェルの単語と同様に分割されます）	（なし）
JAVALENS_GRADLE_ARGS	モデルを読み込む Gradle 実行に追加する引数です。例：-Penv=ci	（なし）
JAVALENS_BAZEL_ARGS	bazel aquery および bazel info に追加するビルドフラグです。例：--config=ci	（なし）

ソースからのビルド

git clone https://github.com/pzalutski-pixel/javalens-mcp.git
cd javalens-mcp
./mvnw clean verify

ディストリビューションは org.javalens.product/target/products/ に出力されます。

ビルド要件

• Java 21 以降（サーバーのランタイム）
• Maven 3.9 以降（ラッパーは ./mvnw として同梱）

テストスイート全体（実際の Maven、Gradle、Bazel ビルドに対するエンドツーエンドテストを含む）を実行するには、対応するツールも PATH に含まれている必要があります。

• Maven（ラッパーから提供）
• Gradle 8 以降
• Bazel 9 以降（または bazelisk）

開発者のマシンにツールがない場合、テストは問題なくスキップされます。JAVALENS_TESTS_REQUIRE_TOOLS=true を設定すると、この判定を切り替えられます。ツールがない場合、スキップではなく失敗になります。CI ではこのフラグを設定しており、プロビジョニングの不足がテストスイートを暗黙に弱めるのではなく、実際の失敗として検出されます。

テスト

# Full suite, gentle (missing tools skip)
./mvnw verify

# Full suite, strict (missing tools fail; what CI does)
JAVALENS_TESTS_REQUIRE_TOOLS=true ./mvnw verify

ビルドシステムのテストは、バグごとに焦点を絞ったテストと、実際の使用環境に即したエンドツーエンドテストで構成されています。エンドツーエンドテストでは、各ビルドシステムにつき代表的なプロジェクトを1つ読み込み、複数モジュールの Maven と Lombok APT、モジュール間参照、アノテーションプロセッサーを使用する複数プロジェクトの Gradle、ターゲット間依存関係を持つ複数ターゲットの Bazel など、すべての修正を一度に検証します。CI では Linux と macOS で実行します。Windows の改行コードについては、テストで CRLF ファイルを明示的に作成して検証します。

アーキテクチャ

flowchart TD
    Client["<b>MCP Client</b>"]
    MCP["<b>org.javalens.mcp</b><br/>McpProtocolHandler → ToolRegistry → 75 Tools"]
    Core["<b>org.javalens.core</b><br/>JdtServiceImpl → WorkspaceManager, SearchService"]
    JDT["<b>Eclipse JDT Core</b> (via OSGi / Equinox)<br/>IWorkspace, IJavaProject, SearchEngine, ASTParser"]

    Client -->|"JSON-RPC over stdio"| MCP
    MCP --> Core
    Core --> JDT

ライセンス

MIT License の詳細については、LICENSE を参照してください。