Summary

--emit neo4j loses import target names: single-type imports such as import java.io.IOException; are projected to a :JPackage {name: "java.io"} node (the class portion stripped), never to the imported type / full path. So J_IMPORTS edges carry only package granularity.

Environment

• codeanalyzer-java 2.4.0

Impact

On daytrader8, all 771 J_IMPORTS edges point at :JPackage nodes; 0 point at :JType — even imports of in-project types. Reconstructing JCompilationUnit.import_declarations from the graph therefore yields package paths (java.io) instead of the real import paths (java.io.IOException), and collapses multiple imports from one package to a single edge.

MATCH (:JCompilationUnit)-[:J_IMPORTS]->(p:JPackage) RETURN count(*);   // 771
MATCH (:JCompilationUnit)-[:J_IMPORTS]->(t:JType)    RETURN count(*);   // 0

Root cause

neo4j/GraphProjector.java, projectImport:

if (!im.isWildcard() && typeKeys.contains(path)) {
    b.edgeToSymbol("J_IMPORTS", cuRef, path, props);   // only when the imported FQN is one of THIS unit's own types
    return;
}
String pkg = im.isWildcard() ? path : packageOf(path);  // otherwise strip to the package

typeKeys is the importing unit's own type_declarations, so an import of any other type (project or library) never matches and is reduced to its package. The full import path is dropped (and the schema's J_IMPORTS -> JType endpoint is effectively never exercised).

Suggested fix

Preserve the full import path — e.g. store path (and is_static/is_wildcard) on the J_IMPORTS edge regardless of resolution, or materialize an external :JType ghost keyed by the imported FQN (mirroring how external call targets could be handled), so non-wildcard imports round-trip their type name.