Ну или классический сонар с еблей

а какой лучше выбрать-то?

крч я взял pvs, спасибо

но вы не написали что она платная (

Ну так скажи своему начальнику

Ставь SonarLint

У PVS крайне бедная поддержка жабы, с кучей фонящих FP

Коллеги, помогите разобраться с архитектурой. Допустим я пишу браузерную игру Камень Ножницы Бумага на спринге. После авторизации пользователь попадает в лобби, где есть кнопка Поиск игры. По клику на кнопку, фронт дергает метод контроллера и сервер кладет его в очередь. Когда в очереди появляется второй игрок, начинается матч. Во время матча игрок не может попасть в лобби просто введя другой адрес в строке браузера, так же как и разлогинившись. Условия выхода это конец матча или кнопка Сдаться. Вот этот матч, это с точки зрения Спринга, что? Я должен как-то передавать сессию, или например добавить флаг isInGame в Entity, или как-то еще? Какое вообще правильное решение?

1. Игрок должен иметь возможность ливнуть с матча, иначе второй будет висеть вечно. Таймер надо сделать, чтобы ему засчиталось поражение, если он истечет.
2. При этом, если человек заходит заново, надо проверить нет ли у него сейчас актуальной игры, в которой он находится.

Ты можешь организовать простой кэш из map'ы, допустим, ID пользователя, лобби

Соответственно, получаешь лобби - получаешь информацию по игре

Это-то понятно, я имею ввиду игра это в спринге что? Там же луп должен быть, таймеры и т.п. это же не статика, как энтити. Этот while(true) где писать?

Нигде не писать while(true)

По таймерам. Нормальный вариант раз в секунду проходить по всем играм и проверять их таймеры.

Что такое игра. В данном случае думаю это класс с инфой об игроках и текущем статусе. Объекты лежат в простейшем случае в мапе, либо в каком-то персистентном или не персистентном хранилище

Если в памяти, то у тебя есть объект Игра/Лобби, у которого есть мета-информация, что-то типо Игрок1, Игрок2, счет, кто какой символ поставил.
И по поводу while, Дмитрий правильно пишет

Про вайл понятно, это будет скорее всего флаг isActive, который покажет идет игра или уже закончилась. Соответственно будет некоторый листенер очереди, который будет матчить игроков, как только появилось два, создается объект класса Game, в котром игроки, время начала матча и время до следующего хода. (В этот момент можно кстати создать объект Ход, содержащий время и айди игры и положить его в отдельную очередь, где отделный поток будет проверять поступили ли данные от игроков в данной игре) Обоим на фронт отправляется инфа из него. В объектах игроков помечается inGame: true и gameId. Фронт отрисовывает игру. Контроллер действий в игре работает только если inGame: true.

Так?

ИМХО тут 2 варианта - либо фронт через пуллинг опрашивает бэк (появилась ли игра?), либо через сокеты. Не нужен будет никакой while. Лист с играми - будет через пуллинг (ты в цикле просто проходишься и находишь свободную игру, а далее создаешь мапу, о которой писали выше),  id топика можно связать на сокетах (ты можешь на 1 топик подсосать 2-их игроков и всю информацию передавать там. Если произошел разрыв, ты можешь в SimpleUserRegistry (к сожалению не помню) найти в каком топике ты был и подключиться заново).

Если ты хочешь активный фронт, то логику работы с backend'ом строй там, а back - будет статичным.
Если ты хочешь "ленивый" фронт, который просто хочет отдать на откуп активному backend'у - тогда сокеты.

P.S. Все таки статичный можешь не так понять, поэтому ленивый 😊

Вот этот момент мне тоже не понятен. Под сокетами что ты имеешь ввиду? Держать постоянное соединение? Так как игра с одновременными ходами двух игроков, я думал на сервере хранить время следующего хода, а на фронте просто Post запросами отправлять ходы, результат же проверять, когда пришло время хода. Поэтому я думал хранить все ходы всех игр в одной очреди отсортированной по времени. Как-то так.