Динамически реализует интерфейс в Java

У меня возникла проблема с динамической реализацией интерфейса, и я не мог понять, как этого добиться. Вот моя проблема:

Я разрабатываю приложение-плагин для 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 сделать это? Если да, то как?

Ценю любую помощь и совет!

Чтобы избежать путаницы: то, что вы называете «путем к классам», на самом деле является «полным именем» вашего интерфейса, иногда сокращаемым до FQN. Путь к классам в Java — это нечто совершенно другое и здесь не имеет значения.

Sam 17.04.2024 11:49

Спасибо за обмен знаниями. Да, это действительно вызывает некоторую путаницу в моем вопросе.

Leon kong 17.04.2024 16:29
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
Как вычислять биты и понимать побитовые операторы в Java - объяснение с примерами
В компьютерном программировании биты играют важнейшую роль в представлении и манипулировании данными на двоичном уровне. Побитовые операции...
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Поднятие тревоги для долго выполняющихся методов в Spring Boot
Приходилось ли вам сталкиваться с требованиями, в которых вас могли попросить поднять тревогу или выдать ошибку, когда метод Java занимает больше...
Полный курс Java для разработчиков веб-сайтов и приложений
Полный курс Java для разработчиков веб-сайтов и приложений
Получите сертификат Java Web и Application Developer, используя наш курс.
1
2
74
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Речь идет не о «разных путях к классам».

Дело в том, что

com.atlassian.plugin.webresource.transformer.WebResourceTransformerFactory

и

com.atlassian.webresource.spi.transformer.WebResourceTransformerFactory

это два разных интерфейса в Java. И не существует «динамического»/«отраженного» подхода, который позволил бы вам обойти это.

Вы должны понимать, что имена классов (или интерфейсов) в байт-коде Java всегда абсолютны, поэтому com.whatever.X никогда не может быть «таким же», как com.something.else.X.

Другими словами: да, это изменение, нарушающее совместимость, и «обойти» его невозможно.

Другие вопросы по теме