Вы говорите в о вашем отчете об ошибке в IntelliJ , « Я удивлен, что никто не обнаружил это ».Вероятно, причина, по которой он не появился, в том, что то, с чем вы сталкиваетесь, не является проблемой в реальном мире.
Я думаю, что настоящая проблема может заключаться в понимании печально известной природы загрузки классов вJava.
Загрузка классов должна работать как на системном уровне , так и на уровне приложения.Class.forName(String)
действительно работает на системном уровне.Но вы как бы отталкиваете системный уровень от уровня приложения с помощью этого вызова на Class
.
Ограничения API / реализации Gradle применяются только на уровне приложения.Не на системном уровне.Вне контекста запуска сборки Gradle, Gradle не может навязать ограничения на то, как сама система загрузки классов Java предназначена для работы.
Как будто у меня не должно быть доступа к регистру инструкций процессора моего компьютера.из приложения текстового процессора.Но это не значит, что операционной системе нужно каким-то образом запретить взаимодействие с процессором.
В вашем случае ваш класс net.me.consumer.Main
является текстовым процессором «» «.org.apache.commons.csv.CSVFormat
и org.apache.commons.codec.Decoder
аналогичны инструкциям в процессоре.И java.lang.Class
аналогичен операционной системе.
Вы не можете получить доступ к ЦП напрямую из вашего текстового процессора.Тем не менее, вы можете делать вещи в текстовом процессоре, которые заставляют ОС взаимодействовать с процессором.Вы делаете нечто аналогичное этому с Class.forName(decoderClazzName)
.
Та же самая « утечка », которую демонстрирует ваш проект, воспроизводима и в Eclipse.А также в Visual Studio Code.На самом деле, я могу добавить это к вашим Main
и MainTest
классам вашего потребительского проекта:
org.apache.commons.codec.Decoder decoder = new Decoder() {
@Override
public Object decode(Object source) throws DecoderException {
// TODO Auto-generated method stub
return null;
}
};
Eclipse не только позволяет это,это автоматически создает это для меня.Плюс он добавляет необходимые операторы импорта, и я даже не спрашиваю об этом.И очень быстро и счастливо компилирует это без проблем и жалоб.Несмотря на то, что в build.gradle
.
не определена зависимость от commons-codec
, определенная в вашем потребителе.вы получите те же результаты в этой или любой другой Java IDE.
Как вы сообщали об ошибке в IntelliJ, вам также нужно будет сообщать об ошибке в каждую Java IDE, каждый сервер приложений на основе Java.каждый компилятор на основе JVM и так далее.
Я не думаю, что разумно ожидать, что каждый поставщик программного обеспечения в экосистеме Java будет соблюдать ограничения, определенные одним единственным инструментом управления зависимостями.Независимо от того, как слон им нравится думать, что они есть;)