mayton2019

Для java11 имеет смысл отказаться от использования java.util.date в пользу java.time.LocalDate, java.time.ZonedDateTime. И использовать API из time для переводов локальных времен.

С точки зрения Java language, аннотации ничего не делают. Они - как каменты в коде. Но они могут быть подсказками для фреймворков которые в compile time, classloader или runtime могут что-то выполнить над кодом. 99%
это какие-то ORM/JSon подказки которые разъясняют фреймворку что делать. Например @Table(name="emp")
подсказка JPA то класс относится к таблице emp.

Ваш вопрос про либы Java/Kotlin слишком общий. Ничего конкретного нельзя сказать. Но по отношению к
Serializable, можно предположить что это гарантия что класс можно сериализовать во внешнюю память
(оперативная или диск) и это не нарушит никакой бизнес логики. Например это DTO которая полностью
самодостаточная. Не все сущности вообще реально сохранить. Некоторые сущности - как орграф опутывают
всю память Java и сохранять их накладно. Как корневой объект хипа. Дешевле дампнуть всю память чем
сохранять такие объекты поштучно. Некоторые - имеют связи с внешними ресурсами Files/Sockets и вне контекста они не имеют смысла. Есть ключевые слова языка (transient) которые запрещают сериализацию для полей.
Есть также проблема версионности для Serializable. Сохраненная структура не трекает ваши изменения
по коду уже после того как вы что-то сохранили. Грубо говоря это не JSON. Если вставили новое поле - можете
старый файл и не прочитать. В качестве маркера проблемы там заводят специальное поле типа versionId или
что-то такое. Просто для детектирования.

Если вы хотите иметь тотальный контроль над сохранением - то определяйте Externalizable и там будут 2
метода в которых вы контролируете Output/Input streams и сами пишете что сохранять и читать. А еще
лучше брать библиотеки Kryo/Protobuf/Avro e.t.c. У них еще и есть оптимизации по скорости и по сжатию.
Вы к этому придете эволюционным путем если будете писать систему где сохранение во вне - важно.

Сериализация во внешнюю память это огромная проблема когда мы пытаемся подружить разные
технологии (32-64 бит целые числа или разный порядок байт в машинном слове). Даже простое
сохранение даты или строки может быть ошибочным если вы сохранили в Java а пытаетесь читать в C++.
Нужна 100% бинарная совместимость всех структур. Вот библиотеки Протобуф и Авро
как раз для этого создавались.

Несмотря на то что java/c++ формально являются ООП языками, многие вещи
с перегрузкой у них реализованы по разному. В случае с методом sound в Java
скорее всего будет создано просто 2 метода (разные сигнатуры).

Есть несколько способов это сделать.

Использовать встроенную в Java машину Nashorn которая по идее реализует JavaScript. Там такое можно сделать.

Подключиться дебаггером к приложению запущенному в debug mode. Там по идее тоже можно выполнять какие-то команды на вычисление выражений и видеть результат.

Но сама идея влезать в работающее приложение - не очень хорошая идея. С точки зрения безопасности и надежности. Возможно те вещи что ты хочешь могут быть закрыты через Logging или JMX или заранее протестировать все кейсы JUnit тестами в оффлайне. Сам факт того что ты хочешь чего-то в runtime говорит
о нехватке тестового покрытия.

Еще посмотри на jschell. Может пригодится.

Добавь такой конструктор.

public AlarmService() {
        super();
 }

Тут описана проблема которая принципиально в Rest-сервисах не решена до сих пор.

Ее коробочное решение было реализовано в GraphQL. Но GraphQL - это не Rest. Это более
сложный и более умный протокол и он позволяет выбирать из entity ровно те поля
которые нужны для responce.

А в твоем случае надо просто в контроллере создать еще один метод. Типа getUserByIdShort