[#91] Draft increment: Support JDKs with strong encapsulation - #184
Draft
peter-lawrey wants to merge 5 commits into
Draft
[#91] Draft increment: Support JDKs with strong encapsulation#184peter-lawrey wants to merge 5 commits into
peter-lawrey wants to merge 5 commits into
Conversation
Local addressment for the 2022-backlog PR programme (see .pr/NOTES.md). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Runtime compilation already works on JDK 17/21 without --add-opens because MyJavaFileManager bypasses setAccessible via the Unsafe 'override' field offset. This hardens the fallback: when making the delegate's internal listLocationsForModules/inferModuleName accessible throws (e.g. InaccessibleObjectException on a future JDK that removes the Unsafe path), the helper now returns a neutral default (empty module list / null) instead of failing the whole compilation. Single-class compilation against the application class path does not need module-location resolution, so the library keeps working without encapsulation flags. The Java 8 path is unchanged. invokeNamedMethodIfAvailable now takes the caller's default; the two tests that reflect it are updated to the new signature, and the missing-method test now asserts the default is returned rather than an exception thrown. Adds compilesAndLoadsClassWithoutEncapsulationFlags as a guard that runtime compile and load succeed with no --add-opens configured. Verified on JDK 21 (full suite, 45 tests green); 17/25 not available here. Refs #91 Co-Authored-By: Claude Opus 4.8 <noreply@noreply.anthropic.com>
First of the two class-definition strategies from issue #91. Adds a non-Unsafe path that defines a compiled class in a caller-supplied MethodHandles.Lookup's package and class loader via the public Lookup#defineClass(byte[]) (Java 9+): - CompilerUtils.defineClass(MethodHandles.Lookup, byte[]) -- no sun.misc.Unsafe, no setAccessible; the Lookup#defineClass method is resolved reflectively at class init so the Java 8 source root still compiles and runs (throws UnsupportedOperationException on 8, where the Unsafe path remains the fallback). - CompilerUtils.isAnchorDefineClassSupported() capability probe. - CachedCompiler.loadFromJava(MethodHandles.Lookup, String, String) opt-in end-to-end overload. The JDK enforces the anchor contract (same run-time package, PACKAGE access): a cross-package class is rejected with IllegalArgumentException rather than being force-defined, the qualitative safety difference from the raw Unsafe path. AnchorDefineClassTest proves the anchor path defines into the anchor's own loader, runs the instance, and rejects a foreign package. Full suite 48 tests green on JDK 21 (was 45). Fail-before is a compile failure: the API is new. Remaining (issue #91): the second strategy (compiler-owned child loader for arbitrary package names) and the MR-JAR split that drops the reflective lookup on 9+ while keeping the Java 8 root. Design note: needs-info-research/Java-Runtime-Compiler-91/anchor-mode.md. Refs #91 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The lookup overload reused retained compiler output, eagerly initialised generated classes, and still initialised legacy Unsafe helpers. It could also define a primary class before a same-source superclass. Scope output to each compilation, cache and serialise definitions by loader and binary name, retry unresolved batch dependencies, preserve non-initialising lookup semantics, and load the legacy definer lazily. This prevents duplicate definitions and ordering failures while providing a genuinely Unsafe-independent Java 9+ path. Refs #91.
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.
What this draft demonstrates
The remote issue is reopened. Local
7fe1f27implements the public Lookup/anchor strategy and the full suite passed 48/0.Why publish it now
This makes the local partial/design/research work for #91 reviewable without claiming that the broader issue is complete. Review can now decide whether to keep the increment, change direction, or stop the work.
Known gap
Publish as an increment; retain Java 8 and finish compiler-owned child-loader/arbitrary-package cases on JDK 17/21/25.
Review status
Draft partial — do not mark ready or close the issue until the known gap is resolved or explicitly split.
Validation
git diff --checkagainstea: passed..pr/scaffolding and local workspace paths: removed.Tracking
Related to #91. This PR deliberately does not use a closing keyword.