mayton2019

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

Вот из википедии. Как из положительного сделать отрицательное в формате ДК (дополнительный код).

int twos_compl_abs(int a) {
    if (a < 0) a = (~a) + 1;
    return a;
}

Инвертируем и добавляем единичку.

Для числа -100. Берем сначала по модулю. 100 - это 64 + 32 + 4

0110 0100

Инвертируем

1001 1011

И прибавляем 1

1001 1100

В хекс-системе тоже число будет

9C

Делаешь такой шаблон

SELECT * FROM `wp_s3cu_authorization_logs` WHERE 1=0

а потом к нему добавляешь строки. Если был активирован флажок windows - то добавляешь строку
OR os_id = 'windows10'

Эта строка просто не работает.

$where .= " AND {$table_prefix}`{$this->search_by}` LIKE '%{$this->search}%'";

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

У меня чаще бывало что не хватало слотов под HDD. И я чаще сожалел что не взял корпус побольше.
То не хватило места в ширину под Zalman-кулер (поперечной компоновки). Тоесть крышка не закрывалась.

Вобщем большой корпус - это очень хорошо. Еще лучше - корпус-штатив или конструктор как Antec
(такой уже не выпускается).

Нет недостатков у большого корпуса. Он как внедорожник с багажником. Просторный.

А если у вас в квартите мало места ... ну. .. это уже про другое вопрос.

Для первой задачи.

Ну тут надо просто перечислить чего есть.

range(0..1) = 2
range(2..3) = 2
range(4..5) = 2
range(6..7) = 2
range(7..9) = 3

2 * 2 * 2 * 2 * 3 = 48

48 вариантов будет. Ну это как камера хранения в которой все ручки имеют 2 положения и лишь последняя - 3 положения.

Ну для второй задачи проще. Будет скорее всего 25. Два поворотных переключателя на сейфе.
И всего 25 состояний замка.