<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:21 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 10:12, Andrew Dinn <<a href="mailto:adinn@redhat.com" target="_blank">adinn@redhat.com</a>> wrote:<br>
> <br>
> That's because most libraries are going to need to rely on at least one other library, maybe several,-- probably written by a third party,-- those libraries likely depend on other libraries, and so on. Making the new library 'work  on the module path' requires making the full closure 'work' i.e. for almost all (non-leaf) library developers requires large-scale, co-ordinated changes by multiple developers who usually do not even know of each others existence. As a further complication, many libraries in the chain, especially leaf libraries, will be in maintenance mode and no one will be interested in performing even the most minor refactoring.<br>
<br>
I don’t think that's the case.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
First, nearly all libraries — which is every library that isn’t a complex container framework employing multiple layers in a ServiceLoader — work well on both the classpath and the module path. It is only complex container that need to require module path only (or classpath only). Second, even for these complex container, there is no need for the “transitive closure” to be on the module path, only the service providers.<br></blockquote><div><br></div><div><span style="font-family:arial,helvetica,sans-serif">Speaking as somebody who is doing this work right now, this is a frankly bizarre response. <span class="gmail_default" style="font-family:arial,helvetica,sans-serif"></span>T<span class="gmail_default" style="font-family:arial,helvetica,sans-serif">his</span> is in fact the case. A module only can be said to "work" on the module path if it, and its dependencies, are all <span class="gmail_default" style="font-family:arial,helvetica,sans-serif">written</span> to work on the module path and are tested on the module path. Likewise for the class path.<span class="gmail_default" style="font-family:arial,helvetica,sans-serif"> It doesn't matter if the Java code itself is largely unchanged to make this happen, there is still at least a bare minimum of real-world work that must be done to modularize a library. In many cases, this is as simple as adding modular test executions to the Maven build and a preferred reversed-domain-name-style automatic module name (as the automatic name is rarely desired). But it is never zero.</span></span><br class="gmail-Apple-interchange-newline"></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">> I suspect David believes that the platform is moving towards privileging modular libraries and, in doing so, in equal measure de-privileging non-modular libraries, making it hard or, even, impossible for them to continue to function in upcoming JDK releases. He appears, as a consequence, to be investigating the use of module layers to automate deploying classpath jars so they can operate as modules with their attendant privileges and, in doing so, employ the other libraries they depend on, also operating as modules i.e. he is trying to work out how to resolve the problem that has led to modules being ignored 'almost always'.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Modules are not a chore, they’re a feature. The feature offers reliable configuration and strong encapsulation, benefits that became essential for the JDK itself. That is why modules have had a 100% uptake — every Java program relies on them and their benefits, albeit indirectly. We also offer the feature directly to those libraries and programs, and they may make use of it if they need/want its benefits.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">This is an incredible statement. Modules are, in fact, a chore. They are an extra burden compared to the status quo, which (like it or not) is for most users building things with Maven or Gradle and not caring one way or another about modules. Modularity in the JDK adds restrictions, not additional capabilities. Sure you can argue that the restrictions are a "feature" but that is a subjective interpretation. The fact is that if you want modules, you do have to do some extra work, and you have to deal with additional rules that did not previously exist. There is simply no logical way around that conclusion.</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">And saying that modules have 100% uptake because the JDK is modularized is beyond disingenuous. This isn't a religious or political argument. You're not going to convince me that our users don't exist, or that I can't believe my own experiences that users are not using modules much (especially in framework applications).</div></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><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>