Нет, не так. В джаве захотел ты подрубить Хибернейт. Зашел на мавен централ или на ДжейБоссовский репозиторий - а там миллион пакетов, в которых одни и те же классы запаблишены. Причем набор классов в разных джарах разный, потому что люди бандлят несколько зависимостей вместе и паблишат это рядом. И в зависимости от того, какой у тебя application server, через какой апи ты хочешь с хибером работать, что у тебя помимо хибера используется, тебе подойдет какой-то конкретный вариант джарника.
Ок, удобно, клево! О нас заботятся. Ага, щаз! На деле обновляешь ты какую-то левую зависимость, а она решила, что в новой версии джарника она теперь будет бандлить еще какие-то классы, которые раньше не бандлила. И внезапно в твоем правильно собраном супчике зависимостей у тебя дублировние классов, которого раньше не было. И ты опять лезешь подбирать джарочки, пока билд не начнет работать.
Поэтому обновлять зависимости в JVM-мире никто не любит. Люди копипастят свои sbt/gradle/maven скрипты со старыми зависимостями, тк знают что эта комбинация работает. Или пишут всякие “генераторы проектов” (jHipster помнишь?) чтобы те за них делали эту работу.
Что сделал npm, и что потом подхватил Rust, Deno, и наверняка еще кто-то - это разделил пространство резолюций зависимостей, так что иметь разные версии транзитивных зависимостей стало возможно.
В npm и cargo я регулярно бампаю версии, тк знаю, что мне ничего не грозит - код мой продолжит работать. В cargo есть момент с зависимостями на C/C++ библиотеки - там dll-hell продолжает присутствовать. Но в живом проекте их единицы.
И да, есть миллион шуток про размер node_modules, но лучше иметь 300 мегов зависимостей, чем плавить мозг jar-hell-ом
