всё так. я специально акцентирую внимания про большие и крупные компании. я имею в виду какие-то здоровые нагромождения продуктов, в которых ещё дохуя всякого "исторически сложилось", типа сбера, яндекса, втб, газпрома итд. кровавый тырпрайз. сюда же идут всякие ритейлы и прочие конторы, которые вроде бы небольшие по ИТ, но столько нацепляли за свою жизнь подрядов и коробок, что теперь это просто так не разгрести

Уже писали о WebUSB?

ну там хотят не только к usb дать доступ, а чуть ли не ко всему

оказывается, кложа не одна. есть ещё вооружённый медведь, и не сказать что он заброшен (послдение обновление месяц назад)
https://abcl.org/

какие могут быть аргументы против установки листенеров в конструкторе Java-классов?

мне вроде бы видно, что это не ок, но почему это не ок - черт его пойми.

А где лучше?

произвольное количество лисенеров ты через конструкор не установишь

а если хардкод на один, то даже хз

то, что надо будет всё равно делать метод переустановки (или добавления) лиснера для гибкости логики?

Имхо, при передаче в конструкторе у тебя идёт негласная завязка на то, что слушатель будет слушать и работать всё время жизни объекта.

Но сам по себе подход слушателя подразумевает возможность отмены, переподписки, изменения слушателя.

На этой ноте как-то не соответствуют подходы.

> Но сам по себе подход слушателя подразумевает возможность отмены, переподписки, изменения слушателя.

Конкретно observer pattern подразумевает, да. Лиснеры в целом бывают разные, не уверен, что они обязаны быть заменяемыми.

Даже если отбросить замену — они должны уметь отписаться.

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

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

Кому именно они должны это уметь?

Тем, кто подписывается на него. Иначе слишком легко поломать подписку, даже не заметив этого.

class X(private val listener: Listener)

val l = Listener()
val x = X(l)
// ...
l.cancel()
// x ещё живёт и шлёт события вникуда

что за логика у метода cancel? как это должно работать?

Тож не понял пример. У меня сто лет лиснеры в коде — это функциональные типы, за редкими исключениями, где таки нужен интерфейс с несколькими методами, и я не помню, чтобы в нём надо было cancel заводить какой-то.

Делай отмену как хочешь.
Можешь её внутри X сделать.

Суть в том, что передавая слушателей исключительно через конструктор у тебя теряется гибкость в работе со слушателями.

Единственный нормальный кейс который я вижу — это передача лямбды как слушателя, чтобы она просто жила вместе с объектом.

Если мне нужна возможность заменять или убирать их — делаю var и наллабл при надобности. Не нужна — не делаю. А тут оказывается, лиснеры кому-то что-то обязаны!