pod
Other formats agents might prefer:
markdownjsonllms.txt

Agent? You probably want markdown or json, or Pod over MCP.

Reported issues for JavaLens

Pod holds 19 of 19 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to JavaLens.

Most discussed

Bug: get_diagnostics floods results with BUILDPATH false positives on files that compile cleanly

get_diagnostics returns hundreds of BUILDPATH-category errors on files that import from pre-Java 9 jars (e.g. org.codehaus.jackson 1.x). The file compiles with zero errors under mvn test-compile. The BUILDPATH failures cascade into synthetic IMPORT, TYPE, and MEMBER errors, making the file appear completely broken when it is not.

Minimal example

pom.xml dependency (the trigger — any pre-Java 9 jar works):

<dependency>
    <groupId>org.codehaus.jackson</groupId>
    

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/18) · 2026-05-25 · closed · external user · 32 comments

### get_diagnostics does not report any issues

### Summary

No errors reported

### Steps to reproduce

1. edit any java file, making it uncompilable: syntax error or anything else (e.g. `class` -> `clazz`)
2. call `load_project` tool to refresh indexes
3. call `get_diagnostics` tool - it returns clean state - **no errors** reported!
4. call `diagnose_and_fix` with the exact file path - **no errors** reported!
5. call `validate_syntax` with the exact file path (same as step 4) - **error confirmed**.

This is what I get:

● javalens - load

Read the thread · 2026-06-11 · closed · external user · 6 comments

javalens_analyze_method fails with PROJECT_NOT_LOADED after successful load_project call

I just installed javalens-mcp and I'm trying to call javalens_analyze_method, but I always get a PROJECT_NOT_LOADED response, even after 10 minutes. The javalens-workspaces directory is empty.

Environment

  • OS: macOS 26.3 ARM64
  • Java: OpenJDK Temurin 21.0.6 (LTS)
  • javalens-mcp: 1.2.0 (installed via zip file)

Configuration in config.toml (Mistral Vibe)

[[mcp_servers]]
name = "javalens"
transport = "stdio"
command = "java"
args = [
    "-jar",
    "/Users/

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/4) · 2026-04-17 · closed · external user · 5 comments

### find_unused_code: false positives for every private field in a generic class (reads not detected)

## Summary
  `find_unused_code` reports `private` fields of a **generic class** (any class with a type parameter) as unused even when they are clearly read inside that class's own methods. Non-generic classes are
  unaffected. The field's *own* type is irrelevant — a plain `String` field in a generic class is mis-flagged just the same.

  ## Environment
  - javalens-mcp version reported by `health_check`: **`2.0.0-SNAPSHOT`** (npm `latest` is `1.3.2`)
  - Java: 21.0.6 (Eclipse Adoptium)
  - OS: 

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/17) · 2026-05-21 · closed · external user · 4 comments

### Bug: `change_method_signature` does not update constructor call sites

`change_method_signature` returns only the constructor declaration edit. All `new ClassName(…)` call sites in other files are silently dropped, leaving the project non-compilable after the edit is applied.

A secondary issue: `newSignature` in the response renders the constructor with a spurious `void` return type (e.g. `void Widget(String name)`) which is not valid Java.

## Minimal example

**Widget.java**
```java
package com.example;

public class Widget {

    private final String name;

   

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/15) · 2026-05-10 · closed · external user · 4 comments

### Bug: `rename_symbol` returns 0 edits for a field with a custom-type

`rename_symbol` silently produces `totalEdits: 0, filesAffected: 0` when positioned on a class field whose declared type is a project-local class. The response is `success: true` with no edits applied and no error signal.

## Minimal example

These files are present in the project's `simple-maven` test fixture
(`org.javalens.core.tests/test-resources/sample-projects/simple-maven`):

**FieldHolder.java**
```java
package com.example;

public class FieldHolder {

    Animal pet;                   /

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/13) · 2026-05-10 · closed · external user · 4 comments

### Bug: `find_implementations` omits transitive implementors

`find_implementations` returns only direct implementors of a target interface. Classes that implement the interface through a sub-interface chain are silently absent from the result, with no indication that the list is truncated.

## Minimal example

