javamavenjcache

As a library: How to provide default JCache implementation

Assume I write a library and want to cache the result some long running or fragile tasks. For that I use the JCache API in my code.

So my pom.xml will contain a dependency entry like

<dependency>
    <groupId>javax.cache</groupId>
    <artifactId>cache-api</artifactId>
    <version>1.1.1</version>
    <scope>provided</scope> <!-- does this even make sense? -->
</dependency>

Based on this I would now want to know how I can make the usage for the user as easy as possible?

The two options I see are both sub-optimal and I have the feeling that this must be some kind of common "problem", so there is probably a common solution I am not aware of.

  1. I provide an implementation of the JCache API myself.

    +: The user/consumer of my library can easily use it out of the box without the need to provide anything.

    -: If a custom, user specific implementation should be used it's necessary to exclude this implementation from my library on a maven level.

    -: Potential clashes between multiple libraries doing this.

  2. I don't provide any implementation the JCache API.

    +: No clashes with other libraries or any custom implementation the consumer of my library wants to use.

    -: It is necessary to provide a JCache implementation, even if the consumer is not aware that there is caching involved.

This looks very much like the logging setup, where I use slf4j-api in my application and the consumer needs to provide an implementation themselves. But logging feels a bit more common then caching to me.

Solution

  • Actually you laid out the pros and cons of the different approaches pretty well already. So I pick your two approaches and give some additional hints:

    1. I provide an implementation of the JCache API myself.

    1.1: You can use the maven shade plugin to move the JCache API and the implementation to a different package. Then you have no conflicts. The downside of it, is confusion when the (original) source code is used for debugging.

    1.2: You can keep the original JCache API and use a shaded version of an implementation. There might be conflicts with applications expecting one or "their" default implementation. You can circumvent this by not using the normal SPI mechanism for instantiation.

    1. I don't provide any implementation the JCache API.

    The caching implementations differ a lot in terms of features and configuration. I would recommend that you have at least one setup with an implementation and configuration that works OOTB. Either with a dependency to an implementation or via a bundled shaded implementation.

    If you use a maven dependency, users may exclude the caching implementation and use their own if they have a different preference or requirements.

    I would recommend to just keep things simple and start with a dependency and then see what users may want or where the problems arise. Better then making things complicated right from the start.