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

[David Lloyd]

On Mon, Dec 16, 2024 at 9:05 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 16 Dec 2024, at 14:01, David Lloyd <david.lloyd at redhat.com> wrote:
> >
> >
> > No, they don't, because the users we are talking about are generally
> using a packaging solution of some sort. They have *some* control. They
> don't have *full* control unless they're ready to break things. It's like
> saying they have full control over what native libraries the JDK is using.
> It's *technically* true. But in practice they're not going to mess with low
> level stuff like that.
>
> Ah, so that’s what I was looking for. Clearly, -p is no more low level
> than -cp. But what you’re saying is that there is something that mediates
> between the application author and the runtime configuration — let's call
> that a build tool — and that build tool knows how to output -cp but not -p,
> even though, from the design of the JDK, the two are equally easy.
>
> That is as I suspected, and the build tool problem is one we’re aware of.
> We have some ideas in mind, but they don’t concern modules’ design directly.
>

No, I think you still misunderstand. This does not have anything to do with
the build tool. The launcher is not used to build the application, and the
build tool is not used to build the launcher, at least in the general case.
The launcher is a separate thing.

> Yes, we are in fact talking about regular libraries, or at least, that's
> what I'm talking about: regular libraries which use ServiceLoader running
> within dynamic containers.
>
> According to what Alan said, a regular library that uses ServiceLoader
> that runs within a dynamic container would work just fine if the container
> uses ModuleLayers. It is only the container itself that would need to
> require being put on the module path.
>

Now, with this context, go back and re-read the beginning of the email
thread where I explain why this is not in fact true.

> The application author is not using `-cp X.jar` or `-p X.jar` because in
> most cases, the application author is either not launching with Java at all
> (i.e. they're launching a container startup script), or they're going to
> launch an uberjar or some special launcher that sets up a class loading
> environment and bootstraps the application, following the instructions
> provided by the container (today this might just be e.g. `java -jar
> startup.jar` but again, in most cases this will be wrapped up in a script
> of some sort).
>
> But a script contains -p just as easily as it does -cp. Anyway, we’re
> getting back to the build tool problem.
>

It doesn't matter what the launcher script does, it matters what the class
loader does.

> You could, and that might work in many cases, maybe even most cases. Few
> third party library authors are going to do that though, especially if
> there isn't a standard blob of code to do that for them.
>
> Very, very, few library authors would ever need to do this. We’re talking
> about, at most, one in ten thousand libraries. Only containers, really.
>

No, we're still talking only and specifically about third-party libraries
which use ServiceLoader. However this meta-debate with you is getting
nowhere, so I'm inclined to end it unless there is evidence of you trying
in good faith to understand what I'm saying, and accepting - on faith
perhaps - that this use case, based on software that has been widely
adopted within the ecosystem for over two decades, is in fact valid and
does exist, rather than constantly redefining and trivializing everything I
say.
-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241216/acd00cee/attachment.htm>