You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: resolve symbols from JDK/dependency bytecode for native-image parity
The GraalVM native binary diverged from `java -jar`: empty callee
signatures/return types and missing CRUD detection. Root cause is that
in a native image `Class.forName` resolves a class but
`getDeclaredMethods()`/`getDeclaredFields()` return empty for
unregistered types, so a `ReflectionTypeSolver` silently "resolves"
every lookup while enumerating zero members.
Add `JmodTypeSolver`, a reflection-free JavaParser `TypeSolver` that
reads `.class` bytecode straight out of zip archives (the JDK's `.jmod`
files and the project's downloaded dependency jars) via a custom
`javassist.ClassPath` backed by `ZipFile`. This works identically in
the JVM and the native image. Wire it ahead of `ReflectionTypeSolver`
in all three extract paths; keep `JarTypeSolver` only as a JVM fallback
when no jmods are present.
Supporting changes:
- ScopeUtils.resolveJmodsDir() made public and honors a
CODEANALYZER_JMODS_DIR override so the packaged distribution can point
at bundled jmods instead of a host JAVA_HOME.
- VersionProvider reads the version from an embedded resource (no JAR
manifest exists at runtime in a native image).
- Declare the native-image-config dir as a nativeCompile input so edits
to reflect-/resource-config reliably trigger a rebuild.
- Regenerate targeted reflect-/resource-config.json.
Verified byte-identical native vs `java -jar` output (Anonymous-UUIDs
masked) across call-graph-test (L2), record-class-test, init-blocks-test,
plantsbywebsphere (CRUD 38=38), and daytrader8.
0 commit comments