Как один из этих самых разработчиков, дополню комментарий Андрея попыткой объяснить, почему просмотр диффов — не больно.
Для начала: у нас нет самоцели «выпускать по N диагностик в неделю». Мы пытаемся брать качеством, а не количеством, и хотим, чтобы диагностиками было приятно пользоваться. Это я к тому, что время, затраченное на их реализацию, не столь критично (в разумных пределах, конечно).
Предупреждения почти всегда лежат на поверхности и нечасто требуют сверх-глубокого анализа. Самих диффов тоже не настолько много, насколько может показаться: вполне обыденной ситуацией являются 0-5 срабатываний для специфичных диагностик и 20-40 для более общих в момент отправки диагностики в master (да, по всем проектам селфтестера в сумме). Перед отбором признаков ложных срабатываний может быть и целая куча диффов (200+, например), но эти признаки, опять же, обычно лежат на поверхности и сильно в них всматриваться не приходится. После этого количество диффов начинает уменьшаться чуть ли не экспоненциально.
Основная боль процесса разработки — ожидание этих самых диффов, которое может занимать много времени. Но оно не требует нашего участия, и в это время можно:
Позаниматься документацией;
Пообщаться с командой;
Причесать код;
Поработать над другой диагностикой;
Отвлечься на написание статьи (вроде этой);
Поревьюить код/диффы товарища по команде;
И прочее.
Соотношение потраченного времени на просмотр диффов и на всё остальное (кодинг, документация, ...), по ощущениям, где-то 25/75.
Так в итоге-то разве ошибка не может возникнуть именно из-за некорректной ленивой инициализации сета, которая тут и не нужна вовсе? Два разных потока одновременно позовут isAnnotation и, пока один заполняет сет, другой возвращает ложно-отрицательный результат, увидев (полу)пустую коллекцию. Другое дело, конечно, если прокси засинхронизирует каждый вызов этого метода, но такой сценарий мне кажется сомнительным. Ну, или если метод гарантированно вызывается всегда из одного и того же потока.
Смысл этого примера, кстати, не в кидании камней в Глассфиш. Он тут исключительно для демонстрации диагностики и очень удачно совпало, что сразу попалось несколько ошибок в одном отрывке кода.
У меня return, кстати, уехал при форматировании не в тот блок, поправил.
А можно, пожалуйста, немного подробнее про магию? Глассфишем пользоваться не приходилось, но если, ткнув в потолок, предположить, что DI-контейнер вызывает метод init перед публикацией синглтона или прокси синхронизирует все обращения к isAnnotation, то очень странным выглядит вообще использование DCL. Причём сама реализация (прошу поправить, если не прав) этого паттерна некорректна — что как раз эта диагностика и рассматривает.
Для начала: у нас нет самоцели «выпускать по N диагностик в неделю». Мы пытаемся брать качеством, а не количеством, и хотим, чтобы диагностиками было приятно пользоваться. Это я к тому, что время, затраченное на их реализацию, не столь критично (в разумных пределах, конечно).
Предупреждения почти всегда лежат на поверхности и нечасто требуют сверх-глубокого анализа. Самих диффов тоже не настолько много, насколько может показаться: вполне обыденной ситуацией являются 0-5 срабатываний для специфичных диагностик и 20-40 для более общих в момент отправки диагностики в master (да, по всем проектам селфтестера в сумме). Перед отбором признаков ложных срабатываний может быть и целая куча диффов (200+, например), но эти признаки, опять же, обычно лежат на поверхности и сильно в них всматриваться не приходится. После этого количество диффов начинает уменьшаться чуть ли не экспоненциально.
Основная боль процесса разработки — ожидание этих самых диффов, которое может занимать много времени. Но оно не требует нашего участия, и в это время можно:
Соотношение потраченного времени на просмотр диффов и на всё остальное (кодинг, документация, ...), по ощущениям, где-то 25/75.
Смысл этого примера, кстати, не в кидании камней в Глассфиш. Он тут исключительно для демонстрации диагностики и очень удачно совпало, что сразу попалось несколько ошибок в одном отрывке кода.
У меня return, кстати, уехал при форматировании не в тот блок, поправил.