Вот здесь описано. Поле Bcc (скрытая копия), в отличие от To (получатель) или Cc (копия), удаляется из сообщений, отсылаемых получателям. Можно спокойно в нём перечислить получателей - их не будет видно в полученных сообщениях. Можете проверить в любом почтовом клиенте.
Кстати, а вы уверены, что текст сообщения для всех пользователей один и тот же? Обычно сообщения начинаются с приветствия по имени. То есть сообщение для каждого получателя - индивидуально.
Да, GPLv2+ можно перелицензировать под GPLv3+ не являясь автором. Насчёт GPLv3 (без плюса) - это врядли, поскольку это уже дополнительное ограничение (не лицензировать по борлее новыми версиями).
Просто по логике. Обычно конструктор просто конструирует объект, но не выполняет никаких действий. Так, можно сконструировать диалог заранее, чтобы не тратить на это время EventDispatchThread и тем самым улучшить отзывчивость приложения.
Я не имел ввиду нечто столь общее. Если говорить о чате, то можно завести службу, которая принимает сообщения и хранит список (массив) последних. А контроллер просто отображает этот список. И не надо никаких слушателей - AngularJS самостоятельно перерисует список при получении нового сообщения и добавления его в список.
Служба содержит только логику. А ваш контроллер будет содержать логику + отображение. То есть будет заведомо тяжелее, вы не находите? Ну а о производительности и потреблении ресурсов придётся думать в любом случае. Никто не запрещает вам предусмотреть механизм остановки службы, если она вам уже не нужна.
А какая разница: "ленивый" он или нет? С какой целью вам необходима эта "ленивость"? Какую задачу вы решаете? Ведь в таком виде "одиночка" не нужен совсем.
Да дублирование всё равно возникнет. Как только потребуется что-то посложнее просто шаблонизации. В самых неожиданных местах. Я это к тому, что лучше не париться и определиться: либо рендерить на сервере, либо на клиенте. То, чего хотите вы - это дополнительные сложности и проблемы ради непонятных целей. Вам это не нужно (YAGNI).
Впрочем, можно воспользоваться профилировщиками. Посмотрите на Eclipse Memory Analyzer или jProfiler. JVM, очевидно, предоставляет для них некоторый интерфейс. Значит, можно попробовать использовать его самостоятельно. Нагуглилась вот такая статья в тему.
Именно так. Другого интерфейса нет и не будет. Невозможно определить список всех ссылок, не останавливая сборщик мусора. Практическая полезность данной функции для конечного пользователя нулевая, и даже отрицательная. Впрочем, посмотрите исходники - может там что-то такое есть, в отладочных целях например.
Остаётся вытащить .so в отдельную директорию и прописать её в java.library.path. Из сборки библиотеки удалить. Библиотеки, разумеется, должны быть только под одну архитектуру. В собранном проекте НЕ ДОЛЖНО быть библиотек для другой - будет конфликт. Если даже это не поможет, то придётся разбираться с тем, как они подгружаются. Смотреть исходный код, разбираться с велосипедом JavaCV для JNI.
Хм, JNI-библиотеки для javacv находятся в javacv-linux-x86.jar. По идее они должны быть доступны. Может, maven-shade-plugin их выкидывает? Посмотрите в финальном jar-файле. Кроме того, нужно учитывать, что загружаются эти библитеки нестандартным образом (в Java нет стандартной поддержки загрузки разделяемых библиотек из jar-архивов). Так что проще всего вытащить so-файлы оттуда и поместить в директорию, которая присутствует в java.library.path.