Uh oh!
There was an error while loading. Please reload this page.
Report the running Jawk version to JSR 223 hosts - #600
Conversation
JawkScriptEngineFactory.getEngineVersion() answered with the literal "3.3.06-SNAPSHOT", frozen at the 3.x line and carried through the move to io.jawk, so every JSR 223 host — and getParameter(ENGINE_VERSION) with it — was told it ran a Jawk that had stopped shipping eleven releases ago. Cli already resolved the real version for -V/--version. Lift that lookup into io.jawk.util.JawkVersion, the single source both callers now read, so the two reports cannot drift apart again; a test pins the CLI report and the engine version to each other. getLanguageVersion() returned "1", which corresponds to no AWK specification. It now reports POSIX, naming the language Jawk actually implements. Fixes#598Fixes#599 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit:c86f8ea84e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| */ | ||
| private static String resolveVersion() { | ||
| Package myPackage = JawkVersion.class.getPackage(); | ||
| String version = myPackage != null ? myPackage.getImplementationVersion() : null; |
There was a problem hiding this comment.
When Jawk is embedded in a shaded/fat application JAR whose main manifest defines the host application's Implementation-Version, Java exposes that value through every package, including io.jawk.util. This branch therefore reports the host application's version and never reaches Jawk's still-correct pom.properties, causing JSR 223 version checks and jawk -V to identify Jawk incorrectly. Resolve the Jawk-owned Maven descriptor first, or otherwise verify that the manifest metadata belongs to the Jawk artifact.
Useful? React with 👍 / 👎.
Package.getImplementationVersion() serves the main attributes of whichever jar encloses the classes, so a Jawk shaded into an application uber-jar reported that application's version: verified at 4.1.0-HOST for io.jawk.util inside a host jar carrying Jawk's classes and descriptor. The Maven pom.properties resource names the artifact it belongs to, so it can only be Jawk's. Resolve it first and keep the manifest as the fallback for jars repackaged without META-INF/maven. Jawk's own jars carry both and they agree, so their reports are unchanged. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bertysentry
commented
Aug 20, 2026
Good catch — that one was real, and it was latent in Verified the premise by shading Jawk's classes and its The package really does serve the host's value, so manifest-first reported the application's version. The Maven descriptor names the artifact it belongs to, so it can only be Jawk's — it now decides, with the manifest kept as the fallback for jars repackaged without Pinned the precedence in @codex please review again |
Codex Review: Didn't find any major issues. Breezy! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
Uh oh!
There was an error while loading. Please reload this page.
Fixes#598
Fixes#599
Two issues, one bug:
JawkScriptEngineFactory.getEngineVersion()answered with the literal"3.3.06-SNAPSHOT", frozen at the 3.x line and carried through the move toio.jawk. Every JSR 223 host — andgetParameter(ScriptEngine.ENGINE_VERSION)with it — was told it ran a Jawk that had stopped shipping eleven releases ago, four of them major.One source of truth
Clialready resolved the real version for-V/--version(#590): manifestImplementation-Versionfirst, the Mavenpom.propertiesresource as the fallback,unknownwhen Jawk runs from a plain class directory. That lookup wasprivate staticinCli, so the factory could not reach it.This lifts it into
io.jawk.util.JawkVersion, resolved once and read by both callers. A second hard-coded copy is what went stale in the first place, soCliOptionTestnow pins the two reports to each other:JawkVersion.getVersion()is public because embedders that do not go through JSR 223 want the same value for their own logs; it is documented injava-advanced.md.Language version
getLanguageVersion()returned"1", which corresponds to no AWK specification. It now reportsPOSIX, naming the language Jawk implements. A revision number would only invite the same staleness the engine version just had, so the value is deliberately the spec name rather than an edition.Verified against the built jars
Probing the engine exactly as java-advanced.md documents it, against
jawk-7.2.00-SNAPSHOT-standalone.jar:The engine version now matches the jar it was loaded from, and matches
jawk --version. The plain jar reports the same; a class-directory run reportsunknown, as documented.Checks
mvn clean verify site: 880 unit tests pass, 0 checkstyle / 0 PMD / 0 SpotBugs findings, no Javadoc warnings. Compatibility (failsafe) results are unchanged — nothing here touches AWK semantics.🤖 Generated with Claude Code