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
