Короч, если можно сматчить instance-метод, то он сматчится!

еще что заметил, если в сигнатуре collect не было бы Supplier, оно бы не матчилось, надо было бы параметризовать методы HashSet<Long>::add, HashSet<Long>::addAll

А с саплаером магически почему-то все само схватывается

Read the docs

В learn Java никто ничего не ответил. Наверное сюда кросспостну свой вопрос

Вопрос:
app1 -> lib1 -> lib2

app1 — разрабатываю я, на работе (jar'ник в Artifactory)
lib1 — тоже разрабатываю я (jar'ник в Artifactory)
lib2 — это какая-то/какие-то зависимости которые нужны для lib1 (например Guava или Unirest)

Запускаю код из lib1 в app1 и получаю NoClassDefFoundError. Вроде бы как всё верно, если я собрал lib1 не "жирным" JAR-ом. Варианта решения вижу два:

1. Добавить lib2 в зависимости app1 (Guava/Unirest) и всё работает сейчас.
2. Начать собирать lib1 в "жирный" JAR. Нагуглил ShadowJar. Вроде бы делает что надо.

Я правильно мыслю? Что будет если app1 будет юзать свою версию Unirest, а lib1 другую? Как такой конфликт резолвится?

Да и вообще насколько это плохая мысль внутреннюю библиотеку прибивать гвоздями к каким-то зависимостям. Ввиду отсутствия опыта на Джаве не могу придумать почему собирать жирные JAR'ники может быть плохо

Разобрался. По сути shadow jar мне и нужен для моих библиотек локальных. И конфликтов не будет при shadow сборке жирного jar

Что будет если app1 будет юзать свою версию Unirest, а lib1 другую?

если в classpath две версии класса то использоваться будет та что загрузиться первой

не понятно какая именно проблема решается, если либа подключена как зависимость то maven/gradle сам выкачает все ее зависимости

Что будет если app1 будет юзать свою версию Unirest, а lib1 другую?

Хм. Проблема в том, что я имплементул свою либу lib1. Собрал обычный не жирный jar. Пушнул в artifactory. Потом указал её в зависимостях в своём приложении app1.

Запускаю gradlew build, потом gradlew run, и получаю noclassdeffounderror в момент, когда происходят вызовы методов внутри lib1, которые используют lib2.

а собираете то fatjar само собой если вы компилите только код, то зависимостям ни вашим ни lib1 взяться не откуда, ибо в репозитории jar опять же только с кодом либы

в любом случае чекните есть ли нужные зависимости, если нету надо разобраться почему их там нету, по идее сборщик должен все зависимости разрулить

А, понял :) Спасибо

То есть идея собрать fatJar моей библиотеки lib1 при помощи этой тулзы shadowJar вполне нормальная. Перед пушем в репозиторий

Ну в библиотеке implementation прописаны. В app1 нет

Загуглить, так не делают так как все зависимости подтягиваются сборщиком

Хм. То есть чтобы зарезолвить зависимость из lib1 я её должен явно прописывать в build.gradle из приложения app1?

Мне уже несколько раз говорили, что gradle сам это резолвит, но я не понимаю как этого добиться. В classpath этого нет

Прошу прощения за такие вопросы. Мне интересен нормальный workflow у джавистов с такими вещами

Пойду гуглить дальше. В гугле говорят резолвит. У меня этот exception

Зависимости lib1 должна быть описаны в lib1

Это есть

Ладно. Днём попытаюсь сделать пример и воспроизвести это. Спасибо. Что-то не так с сетапом у меня