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

[David Lloyd]

On Fri, Dec 13, 2024 at 6:20 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

>
>
> > On 13 Dec 2024, at 23:57, David Lloyd <david.lloyd at redhat.com> wrote:
> >
> > 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.
>
> 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?
>

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.

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.


> > The problem is the run time behavioral differences.
>
> 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.
>

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.

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