On 08/01/2025 22:09, David Lloyd wrote:
The Java module system features several ways to restrict or grant
access to various capabilities. Two of these access permissions can be
shown to be of questionable benefit but clear detriment in practice.
They are `reads` and `uses`.
Both of these permissions, if not granted, cause a run time exception
at various points. Both can be trivially self-granted without any
restriction to speak of. I have been hard-pressed to identify any
incorrect operation, error condition, or security condition which is
averted due to the presence of these permissions. However it is not
hard to identify problems that they introduce, especially in
reflection-heavy frameworks.
Core reflection assumes readability [1] so reflection based frameworks
don't need to add read edge at runtime. One of the motivations for
adding read edges at runtime (with Module::addReads) is code generated
at runtime with references to classes/methods/fields in modules that the
current module didn't read at compile-time.
Is your mail about reflection with method handles? Asking because the
access checks done when creating a method handle is the same as bytecode.
I assume your issue with `uses` is the check in ServiceLoader. I found
Mark's reply to you on this from 2016 [2].
-Alan
[1]
https://openjdk.org/projects/jigsaw/spec/issues/#ReflectionWithoutReadability
[2]
https://mail.openjdk.org/pipermail/jpms-spec-experts/2016-December/000524.html
