Six Java accessors raise NotImplementedError while the graph already carries their data

[rahlk]

Problem

Six Java accessors raise NotImplementedError, and the graph already carries everything they need. They were deferred out of leg 3 by the spec's §4 erratum and pinned in tests/analysis/java/test_java_public_surface.py::RAISING so the gap is recorded rather than silent — but nothing upstream is blocking them.

Measured on the leg-3 reference graph (daytrader8 + thingsboard, codeanalyzer-java 3.0.3):

accessor	data it needs	present
get_imports	J_IMPORTS	42,231 edges
get_variables	J_DECLARES_VAR	30,667 edges
get_class_hierarchy	J_EXTENDS / J_IMPLEMENTS	1,197 / 959 edges
get_methods_with_annotations	J_ANNOTATED_BY	26,162 edges
get_call_targets	the call graph	present
get_calling_lines	the call graph	present; the SDK already computes these absolute file lines

Python answers all six. This is the largest remaining behavioural gap between the Java facade and Python's, and it needs no analyzer release.

Scope boundary

In scope: those six, on both backends, and removing them from the RAISING record.

Out of scope: the three Java accessors that genuinely need a codeanalyzer-java release (config readers, entrypoint coverage, comment nodes over Neo4j) and CRUD (codeanalyzer-java#187). remove_all_comments is half in and half out — the in-process payload carries comments, the projection carries none — so treat it separately.

Goals

• Each of the six answers on JCodeanalyzer and JNeo4jBackend, identically, including on miss paths
• Each keeps Python's signature and return type exactly — the Iron Rule holds
• RAISING shrinks by six, and the public-surface test still pins what remains
• Every new Cypher statement passes the per-variable scope audit

Caveats and known risks

• get_calling_lines is absolute file lines on both backends. Leg 3a deliberately made these agree rather than shift by a declaration prefix; do not reintroduce the shift.
• get_class_hierarchy returns a graph. Python's shape is the contract, not whatever is convenient to build from J_EXTENDS/J_IMPLEMENTS.
• Java's imports are aggregated per import target in the projection, so file-level import order is not recoverable. Assert the set, and say so.
• Six accessors is enough to be worth splitting across more than one PR. Tracking granularity follows PR granularity — split this if it does.

Definition of done

• A reviewer can point at the assertion, per accessor, showing both backends give the same answer, and RAISING names only accessors that are genuinely blocked upstream.

[rahlk]

Correcting the framing in the issue body before acting on it. "Python answers all six" is false.

Measured:

accessor	Python	TypeScript	Java (frozen v1 signature)
get_imports	() -> Dict[str, List]	() -> Dict[str, List[TSImport]]	() -> List[str]
get_variables	absent	() -> Dict[str, List[TSVariableDeclaration]]	(**kwargs) -> Dict
get_class_hierarchy	absent	() -> nx.DiGraph	() -> nx.DiGraph
get_methods_with_annotations	absent	absent	(annotations: List[str]) -> Dict[str, List[Dict]]
get_call_targets	absent	(source_signature: str) -> Set[str]	(declared_methods: dict) -> Set[str]
get_calling_lines	absent	(target_signature: str) -> List[int]	(target_method_name: str) -> List[int]

So five of the six do not exist on Python at all, and the one that does returns a different type there. These are Java v1 legacy accessors carried forward on the facade, not Python-parity accessors — I mis-stated that.

What actually changes:

• The contract is Java's own frozen v1 signature, not Python's. The Iron Rule applies to what is already published on the Java facade: get_call_targets takes declared_methods: dict, get_calling_lines takes target_method_name: str, and get_imports returns List[str]. None of those may move, even where TypeScript spells the same idea differently.
• TypeScript is the prior art, having five of the six. Use its implementations as the model where the semantics line up, but do not import its signatures.
• get_methods_with_annotations has no sibling implementation in either language. It is the one that needs designing rather than porting.

Everything else in the issue stands: the data is present on the graph, and no analyzer release blocks any of the six.