Запуск в режиме формирования строк к покрытию не должен зависеть от наличия EDT

[yukon39]

При запуске в режиме формирования строк к покрытию, не должны проверятся/подгружаться модули EDT.

Сейчас если не установлена EDT (нужны для сбора покрытия), то нет возможности отдельно получать расчет строк к покрытию.

[asosnoviy]

Поправка на то , что нужные jarrники можно подложить и без установки едт. ИМХО лучше всегда подкладывать их, независимо от установки едт

[nixel2007]

на мой вкус кейс @yukon39 действительно имеет место быть. классы же загружаются лениво, вполне можно поддержать такой сценарий работы с runtime-зависимостями

[asosnoviy]

@nixel2007 приму в дар что нить, что бы понять о чем ты =) если оно после этого ещё и билдиться на га начнет, будет двойной профит

[yukon39]

@asosnoviy Или как вариант отдельный jar-ник для подсчета строк покрытию.

[nixel2007]

@asosnoviy помнишь, как в entity идет динамическая загрузка sql-коннекторов в зависимости от окружения? когда в одной реализации коннектора используется библиотека sql, а в другой - работа с информационной базой от оскрипт.веба.
этот прием основан на принципе загрузки-по-требованию. пока класс (в случае оскрипта - библиотека) нигде не импортируется, не происходит и его инициализация.

Классы загружаются в оперативную память и инициализируются класс-лоадером только в том случае, если они явно запрошены. В обратном случае они просто валяются в виде class-файла в жарнике и еды не просят.
Запрошены они могут быть несколькими способами.

1. Самый простой - импортировать класс через секцию import. В этом случае от точки входа в приложение (где main-метод) строится огромное дерево зависимостей классов по их связям в импортах. каждый класс что-то импортирует, это уходит на класс-лоадер, класс-лоадер загружает класс, который что-то импортирует and so on. В этом случае если до класса, который использует зависимости edt, есть прямая цепочка от точки входа, мы получим ClassNotFoundException (конечно же, в случае отсутствия жарников едт в classpath).
2. Но есть и другой вариант - рефлексия. в навороченном варианте - это, например, спецификация Service Provider Interface (https://www.baeldung.com/java-spi) на пару с ServiceLocator, или тот же спринг. Но есть и самый простой способ - метод Class::forName https://doc.bccnsoft.com/docs/jdk8u12-docs/api/java/lang/Class.html#forName-java.lang.String-

Я не смотрел реализацию cli-диспатчинга в coverage41c, но думаю, что не составит труда заменить прямые импорты реализаций подкоманд на загрузку нужных классов через рефлексию. Таким образом классы снятия замера, которые зависят от библиотек едт, будут загружаться только в том случае, если указана команда по работе с замерами. А в случае получения строк к покрытию управление будет уходить на классы без прямых импортов edt. Для удобства и надежности можно ввести промежуточные интерфейсы, чтобы методы классов подкоманд дергать не через рефлексию и method.invoke(), а через обычный вызов методов после явного каста полученного инстанса лениво загруженного класса к нужному интерфейсу.

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

[asosnoviy]

@nixel2007 Огромное Спасибо!