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

[David Lloyd]

On Wed, Dec 18, 2024 at 9:09 AM David Lloyd <david.lloyd at redhat.com> wrote:

> On Wed, Dec 18, 2024 at 3:55 AM Alan Bateman <alan.bateman at oracle.com>
> wrote:
>
>> Finally, just to say that your prototype addProvides doesn't specify any
>> validation. It looks like it can be used to add any random class and
>> implementation class. If a method were to be added then it would minimally
>> need to check that the implementation class is in the module and that it
>> extends the service class.
>>
>
> The services are actually internally registered by class *name* rather
> than class object, which seems weaker than necessary (maybe to avoid a
> strong class reference?) and might allow any validation to be tricked or
> bypassed somehow: there's only an imperfect guarantee that the service and
> provider will actually be the *same* as what was registered. This seems to
> undermine any validation, though we could just do it anyway I suppose.
>

Actually after further analysis I've found that I'm incorrect about this,
in part: the module does seem to get recorded and its class loader is then
used to locate the provider. So, this validation would not realistically be
bypassable, and dropping the `Module` argument would not be useful.

That said, I would be inclined to drop the restriction that the provider
module (or class) or the server module (or class) must be located within
the layer. It would be the layer catalog which is updated, and this would
allow layers to locate services outside of their parent hierarchy, which is
basically the point of adding the API to begin with.

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