Дмитрий Кинаш

С точки зрения 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% бинарная совместимость всех структур. Вот библиотеки Протобуф и Авро
как раз для этого создавались.

Самое простое - это один метод помеченный аннотацией @Scheduled и второй метод с аннотацией @Async. Первый срабатывает по расписанию и вызывает второй для каждого счётчика.

Проблема решена обновлением драйвера в гипервизоре)

Основные направления тебе перечислили, немного дополню.
- есть очень сложный и очень старый энтерпрайз, например, банки. Бывают написаны на очень старой Java, говорят, даже 5 встречается :) Охренеть какая сложная предметная область. Тебе могут дать задание написать или исправить класс, а ты вообще в душе не шаришь что это и зачем. И так всю жизнь :)
- есть системы типа SAP, которые надо не писать, а адаптировать под конкретного заказчика типа Аэрофлота. Делается это путём прописывания логики работы уже готовой системы, а также написания своих плагинов, в т.ч. на Java.

Ну а если тебе нужен универсальный совет, то вот он:
- не знаешь что учить - учи Spring, вакансии не дадут соврать;
- обязательно познакомься с SQL - чтобы понимать не только JPA, но и "голые" запросы и уметь хотя бы немного в их оптимизацию;
- познакомься с фронтендом на базе фреймворка, самый популярный React, хотя бэкендерам лучше заходит Angular. Это позволит на практике понять как происходит взаимодействие бэк-фронт, ну и вообще - расширит сознание :)

С таким стэком и (желательно) домашним проектом искать работу будет легче и веселее :)
Удачи!

Надо было создать конфигурационный фаил где прописать эти маперы в бины )))