<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Dec 16, 2024 at 9:05 AM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On 16 Dec 2024, at 14:01, David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>> wrote:<br>
> <br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 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.<br>
<br>
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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 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).<br>
<br>
But a script contains -p just as easily as it does -cp. Anyway, we’re getting back to the build tool problem.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It doesn't matter what the launcher script does, it matters what the class loader does.</div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> 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.<br>
<br>
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.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>