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).

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.

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.

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.