# Entry-Point Runtime — Java

## Signals to gather
- `argv0` equals `java` / `javaw` or resides under `*/bin/java`.
- `-jar <app.jar>` argument with the jar present in the VFS.
- Manifest metadata (`META-INF/MANIFEST.MF`) containing `Main-Class` or `Start-Class`.
- Spring Boot layout (`BOOT-INF/**`).
- Classpath form (`-cp/-classpath`) followed by a main class token.
- Presence of an embedded JRE (`lib/modules`, `jre/bin/java`).
- `JAVA_OPTS`, `JAVA_TOOL_OPTIONS`, or `JAVA_HOME` environment hints.
- `EXPOSE` ports often associated with Java servers (`8080`, `8443`).

## Implementation notes
- Expand env variables before resolving jar/class paths (supports `${VAR}`, `${VAR:-default}`).
- For classpath mode, open a subset of jars to corroborate `Main-Class`.
- Track when the app is started through shell wrappers (`exec java -jar "$APP_JAR"`); ShellFlow should already collapse these.
- Distinguish between installers (e.g., `java -version`) and actual app launches by checking for jar/class arguments.
- When multiple jars/classes are possible, prefer manifest-backed artefacts but record alternates in evidence.

## Evidence & scoring
- Reward concrete artefacts (jar exists, manifest resolved).
- Add evidence entries for each heuristic (`"MANIFEST Main-Class=com.example.Main"`, `"Spring Boot BOOT-INF detected"`).
- Penalise missing artefacts or ambiguous classpaths.
- Surface runtime-specific env/ports as supplementary clues, but keep their weight low to avoid false positives.

## Edge cases
- Launcher scripts that eventually run `java` — ensure ShellFlow surfaces the final command.
- Multi-module fat jars: only expose the main entry jar in evidence; keep supporting jars as context.
- Native image (`native-image` / GraalVM) should fall through to Go/Rust/C++ detectors when `java` binary is absent.