[External] : Re: provides and requires static ... runtime error

[Gregg Wonderly]

> On Apr 23, 2023, at 3:46 AM, Ron Pressler <ron.pressler at oracle.com> wrote:
>> On 22 Apr 2023, at 23:05, Rob Bygrave <robin.bygrave at gmail.com> wrote
>> 
>>> Ron: I’m guessing that what’s bothering you isn’t so much the number of *modules* but the number of JARs. So I think a more general solution than adding a way to describe “this service is conditional on the presence of X” would be to allow multiple modules in a single JAR that would contain both Y and the X-Y-plugin. 
>> 
>> How would this solve the issue? I can't see how having a second module on the same jar/artifact would work for this case. 
> 
> See Josiah’s email and my response to him.
> 
>> 
>> Bearing in mind this library needs to support both classpath and module-path. 
> 
> Since we don’t yet have multi-module JARs, the question of how it would be used on the classpath is TBD. However, one possible approach is to treat a multi-module JAR on the classpath as if each module was in its own JAR, and all of them were placed on the classpath.

It seems “bad” to somehow impose an order by taking a “package” (jar) and turning it into a list (classpath).  Again, I really think that order of reference and use should be explicit.  If there is manifest data describing an ordering that is explicit there, that might work, but we still have the problem that if I need a different ordering to use a service or other interface implementation as an override of what the multi-module jar contains, we need to control that somehow very explicitly.  Stacking so many “orderings” to implicit details will be more problematic than a simplifying detail it seems to me.

Gregg Wonderly