docs: fix the README sample, and refresh version examples before they ship

[RefuX]

Two unrelated documentation defects, both surfaced by a pre-tag audit of 0.0.7, both worth fixing before publication rather than after.

README's first Java sample did not compile

It opens with import io.github.refux.slang.*;, and java.lang.Module is implicitly on-demand imported too, so Module module = ... is ambiguous:

error: reference to Module is ambiguous
  both class io.github.refux.slang.Module in io.github.refux.slang
  and class java.lang.Module in java.lang match

Not a regression from the Slang bump — it has been wrong since the consumer-facing README was written — but it is the first code anyone runs against this library.

Verified in both directions by extracting the block straight out of README.md and compiling it against the real 0.0.7 jar: the error above without the added import, clean with it.

Stale version examples in the published javadoc

These matter for a narrow but unforgiving reason: they ship inside slang-java-0.0.7-javadoc.jar to Maven Central, which cannot be replaced once released. A stale example is then permanently stale for this version.

	was	now
GlobalSession#buildTagString	e.g. "2026.13"	e.g. "2026.14.1"
SlangNative#spGetBuildTagString	e.g. "2026.13"	e.g. "2026.14.1"
SlangLibrary versioned-filename fallback	libslang-compiler.0.2026.13.dylib	libslang-compiler.0.2026.14.1.dylib

The two build-tag examples also stop under-representing the real tag, which is now three components rather than two — a detail that matters for anyone parsing it. The dylib name is taken from natives/manifests/macos-aarch64.json rather than invented, so it is a filename that genuinely ships.

One flagged example deliberately left alone

The audit also flagged ModuleInfo's @param compilerVersion … e.g. "2026.8". That one is correct as it stands: the field is the build tag of the release that wrote the IR, and an older writer than the running compiler is precisely the case the surrounding javadoc is describing. An example naming the current release would illustrate the wrong thing.

Verification

javac against the real jar for the README block (both with and without the fix), and :slang:javadoc builds clean. No 2026.13 remains in any hand-written source.

🤖 Generated with Claude Code

[github-actions]

Qodana for JVM

It seems all right 👌

No new problems were found according to the checks applied

💡 Qodana analysis was run in the pull request mode: only the changed files were checked

View the detailed Qodana report

To be able to view the detailed Qodana report, you can either:

• Register at Qodana Cloud and configure the action
• Use GitHub Code Scanning with Qodana
• Host Qodana report at GitHub Pages
• Inspect and use qodana.sarif.json (see the Qodana SARIF format for details)

To get *.log files or any other Qodana artifacts, run the action with upload-result option set to true,
so that the action will upload the files as the job artifacts:

      - name: 'Qodana Scan'
        uses: JetBrains/qodana-action@v2026.1.3
        with:
          upload-result: true

Contact Qodana team

Contact us at qodana-support@jetbrains.com

• Or via our issue tracker: https://jb.gg/qodana-issue
• Or share your feedback: https://jb.gg/qodana-discussions