<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 Sun, Dec 15, 2024 at 8:55 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 14 Dec 2024, at 17:10, David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>> wrote:<br>
> <br>
> <br>
> For modules, we face the same issue. I can, for example, create a single application layer with a thousand modules in it. Before the application can start, every JAR has to be opened and every module has to be loaded, which entails parsing or dynamically creating descriptors (generally a combination of these things), each with dozens of support objects for things like dependencies, exports, and services, and then their internal graphs have to be resolved and wired and checked for consistency. So there is a significant performance cost there. But, that is not the only problem. A user application is often a combination of many modules in addition to our own basic modules, plus a significant amount of generated code. The resultant module graph might even have internal consistency problems (for example, having multiple versions of a module, or cyclical dependencies) that can't realistically be resolved socially because many of these modules are going to be from third parties that we may or may not have any control over, and might even be dependencies brought in by the user which we know nothing about. These graphs could be the result of very complex resolution of Maven artifacts for example.<br>
<br>
I’m having a hard time understanding the scenario described here, especially when it comes to who loads what and how, and what goes into named or unnamed modules (as it’s not an all-or-nothing proposition).<br>
<br>
Is it the case that by “application” you mean JBoss, hereinafter called “the container”, and by “user application” you mean some web application deployed intto the container?</blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">No, the "single application layer" is for illustrative purposes to explain the cost of having such a large layer.</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">
Does the container load the user application as a service provider?</blockquote><div><br></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><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Does the user application also use its own ServiceLoader with classloader isolation in addition to that employed by the container itself?</blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It might. But to illustrate the point, it is sufficient to narrow the focus to just ServiceLoader usage within a third-party library.</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">If a user application is a single unit constructed by Maven, how can there be version conflicts *within that unit*, and if there are any, how is the author of that unit — the user application — expected to deal with them?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Because, among other reasons, a user application being built for deployment will typically include "provided" APIs which in turn have implementations and dependency graphs which are not expressed within their individual project build. The application has a local view which ends at the encapsulation boundary of these libraries.</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">
In the (common) case where the user application isn’t itself modular (and possibly contains circular dependencies within its JARs), can’t the container load the user application into the unnamed module of some module layer that the container creates? Why would the user application itself need to be broken up into layers?<br></blockquote><div><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">By our historical (pre-Java 9) definition, every application is modular. We have never had a problem loading application JARs into isolated class loaders that are linked together, even if there are circular dependencies. The problem arises when we want the JDK to recognize these modules as being JPMS modules.</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">Historically, I agree that there were not many reasons to do so. Doing so amounted to two key benefits: encapsulation (essentially, blocking reflection or hiding packages at module boundaries), and fancy stack traces. We achieved parity for stack traces using named class loaders. Blocking reflection has never been a priority for us, and we can adequately hide packages by preventing them from being accessed at a class loader boundary.</div></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">But things are changing. Native access is now being authorized by Module, Unsafe is being deprecated, and it's not hard to imagine a world where modular libraries begin to have other privileges not afforded to the classical class path world. So it is becoming more important to find ways to bridge the gap for third-party libraries and for classical containers.</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">You are right that we don't really have to bother with this. We could in fact use what influence we have to push users and library authors away from modularity, citing its limited benefit and these and other practical concerns (which are far more significant to most users than any subjective principles), instead of doing the bulk of the heavy lifting in terms of trying to bring them on board as we are today. The resultant continued bifurcation of the ecosystem would surely cause pressure that could hinder progress for things like jlink and other future module-oriented technologies. Module-only APIs would continue to be unused by popular libraries and frameworks. But, I'd still get a paycheck, and our users will be happy enough with the results; we can after all resort to such measures as `--add-opens` for `java.base` in our launcher and essentially do whatever we need to in that way.</div></div><span class="gmail_signature_prefix"><div><span class="gmail_signature_prefix"><br></span></div><div><span class="gmail_signature_prefix"><span style="font-family:arial,helvetica,sans-serif"><span class="gmail_default" style="font-family:arial,helvetica,sans-serif">But instead, we're trying to find ways to modernize the ecosystem and draw within the lines.</span> Andrew rightly described this as a "rear guard action"<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> rather than a vote of confidence</span>. The JPMS is not what we ever wanted it to be<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">. Our concerns with this system and its principles have been largely dismissed since its inception. But with a couple accommodations, it could be close enough for our purposes and we can find a way forward.</span></span></span></div><div><span class="gmail_signature_prefix"><br></span></div>I<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> hope we can close this meta-debate to get back to the problem at hand.</span></span><div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div></div>