> On 16 Dec 2024, at 10:12, Andrew Dinn <ad...@redhat.com> wrote: > > 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.
I don’t think that's the case. 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. And so, nearly all libraries don’t need to care, and even those handful that do (and they are important, but not numerous) don’t impose a requirement on other libraries used in the application. > > 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'. 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. Every feature is used directly by more or less code depending on whether or not that code can enjoy its benefits. For now, most Java programs are content with enjoying the maintainability, security, and soon performance (once integrity by default is complete) that modules offer indirectly. Once we add further benefits to the feature, I would expect more code would want them and would directly use the feature. This would happen organically. We have no need or desire to force a feature on users. After all, we work to serve them, not the other way around. One pain point in the case of complex containers has been the need to support being itself put on either the classpath or the module path because of JDK 8. This is now gone. As DL now explains, a similar strain is put on containers now because of build tool limitations. It is not a problem with the modules feature itself, but it is something we’ll need to address. We’re working on it. — Ron
