<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 10:40 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">I am very much trying to understand the points you’re raising, but the scenario of a dynamic container you’re describing is complicated, and I’m trying to get to the bottom of the issue.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Very well.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So far I’ve seen two components of concern. The container itself and some regular library that is loaded by the container and uses a ServiceLoader.<br>
<br>
Now, when Alan suggested "Have you looked at changing these frameworks to work with modules and specify a module layer to ServiceLoader.load?” you responded that “frameworks” — the container and/or the regular ServiceLoader-using library — need to work both on the module path and the classpath, which is what piqued my interest, as I’m interested in the JDK’s runtime configurations.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Yes, and furthermore, such a change is too broad to be practical. We don't have direct control over most of these frameworks.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For the sake of simplicity, let’s say that the container itself is modular and is only ever used on the module path, and put aside the question of why this should or shouldn’t be the case. We’ll focus on the “regular” ServiceLoader-using library.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Perfect.</div></div><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">
Being a regular library, it doesn’t itself construct module layers and it creates a ServiceLoader of the ClassLoader variety.<br>
<br>
Is the problem you’re describing that of the regular library not being able to find one of its service providers because that service provider would have been placed by the container in a separate module layer to that of the library itself?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Yes.</div></div><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">
If so, can you describe how that situation could arise? To prove to you that I am trying to understand your situation, here’s how I think that might happen:<br>
<br>
Say the library in question is a logging facade that relies on logging service providers, and it happens to be used by both the user application and the container. Because it is used by the container, the container will load the library, and its logging provider in some container layer. But when the library is loaded again by the user application, in some user application layer, that copy won’t find the provider in the container’s parent layer.<br>
<br>
Is that the situation you’re describing?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">No.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The model I'm working with is such that we are loading every single module (whether they are within our container or the user's application) into a separate layer, as has been previously recommended as the way to meet requirements like ours, with our class loaders handling all inter-module linkage concerns. Everything works exactly as we want in this scenario: modules are able to be lazily loaded and linked (just like classes); our integrity constraints are enforced locally per module on demand, rather than globally across the whole layer (again, just like classes); and, we get our nice stack traces and encapsulation behaviors. However there is one exception, and that is that service loading does not work for any module, since no modules can find their implementations, regardless of what we do with class loading. This is what I'm trying to address.</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">This was never a problem before we tried integrating JPMS, because outside of JPMS we can manage service dependencies as a variation on regular module dependencies due to their usage of regular resource files (I can get into the mechanics of this if you are interested but it's beside the point; suffice it to say that it has worked well to date).</div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>