Skip to content

Derive JDK version in stdlib symbols from bytecode target#890

Closed
jupblb wants to merge 1 commit into
mainfrom
michal/jdk-version-bytecode
Closed

Derive JDK version in stdlib symbols from bytecode target#890
jupblb wants to merge 1 commit into
mainfrom
michal/jdk-version-bytecode

Conversation

@jupblb
Copy link
Copy Markdown
Member

@jupblb jupblb commented May 29, 2026

No description provided.

PackageTable previously baked the indexer's runtime JDK version into
every stdlib SCIP symbol (e.g. 'jdk 11 java/lang/String#'), so the
embedded version varied with whichever JVM happened to run scip-java
in CI. Source it instead from the project's bytecode target:

- JdkPackage gains fromClassfile/fromDirectory/fromJar/fromPath, all
  going through a single Files.walk traversal (jars are mounted as a
  NIO FileSystem). META-INF/versions/ entries are skipped so the result
  reflects the base bytecode target of multi-release jars.

- ScipSemanticdbOptions gets a jdkPackage field; PackageTable uses it
  in place of JdkPackage.forRuntime().

- IndexSemanticdbCommand resolves the value from any .class under a
  project-owned classes dir (the -d entry parsed from javacopts.txt,
  which Maven and Gradle emit through scip-java's wrappers), then the
  sibling 'classes/' of the targetroot's parent (sbt/Maven layout),
  falling back to JdkPackage.forRuntime() when nothing is found.

- BazelBuildTool autodetects from its output jars.

- The scip.jdk.version system-property escape hatch and the test JVM
  pin in build.sbt/SaveSnapshots are gone; snapshot tests now autodetect
  jdk 11 from the minimized fixture's classfiles under JDK 11/17/21.
@jupblb jupblb marked this pull request as draft May 29, 2026 12:11
@jupblb jupblb closed this May 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant