Конфликт имен: как разрешить?
 

Всем привет.
Столкнулся с проблемой. Пишу код, использовал в процессе библиотеку org.jsr107.ri. Пишу, отлаживаю, все хорошо. Через gradle оно замечательно запускается... собираю war-файл, скармливаю его томкату - и получаю эксепшн:

java.util.ServiceConfigurationError: javax.cache.spi.CachingProvider: Provider org.jsr107.ri.spi.RICachingProvider could not be instantiated
...
Caused by: java.lang.IncompatibleClassChangeError: Implementing class

Запускаю томкат с $JAVA_OPTS -verbose:class - вижу, что класс javax.cache.CacheManager загружается из файла appengine-api-1.0-sdk-1.9.57.jar.
При этом, в cache-api-1.0.0.jar есть интерфейс javax.cache.CacheManager. И если верить JSR107 - должен быть именно интерфейс.

Вопрос номер 1 - чтозанафиг?
Вопрос номер 2 - что с этим делать?
Если из файла appengine-api-1.0-sdk-1.9.57.jar удалить неугодные классы, или хотя бы переименовать его в zappengine-api-1.0-sdk-1.9.57.jar - все запускается. Но как-то это криво.

Как бы это получше обойти? Чтобы автоматизированно. Вручную в gradle переименовать файл? Может, есть способ указать порядок загрузки из WEB-INF/lib? Или загружать из jar не все файлы? Миграцию на джаву9 не предлагать.

если у вас томкат, то откуда 'appengine-api-1.0-sdk' ?

не понял вопроса. Разве они исключают друг друга?

Во-первых, его тянет spring boot.
Во-вторых, его тянут библиотеки для работы с гугловским oauth2, и еще штук 6 библиотек, которыми мы пользуемся.

ОМГ. Знаток ассемблера, ведь всего-то нужно "обернуть в свой намеспейс".

а можно поподробнее? Как это на джаве сделать? Подозреваю, что никак.

Обращаю внимание, что это не моя библиотека, и я не могу просто взять и переименовать класс\перенести его в другой пакет.

>Во-первых, его тянет spring boot.

наверняка не сам спринг бут, а бутстартеры, а они тянут много всякой фигни

в общем надо смотреть нужная ли эта библиотека, то что она тянется этого не означает

Я нашел ссылку на него в
spring-boot-1.5.2.RELEASE.jar!/META-INF/maven/org.springframework.boot/spring-boot/pom.xml
плюс еще в 5-6 библиотеках.

Ну да ладно. А если предположить, что отказаться от этой библиотеки я не могу. Что часть классов, уникальных для этой библиотеки, мне нужна, а остальные - нет.
Сейчас изучаю плагин для грейдла - fatjar (и в частности - применимость его к war-файлам), но все равно мне это кажется костылем.

[quote=Добрых дел мастер;44865845]Я нашел ссылку на него в[/quote]

Это плохо:

[code]<dependency>
<groupId>com.google.appengine</groupId>
<artifactId>appengine-api-1.0-sdk</artifactId>
<scope>test</scope>
</dependency>[/code]

Намекаю: scope=test - означает что зависимость не нужна в продакшене

А градл может подтягивать все зависимости, в зависимости от кучи нюансов.

1. Намек понятен. Но эта библиотека подтягивается и из других мест, которые нужны не только на этапе тестирования. Плюс, это только грейдлу\мавену понятен этот скоуп. А когда томкат загружает классы - кто первый по алфавиту, тот и молодец.
2. Вообще, вопрос в,
- какого хрена гугл нарушает спецификацию.
- какого хрена гугл кладет в свои библиотеки классы из совсем другого неймспейса (тут и без нарушения спецификации хватит конфликтов)
- Что в этом случае делать.
Мне кажется, хорошим решением было бы, если бы в gradle можно было указать, какие модули грузить, а какие нет.
Но это (если я все правильно понял) можно сделать только на этапе компиляции. Дальше он упаковывает исходные jar-файлы - и на этапе загрузки у нас куча не нужного.
Я поигрался с класслоадерами - лучше, чем переименовывать jar, но если честно - все равно костыль.
Кажется, в этом должна помочь jigsaw?

>Но эта библиотека подтягивается и из других мест, которые нужны не только на этапе тестирования. Плюс, это только грейдлу\мавену понятен этот скоуп.

всё не так, этот скоуп означает, что библиотека нужна только для тестирования spring-boot. То бишь пользователю spring-boot [b]она не нужна[/b]. Это важно. Это означает, что в релизном наборе библиотек её вообще не должно быть по этой зависимости.

И единственный верный путь - это нырнуть в этот dependency hell (т.е. почитать про мавен, его скоупы и то как на всё это ложил гребанный градл с пробором) и разобраться какого хрена (и по какой зависимости) она пролезает в финальную сборку.

вот, как раз этим и занимаюсь.
Если честно, пока тяжеловато дается.

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

а сбор проекта - это вообще квест в квесте...
спасибо тебе боженька за это!

А что не так? Можно пару примеров, чем шарп в данной ситуации лучше?

Ну и время идет, джава меняется. Давно это было?
Вон и с этой проблемой со сборкой должен помочь jigsaw, правда подробно не изучал.

столько технологий только для того, чтобы собрать проект..
проблема жабы в ее преимуществе.
именно ее обратная совместимость рождает таких мутантов как соуты, или, к примеру, чтение из буфера:
try(BufferedReader br = new BufferedReader (new InputStreamReader(System.in));
BufferedWriter bw = new BufferedWriter(new FileWriter("D:\\notes5.txt")))

этим кодом сотону вызвать можно.

и так в джаве везде.