удобно вам?

Я думаю не я один где нибудь да использует в коде подобные вещи. Если нет - то ок. Это мое мнение, на абсолютное не претендует

передавать "параметры" в коде через system env — это, извините, извращение. они предназначены для других целей — чтобы при запуске можно было их устанавливать опцией -D

а если приходится в коде их устанавливать, потому что другого способа нет — надо бить того, кто проектировал API

конечно люди злоупотребляют. каждый первый, наверное, знает, что для указания пути к хромдрайверу надо установить свойство "webdriver.chrome.driver", так вот — это неправильно! так делать в коде не надо! системные свойства — для опции -D

а правильно так:

new ChromeDriver(new ChromeDriverService.Builder().usingDriverExecutable(....).build())

Возможно меня не так понял, или я не так понял, но я вот про это говорил (например с хромдрайверсервиса)
 public static final String CHROME_DRIVER_VERBOSE_LOG_PROPERTY =
     "webdriver.chrome.verboseLogging";

public static final String SELENIDE_BASE_URL = "selenide.baseUrl";

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

я с ними связался исключительно из-за того, что дефолтный SelenideConfig на них

за способ конфигурирования я селенид отдельно не люблю :)

а некоторые, наоборот, за него как раз и любят

чем богаты говорится. В общем взялся из-за того что SelenideConfig на них. Приходится делать агрегатор env / properties / еще одна ерунда. (Чтоб где нибудь да взял параметр). И вот пришлось копипастить "константы" стринговых параметров селенида, сопстно обычно эти вещи (как в хром драйвер сервисе, например) вынесены, решил написать. Пережить то переживу, но опять же - думаю не я первый кто этим занимается. Селенид это не ломает никак вообще. Ну и придется если там параметр добавится - добавлять тоже. мое желание было поделиться, может скажут "да, норм, сделаем" :)

ты чего-то велосипед изобретаешь имхо. что значит "SelenideConfig на них."?
зачем делать какой-то "агрегатор env / properties "

что значит "SelenideConfig на них."
private boolean headless = Boolean.parseBoolean(System.getProperty("selenide.headless", "false"))
=======
зачем делать какой-то "агрегатор env / properties "
Ну вот так вот, нюансы старой реализации. Это мой кейс (так что это не суть), общий кейс в том, что захочу я узнать значение selenide.remote вне конфига - придется писать свою хард стрингу

захочу я узнать значение selenide.remote вне конфига ну да. если тебе это нужно ты должен страдать

а зачем это узнавать, в самом деле?

Я не уверен что, стоит расписывать всю архитектуру моей прилаги, с её историческими велосипедами и кастомизациями, я ж сюда написал по теме selenide, а не - "сделай сам / стреляем себе в ноги". В кратце - чем больше кастомизации, тем больше костылей с ситуациями "нужно узнавать". Практика констант решила б проблему, и она вроде не незаконная. Я лишь поделился, так то все хорошо 👌

>Практика констант решила б проблему,
так проблемы нет, чтобы ее решать. эти константы нужны только вне кода. ради каких-то "историческими велосипедами и кастомизациями, " не думаю что нужно что-то делать))

понялпринял :)