2014-12-11 3 views
14

У меня есть следующая проблема совместимости API и поиск путей ее решения.Есть ли способ «псевдонима» одного класса в Java для другого?

TL; DR Есть ли способ создать «псевдоним» для класса в Java? То есть какой-то трюк сделать com.acme.foo.SomeEnum, чтобы быть псевдонимом для com.acme.bar.SomeEnum?

Длинная история. (Я немного анонимный, чтобы избежать fingerpointing.)

Я работаю с мощным инструментом Java, который также поддерживает плагины. Нет строго определенного public API (в смысле того, что вы можете и не можете коснуться), просто обычные частные/защищенные/пакетные/общедоступные классы, методы и поля. Существуют определенные точки расширения (например, расширяйте класс com.acme.plugin.Plugin), но тогда у вас будет доступ к широкой области внутренних инструментов инструмента.

В последнее небольшое обновление версии (например, 1.2.3 ->1.2.4) разработчики инструмента переместились один класс перечисления в другой пакет - com.acme.foo.SomeEnum стал com.acme.bar.SomeEnum. Я думаю, что это считалось просто тривиальным рефакторингом, а не реструктуризацией сериалов.

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


Мой вопрос, если есть какой-то способ в Java для создания «псевдоним» com.acme.foo.SomeEnum для com.acme.bar.SomeEnum? Это позволит старым плагинам продолжать работу с новой версией инструмента.

Какой-то классный уловщик? В JavaScript, который был бы тривиальным для прокладки, но на Java?

Почему I Я прошу об этом. Я являюсь автором плагина Maven, который обертывает этот инструмент. Поэтому я мог бы легко добавить свой сахар к этому кофе, например, загрузчики классов и так далее. Если есть технический способ сделать эту работу, я бы мог сохранить большую часть экосистемы плагинов инструмента - по крайней мере для пользователей Maven.

Я связался с продавцом этого инструмента, но не уверен в успехе.

Просто чтобы понять - я я не поставщика инструмента в вопросе. Я (а) пишу плагины для инструментов (и не испытываю больших проблем с обновлением моих плагинов) и (б) я являюсь автором the-tool-maven-plugin, который позволяет выполнить Инструмент в сборках Maven. Я также много проконсультирую о Инструменте и забочусь о его экосистеме (есть много очень полезных плагинов).


Update

Конец истории: Разработчики инструмента приняли мои пункты во внимание, и решил вернуться изменения. Престижность для этого!

+1

TL; DR - Нет. –

+0

(За исключением, возможно, использования некоторых средств отладки.) –

+0

Является ли это частью времени компиляции, которую вы хотите, или временем выполнения (как в отражении)? –

ответ

4

Предлагаю использовать jarjar.Это инструмент, который позволит вам переупаковывать классы в библиотеке. Вы можете запустить это против последней версии инструмента и переместить класс SomeEnum в пакет, который не конфликтует с плагинами.

Документ Getting Started имеет пример с jaxen.jar, который, как представляется, имеет отношение к вашей ситуации.

+0

Вы имеете в виду, чтобы переупаковать * инструмент *? Очень интересная идея. – lexicore

+0

Да, это то, что я предлагаю. Я никогда не использовал его лично, но другие предложили это разрешить столкновения классов в Android (т. Е. Я считаю, что в ядре Android есть или есть какой-то код Apache). – EJK

+1

Очень хорошая идея. Это будет частично работать. Недостатком является то, что плагины, скомпилированные с * новой * версией The Tool, потерпят неудачу. Это только старый xor новый, не оба одновременно. Псевдоним (если возможно) мог бы позволить одновременно работать параллельно. – lexicore

Смежные вопросы