Как библиотека: как обеспечить реализацию JCache по умолчанию - PullRequest
Новая
       33

Как библиотека: как обеспечить реализацию JCache по умолчанию

1 голос
/ 19 сентября 2019

Предположим, я пишу библиотеку и хочу кешировать результат некоторых длительных или хрупких задач.Для этого я использую JCache API в своем коде.

Так что мой pom.xml будет содержать запись зависимости, такую ​​как 

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

На основании этого я бы хотел знать, как яМожно ли сделать использование для пользователя настолько простым, насколько это возможно?

Два варианта, которые я вижу, оба неоптимальны, и у меня есть ощущение, что это должна быть какая-то общая "проблема", поэтому, вероятно, существуетОбщее решение, о котором я не знаю.

  1. Я сам предоставляю реализацию API JCache.

    +: пользователь / потребитель моей библиотеки может легко использовать егокоробки без необходимости предоставления чего-либо.

    -: Если должна использоваться пользовательская, специфичная для пользователя реализация, необходимо исключить эту реализацию из моей библиотеки на уровне maven.

    -:При этом возможны потенциальные конфликты между несколькими библиотеками.

  2. Я не предоставляю никакой реализации JCache API.

    +: Нет конфликтов с другими библиотеками или любой другой пользовательской реализацией потребителя.из моей библиотекиrary хочет использовать.

    -: необходимо предоставить реализацию JCache, даже если потребитель не знает, что кеширование задействовано.

Это выглядит оченьочень похоже на настройку журналирования, где я использую slf4j-api в своем приложении, и потребитель должен сам обеспечить реализацию.Но логирование кажется мне более распространенным, чем кэширование.

1 Ответ

0 голосов
/ 20 сентября 2019

На самом деле вы довольно хорошо изложили плюсы и минусы различных подходов.Поэтому я выбрал два ваших подхода и дал несколько дополнительных советов:

  1. Я сам предоставляю реализацию API JCache.

1.1: Вы можетеиспользуйте плагин maven shade, чтобы переместить JCache API и реализацию в другой пакет.Тогда у вас нет конфликтов.Недостатком является путаница, когда (отладочный) исходный код используется для отладки.

1.2: Вы можете сохранить исходный API JCache и использовать затененную версию реализации.Могут быть конфликты с приложениями, ожидающими одну или «свою» реализацию по умолчанию.Вы можете обойти это, не используя обычный механизм SPI для создания экземпляров.

Я не предоставляю никакой реализации JCache API.

Реализации кэширования сильно отличаются с точки зрения возможностей и конфигурации.Я бы порекомендовал, чтобы у вас была хотя бы одна установка с реализацией и конфигурацией, которая работает OOTB.Либо с зависимостью от реализации, либо с помощью связанной затененной реализации.

Если вы используете зависимость maven, пользователи могут исключить реализацию кэширования и использовать свою собственную, если у них есть другие предпочтения или требования.

Я бы порекомендовал просто упростить ситуацию и начать с зависимости, а затем посмотреть, чего могут хотеть пользователи или где возникают проблемы.Лучше с самого начала усложнять ситуацию.

...