Java extensibility and JPMS (ServiceLoader)

[Alex Buckley]

On 1/19/2024 5:02 AM, Tomas Langer wrote:
> Helidon currently has around 300 modules with module-info.java. In 
> general, this has improved our module structure and design.
> Yet, we are now encountering some major issues related to extensibility.
>   I will put down a few points that are problematic, and explain each in 
> detail further in the e-mail (it is quite long, sorry about that).
> 
> 1. provider implementations cannot be code generated without major problems

Annotation processing is designed to avoid mutating the elements, so it 
would be a fundamental change to allow mutation of module elements in 
the annotation processing API. It's on the framework to post-process 
module-info.class so it has `provides` clauses. The framework can use 
the ClassFile API to do this.

It's not "weird" for a framework to modify module-info.class to ensure 
that code in the module has the right execution environment. Another 
example would be a tool that injects calls to a logging API into user 
code, then has to post-process module-info.class to add `requires 
logging.lib;`.

> 2. the provider interface module MUST be on module path, even if it 
> could have `requires static`

Relaxing module resolution to allow a module to `provides` an interface 
that it can't access is do-able, but the implications are unknown. It 
would be unfortunate if resolution succeeded but then unforeseen 
exceptions occur when faraway code tries to access the missing 
interface. We'll leave JDK-8299504 open for now, but we would need 
evidence that a large number of users are finding the current rules 
unworkable before actively looking at `provides` again.

> 3. the provider implementation must be public with public constructor
> 4. duality of definition between module path and class path

These requests for ServiceLoader to (i) support package-private 
providers and (ii) inspect module-info.class files for `provides` 
clauses in JARs on the classpath both stem from insisting that modular 
JARs can be deployed on the classpath without losing functionality. This 
is a net-new requirement on the module system. It's relatively low risk, 
but also low reward, so we aren't going to investigate it further.

Alex