**IShape.java**
```java
package com.example;
public interface IShape { void draw(); }

IFillable.java

package com.example;
public interface IFillable extends IShape { void fill(); }

Rectangle.java

package com.example

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/11) · 2026-05-10 · closed · external user · 3 comments

### Sources under nested aggregator modules are not indexed

I recently stumbled into this MCP server which I was working on creating a java based refactoring skill for claude and found this tool to be extremely useful.

Ours is a multi level multi module maven project. I found that when using this tool against my company project, it would not index the classes that are present in the nested sub modules.

## Summary

`load_project` does not index Maven modules that are themselves multi-module
aggregator POMs — i.e. modules that have `<modules>` entries bu

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/8) · 2026-05-08 · closed · external user · 3 comments

## Most recent

### zero-based vs 1-based line numbers

### Summary

`search_symbols` returns 1-based line numbers, and `find_affected_tests` also takes 1-based lines (despite the docs saying zero-based)

### Steps to reproduce

Prompt:

use find_affected_tests for class XYZ. don't grep, use search_symbols tool to discover it.


### Expected behavior

All tools use the same line numbers.

### Actual behavior

Claude Code is confused and makes many mistakes, which is resulting in a high number of additional calls.

### Minimal reproducible exam

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/31) · 2026-06-12 · closed · external user · 2 comments

### Test rigor — boundary and error-code coverage

# Test rigor — boundary and error-code coverage

## Summary
Add systematic `maxResults` boundary coverage and per-tool error-code assertions across the tool suite.

## Problem / motivation
Two cross-cutting test dimensions are not systematically covered:
- **`maxResults` boundaries** — tools with a `maxResults` parameter are mostly tested at one value; there is no systematic 0 / 1 / total / total+1 / `MAX_VALUE` coverage, and no dedicated boundary test class exists.
- **Per-tool error codes** — 

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/29) · 2026-06-06 · closed · 1 comment

### Lombok support

# Lombok support

## Summary
Attach the Lombok javaagent to the analysis runtime so JDT/ECJ surfaces Lombok-generated members.

## Problem / motivation
Lombok is ubiquitous. Without its javaagent, JDT analyzes the unprocessed source, so generated members (getters/setters/builders/constructors) are invisible — producing false "unresolved" errors and breaking rename/references/diagnostics on Lombok code. This is the same false-error class as issue #18, different cause. Raised in Discussion #6; the

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/28) · 2026-06-06 · closed · 1 comment

### Working-copy / incremental mode

# Working-copy / incremental mode

## Summary
Apply an edit in-memory and re-query without a full `load_project` reindex, using JDT working copies and `reconcile`.

## Problem / motivation
Every edit currently forces a full project reload to re-query, and stale-index correctness is pushed onto the caller. That tax sits on the agent's hottest loop (edit → verify). A working copy lets analysis run against in-memory edits without a reindex.

## Proposed approach
- Use `ICompilationUnit.becomeWorkin

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/26) · 2026-06-06 · closed · 1 comment

### New descriptor-based refactorings

# New descriptor-based refactorings

## Summary
Expose JDT-shipped refactorings not currently available — extract-superclass, pull-up/push-down member, encapsulate-field, introduce-parameter-object, move-type-to-new-file.

## Problem / motivation
The refactoring catalog covers rename / extract-* / inline / change-signature. JDT ships many more as refactoring descriptors; reusing them roughly doubles the catalog without hand-writing each transformation.

## Proposed approach
- Use JDT refactoring

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/25) · 2026-06-06 · closed · 1 comment

### Framework-semantic extractors — JPA + HTTP endpoints

# Framework-semantic extractors — JPA + HTTP endpoints

## Summary
Add extractors for JPA entities/relationships and HTTP endpoint mappings, alongside the existing Spring DI extractor.

## Problem / motivation
`get_di_registrations` surfaces Spring DI (`@Component`/`@Bean`/`@Autowired`/`@Inject`), but two other high-value framework structures are invisible: the JPA data model (entities, fields, relationships) and the HTTP surface (`@RequestMapping`/JAX-RS route → handler). An agent must otherwis

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/24) · 2026-06-06 · closed · 1 comment

### Interprocedural data / control flow (opt-in)

# Interprocedural data / control flow (opt-in)

## Summary
Extend data/control-flow analysis across method boundaries — sound nullability and simple taint (e.g. does a request parameter reach a SQL string).

## Problem / motivation
`analyze_data_flow` and `analyze_control_flow` are intra-method only. The genuinely "compiler-accurate" findings — cross-method null propagation, taint from source to sink — require following calls between methods. This is also what would make `find_possible_bugs` mor

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/23) · 2026-06-06 · closed · 1 comment

### Compound diagnose→fix (read-only)

# Compound diagnose→fix (read-only)

## Summary
A single tool that runs diagnostics, computes the available quick-fix edits, and returns the combined edits in one response — without applying them.

## Problem / motivation
The diagnose→fix loop is the tightest loop an agent runs, but today it takes three calls: `get_diagnostics`, then `get_quick_fixes`, then `apply_quick_fix`. A compound read-only aggregator collapses that to one round-trip.

## Proposed approach
- New compound tool: for a file (

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/22) · 2026-06-06 · closed · 1 comment

### `find_affected_tests(symbol)`

# `find_affected_tests(symbol)`

## Summary
Given a symbol, return the test methods that exercise it by walking callers transitively to JUnit/TestNG test methods.

## Problem / motivation
After changing a symbol, an agent needs to know which tests to run. Today it can discover tests (`find_tests`) and walk callers (call hierarchy) separately, but nothing connects the two into "what tests cover X."

## Proposed approach
- New tool: from the target symbol, walk incoming calls transitively; collect

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/21) · 2026-06-06 · closed · 1 comment

### Whole-program reachability graph

# Whole-program reachability graph

## Summary
Aggregate the per-method call hierarchy and type-dependency data into one queryable project-wide graph, enabling reachability and true dead-code questions.

## Problem / motivation
Today's graph tools answer local questions only: callers/callees of one method, dependencies of one package. There is no project-wide reachability view, so questions like "is this public method reachable from any entry point or test?" or "what is the full blast radius of 

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/20) · 2026-06-06 · closed · 1 comment

### Adopt JDT `ASTRewrite` / `ImportRewrite` for refactoring edit generation

# Adopt JDT `ASTRewrite` / `ImportRewrite` for refactoring edit generation

## Summary
Refactoring tools generate edits by building replacement text and computing source offsets. Move edit generation onto JDT's `ASTRewrite` and `ImportRewrite` so edits are produced structurally from the AST.

## Problem / motivation
Text-based edit generation must enumerate every syntactic form it may encounter — the various call-site node types, type-parameter clauses, import placement and ordering. `ASTRewrite

[Read the thread](https://github.com/pzalutski-pixel/javalens-mcp/issues/19) · 2026-06-06 · closed · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/pzalutski-pixel/javalens-mcp/issues).