Resolve packages through realm imports and parent

[slachiewicz]

Fixes #126. Package.getPackage(name) resolves through the caller's class loader, and ClassRealm inherited ClassLoader.getPackage, which never consults imports or the parent realm, so JEXL's import pragma dropped imported packages.

getPackage and getPackages now apply the same routing as loadClass: own class path and base loader, then any import that would load a class in the package, whether a package import or a single-class import, then the parent where parent imports allow it. A package is visible exactly where a class in it would load, so a FilteredClassRealm exposes no package its filter hides. Import or parent cycles return null instead of recursing.

Verified: ClassRealmPackageTest fails on master (expected: <package a> but was: <null>) and passes on JDK 8, 21 and 27.

[Copilot]

Copilot review overview

🟡 Changes recommended

Synthetic package class names produce incorrect results for exact class imports.

Review effort: Balanced
Findings: 2 · 1

Open (3)

• getPackage routes through a fabricated class name · New
• getPackages omits packages visible through exact class imports · New
• Test uses reversed import targets and misses exact-import behavior · New

What changed in this PR

Adds package lookup across realm imports and parents while preventing cyclic recursion.

Changes:

• Overrides package lookup and enumeration in ClassRealm.
• Adds import, parent, filter, and cycle tests.
• Adds a realm-loaded package probe.

File	Description
ClassRealm.java	Implements realm-aware package resolution.
ClassRealmPackageTest.java	Tests package visibility scenarios.
PackageProbe.java	Invokes caller-sensitive Package APIs.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🔵 Needs a closer look

Exact imports of unnamed-package classes are not included in package lookup.

Review effort: Balanced
Findings: None

Resolved since last review (3)

• getPackages omits packages visible through exact class imports
• getPackage routes through a fabricated class name
• Test uses reversed import targets and misses exact-import behavior

Previously missed (1)

In code that hasn't changed since last review

Handle unnamed-package imports in package lookup

src/​main/​java/​org/​codehaus/​plexus/​classworlds/​realm/​ClassRealm.java:538

Exact imports of classes in the unnamed package are omitted here. For an import such as "A", lastIndexOf('.') is -1, so loadClass("A") routes to the imported loader but both getPackage("") and getPackages() ignore that loader even though a loaded default-package class has a Package named "". Treat a non-empty, dotless import as a candidate class name when packageName is empty.