[External] : Re: Inconsistency with service loading by layer or by class loader

[David Lloyd]

On Mon, Dec 16, 2024 at 9:21 AM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 16 Dec 2024, at 10:12, Andrew Dinn <adinn at 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.
>

Speaking as somebody who is doing this work right now, this is a frankly
bizarre response. This is in fact the case. A module only can be said to
"work" on the module path if it, and its dependencies, are all written to
work on the module path and are tested on the module path. Likewise for the
class path. 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.


> > 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.
>

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.

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).

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jigsaw-dev/attachments/20241216/52e28bdc/attachment.htm>