[External] : Re: Inconsistency with service loading by layer or by class loader

[David Lloyd]

On Thu, Dec 19, 2024 at 7:58 AM Alan Bateman <alan.bateman at oracle.com>
wrote:

> On 18/12/2024 15:09, David Lloyd wrote:
>
> :
>
> No. Since we are late-binding all modules, every module we would load
> would start with no `requires`, and we use `addReads` on the controller to
> wire in the dependencies when the module is lazily linked.
>
>
> I'm going to stop here as I think there is enough in this sentence to put
> context on where you are coming from and why some of the previous mails
> were a bit baffling.
>
> If I've compiled my code as a module then it will have declared its
> dependencs, it may use or provide services, and it might export some
> internal packages to other modules in the project.  I think your mail is
> suggesting that the module-info.class is modified, or substituted, in your
> system to not have any references to other modules. Once the module is
> reified by creating a single-module module-layer then read edges will be
> added dynamically. I assume that anything that uses APIs to examine the
> Module or ModuleDescriptor will see a module that only requires java.base.
>

Right, though many of our "modules" won't actually have `module-info` at
all, so we're essentially spinning them into automatic modules (though we
prescribe the module name in many cases where the automatic module detected
name is not good/clashes with another/etc.). IIRC this was the "concession"
approach that was recommended for this use case back in the day (it was the
outcome of some discussion or another, or maybe a call, I have notes
somewhere), though we never got it to work at the time due in part to the
services stuff.

My view is that this direction is in a completely different design space to
> that of configurations and module layers. We did build an internal API to
> support very specific "dynamic module" use-cases in the JDK, e.g. some
> Proxy scenarios required do code gen into a dynamic code, same thing with
> code generation for RMI remove refs. We decided to not expose anything at
> this level as it's essentially the all powerful Unsafe API for modules.
>

If I could ask, what makes it unsafe? It only would apply to custom layers
after all. There would be no way to crack open anything in the JDK or
arbitrary memory (for example); I see access to a Controller as being
analogous to having access to an original Lookup for my own app classes
(but not the JDK itself of course, or anything else outside of the layer).
The object itself is the permission.

Would you say that this is an inaccurate analogy?

--
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241219/af629397/attachment.htm>