Resolve the class hierarchy through the defining loader at load time (release 0.1.1) - #15
Merged
Merged
Conversation
… release 0.1.1 On the load-time path the class hierarchy was resolved through the system class loader for both stack-map generation and verification, so a weave into a class whose method frames merge the application's own types was rejected -- dropped silently under verification=report, or reported as AW4001 / a Class-File API "Could not resolve class" under verification=strict. The defining ClassLoader is now threaded from the agent through the injection (WeavingPipeline), merge (StructuralWeaver) and verification (Verifier) steps, all of which build through FrameSupport.forLoadTime(loader). The prior no-loader signatures are kept as overloads for the build-time and test callers. Also bump the version to 0.1.1 across the release-tracked files (CHANGELOG, Writerside) and the IDE plugin per RELEASING.md, plus the agent startup banner and the built-in plugin id, and update the version assertions in the tests. Signed-off-by: Erik Pförtner <splatcrafter@splatgames.de> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CqYo6SHBSt77q8Kgy2ynZ8
The IntelliJ plugin build resolves aether-weaver-api and -engine as ordinary dependencies and bundles them, so pinning them to 0.1.1 before that version is published fails to resolve (the reactor still builds 0.2.0-SNAPSHOT). Per RELEASING.md step 6 the IDE version is bumped and the plugin built after Central serves the release, not in the release PR. Signed-off-by: Erik Pförtner <splatcrafter@splatgames.de> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CqYo6SHBSt77q8Kgy2ynZ8
The release commit's version bump is not the four files the workflow reads alone: the agent's WeaverAgent.VERSION and CorePlugin's built-in plugin id must move with them or the gate fails, and the three IDE-plugin versions must NOT — the IntelliJ plugin CI check resolves the published api/engine, so bumping them before the release is on Central fails to resolve. Move the IDE bump to step 6. Signed-off-by: Erik Pförtner <splatcrafter@splatgames.de> Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CqYo6SHBSt77q8Kgy2ynZ8
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #14.
The fix
On the load-time path the class hierarchy was resolved through the system class loader for both
stack-map generation and verification, so a weave into a class whose method frames merge the
application's own types was rejected:
verification=report(the class loads unwoven), orCould not resolve class …underverification=strict.The defining
ClassLoaderis now threaded from the agent (WeavingTransformer.transform) throughWeaver.weave(…)into the injection (WeavingPipeline), merge (StructuralWeaver) and verification(
Verifier) steps, all of which build throughFrameSupport.forLoadTime(loader)instead of a plainClassFile.of().FrameSupport.forLoadTime(ClassLoader)already existed but had no callers on theload-time path. The prior no-loader signatures are kept as overloads for the build-time and test
callers, so behaviour there is unchanged; build-time and load-time output stay byte-identical.
Release 0.1.1
Per
RELEASING.md, this also bumps the version to0.1.1:CHANGELOG.md,Writerside/writerside.cfg,Writerside/v.list,Weaver.VERSION;build.gradle.kts,gradle.properties,sample/pom.xml);RELEASING.md— the agent's ownWeaverAgent.VERSION(its startupbanner) and the built-in plugin id in
CorePlugin. The version assertions inExplainReportTest,WeaverAgentEndToEndTestandWeaveMojoTestare updated to match.Verification
mvn -B -o verifypasses forapi,engine,runtimeandagent. Themaven-plugin,testkitand
testsmodules were not run to completion locally (their forked-JVM integration tests are slow);they are untouched by the code change and carry only the single
WeaveMojoTestversion-stringupdate. Please let CI run the full gate.
The tag (
v0.1.1) that triggers the immutable Central publish is intentionally left to you.🤖 Generated with Claude Code
https://claude.ai/code/session_01CqYo6SHBSt77q8Kgy2ynZ8