Я пишу API-плагин для Java-приложения, идея которого заключается в том, что в конечном итоге третьи стороны предоставят свои собственные расширения плагинов для приложения, и все, что нужно сделать пользователю, это поместить банку плагинов в каталог плагинов приложения. Для нетерпеливых мой короткий вопрос - как справиться с возможными конфликтами версий, когда плагин связан с API, отличным от того, который используется в системе, см. Ниже подробную информацию о моей ситуации и о чем я думал.
Я прочитал несколько статей с использованием интерфейсов поставщика услуг и кое-что с этим работаю. Проблема возникает при рассмотрении того, как бороться с различными комбинациями версий.
Мне известна техника добавления при добавлении в API интерфейсов расширения вместо изменения существующего интерфейса (например, API 1.0 с MyInterface, API 1.1 с добавлением MyInterface2 с новыми методами и т. Д.). С помощью этой техники, если у пользователя самый последний API, тогда старые плагины должны работать нормально, но что будет, если у пользователя есть старый API и новые плагины?
Так, например, пользователь имеет API 1.0 только с MyInterface, но устанавливает двоичный плагин, скомпилированный с API 1.1, где класс провайдера реализует MyInterface2. Хотя приложение может вызывать плагины только с помощью MyInterface, что произойдет, если плагин внутренне вызывает MyInterface2? Вызовет ли это ошибку или исключение и когда (т.е. когда класс загружается или когда вызывается метод из MyInterface2). Также этот стандарт распространяется на JVM или может отличаться в зависимости от используемой JVM?
Наконец, будет ли лучше использовать инфраструктуру плагинов, которая сможет проверить требования к версии? В интернете я нахожу PF4J на github. Беглый взгляд на исходный код, кажется, показывает, что он может поддерживать какие-то проверки версий.