MethodHandles.lookup errors where publicLookup is ok

[Charles Oliver Nutter]

On Tue, Sep 2, 2025 at 12:12 PM Alan Bateman <alan.bateman at oracle.com>
wrote:

> The access check fails because org.jruby.dist does not read jdk.proxy3. If
> you invoke j.l.Module.addReads(proxyClass.getModule()) from code in
> org.jruby.dist then it will add the read edge. Can you try that?
>

This does fix the issue without resorting to `publicLookup()`. Thanks!

However... why doesn't `findVirtual()` request read access to the given
class's module before erroring? Presumably this is what the reflected call
and the `publicLookup()` logic does. Worst case, it would raise an error
because it cannot gain such access. If there's another down side to
requesting read access automatically when read access is clearly required,
I'd like to know about it... because now I have to do it manually anyway.

As regards diagnosing this then I think we need improve the
> IllegalAccessExceptions exception messages. A lot of effort went into JDK 9
> to ensure that the IAE thrown in the core reflection access spelled out the
> reason why the access check failed. Most reflection based frameworks used
> core reflection at the time. We should have put more effort into the having
> the IAE exception messages in j.l.invoke as "is not accessible" makes it
> hard to diagnose.
>

Raising an error saying it "is not accessible" is also rather misleading
when it actually **is** accessible, but I have not (or the underlying API
has not) explicitly requested that access. One of the most frustrating
aspects of JPMS is the amount of times I have to explicitly request read
access knowing it will be granted, like to silence warnings for unnnamed
module accesses.

The new patch combining `lookup()` with `addReads()` is running through CI
now, but I expect it will pass. I do wonder about the overhead of us
requesting read access every time we access a class through
`MethodHandles.Lookup`, though.

https://github.com/jruby/jruby/actions/runs/17413967057

- Charlie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20250902/3b33a6a3/attachment.htm>