<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Fri, Dec 13, 2024 at 6:20 PM Ron Pressler <<a href="mailto:ron.pressler@oracle.com">ron.pressler@oracle.com</a>> wrote:</span></div></div><div class="gmail_quote gmail_quote_container"><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 13 Dec 2024, at 23:57, David Lloyd <<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>> wrote:<br>
> <br>
> if I design a library or framework to work *only* in module mode, the user might still try to use it in a non-module application container, possibly leading to (potentially subtle) breakage. If I design it only for classpath mode, then it may subtly break in module mode.<br>
<br>
If you design a library or framework to work only on the module path, why would the user insist on putting it on the classpath? And if they do so accidentally, why would you not fail immediately with a clear message rather than risk some breakage?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I'm honestly baffled by your question, because it indicates that you probably haven't really read or understood the entirety of my message, though I tend to be pretty wordy so I acknowledge that I'm at least partially to blame if that is the case. You phrase the question as if users were being rebellious against some broadly accepted natural order of things, which does not reflect any reality that I or my colleagues are aware of. But to answer the question at exactly face value: the user typically doesn't even know the difference. Many users don't ever launch an application using the `java` launcher outside of university. They're running a Quarkus application, or deploying into WildFly or Tomcat, or launching via JBang, or running in Spring Boot, or maybe running a prepackaged application, or any one of dozens of other ways that an application can be packaged and deployed. A user doesn't usually have any idea about whether the class loader which loads their classes is setting them up as a named module or just defining classes the old fashioned way.</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">It's not really feasible to expect library authors to detect whether they are going to be run as a module or not, particularly if they have many entry points, as they sometimes do. They could for example add a run time check on every entry point, or on the class initializers of every entry point class. But even if they could, they are not going to do that. Why would they? Library authors are nearly universal in that they want people to actually use their libraries. Even if they understand the implications of running in the two different environments - and in most cases they probably do not - there is nothing to be gained by cutting off users based on the environment into which their library is deployed. It's a much wiser strategy to meet users where users are.</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">> The problem is the run time behavioral differences.<br>
<br>
That would indeed be a problem if you want *every* JAR to work both on the module path and on the classpath but, as far as I know, making that easy or even possible *for every JAR* is not and has never been the goal of the platform. I'm not saying it shouldn’t be the goal, nor am I trying to dismiss the difficulty of achieving that currently (which is expected given it’s not a goal of the platform as it currently is). I’m merely trying to understand *why* that’s needed.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hopefully the messages I've sent in this thread make it abundantly clear that I'm not under any kind of impression that there can or should be no behavioral differences. I'm also not saying that it's the responsibility of the platform to make every behavior of every possible JAR work in every possible situation. What I am saying, however, is that service loading in particular is essentially broken for any practical purposes for library authors due to these differences, and also for container providers in some situations. This is a narrowly defined problem and is eminently solvable. While there are multiple ways to approach a solution, some of which I've suggested already elsewhere in this thread, I'm reasonably confident that solving this particular issue won't require any kind of broad platform-wide philosophical changes.</div></div><div><br></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>