Overriding requirements of 3rd party modules

[Alan Bateman]

On 03/05/2016 13:46, Gunnar Morling wrote:
> Hi,
>
> While looking into Jigsaw-enabling some existing code, I came across the
> following use case for which I'm seeking advice on how to deal with.
>
> Consider a 3rd party library that contains JPA entities. Application
> developers will include that library into their app and work with its
> entities as part of their model. The library author doesn't know which JPA
> provider will be used (Hibernate, EclipseLink etc.), so the library should
> work with any compatible provider.
>
> Now the different providers all have their own JPA API Jar. Thus in the
> module-info.java of the library, there'd be a "requires" clause to one of
> the API Jars (e.g. "hibernate-jpa-2.1-api") for compiling and testing the
> library.
>
> But users of the lib might want to use *another* JPA provider and hence
>   API Jar for their app. What's Jigsaw's approach for letting the user deal
> with that? I.e. how could the user override the requirement of the lib in
> order to work with the provider of their choice?
>
> I vaguely remember a concept of "module aliases" in earlier drafts which
> might have been used for that (for instance, all the different API Jars
> could act as "jpa-2.1"), but I cannot seem to find that in the current docs
> anymore.
>
The early exploration phase did have some support for aliasing 
(`provides jpa` for example). This is not in the current design.

An alternative is to use services of course, say where there is one API 
module and a service provider interface to allow the implementation be 
plugged in. The current design (with `uses` and `provides`) leads itself 
very well to this type of loose coupling. We have many examples in Java 
SE and the JDK. Sorry I don't know JPA too well to know whether this 
applies or not but I do see a javax.persistence.spi package that looks 
like it supporting plugging in alterative implementations.

-Alan