У меня возникла проблема с динамической реализацией интерфейса, и я не мог понять, как этого добиться. Вот моя проблема:
Я разрабатываю приложение-плагин для Confluence, у меня есть класс Transformer
, который реализует тип WebResourceTransformerFactory
, взятый из публичной библиотеки Atlassian Confluence с путем к классам com.atlassian.plugin.webresource.transformer.*
.
Я хочу, чтобы мое приложение-плагин было совместимо с определенным диапазоном версий (8 -> 9) Confluence, но с изменениями последней версии Confluence тип интерфейса WebResourceTransformerFactory
переместился в новый пакет com.atlassian.webresource.spi.transformer.WebResourceTransformerFactory
, и это привело к тому, что мой плагин приложение несовместимо с новой версией Confluence.
Transformer.java
совместим со старой версией (Confluence v8)
import com.atlassian.plugin.webresource.transformer.*;
public class Transformer implements WebResourceTransformerFactory {
// Do something...
}
Transformer.java
совместим с новой версией (Confluence v9)
import com.atlassian.webresource.spi.transformer.WebResourceTransformerFactory;
public class Transformer implements WebResourceTransformerFactory {
// Do something...
}
Как вы можете видеть, WebResourceTransformerFactory
имеет разные пути к классам с разными средами выполнения (Confluence). Мне интересно, как сделать так, чтобы мой класс Transformer.java
реализовывался WebResourceTransformerFactory
динамически с разными путями к классам при работе в разных версиях Confluence. Может ли отражение Java сделать это? Если да, то как?
Ценю любую помощь и совет!
Спасибо за обмен знаниями. Да, это действительно вызывает некоторую путаницу в моем вопросе.
Речь идет не о «разных путях к классам».
Дело в том, что
com.atlassian.plugin.webresource.transformer.WebResourceTransformerFactory
и
com.atlassian.webresource.spi.transformer.WebResourceTransformerFactory
это два разных интерфейса в Java. И не существует «динамического»/«отраженного» подхода, который позволил бы вам обойти это.
Вы должны понимать, что имена классов (или интерфейсов) в байт-коде Java всегда абсолютны, поэтому com.whatever.X никогда не может быть «таким же», как com.something.else.X.
Другими словами: да, это изменение, нарушающее совместимость, и «обойти» его невозможно.
Чтобы избежать путаницы: то, что вы называете «путем к классам», на самом деле является «полным именем» вашего интерфейса, иногда сокращаемым до FQN. Путь к классам в Java — это нечто совершенно другое и здесь не имеет значения.